No findings at or above the severity gate
security/no-high-findings@v1
Every finding the scanner reported sits 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 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 |
|---|---|---|
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, 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": "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 a time limited exception. Raising severity to hide them is not an exception: it is an undocumented one, and an override nobody can see is the finding auditors report most often.
Where a finding is genuinely not exploitable in this codebase, suppress it in the scanner with a justification and an expiry, so the suppression is reviewable where the finding is.
More in security
security/finding-budget. The number of findings at or above a severity sits within the budget the team set, so a report nobody can read does not pass for a clean one.security/fixable-vulnerabilities. Every finding the scanner reported a fixed version for is taken, so the ones that cost an upgrade rather than a redesign are not the ones left open.security/scan-results-present. A scanner ran and left a report the build can be judged on, rather than the build reporting nothing at all.