Triage Findings by Risk, Fix What Works

Why this matters

A scan flags four hundred findings and the team spends a sprint fixing test dependencies no attacker can reach, while a remotely exploitable service bug waits because its score looked lower. Score-chasing burns the security budget on noise. Risk is reachability times exploitability times blast radius, and only the findings scoring high on all three deserve the sprint.

Concepts

Read each finding as four questions. What is it: the vulnerability, the affected component and version. Can it be reached: is the vulnerable code path exposed to untrusted input, or buried in an unused test helper. Can it be exploited: public exploit, trivial trigger, or theoretical chain requiring five preconditions. What breaks if it fires: data theft, remote execution, or a crash in a stateless worker. A critical in an unreachable dev tool loses to a medium on the login path; context outranks the number.

Fixes come in four shapes. Upgrade the dependency or base image when the fix release exists and the change is safe: the common case, automated where possible. Replace the component when upgrades stall (abandoned library, breaking major): swap for maintained equivalents. Isolate when neither works yet: network policy, dropped capabilities, read-only mounts that shrink what an exploit can reach, honest about being mitigation, not cure. Accept with a date when risk is genuinely low: written, expiring, owned, reviewed at expiry. Accept-forever is the finding equivalent of retry-until-green.

Base images deserve their own cadence. Rebuild regularly from current pinned bases (M05 pinning plus M06 pipelines make this cheap), scan the result, and track fixable versus unfixable separately. An unfixable-count obsession blocks releases over kernel notices in a distroless image nobody can act on; a fixable backlog going stale means the rebuild cadence slipped. Cadence plus triage beats either alone.

Scanning's blind spots stay explicit. Scanners see known vulnerabilities in known components; they do not see your code's logic flaws, misconfigurations except the catalogued ones, leaked secrets beyond patterns, or malicious maintainers below the radar. A clean scan is one passing check among many, never a verdict of safety. Lessons 1 and 2 plus this one are three legs; remove any and the stool falls.

Worked example

A fixture scan report lists 60 findings on a small service. The triage:

CRITICAL lib-xml 2.1 → reachable via upload parsing, public exploit: upgrade to 2.4, verify with the exploit's trigger input now benign. HIGH base-image openssl → fixable in rebuilt base: rebuild, rescan. 40x MEDIUM/LOW in devDependencies → unreachable in runtime image: confirm slim stage excludes them, accept with rebuild-date review. 1 unfixable kernel notice → not actionable in container: note, move on.

Expected reading: two fixes ship this week, forty findings die by runtime exclusion proof, one note records the unfixable. The sprint spends days on real risk instead of weeks on counts. Lab L23 requires this exact artifact: ranked findings, workable fixes, verified where verifiable.

The common wrong move

Gating releases on zero findings. The count never reaches zero (new CVEs daily, unfixable notices permanent), so the gate becomes either a permanent blocker everyone hates or a rubber stamp everyone bypasses, exactly the gate decay from M06 lesson 2. Gate on fixable-reachable findings with an SLA instead; track the rest on a visible backlog with dates.

Lab and next step

Lab L23 triages a fixture scan report with risk and workable fixes, verified where verification exists. Next, lesson 4 closes Foundations with the change decision itself: risk, go/no-go, rollback and delivery.