Securing the Secrets Scanning Tool Itself

A secrets scanner is built to find live credentials, so its own findings database, its read access to every repository and its pipeline tokens make it one of the richest targets in the software estate. Few programmes ask who can read the findings or who can quietly add an allowlist entry that hides a leak. This vendor-neutral guide covers the scanner as a system to be secured: what it holds, its admin roles, the service accounts and tokens it runs on, how findings and rules are protected, how it behaves inside CI/CD, and how to log, run and retire it. It is written for application security, platform and identity teams who own scanning, whether the scanner is a hosted service, a self-hosted server or an open-source command-line tool running in pipelines. For how scanning itself works, see the Git Secret Scanning Guide.

Key takeaways

The findings store is a secrets store. Most scanners keep the matched value, or enough of it to use, next to the file path and commit, so read access to findings is read access to every leaked credential that has not yet been revoked.
Scanner tokens are broad by design. An integration that reads every repository, history included, is one of the widest read grants in source control, and it deserves the care given to a privileged account.
Rules, allowlists and dismissals are security settings. Whoever can add an exclusion, lower a severity or close an alert can make a real leak invisible, so those actions need separation of duties and an audit trail.
Validity checks send your secrets somewhere. Testing whether a found key is live means presenting it to the issuing service from a scanner host; decide which secret types may be verified, from where, and with what logging.
In pipelines, the scanner is untrusted code with access to secrets. Pin its version, verify its integrity and give the scanning job no more credentials than reading the code requires.

What the scanner holds and can do

Product shapes differ, but every secrets scanning deployment has the same parts. Each one carries its own identities and its own data.

Component	What it holds or does	Identities involved	Primary hardening
Findings database and alert queue	Matched secret values or fragments, file paths, commits, authors, validity status	Scanner service account, database or storage account, analysts	Encryption at rest, masked display, role-based read access, retention limits
Source control integration	Reads code and full history across organisations; may comment on pull requests or block pushes	App installation, bot account or access token	Read-only scope, per-organisation installation, no write to code
Pipeline scanning step	Runs the scanner binary or container inside CI jobs	Job token, runner identity	Pinned and verified tool version, minimal job permissions
Other connectors	Scans chat, wikis, ticketing, container registries and object storage	API tokens and OAuth grants per source	One credential per source, read-only, inventoried with owner and expiry
Validity checking	Presents found secrets to issuing services to test whether they work	The found credentials themselves, scanner egress	Per-type opt-in, fixed egress, logged calls
Rules, allowlists and baselines	Decide what counts as a finding and what is ignored	Rule authors, platform administrators	Version control, review before change, change alerts
Notifications and outbound integrations	Sends alerts to chat, ticketing, SIEM and webhooks	Webhook secrets, ticketing and SIEM tokens	Mask secret values in every outbound message

The relevant MITRE ATT&CK techniques show why this matters. An attacker who reads the findings store gets the same result as T1552.001 Credentials In Files across the whole estate, without searching. A stolen scanner integration token is T1528 Steal Application Access Token with organisation-wide read. A tampered scanner release is T1195.002 Compromise Software Supply Chain, and suppressing detection maps to T1685 Disable or Modify Tools.

Admin roles and separation of duties

NIST SP 800-53 AC-5 (separation of duties) and AC-6 (least privilege) apply to the scanner as they would to any security tool. The design goal: no single person can see a leaked secret, hide that it was found and close the record.

Role	Can do	Should not be able to do
Platform administrator	Configure integrations, authentication, retention and connectors	Dismiss findings or edit detection rules without review
Rule and policy owner	Propose custom patterns, exclusions and severity changes through review	Merge their own rule changes or change platform settings
Triage analyst	View findings for assigned repositories, request revocation, record outcomes	See unmasked values outside their scope, close findings marked live without evidence of revocation
Repository owner or developer	See findings in their own repositories, request a push protection bypass	Approve their own bypass, see other teams' findings
Auditor	Read audit logs, reports and dismissal history	Change anything

Scope findings by repository ownership: a developer should see findings in the code they own, not a tenant-wide list of every live key. Keep any tenant-wide security role small and named.
Mask by default: display only a prefix and suffix of each matched value. Reveal the full value only where a role genuinely needs it to locate and revoke the credential, and log every reveal.
Delegated bypass needs a second person: where push protection allows bypass, route requests to a reviewer group rather than letting the pusher self-approve. The NSA and CISA Defending CI/CD Environments information sheet recommends two-person review of code changes for the same reason: one compromised account should not be enough.
Dedicated admin identities: platform administrators sign in through the identity provider with phishing-resistant MFA (IA-2(1)) and a separate admin account. Avoid local accounts on self-hosted servers except a break-glass account held under control. See the Break-Glass Account Guide.

