The vulnerability gate was real, and it was guarding one repository out of seven

Background

The scan definition lived in the shared pipeline template and its own header stated that every repository includes it. Six of seven never did, and the template registry did not even list the file — so nothing in the written record contradicted the belief that images were being scanned. Enabling it revealed why that mattered: all nine application images carried CRITICAL vulnerabilities that already had upstream fixes available. None of them originated in application dependencies. They came from a package manager bundled into base images and never used at runtime, from a compiler version used to build a small agent, and from a pre-built binary shipped inside a development tool.

Path

Symptom

a written standard said every repository scans its images

Assumption

assumed the standard described what was happening

Measurement

compared the standard against what each pipeline actually included

Decision

removed the causes first, then enabled the gate

Response

The gate was deliberately not switched on first. A dry run against every image was measured before any pipeline changed, because enabling it immediately would have turned five pipelines red on the same commit and taught everyone that the gate is noise to be worked around. The causes were removed first — unused package managers deleted from runtime images, the compiler raised, the development tool upgraded — each verified by re-scanning to zero. Only then was the gate wired in, and only then did it mean anything. Two vulnerabilities could not be fixed at all, living inside vendor-supplied libraries in a commercial application server; those are recorded as documented exceptions with a re-check obligation rather than by loosening the threshold, because a gate that gets relaxed whenever it complains stops being a gate.

Skill upgrade