Notifications
Clear all
Topic starter
02/09/2026 1:29 pm
TL;DR: Patchmageddon argues that disclosed software vulnerabilities are being exploited faster than most security teams can verify exposure, with median time from disclosure to first confirmed exploitation falling to one day in 2026 and projected to reach one minute by 2027, according to Kusari. The practical shift is from scanning declarations to proving what is actually in software, what is reachable, and what was remediated.
NHIMG editorial — based on content published by Kusari: Patchmageddon and the changing cost of software exposure
By the numbers:
- The report says 95% of open source vulnerabilities live in the transitive dependency layer.
- Only 26% of vulnerabilities on the CISA KEV list were fully remediated last year, according to the report.
- 45% of KEV-listed vulnerabilities remain unpatched after a, npatched after a full year.
Questions worth separating out
Q: What breaks when software inventories rely on manifests instead of source-built evidence?
A: Manifests capture intent, not reality.
Q: Why do disclosure-based vulnerability workflows fail so often in regulated environments?
A: They assume advisories will exist and arrive quickly enough to guide action.
Q: What do security teams get wrong about dependency scanning?
A: They often assume a clean manifest means a clean environment.
Practitioner guidance
- Implement source-built software inventory Resolve dependencies from build and source outputs so the inventory reflects what was actually shipped, including transitive and vendored components, not just what manifests declared.
- Tag every unresolved dependency explicitly Mark incomplete resolution, unknown components, and ambiguous provenance as first-class states so teams can see where the inventory boundary ends and where confidence drops.
- Attach reachability evidence to triage decisions Remove a vulnerable component from the remediation queue only when the code path, call graph, or package reachability is documented and reproducible.
What's in the full article
Kusari's full analysis covers the operational detail this post intentionally leaves for the source:
- A step-by-step breakdown of how source-built dependency graphs are generated from build artefacts and code.
- Operational examples of reachability-based triage and why some vulnerable components can be removed from scope with evidence.
- The compliance mapping behind DORA, PCI DSS 4.0, NYDFS, CISA SBOM elements, and the EU Cyber Resilience Act.
- Examples of how examiners, allocators, and board requests translate into evidence and remediation timelines.
👉 Read Kusari's analysis of why software exposure now requires source-built evidence →
Source-built software graphs: what it means for security teams?
Explore further
02/09/2026 1:30 pm
Source-built evidence is becoming the new baseline for software exposure governance. Declaration-based inventories no longer match the speed or structure of modern exploitation. When vulnerability windows shrink to days or hours, the question is not whether a scanner exists but whether the organisation can prove what was actually shipped. Practitioners should treat evidence quality as the control, not a reporting afterthought.
A question worth separating out:
Q: How do security teams prove software is trustworthy to auditors and boards?
A: They need evidence beyond scanner output: approved provenance, continuous verification, remediation timelines, and enforceable policy gates. Trust is demonstrated by showing how code was introduced, how it was reviewed, how quickly defects were closed, and whether the production state still matches the approved one.
👉 Read our full editorial: Why software exposure answers now require source-built evidence
