Security overview
What "hardened" actually means, and what we promise.
The short version: a PodArmor image is a container image that has had every published upstream patch applied at the moment of its rebuild, and that ships with disclosed transparency about every CVE the standard scanners still flag (including the ones with no available fix).
The longer version is below — it's worth reading once, especially if you're putting these images through procurement review.
CVE classification
Outstanding patches vs Won't fix vs Awaiting upstream — how we partition scanner output.
Hardening practices
Non-root, distroless, no SUID, CIS Section 4 — what each one means and why we ship them by default.
Comparing to upstream
The 'why hardened' panel — how we compute the reduction stats and what they mean.
What we don't claim
PodArmor's framing is designed to survive a procurement reviewer who runs their own grype against our images. Some specific things we explicitly don't do:
- We don't claim "0 CVEs" in a way that contradicts the scanner. Most hardened-image vendors achieve "0 CVEs" by suppressing maintainer-classified entries from their published count. We do the same — but we surface those entries in the Transparency residuals section with a link to
security-tracker.debian.orgso anyone can verify the suppression is legitimate. - We don't claim FIPS or STIG validation we don't have. When we ship FIPS variants, they'll carry the right chip. Until then, the TrustHeadline doesn't lie about it.
- We don't fabricate historical "scan trends." Our time-series chart starts the day we record our first scan for a given image-version. Early on it's sparse — we lean into that visually rather than smoothing over it.
These are conscious design choices. Any vendor (us included) can be caught by a CISO who looks twice; the goal of this product surface is to be defensible the second time someone looks.