Oh, the `*dev*.txt` regex band-aid brings back memories. We did exactly that, and you're right, it lasted about a week until our data science team added `requirements-data-science-dev.txt`. Chaos ensued.
Hooking into the actual build graph is the only sane path. We got there by having our CI pipeline spit out a manifest of what actually ended up in the final image layer, then diffed that against Mend's raw report. The first run was a shock - about 70% of the "critical" findings were just noise from build stages. It gave us the hard data we needed to kill the blanket review policy and build those context tags everyone's mentioning.
it worked on my machine
That approach, diffing the final image manifest against the raw scan, is the gold standard for this problem. It cuts straight to the relevant risk.
One caveat we found was the initial parsing overhead. Creating that delta report was heavy for the first few weeks, until we automated the mapping between the build stage output and the scanner's dependency tree. The payoff in policy credibility was immense, but it does require dedicated pipeline work to keep it running smoothly.
Your 70% noise figure is telling, and matches our early data. It's the only kind of evidence that persuades stakeholders to move from a culture of blanket compliance to one of targeted, evidence-based review.
Your breakdown into `shared-ci-runtime` vs `ephemeral-test-container` is a necessary evolution. The nuance you added about a gold image pipeline is critical - we found the same pushback until we mapped dependencies to actual image layers.
One caveat from our implementation: tagging based purely on declared context like you describe created a maintenance burden. We had to audit and update tags whenever a team changed a Dockerfile's multi-stage structure. The solution, which built on what user238 mentioned, was to generate the tags automatically by analyzing the final built artifact's SBOM against the scan output. This made the `no production artifact touch` metric defensible and automated.
—Alex
Your point about the maintenance burden of manual tagging is exactly why we treat SBOM diffing as a non-negotiable prerequisite. We made the same mistake of tying context tags to Dockerfile stage names, which broke constantly.
The deeper lesson from automating this is that you need a canonical source of truth for what constitutes a "production artifact." For us, that's the registry digest. Our automation keys off that, comparing the SBOM of that final image layer against the full dependency tree from the build scan. It eliminates the entire class of problems caused by teams refactoring their Dockerfiles.
One caveat we discovered is that this only works if your scanner can correctly attribute a finding to a specific layer. We had to switch scanners early on because ours couldn't reliably trace a CVE back through the build graph to distinguish a `COPY --from=build` package from one installed in a final `RUN` step. Without that, your automated tagging will have dangerous gaps.
Migrate slow, validate fast.
That's exactly the pattern I've seen. It turns a security tool into a compliance chore. Did your team ever track how much time was spent researching those dev-tool CVEs versus actual runtime fixes? I wonder if that metric could help argue for smarter rule tuning.