Service accounts, tokens and the scanner's own credentials

A scanner is a non-human identity with some of the broadest read rights in engineering. The OWASP Top 10 CI/CD Security Risks entry CICD-SEC-6 (Insufficient Credential Hygiene) asks teams to map where credentials exist, give each only the permissions its service needs, avoid sharing one credential across contexts, prefer temporary credentials and restrict where a credential can be used. Apply all five to the scanner itself.

Credential	Needs	Common excess	Better pattern
Source control integration	Read contents and metadata; write alerts or checks where used	Personal access token of an administrator, or write access to code	App-style installation with read-only content scope, owned by a team, not a person
Pipeline scanning job token	Read the checked-out code; upload a results file	Default job token with write permissions, deployment secrets in scope	Explicit minimal job permissions; scanning job separated from jobs that hold deployment secrets
Chat, wiki and ticketing connectors	Read messages or pages in scope	Workspace-admin tokens	Read-only grant per workspace, reviewed at least annually
Notification and SIEM tokens	Write events to one destination	Tokens that can also read or administer the destination	Write-only ingestion credential per integration
Self-hosted database and storage	Store findings and scan state	Database credentials in plain configuration files	Credentials from a secrets manager; encryption key held outside the host

Federate where you can: scanners running in cloud or pipelines should use workload identity and short-lived tokens rather than static keys. The OWASP Secrets Management Cheat Sheet recommends short-lived OIDC tokens through workload identity federation instead of static bootstrap credentials. See the GitHub Actions OIDC Federation Hardening Guide.
Inventory them: record every scanner credential with owner, scope, creation date and expiry, and rotate it when an administrator leaves. See the Service Account Security Guide.

Protecting findings and validity checks

The OWASP Secrets Management Cheat Sheet states that secrets should never be logged and recommends masking or encryption to keep plaintext out of logs. A scanner that writes full matched values into its database, its alert e-mails and its chat notifications is doing exactly that, at scale.

Store less: where the product allows it, keep a hash or fingerprint for de-duplication and a masked fragment for display, not the full value. NIST SP 800-53 SC-28 (protection of information at rest) applies to whatever is kept.
Short retention for revoked values: once a credential is confirmed revoked, the stored value has no use. Purge it and keep the metadata for metrics and audit.
Mask everywhere it travels: check notification templates, ticket bodies, pull request comments, results files (SARIF or JSON) uploaded as build artefacts, and exports. A results file with full values in a public pipeline's artefacts is a fresh leak.
Control validity checking: validation presents a found credential to the service that issued it. Enable it per secret type, run it from fixed scanner infrastructure with known egress, and log each check. Do not run validation from developer laptops or from shared runners that also serve untrusted forks.
Treat an unverified result as possibly live: a failed check may only mean the endpoint was unreachable or the type is unsupported. See the Developer Secret Scanning Triage guide.

Rules, allowlists and dismissals

Every scanner has ways to ignore content: path exclusions, inline ignore comments, baseline files, allowlisted values, entropy thresholds, disabled detectors and alert dismissal reasons such as false positive, test credential or will not fix. Each is legitimate, and each is the simplest way to hide a real leak.

Suppression method	Abuse risk	Control
Inline ignore comment in code	A developer silences a real secret in the same commit that adds it	Report ignore comments as findings in their own right; require review on files that add them
Path or file exclusion	Whole directories (configuration, test fixtures) drop out of scope	Keep exclusions in a central, version-controlled configuration with code owner review
Baseline or known-findings file	New secrets slipped into the baseline during regeneration	Diff baselines in review; regenerate only through a controlled job
Disabled detector or raised threshold	An entire secret type stops being found	Platform change alert; approval from the rule owner group
Alert dismissal	Live credential closed as false positive or test value	Require a reason; sample dismissals monthly; block dismissal of verified-live findings without revocation evidence

The OWASP cheat sheet suggests organisation-wide standard test secrets to cut false positives, which also removes the main excuse for broad exclusions. Rule coverage choices are covered in the Secret Scanner Rule Coverage Comparison Guide.

The scanner inside CI/CD

A pipeline scanning step runs third-party code in an environment that often holds deployment secrets. The 2021 Codecov breach showed the pattern: a modified script that customers ran in their CI jobs sent environment variables, including credentials, to an attacker. A scanner step is the same kind of tool and carries the same risk.

