Guardrails / secrets

A secret detector scanned the checkout

secrets/detector-ran@v1

A secret detector ran, or left a report the build can be judged on, rather than nothing having looked for a credential at all.

Id	secrets/detector-ran
Version	v1
Category	secrets
Default severity	error
Interpreter	python3
Timeout	30 seconds
Violations tolerated	0
Collects	secrets

Collectors

This guardrail gathers nothing itself. It depends on the collectors below, which the CLI runs once per build before any check, and reads what they found out of GUARDRAIL_FACTS. A collector that collects nothing skips this guardrail rather than failing it.

Collector	Gathers	Inputs it is given
secrets	Secrets found in the checkout, read from the report a secret scanner already left behind, or collected by running gitleaks or trufflehog when the runner carries one and no report is there. Only the rule, the file, the line and a fingerprint are collected: the matched value never is, because these facts are attached to the run event.	none

The inputs above are this guardrail's own, passed straight through. Configuring one in buildnote.json changes what is collected, and two guardrails configured the same way share the one collection.

Configuration

{
  "guardrails": {
      "failOn": "error",
      "comment": true,
      "checks": [
          {
              "use": "secrets/detector-ran@v1",
              "severity": "error",
              "with": {},
              "exemptions": []
          }
      ]
  }
}

How to fix

Run a secret detector in the pipeline and leave its report in the checkout before buildnote guardrails runs, or put one on the runner and let this collector invoke it. Any of these is enough:

gitleaks detect --no-banner --redact --report-format sarif --report-path gitleaks.sarif
trufflehog filesystem . --json > trufflehog.json
detect-secrets scan > .secrets.baseline

The guardrail reads whatever report is there, so the detector is your choice. The absence is the violation, and it is the reason this guardrail exists: secrets/no-hardcoded-credentials skips when nothing scanned, so a repository nobody scans would otherwise report the same clean build as a repository with no secrets in it.

More in secrets

• secrets/gitignore-present. The repository carries a .gitignore, so build output and the local credential files beside it are not committed by the next person who runs git add ..
• secrets/no-credential-files-committed. None of the well known credential files is in the working tree: no .env, no private key, no keystore, no kubeconfig and no cloud credential file.
• secrets/no-hardcoded-credentials. Every secret the detector reported sits below the severity the team gates on, or is a rule the team has already accepted.

All 4 secrets guardrails