Your base image adds hundreds of OS package CVE findings your application never calls — what does shrinking the base actually reduce?

## Two arguments wearing the same coat Ask five engineers why they want a minimal base image and you get one answer: "fewer CVEs." Press, and it splits into two claims that are both true, both worth making, and answerable by different actions. **Claim 1 — the ledger.** Every package in the base layer is software you now own the risk assessment for. When an advisory lands against it, someone must decide whether it applies. Multiply by the number of images and the frequency of advisories and you have a standing operational cost, plus an accountability artefact: the list is what an auditor, a customer security questionnaire, or a regulator's reviewer will actually look at. A smaller base means a shorter list and less recurring assessment work. **Claim 2 — capability.** Independently of counts, a base without a shell, package manager or interpreter hands an attacker who achieves execution far less to work with. That is a change in the consequences of compromise. These diverge in practice. A base can be minimal and still carry an unpatched library that is directly reachable from your request path — small ledger, real exposure. A base can be large and fully current — long ledger, little exposure. **The count is a measure of what you inherited, not of what an attacker can achieve.** ## What a finding count does and does not tell you A finding against an inherited OS package means: a package matching this name and version is present, and an advisory covers that range. It does not by itself tell you that the vulnerable code path is ever entered, that an attacker can reach it from outside, or that a working exploit exists. Those are separate determinations, made by separate disciplines, and a candidate who treats a raw count as a risk number is telling you they have never had to work through one. Be precise with the vocabulary here, because interviewers listen for it: - A **vulnerability** is the flaw itself. - An **exploit** is a working technique against it. - A **threat** is what could go wrong, and a **risk** is the rated consequence given likelihood and impact. A number is only the first of those, counted. ## The scenario that makes the split concrete A regulated operator ships a service on a full distribution base. The scan report against the base layer runs to several hundred findings, largely in packages the application has no code path into — locale data, terminal utilities, archive tools present because the distribution ships them. Engineering wants a minimal base. Now notice that two people in the room want it for different reasons: - The **compliance owner** wants the list short, because the list is the evidence and the recurring assessment is the cost. Their goal is satisfied by anything that shrinks or justifies the list. - The **security engineer** wants the shell and the installer gone, because those change what happens on the bad day. Their goal is not satisfied at all by a report that merely looks cleaner. If you make only the first argument to leadership, you will win a budget for cleaning up a report and lose the control that mattered. If you make only the second, the compliance owner keeps paying assessment cost forever. Make both, and label them. ## What to say when someone demands zero findings "Zero findings" is a target that quietly optimises for the metric. It pushes teams toward whichever base produces the shortest report, toward suppressing rather than assessing, and toward avoiding a base change that is right on capability grounds because it would temporarily lengthen the list. The healthier framing is: **findings you have not assessed** is the number to drive to zero, and inherited-package count is a cost driver you manage deliberately. ## Getting the direction of the claims right Two mistakes to avoid saying out loud. First, a minimal base is not a patching strategy — the packages that remain still need to be current, and choosing a smaller base does not update anything. Second, shrinking the base does not fix the application's own dependencies; the libraries your code actually calls are usually the higher-value target precisely because they are reachable, and they live above the base layer, not in it. ## How to answer Open by refusing the single answer: "It reduces two different things." Give the ledger argument with its cost and audience, give the capability argument with a concrete post-compromise chain, then state which one you would lead with for the workload in front of you — capability for an internet-facing service, ledger for a large fleet where assessment time is the actual constraint.