Pin and verify: reference the scanner action, container or binary by an immutable digest or commit, not a floating tag, and check signatures or checksums where the project publishes them (NIST SP 800-53 SI-7 and SR-11). See How to Pin GitHub Actions to Commit SHAs.
Isolate the job: run scanning in its own job with no deployment secrets in scope. CICD-SEC-6 recommends that each pipeline and step can reach only the secrets it needs.
Keep output quiet: configure the scanner to redact values in console output, because pipeline logs flow into log platforms that many people can read. CICD-SEC-6 lists secrets in console logs as a common exposure.
Forks and untrusted contributions: do not let pull requests from forks run scanning jobs that have access to secrets or to validity checking.

For pipeline hardening beyond the scanner, see the CI/CD Security Guide.

Lifecycle: choose, deploy, run, retire

Choose: ask how findings are stored (full value, masked, hashed), whether retention is configurable, whether roles can be scoped per repository, how bypass and dismissal are audited, and whether the audit log can be streamed out. The Secrets Scanning Buyer's Guide lists wider evaluation criteria.
Deploy in report-only mode: start with scanning and alerting on a pilot set of repositories, with masked notifications, before enabling push blocking. Confirm that no full values appear in tickets, chat or artefacts.
Turn on enforcement in rings: enable push protection or failing builds for one business unit, then widen. Rollback is switching enforcement back to report-only, not removing the scanner.
Run: patch self-hosted scanners as security-critical systems, review roles quarterly (NHI Mgmt Group recommendation), rotate integration credentials on a schedule and on administrator departure, and update detectors as new token formats appear.
Retire: export the metadata needed for audit, purge stored values, revoke every integration token and app installation, remove webhooks and pipeline steps, and confirm that no repository still references the old tool.

Detection and measurement

Forward the scanner's audit log to a SIEM that scanner administrators cannot change, in line with NIST SP 800-53 AU-9(2) and AC-6(9). The OWASP cheat sheet asks that auditing be resilient against attempts to tamper with or delete the audit logs. See Securing the SIEM itself.

Event	Why it matters	Alert?
Admin role granted, SSO or authentication settings changed	Takeover or persistence on the scanner	Always
Detector disabled, threshold raised, exclusion added	Coverage silently reduced	Always, with approver
Bulk dismissal or dismissal of a verified-live finding	Possible cover-up of a real leak	Always
Full secret value revealed or findings exported	Concentrated credential access	Against baseline
Integration token created or changed; new app installation	Added credentials (T1098.001 for cloud credentials)	Always
Scanner version or pipeline step definition changed	Possible tampered tool	When not from the controlled update path

Metrics that show the scanner itself is under control:

Number of people who can see unmasked values, against a target that falls over time.
Share of scanner integration credentials that are short-lived or federated.
Percentage of dismissals sampled and confirmed correct each month.
Exclusions and ignore comments added per month, and the share reviewed.
Pipelines running a pinned, verified scanner version, as a percentage of all scanning pipelines.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0
Admin roles, scoped findings, bypass approval	AC-2(7), AC-5, AC-6	PR.AA-05
Scanner tokens and service identities	IA-5, IA-9	PR.AA-05
Findings storage and retention	SC-28	PR.DS-01
Scanner integrity in pipelines	SI-7, SR-3, SR-11	GV.SC-07
Coverage and scanning operations	RA-5, CM-7	ID.RA-01
Audit logging and monitoring	AU-9(2), AC-6(9), SI-4	PR.PS-04, DE.CM-03

Common failure patterns

Findings readable by everyone: the whole engineering organisation can browse live keys from other teams because visibility was left at the tenant default.
Full values in chat: alert messages post the complete matched secret into a busy channel, copying the leak into another system with its own retention.
Administrator token as the integration: the scanner connects with a personal token belonging to an administrator, with write rights, which breaks when that person leaves and is too powerful while they stay.
Floating tags in pipelines: the scanning step pulls the latest version on every run, so a compromised release reaches every repository at once.
Dismissal as remediation: alerts are closed as false positives to meet a queue target while the credentials still work.

Practitioner checklist

Classify the scanner's findings store as sensitive credential data and restrict, mask and log access to it.
Scope finding visibility by repository ownership and keep the tenant-wide security role small and named.
Replace personal or write-capable tokens with read-only, team-owned integration identities.
Inventory every scanner credential with owner, scope and expiry, and federate where possible.
Put rules, exclusions and baselines in version control with review, and alert on detector changes.
Require a second person for push protection bypass and for dismissal of verified-live findings.
Enable validity checking per secret type from fixed infrastructure only, and log each check.
Pin and verify the scanner version in every pipeline and isolate the scanning job from deployment secrets.
Stream the scanner audit log to a SIEM outside the scanner team's control.

Securing the secrets scanning tool itself: protect findings, tokens, rules and pipelines