Topic starter
21/08/2026 4:48 pm
TL;DR: Enterprise software is still dominated by open source, with 85% of code bases relying on it, while 235,000+ CVEs with known fixes were identified from 2016 to 2025 and active exploitation can begin within 10 hours of disclosure, according to Rapidsort. The operational lesson is that vulnerability reduction and runtime evidence matter more than post-deployment detection when sensitive-data sectors need both resilience and auditability.
Editorial analysis by NHI Mgmt Group, based on content published by Rapidsort: “Navigating the Evolving Threat Landscape”.
By the numbers:
- 85% of enterprise software is open source.
- Active exploit activity can begin within 10 hours of vulnerability disclosure.
Key questions
Q: What breaks when vulnerable software is left unpatched or poorly prioritized?
A: Unpatched vulnerabilities let attackers use known weaknesses to gain control, move laterally, and compromise data or services at scale.
Q: Why do open-source components and CI/CD pipelines increase software supply chain risk?
A: Open-source components and CI/CD pipelines expand the attack surface because they introduce third-party code, automation, and many trusted handoffs.
Q: How do SBOMs and runtime bills of materials complement each other?
A: An SBOM tells you what was packaged, while a runtime bill of materials tells you what is actually executing.
Practitioner guidance
- Implement intake-stage software controls Block vulnerable base images, libraries, and packages before they enter build pipelines, and require approved hardened sources for regulated workloads.
- Pair SBOMs with runtime evidence Use SBOMs to declare intended software content, then verify deployed execution with runtime bills of materials so audit records reflect reality.
- Reduce unused components in production images Remove packages and binaries that are installed but not required, then keep the resulting image set continuously refreshed as disclosures change.
Bottom line: The article’s core risk is that software supply chain exposure is created long before deployment, when vulnerable components are admitted into the stack and left to persist.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:07 pm
Elimination at source is now the governing idea, not a niche hardening tactic. Once software ecosystems are dominated by open-source components and exploit windows can open within hours, security teams cannot treat detection as the primary control. The practical issue is not whether alerts exist, but whether vulnerable components survive long enough to become reachable. For practitioners, that means the control objective moves upstream into intake and build governance.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
A question worth separating out:
Q: When should security teams prioritise attack surface reduction over more vulnerability alerts?
A: When the organisation processes sensitive data, operates at scale, or faces short exploit windows, reducing exposure matters more than adding another detection layer. If the software never reaches runtime in a vulnerable state, alerts become secondary to preventing the risk in the first place.
👉 Read our full editorial: Software supply chain risk shifts from detection to elimination