Secret detection

Every av sast scan hunts for hard-coded secrets - API keys, access keys, private keys, passwords, tokens - and tiers what it finds REDYELLOWGREEN like every other finding.

What runs

More than one scanner in the series looks for secrets:

• A dedicated secret scanner walks the working tree in directory mode - the files as they exist on disk at the scan path.
• The infrastructure scanner runs its secret checks alongside its misconfiguration checks in the same filesystem pass.

Both run locally as separate, checksum-verified subprocesses; your source never leaves the machine. See Code scanning (SAST) for how the scan series is downloaded, pinned and cached.

How findings are bucketed

On the Code Scan page a finding lands in the Secrets category when:

• it came from the dedicated secret scanner - always treated as a secret, or
• its rule or message matches a credential pattern (secret, credential, API key, access key, private key, password, token) - so a code-scanner hit on a hard-coded password buckets as a secret too.

Tiering

Secret findings use the same SARIF-to-tier mapping as all SAST findings: a security-severity score of 7.0 or higher is RED, 4.0 or higher is YELLOW; without a score, SARIF level error maps to RED and warning to YELLOW. The full mapping is on Code scanning (SAST).

Gate your CI

Run the full scan series in your pipeline and fail the build on any RED finding. Secret findings are tiered alongside every other finding, so one gate covers a leaked credential and everything else the series detects:

av sast scan --path . --fail-on red

Caution

A secret that has ever been committed is compromised. Rotate the credential - deleting the line, the file, or even the commit does not un-leak it.

Only git-tracked files

Local scans only raise secret findings for files git tracks (the git index - tracked or staged). A local .env that is gitignored and never committed is not a leak, so it is never flagged. A file that IS tracked stays flagged even if it was later gitignored - it is still in the repo. Outside a git work tree the filter cannot run, so every file is considered and the scan summary says so.

Never de-escalated

Secret findings never receive a reachability verdict: a leaked credential is exploitable by existing in the repo at all, dead code or not. They always keep their full engine severity.

False positives

Three ways to silence a false-positive secret - two repo-side, one from the dashboard:

• an inline // alertavuln-ignore comment on the flagged line (repo-side, versioned), or
• an .alertavuln-ignore path prefix (repo-side, versioned), or
• the Ignore button on the finding’s card on the Code Scan page (dashboard-side, no commit).

The dashboard Ignore applies a permanent suppression keyed to the finding’s fingerprint, so it survives re-scans and repo-URL changes. It drops the finding from the open list, the severity counts, the OWASP scorecard and alerting - without touching the finding’s Open/Fixed lifecycle (the scanner keeps tracking it). Ignored findings move to the Ignored filter on the Code Scan page, where each shows its reason and an Un-ignore button that restores it. Ignoring is audit-logged and needs the scans-manage permission.

Prefer a repo-side // alertavuln-ignore when the false positive is intrinsic to the code - a test fixture, a documented example key - so every clone agrees without a dashboard round-trip. Prefer the dashboard Ignore when you want to clear a finding without committing to the repo.

Note

The Ignore action is scoped to secret findings today. Other finding types clear only when the scanner stops reporting them (or, for code findings, when reachability de-escalates them).

See also

• Code scanning (SAST) - the scan series, tiering and local-first design
• av sast scan - run a local scan
• IaC misconfiguration - the other half of the infrastructure scanner’s pass