The Audit-Proof Way to Ignore a CVE
Your scanner found multiple vulnerabilities in your base image this morning, and your release is blocked until every one of them is triaged out of the queue. Most of them will never be fixed, and for most of them that is the correct outcome.
The catch: you work on government code, so you can't hand the problem to the tools built to solve it.
The agentic CVE-analysis platforms want to embed your source. The good commercial suites cost real money and still phone home. And the rules about AI and sensitive code are only getting tighter.
So this talk is about a question I had to actually answer on a live government program: how do you supercharge vulnerability triage using the most powerful tools available, without a single byte of privileged code or infrastructure leaving your boundary?
Most container CVEs on a Debian base aren't scanner errors. Modern scanners already consume the distribution's advisories and map backported fixes correctly. What they faithfully report is a long tail of vulnerabilities Debian has assessed and marked no-dsa: a documented decision not to issue a stable fix. Dismissing those is defensible, but only if you ground it in that decision rather than your gut, and re-check it when the decision changes, because no-dsa doesn't mean safe, it means someone accountable decided it was minor, and that can lag upstream or be wrong.
The catch on government code is doing all this without sending your images or source to a cloud model. The agentic CVE platforms reason brilliantly about whether your code reaches a flaw, by embedding your code. The good commercial suites cost real money and still phone home. And the rules on AI and sensitive code keep tightening. The insight that makes the problem tractable is knowing what's actually secret. A CVE, its package, and Debian's ruling are all public, so the most powerful tools available can synthesize them freely. What's privileged is the join: the fact that your specific protected image, in your protected GitLab instance, behind your gate, contains that package. That mapping never leaves the boundary. You assemble the affected list locally from data only you can see, enrich each public CVE with the best tooling you have, and stitch the result back onto your private findings at home. The model never sees your image, your repo, or the fact that you're the one affected, and it never makes the call.
The output is a work order, not a verdict, and it has two halves on purpose. The top half is settled fact: Debian's status with the link, the installed version versus the fixed version, and any place GitLab's stored guidance disagrees with the live source. Every line is independently verifiable, which is what grounds the decision. The bottom half is a tailored exploitability checklist, the right questions to ask before dismissing on exploitability grounds, generated from the public CVE and the generic app context, this is a .NET service on Debian, never from your source. The machine poses the questions; the human answers them inside the boundary. The result is faster triage that never pretends the model determined exploitability, and a structured record that keeps a distribution-grounded dismissal distinct from an internal-judgment one, because an auditor treats those very differently.
The reasoning is written back into GitLab alongside the human-readable comment, so the same artifact is both the human's prompt and the auditor's record. Then, on a schedule, every past disposition is re-checked against the current decision and the current image, so a finding you dismissed last spring resurfaces the day its basis changes. The dangerous findings aren't the ones in your queue, they're the ones you already cleared and stopped looking at.
Charl Cilliers is a technology executive at Foci Solutions. He works in enterprise .NET and platform security, with a long-running interest in the layer where software meets hardware. Outside of work he's a maker and electronics tinkerer: 3D printers, CNC, SDR and a steady stream of microcontroller projects, usually with one of his kids nearby. He has a low tolerance for tools that generate work without reducing it, in roughly equal measure at the office and in the garage.