Guardrails / security

No findings at or above the severity gate

security/no-high-findings@v1

Every finding the scanner reported is below the severity the team gates on.

Id	security/no-high-findings
Version	v1
Category	security
Default severity	error
Interpreter	python3
Timeout	30 seconds
Violations tolerated	0
Collects	scan

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
scan	Findings from whatever scanner the build already ran, read from the report it left behind and normalized into one shape, whether the tool was a SAST, an SCA, a secret detector or an infrastructure scanner.	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": "security/no-high-findings@v1",
              "severity": "error",
              "with": {
                  "severity": "high",
                  "kinds": "sast,iac,container,secret"
              },
              "exemptions": []
          }
      ]
  }
}

Inputs

Input	Description	Default	Environment variable
severity	Lowest severity that violates: critical, high, medium, low or info.	high	GUARDRAIL_INPUT_SEVERITY
kinds	Comma separated finding kinds to gate on. Dependency findings are left to the supply chain guardrails.	sast,iac,container,secret	GUARDRAIL_INPUT_KINDS

How to fix

Fix the findings, or record an exception with a time limit. Raising severity to hide them doesn't create an exception, just an undocumented one, and an override nobody can see is the finding auditors report most often.

If a finding genuinely isn't exploitable in this codebase, suppress it in the scanner with a justification and an expiry date, so the suppression can be reviewed next to the finding.

More in security

• security/finding-budget. The number of findings at or above a severity stays within the budget the team set, so a report too long to read doesn't pass as a clean one.
• security/fixable-vulnerabilities. Every finding the scanner reported a fixed version for has had that fix applied, so the findings that only need an upgrade, not a redesign, aren't left open.
• security/scan-results-present. A scanner ran and left a report the build can be judged on, instead of the build reporting nothing at all.

All 4 security guardrails