A container vulnerability pipeline that ends in a fix, not a report
Short answer
A container vulnerability pipeline scans every image, ranks findings by real risk (actively exploited first, then EPSS likelihood, then code the app loads), fixes what can be fixed, gates releases on a policy, and keeps watching deployed images for new CVEs. Its outputs are SBOMs, SARIF for code scanning and VEX for findings that do not apply.
- 01Scanregistry → SBOM
- 02RankKEV · EPSS · in use
- 03Fixrebuild or rebase
- 04Gatepolicy in CI
- 05Watchnew CVEs, daily
Why ranking comes first
known~460
loaded~15 %
Studies of popular images find hundreds of known CVEs per image, most in packages the application never loads. A pipeline that treats them equally produces fatigue, not fixes.
The outputs each stage should produce
| Stage | Output | Consumer |
|---|---|---|
| Scan | SPDX 2.3 / CycloneDX 1.6 SBOM | release records, EU CRA |
| Rank | fix-first list | engineers |
| Gate | SARIF 2.1.0, exit code | GitHub code scanning, CI |
| Triage | OpenVEX | auditors, downstream scanners |
| Watch | signed webhooks | Slack, on-call |
In CI
ocimend scan ghcr.io/acme/api:$GITHUB_SHA --policy ocimend-policy.yaml --format sarif -o ocimend.sarif ocimend fix ghcr.io/acme/api:1.4 --kind fixed
Questions
What should fail a build?
Actively exploited (KEV) vulnerabilities with a fix, critical CVEs in code the app loads, secrets, and a failed FIPS verdict where FIPS is required.
Do I need an SBOM?
Increasingly yes: the EU Cyber Resilience Act requires machine-readable SBOMs for products by December 2027.
Sources
More guides
- How to build FIPS-enabled containers (FIPS 140-3)
- OCImend FIPS containers: what you get and how they are verified
- How to fix container image CVEs automatically
- "No fix available": what to do about unfixable container CVEs
- Base image or your layers? Finding which Dockerfile step introduced a CVE
- EU Cyber Resilience Act for container images: SBOM, VEX and 24-hour reporting