On April 7, 2014, the OpenSSL project disclosed CVE-2014-0160 — Heartbleed — and shipped the fix, OpenSSL 1.0.1g, the same day. That same-day alignment of disclosure and patch is the exception, not the rule. Eight years later, on November 1, 2022, OpenSSL disclosed two punycode-decoding flaws, CVE-2022-3602 and CVE-2022-3786, in versions 3.0.0 through 3.0.6, fixed in 3.0.7 — but not before the project's own pre-announcement had to walk back its initial "CRITICAL" label to "HIGH" once deeper analysis showed exploitation required a CA-signed malicious certificate. And on March 29, 2024, Andres Freund reported CVE-2024-3094 to the oss-security mailing list — a backdoor in XZ Utils 5.6.0–5.6.1 with a CVSS score of 10.0 — not because a scanner flagged it, but because he noticed SSH logins were consuming slightly more CPU than expected. There was no forward patch to apply; the only remediation was rolling back to a known-good version. Three critical open-source CVEs, three different timelines, three different fixes. A patching playbook built around a single CVSS number and a single 72-hour SLA clock breaks on at least two of them. Here's a playbook built to survive all three.
Why can't an SLA clock start at the initial CVSS score?
An SLA clock can't start at the initial CVSS score because that score is frequently provisional. When OpenSSL pre-announced CVE-2022-3602 and CVE-2022-3786 on October 25, 2022, it labeled the more severe of the two "CRITICAL" — only the second such rating in OpenSSL's history after Heartbleed. By the November 1 disclosure, further analysis from researchers including Check Point showed that exploitation depended on an attacker obtaining a certificate signed by a trusted CA with a malicious punycode-encoded name, a materially harder bar than a network-reachable buffer overflow. The published severity dropped to HIGH. A team that fired its "critical incident" SLA — all-hands, emergency change window, executive notification — on the pre-announcement, then never re-evaluated, either burned unnecessary response capacity or, worse, treated the re-triage as permission to stop tracking it. The fix: bind the SLA to current severity, with a mandatory re-triage checkpoint at every published severity change, not just at initial disclosure.
Why does "disclosed" not mean "patchable"?
"Disclosed" doesn't mean "patchable" because a fix release and a public advisory aren't guaranteed to land together. Heartbleed is the case where they did: CVE-2014-0160 and OpenSSL 1.0.1g shipped the same day, April 7, 2014, giving defenders an immediate upgrade path. XZ Utils is the case where they didn't: there was no OpenSSF- or maintainer-issued forward-fix version for 5.6.0/5.6.1 because the backdoor was injected by a co-maintainer account into the release tarballs themselves, per the account Freund posted and subsequent analysis from Qualys and the OpenSSF. The only correct remediation was downgrading to 5.4.x or another version predating the backdoor, not waiting for a forward patch that was never coming. A playbook that only has one remediation lane — "apply the vendor patch" — has no action to take on day one of an XZ-style event. It needs a second lane: pin or roll back to last-known-good, triggered the moment "trusted release compromise" is suspected, independent of whether a fixed-forward version exists yet.
How do you find out about a CVE like XZ before a scanner does?
You find out before a scanner does by treating anomalies in system behavior as a detection source in their own right, not just logs to check after the fact. Freund's discovery of CVE-2024-3094 started with a performance complaint: sshd logins on a Debian sid system were taking noticeably longer and consuming more CPU under valgrind than expected, which he traced back through liblzma's build-time obfuscated payload rather than through any CVE feed, SCA scanner, or static analysis rule — none of which had anything to match against, because the malicious code didn't exist as a known signature yet. This is the argument for pairing dependency scanning with basic operational telemetry — auth latency, unexplained CPU deltas, unexpected outbound connections from build or CI infrastructure — as a parallel detection lane, since a supply-chain compromise this deliberate is designed specifically to evade the scanners looking for it.
Why should triage rank by exploitability, not just severity?
Triage should rank by exploitability because a raw CVSS score conflates a bug's worst-case impact with the real preconditions needed to trigger it, and those preconditions vary enormously between incidents. Heartbleed needed nothing but a TLS connection to a vulnerable server. The OpenSSL punycode bugs needed a CA-signed malicious certificate — a much narrower attack surface that justified the severity downgrade. When hundreds of CVEs land on a dependency report in the same week, treating all "critical" labels as equally urgent means a rarely-reachable bug with an exotic precondition competes for the same emergency response slot as one requiring no attacker setup at all. Safeguard's SCA engine addresses this by enriching every CVE/GHSA match with EPSS exploitation-probability scores and CISA KEV (Known Exploited Vulnerabilities) status, and by cross-referencing each finding against reachability analysis so a vulnerable function that your code never actually calls is de-prioritized instead of paged on equally with one sitting on a live request path.
What breaks when a mass-CVE event floods your findings queue?
What breaks is triage throughput: a single ecosystem-wide advisory like the OpenSSL punycode disclosure or the XZ backdoor can generate a duplicate finding from every scanner touching the same dependency — SCA, container-image scanning, and SBOM diffing all flagging the identical liblzma or libcrypto version simultaneously. Without deduplication, on-call engineers triage the same underlying issue three or four times under three or four different ticket IDs, which is exactly the kind of noise that causes real findings to get lost in a flood. Cross-scanner deduplication — collapsing correlated findings from multiple engines into one, while never suppressing malware or secrets categories regardless of dedup logic — keeps the queue at "one ticket per real problem" during exactly the moment an incident-response team can least afford triage fatigue.
How Safeguard fits into the playbook
Safeguard doesn't run your incident-response process end to end, but it supplies the triage inputs the playbook above depends on. SCA resolves your full dependency graph — direct and transitive — against CVE/GHSA advisories enriched with EPSS and CISA KEV, attaches a reachability verdict to each finding, and surfaces the safe upgrade target so the "what do we patch to" question is answered in the finding itself rather than researched separately during an active incident. When a mass-advisory event like an OpenSSL or XZ-style disclosure produces overlapping findings across scanners, AutoTriage deduplicates them into a single correlated view with a measured reduction percentage, while guaranteeing malware and secrets findings are never suppressed — so your responders are triaging the incident, not the tooling.