Guardrails / secrets

No credential the detector found at or above the severity gate

secrets/no-hardcoded-credentials@v1

Every secret the detector reported is below the severity the team gates on, or matches a rule the team has already accepted.

Id	secrets/no-hardcoded-credentials
Version	v1
Category	secrets
Default severity	error
Interpreter	python3
Timeout	30 seconds
Violations tolerated	0
Collects	secrets

Collectors

This guardrail doesn't gather anything itself. It relies on the collectors below, which the CLI runs once per build before any check, and reads what they found from GUARDRAIL_FACTS. If a collector collects nothing, this guardrail is skipped, not failed.

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 inputs, passed straight through to the collector. Setting one in buildnote.json changes what is collected, and two guardrails configured the same way share a single collection.

Configuration

{
  "guardrails": {
      "failOn": "error",
      "checks": [
          {
              "use": "secrets/no-hardcoded-credentials@v1",
              "severity": "error",
              "with": {
                  "severity": "high",
                  "ignore": ""
              },
              "exemptions": []
          }
      ]
  }
}

Inputs

Input	Description	Default	Environment variable
severity	Lowest severity that violates: critical, high, medium, low or info. A detector that verified a credential against the service it belongs to reports critical; an unverified match reports high.	high	GUARDRAIL_INPUT_SEVERITY
ignore	Comma separated rule ids the team has already reviewed and accepted, such as generic-api-key. Rules named here are left out of the verdict, so only list ones someone has actually reviewed.	``	GUARDRAIL_INPUT_IGNORE

How to fix

A credential that reached the repository is compromised from the moment it was pushed, so deleting the line doesn't fix it. First rotate it, then remove it from the checkout, then make sure it stays out:

gh secret set STRIPE_API_KEY --body "$(op read op://deploy/stripe/api-key)"
git rm --cached config/app.yaml && echo 'config/app.yaml' >> .gitignore

Read the value from the environment where it's used, so there's nothing left in the repository to detect:

val apiKey = System.getenv("STRIPE_API_KEY") ?: error("STRIPE_API_KEY is not set")

If a match is a test fixture and not a credential, add its rule to ignore and explain in the pull request why it isn't one. Don't raise severity to clear the findings: that hides every rule at once, and an override nobody can see is the finding auditors report most often.

More in secrets

• secrets/detector-ran. A secret detector ran on the checkout, or left a report the build can be judged on, so something has actually looked for credentials.
• secrets/gitignore-present. The repository has a .gitignore, so the next person who runs git add . doesn't commit build output or the local credential files next to it.
• secrets/no-credential-files-committed. None of the well-known credential files is in the working tree: no .env, private key, keystore, kubeconfig or cloud credential file.

All 4 secrets guardrails