Scan for secrets - Endor Labs Documentation

Run endorctl scan --secrets to scan for leaked secrets in your source code. You can also scan for secrets with monitoring scans and CI scans. Ensure that you select Secrets as a scan type when you install the Endor Labs App for your SCM to scan for secrets during monitoring scans. The following table lists the options available with endorctl for secrets scan.

Scan methods

You can perform the following types of scans to detect secrets:

Scan a specific code reference: Scan for secrets only on a defined path in the context of a checked-out branch, commit SHA or tag to identify secrets and raise findings. This helps you to identify secrets that are leaked in the context of what you are working on right now.
Scan complete history: Scan for secrets in all existing branches or tags to identify if a secret has ever been leaked in the history of the project and raise findings. This helps you to identify if any secret has ever been leaked even if it was not leaked in the context of what you are working on right now.
Scan pre-commits: Scan for secrets in the code before committing the code to your repository during the automated pre-commit checks. This helps you identify and remove sensitive information from your code files early in the development life cycle.
Scan with custom rules offline: Include the custom secret rules from your namespace in a --pre-commit-checks or --local scan by exporting them to a file, without connecting to Endor Labs.
Scan changed files only: Limit a secrets scan to the files that changed to speed up pre-commit and pre-merge workflows.

Scan a specific code reference

By default, a secrets scan searches the files in the path where you start the scan. Run the following command in the directory of the code reference to scan for secrets.

endorctl scan --secrets

--dependencies runs a separate dependency scan, not a secrets scan option. To run both in one command, combine the flags: endorctl scan --secrets --dependencies.

Scan complete history

You can scan the Git logs by using the complete history scan. The repository should be present in the scanned path. Endor Labs examines the entire repository history to search for secrets. To perform a complete scan, include the --git-logs option in the command line.

endorctl scan --secrets --git-logs

Add --dependencies to also run a dependency scan in the same command.

endorctl scan --secrets --git-logs --dependencies

The --git-logs option scans the repository’s Git logs using the following logic:

Perform a full scan if it is the first time the repository’s Git log history is scanned.
Perform a full rescan if a change has been detected to any of the rules in the namespace.
Perform an incremental scan based on the last time a scan was performed in all the other cases.

Run the following command to force a full rescan if any of the detected secrets are no longer valid, and you want to accurately reflect the state of the secrets.

endorctl scan --secrets --force-rescan

You can combine --force-rescan with --dependencies in the same way.

endorctl scan --secrets --force-rescan --dependencies

Scan pre-commits

You can check for secrets before committing the code to the repository as part of pre-commit hooks. You must install and initialize endorctl before scanning the pre-commits.

Create a .git/hooks/pre-commit file at the root of your Git repository to configure the pre-commit hook. It runs automatically when you make a commit and looks for secrets in your commit.
```
cd .git/hooks
touch pre-commit
```

Edit the .git/hooks/pre-commit and include:

#!/bin/bash
#
# Script invoked on git commit.
#
if ! endorctl scan --pre-commit-checks --secrets; then
   echo "Pre-commit checks failed"
   exit 1
fi
echo "No secrets found: Pre-commit checks succeeded"

--pre-commit-checks scans only the changes you are about to commit to the repository.

Set the file permissions to make it executable.
```
chmod +x .git/hooks/pre-commit
```
You can’t push the .git/hooks/ folder to the Git repository because it’s only recognized locally on your system. To include the pre-commit code in the Git repository, save it in a different location, like a hooks/ directory, and then copy it into .git/hooks/. This way, you can push the hook code to your Git repository.

You can set up this hook on other systems in your organization by creating a script and running it on each system.

sh setup-hooks.sh
#!/bin/sh
# Copy all hooks to .git/hooks
cp hooks/* .git/hooks/
chmod +x .git/hooks/*

Here’s an example output when no secrets are found.

Here’s an example when secrets are detected and the commit fails.

Scan with custom rules offline

By default, --pre-commit-checks and --local scans use the secret rules built into the endorctl binary. They run fully offline but do not include the custom rules in your namespace. To use your namespace rules offline, export them to a file and pass that file to the scan.

Export your rules to a YAML file.

endorctl api list -r SecretRule -o yaml --list-all > secret-rules.yaml

Run the scan with the exported file.

endorctl scan --secrets --pre-commit-checks --secret-rules-file secret-rules.yaml

The file replaces the built-in rules for that scan. The scan stays offline and needs no API key. Re-export the file after you upgrade endorctl, because the scan rejects a file whose schema does not match the running binary.

Scan changed files only

Use --diff-scope to limit a secrets scan to files that changed, which speeds up scans in pre-commit and pre-merge workflows. The flag requires endorctl v1.7.1040 or later and accepts two values:

local: Scan files with local edits, including staged, unstaged, and untracked changes, against the current HEAD.
baseline: Scan files that changed against the repository default branch.

Endor Labs reports only secrets on lines that the change adds or modifies. Untracked files are new, so all findings in them are reported. Run the following command to scan only the files changed against the default branch.

endorctl scan --secrets --diff-scope baseline

--diff-scope cannot be combined with --pre-commit-checks, --local, --git-logs, or --force-rescan, because each of those modes defines its own scan range.

Exclude false positives from secret scans

A scan can flag a value that is safe, such as a test credential or an example token. Endor Labs offers three ways to suppress a false positive, from the narrowest to the broadest.

Annotate a safe line

Add an endorctl:allow comment to mark a non-sensitive line, such as a test value.

# These are test credentials, safe to commit
username = "test_user"  # endorctl:allow
password = "test_password"  # endorctl:allow

Allowlist a pattern in a rule

To exclude a known false positive from every scan of a rule, add an allowlist to the rule. Allowlists match on content, path, commit, or stop words. See Allowlists.

Dismiss a finding

To suppress an individual finding after a scan, create a finding exception. Exceptions are managed through finding policies. See Finding policies.

Scan for secrets using regular expression

Endor Labs scans for secrets based on regular expressions that are designed to detect the presence of a secret. It then validates the discovered secrets against external APIs to identify if they are valid. Valid secrets actively provide access to a service or an application and can be used to gain unauthorized access. Regular expressions are customized to match specific types of secrets, such as GitHub personal access tokens, OAuth access tokens, AWS access tokens, OpenAI keys, Client IDs, Client Secrets, and more. For example, you can describe a GitHub Personal Access Token with the following regular expression.

github_pat_[0-9a-zA-Z_]{82}

​Scan methods

​Scan a specific code reference

​Scan complete history

​Scan pre-commits

​Scan with custom rules offline

​Scan changed files only

​Exclude false positives from secret scans

​Annotate a safe line

​Allowlist a pattern in a rule

​Dismiss a finding

​Scan for secrets using regular expression