Secrets scanning in the Snyk CLI

Use Snyk Secrets for the CLI to identify and manage sensitive information (API keys, passwords, tokens) in your source code. You can:

1. Scan your current directory for hard coded secrets.

2. Ignore findings.

3. Scan and review ignored secrets.

4. Exclude files and directories from a scan.

5. Scan with a pre-commit hook.

Prerequisites

To use this feature, you must:

1. Install the latest version of the Snyk CLI. For installation instructions, visit Install the Snyk CLI.

2. Authenticate your machine with the following command:

snyk auth

If you receive a SNYK-CLI-0016 error, contact your Snyk account manager to enable the Secrets feature for your Organization.

Run a secrets scan

To scan your current directory for hard-coded secrets, run:

snyk secrets test

To map results to your Organization, include the --org option.

snyk secrets test --org=<your-org-id-or-name>

The output includes the following information:

• Severity: Snyk assigns a severity level to each finding based on the type and risk of the exposed secret.

• Finding ID: A unique identifier for the specific leak. You need this ID to ignore findings.

• Path and line number: The locations of the discovered secret in your codebase.

Ignore findings

If a secret is a known placeholder, a revoked key, or a won't fix scenario, use the ignore command to suppress the finding.

To ignore a finding:

1. Copy the Finding ID from the snyk secrets test output.

2. Run the ignore command:

   snyk ignore create

3. Follow the prompts:

   • Finding ID: Paste the ID you copied.

   • Ignore Type: Select wont-fix, not-vulnerable, or temporary-ignore.

   • Expiration: Set an optional expiry date (YYYY-MM-DD).

   • Reason: Provide context (for example, Key has been rotated and is no longer active).

Review ignored secrets

Use the --include-ignores option to run a scan and view suppressed items. This helps you audit your codebase and ensures you do not hide critical leaks.

snyk secrets test --include-ignores

Exclude files and directories from a scan

Exclude the paths that you do not want Snyk Secrets to scan, such as test fixtures, vendored dependencies, or sample credentials. Snyk applies the exclusions before the scan, so excluded files are not uploaded to Snyk and produce no findings.

Excluding a path is not the same as ignoring a finding. Snyk does not scan excluded paths at all, so they produce no findings and do not appear in the Snyk Web UI as ignored issues. To suppress a specific finding but continue to scan the file, use ignores instead. Visit Ignore findings.

You can exclude paths in the following ways:

• Commit a .snyk file to your repository. Snyk recommends this approach, because everyone who scans the repository shares the exclusions, and Snyk also applies them when the repository is scanned through an SCM integration. Visit Exclude paths using the .snyk file.

• Use the --exclude option for a single scan. Visit Exclude paths for a single scan.

Snyk Secrets also skips the paths listed in your .gitignore files, as well as file types that cannot contain readable secrets, such as binaries, archives, media files, fonts, and dependency lockfiles.

Exclude paths using the .snyk file

The .snyk file is a YAML policy file that you commit to your repository. The snyk secrets test command applies the patterns from the following exclude sections of every .snyk file it finds in the scanned directory tree:

• global: Applies to Snyk Secrets and to the other Snyk products that support the global section.

• secrets: Applies to Snyk Secrets only.

The following example excludes the vendor directory from all the supported Snyk products, and excludes the PEM test fixtures and the examples directory from Snyk Secrets only:

