No critical vulnerabilities in dependencies
supply-chain/no-critical-vulnerabilities@v1
No dependency of the build has an open finding at or above the severity the team gates on.
| Id | supply-chain/no-critical-vulnerabilities |
| Version | v1 |
| Category | supply-chain |
| 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": "supply-chain/no-critical-vulnerabilities@v1",
"severity": "error",
"with": {
"severity": "critical",
"ignore": ""
},
"exemptions": []
}
]
}
}Inputs
| Input | Description | Default | Environment variable |
|---|---|---|---|
severity | Lowest severity that violates: critical, high, medium, low or info. | critical | GUARDRAIL_INPUT_SEVERITY |
ignore | Comma separated vulnerability identifiers to leave out, for findings already accepted. Someone should be able to explain each one. | `` | GUARDRAIL_INPUT_IGNORE |
How to fix
Upgrade the dependency to the version the scanner reports as fixed. If no fix exists, record a risk acceptance with an owner and an expiry date where the exception register can see it, instead of raising the threshold.
Run the scanner in the pipeline and leave its report in the workspace:
trivy fs --format json --output trivy.json .More in supply-chain
supply-chain/components-licensed. Enough of the components in the bill of materials name a licence for the inventory to tell you what the artifact may be distributed under.supply-chain/disallowed-components. No component in the bill of materials is one the team has decided it won't ship, however it got there.supply-chain/disallowed-licenses. No component in the bill of materials uses a licence the team has decided it won't ship.supply-chain/sbom-present. An SBOM was produced for this build, so the components that went into the artifact are recorded at build time instead of reconstructed later.supply-chain/sbom-standard-format. The bill of materials uses a standard format other tools can read, and declares which version of that format it follows.