No critical vulnerabilities in dependencies
supply-chain/no-critical-vulnerabilities@v1
No dependency the build takes on carries 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 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": "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. Each one is an exception somebody should be able to explain. | `` | GUARDRAIL_INPUT_IGNORE |
How to fix
Upgrade the dependency to the version the scanner names as fixed. Where no fix exists, the decision is a risk acceptance with an owner and an expiry, recorded where the exception register can see it, rather than a raised 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 the bill of materials lists name a licence that the inventory can answer what the artifact may be distributed under.supply-chain/disallowed-components. No component the bill of materials lists is one the team has decided it will not ship, whatever brought it in.supply-chain/disallowed-licenses. No component the bill of materials lists is licensed under one of the licences the team has decided it will not ship.supply-chain/sbom-present. An SBOM was produced for this build, so the components that went into the artifact are recorded rather than reconstructed later.supply-chain/sbom-standard-format. The bill of materials is written in a format anything else can read, and it declares which version of that format it is.