# Snyk (https://snyk.io) policy file
exclude:
  global:
    - vendor/**
  secrets:
    - "fixtures/**/*.pem"
    - examples/**

• Snyk Secrets applies the global and secrets sections only. It does not apply the code and iac-drift sections, which apply to Snyk Code and Snyk IaC.

• Patterns follow the .gitignore pattern syntax and are relative to the directory that contains the .snyk file. A pattern such as fixtures/ matches at any depth below that directory; start the pattern with a slash, for example /fixtures/, to match only at the level of the .snyk file. Absolute paths are not supported and are skipped.

• Wrap any pattern that begins with a special character, such as an asterisk (*), in double quotation marks.

• If Snyk cannot parse a section of the .snyk file, it skips that section and applies the remaining sections. If it cannot parse the file at all, the scan continues without the exclusions from that file.

For the full exclusion pattern syntax and formatting rules, see Exclusion syntax of the .snyk file.

Exclude paths for a single scan

Use the --exclude option to exclude directory names and file names for one scan, without committing anything to the repository. Provide a comma-separated list of names, without paths:

snyk secrets test --exclude=fixtures,secrets.example.yaml

This excludes every directory or file with a matching name, at any depth, for example ./fixtures and ./src/fixtures.

Scan with a pre-commit hook

Run Snyk Secrets as a pre-commit hook to catch secrets before they reach a commit. The hook keeps secret detection in the developer workflow and prevents new secrets from entering the repository.

Authenticate the hook

The secrets test command must run as an authenticated CLI command. Each developer authenticates their own CLI locally.

Authenticate in one of two ways:

• Run snyk auth to use your local Snyk credentials.

• Export SNYK_TOKEN in your shell environment.

Do not embed a token in the hook command

Do not embed a token in the hook command, for example SNYK_TOKEN=... snyk secrets test. The repository stores and shares hook configuration, so anyone with repository access can copy an embedded token. The token can leak into logs and get flagged by future scans. Keep credentials out of the repository and have the CLI read them from local auth state or SNYK_TOKEN.

Pass staged file paths

Pass the staged files to Snyk instead of scanning the whole project. Scanning the full repository on every commit is slower, can block unrelated commits on pre-existing findings, and makes it harder to tell whether a failure came from your change or from older files.

The secrets test command accepts only one file per invocation. For this reason, the following hooks loop over the staged files and run the command once per path, tracking the worst exit code, instead of passing all files at once.

Set up with the pre-commit framework

Add a local hook to .pre-commit-config.yaml:

repos:
  - repo: local
    hooks:
      - id: snyk-secrets
        name: snyk secrets test
        entry: sh -c 'status=0; for path do snyk secrets test "$path"; rc=$?; if [ "$rc" -ne 0 ]; then status="$rc"; fi; done; exit "$status"' --
        language: system
        pass_filenames: true
        stages: [pre-commit]

With pass_filenames: true, pre-commit appends the staged files to the command. The shell wrapper preserves the blocking behavior by exiting non-zero when any scan fails.

Use other hook managers

The same pattern works with other hook managers: collect the staged files and pass them to secrets test.

Raw Git hook

Add the following to .git/hooks/pre-commit:

#!/usr/bin/env sh
files="$(mktemp)"
status=0
git diff --cached --name-only --diff-filter=ACMR > "$files"
while IFS= read -r path; do
  snyk secrets test "$path"
  rc=$?
  if [ "$rc" -ne 0 ]; then
    status="$rc"
  fi
done < "$files"
rm -f "$files"
exit "$status"

Husky

Add the following to .husky/pre-commit:

#!/usr/bin/env sh
. "$(dirname "$0")/_/husky.sh"
files="$(mktemp)"
status=0
git diff --cached --name-only --diff-filter=ACMR > "$files"
while IFS= read -r path; do
  snyk secrets test "$path"
  rc=$?
  if [ "$rc" -ne 0 ]; then
    status="$rc"
  fi
done < "$files"
rm -f "$files"
exit "$status"

Lefthook

Add the following to lefthook.yml:

pre-commit:
  commands:
    snyk-secrets:
      glob: "*"
      run: sh -c 'status=0; for path do snyk secrets test "$path"; rc=$?; if [ "$rc" -ne 0 ]; then status="$rc"; fi; done; exit "$status"' -- {staged_files}

Hook managers vary in how they handle placeholder behavior, such as spaces in filenames and empty file lists. Check the documentation for your specific hook manager.