No finding with a fix available is left open
security/fixable-vulnerabilities@v1
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.
| Id | security/fixable-vulnerabilities |
| Version | v1 |
| Category | security |
| Default severity | warning |
| 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/fixable-vulnerabilities@v1",
"severity": "warning",
"with": {
"severity": "medium",
"kinds": "sast,sca,iac,container,secret"
},
"exemptions": []
}
]
}
}Inputs
| Input | Description | Default | Environment variable |
|---|---|---|---|
severity | Lowest severity that is a violation when a fix is available: critical, high, medium, low or info. | medium | GUARDRAIL_INPUT_SEVERITY |
kinds | Comma separated kinds of finding that are counted, as the collector normalises them: sast, sca, secret, iac, container, unknown. | sast,sca,iac,container,secret | GUARDRAIL_INPUT_KINDS |
How to fix
Upgrade the packages named in the violations to the version the scanner reports as fixed. The fix is already written and released; all that's left is to take it.
A finding with no fix is a risk decision, and it's reasonable to leave one open while the team weighs it. A fixable finding isn't that kind of decision. It's the part of the report worth separating out, because it's the part you can close this afternoon.
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/no-high-findings. Every finding the scanner reported is below the severity the team gates on.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.