Contents (4 sections)
Ask your provider, or yourself: “how many known critical vulnerabilities are running in your infrastructure, here and now?”. For a long time, our honest answer was: we do not know exactly. Around a hundred container images in production, dozens of upstream projects publishing fixes every week, and no process to cross-check the two. Here is how we closed that gap: with Trivy, an open-source scanner, and above all with the architecture around it, which matters more than the tool.
Scan what runs, not just what you build #
The usual reflex puts vulnerability scanning in the CI pipeline: every build is checked before deployment. Necessary, but structurally insufficient, for a simple reason: CVEs are published after your deployments. An image that was clean when built on 1 March can carry a critical flaw disclosed on the 15th. If your only scan lives in CI, an application that is not rebuilt stays blind indefinitely. Hence the reverse principle: periodically scan what is actually running: the list of live images, collected on the hosts themselves, not the theoretical list of repositories.
The architecture, from collection to report #
- Collection: every week, an inventory queries the thirty or so hosts in the fleet and records the images actually running: the observed inventory, not the declared one.
- Scan: Trivy analyses the ~93 to 97 unique images of the moment. Count on ~20 minutes with three scans in parallel, perfectly acceptable for a weekly rhythm.
- Triage: a documented exclusion list (the known false positive, the CVE with no fix available, the component that is not exposed), each exclusion with its written justification, otherwise the list becomes a rug for everything to be swept under.
- Reporting: the number of critical findings appears in the subject line of the weekly e-mail, not on page 12 of a report. A week at zero is read in a second; a new critical finding jumps out.
- Resilience: a scan failure does not cancel the rest of the report (the error is noted, the chain carries on), and the monitoring chain is itself watched by a heartbeat: the Monday the report does not arrive is precisely the one to worry about.
A report that does not state its own limits reads as complete coverage. The “scope and limits” section is not modesty: it is what makes the rest credible.
Triaging the noise: the real skill #
The first scan of a real fleet is a cold shower: hundreds of entries, the overwhelming majority of which do not warrant immediate action. The value is not in the scanner: it is in the triage. Our grid: a vulnerability warrants quick action if it is critical + has a fix available + affects a component that is actually exposed. The rest feeds the normal update cycle. Because that is the real operational conclusion: in 95% of cases, fixing CVEs simply means updating. The scan does not replace version hygiene, it prioritises it. The two kinds of monitoring (version freshness, vulnerabilities) are two sides of the same process.
The bonus that changes conversations: the PDF report #
Beyond the weekly e-mail, the chain generates a PDF audit report of around thirty pages: summary, inventory, access hardening, network exposure, vulnerabilities per image, version drift, and the famous “scope and limits” section. Two refinements of the hardening probe are worth stealing: read the effective SSH configuration (sshd -T) rather than the main file (a drop-in can reopen what the file closes), and cross-check “password authentication enabled” with “accounts actually have a password”, otherwise you flag as critical hosts where the attack is impossible. This PDF is as useful for steering as for answering: customer security questionnaires, insurers, tenders.
This monitoring is one link in the chain we run as managed services, with the patching that follows and backups for the worst case. If the question in the first paragraph made you uneasy, that is the right starting point.
