Claude Mythos has put the cybersecurity world on high alert, and recently we’ve heard some security professionals declaring that “SBOM is dead” a in a post-Mythos world. The theory is that advanced AI models will uncover vulnerabilities so quickly that there is no point in maintaining a Software Bill of Materials (SBOM) for your software packages, because the AI model will figure that out for you. If a piece of software has a vulnerable dependency, like what happened with Log4j, Mythos (or another highly capable AI model) will uncover that in the parent software package, and the dependency won’t matter.
So is SBOM dead? Probably not, but it depends on your Threat Model, your organization, and your critical software suppliers. AI may reduce the effort required to discover vulnerable dependencies, but it does not replace the operational, governance, compliance, and response value of SBOM.
An SBOM is a structured inventory of all components, libraries, and dependencies within a software application, including their versions and sources. It provides visibility into the software supply chain, allowing organizations to quickly identify whether and where they are affected by newly disclosed vulnerabilities, and take targeted remediation actions.
The problem with highly capable AI models is the speed at which they can identify “bottom-up” vulnerabilities that feed into all types of software packages. If they identify a significant vulnerability in a low-level software component that is widely used, that can have ripple effects throughout an entire enterprise, or across the globe. These models are also extremely adept at reverse-engineering patches and creating working Proof of Concept (POC) code. Patches for vulnerabilities that were previously theoretical can be reverse-engineered and weaponized to develop working exploits within hours.
So what are the implications for the future of SBOM? Here are some considerations:
-
If you develop your own software:
Managing vulnerabilities in software dependencies was HARD even before we started talking about Mythos. Even for a small internal application, mobile application, or web application, new versions and vulnerabilities are released multiple times per sprint. Because these can introduce bugs, create compatibility issues, and complicate testing, many organizations only update software dependencies monthly, quarterly, or even less frequently. Highly capable AI models will significantly increase speed and volume of identified vulnerabilities. This means the already difficult problem of managing updates to dependencies will compound, and the associated risk of not updating will also increase due to the increased availability of exploits and toolkits. If you use tools like npm, some of this work is done for you. But not all packages are updated timely, and MANY package versions are incompatible with each other. An SBOM can help you understand where unpatched vulnerabilities exist, and where replacement packages or other mitigations may be required. Also, many organizations are not as fortunate when it comes to legacy software. If your software has dependencies that are not managed by a package manager (e.g., npm), you need to ensure you are aware of vulnerabilities in that software, and have the ability to mitigate them.
-
If you rely on smaller software vendors:
You may or may not develop your own software, but if you rely on smaller software vendors, they may not be prepared to address everything discussed above. If you rely on older software that is no longer supported, this is an even bigger problem. AI models will uncover vulnerabilities in this software – the question is whose AI models will find it first. If defenders uncover the vulnerabilities first, you may have warning that they exist. But if attackers find them first, you have limited choices. This is where Defense In Depth, effective monitoring, and Zero Trust are critical. Prioritization is also important. You need to understand your security posture as it relates to third-party applications, and prioritize your efforts in areas that are business critical, involve sensitive data, and support compliance requirements.
-
If you have SBOM-specific compliance requirements:
For all the reasons mentioned above, certain laws, regulations, and procurement frameworks now drive SBOM practices. In the United States, Executive Order 14028 made SBOM a significant software supply chain expectation in federal procurement and supplier assurance. In healthcare, the FDA now expects SBOM-related documentation as part of cybersecurity submissions for certain medical devices. In Europe, the EU Cyber Resilience Act makes software component transparency a direct compliance issue for products with digital elements sold into the EU market.
In Summary:
If you only use updated, supported Commercial Off-the-Shelf (COTS) software and cloud solutions from large, reliable software companies, SBOM may provide less operational value and risk reduction for you going forward. (But you could still have compliance requirements related to SBOM)
Unfortunately, most companies don’t fall into this category. Regardless, all organizations can expect a heightened volume and urgency to patch their software, and we can expect an increase in zero-day exploits for even the best software and cloud-based solutions. So for most of us, SBOM is not dead; in many cases it becomes more important as response windows shrink.
What You Can Do:
1) Enhance your Rapid Patch Capability:
Organizations need the ability to identify affected assets quickly, prioritize remediation based on exploitability and business impact, and deploy fixes in a staged, disciplined way. Robust test environments are a major enabler here: when pre-production environments closely mirror production, teams can validate patches, dependency updates, and configuration changes faster and with more confidence, reducing the tendency to delay updates out of fear of breaking critical systems. Strong rollback procedures, deployment rings, and clear decision criteria also help organizations move faster without turning patching into unnecessary operational risk.
2) Understand Your Software Risks and Dependencies:
Review the third-party software in your environment, starting with software that is exposed externally, is critical for operations, impacts sensitive data, or has compliance implications. If you develop your own software, this should include all dependent software packages in use. Assess each piece of software to evaluate the likelihood that it will receive timely patches if a vulnerability is discovered. If third-party supportability is a risk, develop plans for responding in the event of zero-day exploits, and implement mitigating controls as appropriate.
3) Rethink Defense In Depth:
We’ve been talking about Defense in Depth for decades, but it’s an ongoing struggle. In this new era, organizations need to shift their DoD posture to prioritize the software that is most vulnerable to unmitigated and rapidly exploited vulnerabilities.
4) Monitor, Monitor, and Respond:
Bad things will happen. There are many tools in our toolbelts to help prevent or limit those occurrences, but the coming years will test our capabilities. Adversaries will compromise our defenses, and the next step is knowing when they do, and responding. There is a narrowing window in which we can shore up these defenses.
5) Deliver the Table Stakes:
Organizations need robust security fundamentals to be able to respond to this new threat environment. Capabilities such as Asset Management, External Attack Surface Management, Rapid Patch Capability, Secure Configuration Management, and DevSecOps will separate organizations that succeed from those that fail.
How Protiviti Can Help:
Protiviti offers a variety of security services that help clients improve dependency visibility, enhance rapid patch and testing capabilities, and strengthen the monitoring, prioritization, and defense-in-depth measures needed to respond when exposure windows shrink. This includes services such as:
- Mythos Response Capabilities Assessment
- Software Supply Chain and SBOM Documentation
- Zero Trust Strategy and Architecture
- Tabletop Exercises for Zero-Day and High-Velocity Vulnerability Scenarios
- Application Security and DevSecOps Enhancement
- Vulnerability and Patch Management Process Improvement
- Third-Party and Legacy Software Risk Assessments
- Detection, Monitoring, and Response Capability Enhancements
- Threat Modeling and Compensating Controls Design
