From Static Inventory to Real-Time Defense: Why the SBOM conversation has to change now

When the next widely exploitable vulnerability appears, your organization will have far less time to respond than the processes you have built were designed to handle. That is not a prediction. It is what the data shows, and it is already changing what it means to have a mature software supply chain security practice.

This piece is built around three questions. They are operational, not theoretical. Most organizations working in software supply chain security today cannot answer all three reliably. That gap is about to become the most consequential variable in the field.

The Window Is Gone

Vulnerability management has always assumed time. A researcher finds an issue, discloses responsibly, and defenders have a window to patch before exploitation occurs. That assumption shaped everything: tooling, team structures, patch cycles, board reporting cadences.

Recent KEV-based analyses show the average time between disclosure and exploitation has dropped dramatically over the past decade. In 2018 typical time-to-exploit was measured in years. By 2022 it had fallen to months. By 2024 to days. In some cases exploitation now begins within hours of disclosure, and the average time between disclosure and operational weaponization continues to shrink. The direction is not reversing.

Regulatory expectations are moving in the same direction. Federal acquisition policy, secure-by-design guidance from CISA and partner governments, and implementation timelines under the EU Cyber Resilience Act all assume organizations can rapidly identify where vulnerable components and cryptographic dependencies exist across their software portfolios.

The reason is not simply that attackers have become more capable. Capability itself is being automated. AI systems like Anthropic’s Claude Mythos can now chain separate vulnerabilities into working exploits with minimal on no human involvement. They can scan codebases at a scale and speed no research team can match. And crucially, this happens across many actors at once.

The practical consequence, as Forrester Research noted in its April 2026 analysis of Project Glasswing, is that the same vulnerability will no longer be discovered once. It will be discovered multiple times, by different actors, at roughly the same time. Some will follow responsible disclosure. Some will not. The find-report-fix model assumed a single discoverer and a linear timeline. Neither assumption holds. The limiting factor in security is no longer the ability to find problems. It is the ability to absorb, prioritize, and act on them before adversaries do.

Project Glasswing is an Anthropic-led initiative giving critical infrastructure partners and open-source maintainers early access to frontier AI vulnerability discovery capabilities for defensive use. It buys time. But similar capabilities are likely to diffuse beyond controlled environments, and nation-states are developing their own independently. The window Glasswing creates is real. It is not permanent.

Three Questions. Answer Them Honestly.

When a zero-day lands and the exploit is already circulating, your SBOM practice will be tested against three questions. Not against your schema compliance. Not against your generation tooling. Against these:

1. Do you know where this component version exists across every product you ship and operate, across your entire portfolio, right now?
2. Can you determine your blast radius, which products are affected, which customers are exposed, and what the downstream dependencies are, in hours rather than days?
3. Can you communicate that risk clearly to operators and customers, before they hear about it from someone else?

If any of those answers is not a reliable yes, that is the gap. Not a format gap. Not a schema gap. An operational gap.

Forrester is direct on this point: without usable SBOMs, fixes arrive faster than organizations can map impact. Static asset inventories fail when discovery and patching happen continuously. An SBOM generated once and stored is not a defense. It is a false assurance.

There is something else worth naming here. AI vulnerability discovery tools, however capable, operate without knowledge of your control environment, your deployment context, or what is most important to your organization. That contextual judgment belongs to the defender. Understanding your own blast radius, knowing which exposures are actually reachable in your environment, and prioritizing based on business impact: these advantages only exist if your inventory is accurate, current, and queryable. That is what an operationally mature SBOM practice provides. It is the defender’s asymmetric advantage. It only counts if you have done the work before the incident, not during it.

Four capabilities that separate operational from aspirational

Building toward operational maturity means closing the gap on each of these:

1. Query at speed. Portfolio-level component lookup that answers whether you are affected, in minutes. Not a spreadsheet exercise. Not a ticket to the engineering team.
2. VEX as workflow. Vulnerability Exploitability eXchange documents are how you communicate reachability and context to customers under pressure. VEX generation needs to be as automated and real time based on the SBOM itself.
3. Continuous, not periodic. SBOMs generated at every build, components monitored against CVE feeds on an ongoing basis. Newly disclosed vulnerabilities trigger alerts, not quarterly reviews.
4. Decisions, not findings. A list of CVEs is not an action plan. The goal is remediation velocity. Your SBOM practice should drive prioritization and impact analysis as much as discovery.

What the Community Needs to Push On

Adoption is no longer the primary argument. The field has largely accepted that SBOMs are necessary. The argument that needs to be made now is operational. These are the areas where the conversation needs to move:

Query infrastructure. Standardized, fast, federated query APIs need to be treated with the same seriousness as generation standards. An SBOM that cannot be queried at speed under incident conditions is an artifact, not a capability.

Automated and always up to date sharable VEX as a standard workflow. The speed and quality of VEX communication separates organizations that lead the response from those that follow it. VEX needs the same automation investment as generation.

Where This Leaves You

Go back to those three questions:

1. Can you locate a specific component across your entire product portfolio in real time?
2. Determine the exploitability status, and communicate that risk clearly to customers before they hear it elsewhere?
3. Most importantly, can your customers connect that exposure to the products affected and the business functions they support?

If the answer to any of them is not a reliable yes, that is where to start. Not with schema debates. Not with format working groups. With the operational capability to answer hard questions fast, under pressure, when it matters.

The organizations both producers and consumers doing this well are treating their SBOM practice as live infrastructure, not periodic compliance. They are building the muscle now, while there is still time to build it deliberately rather than under fire. The velocity of AI-driven discovery means that window is shorter than most teams ever assumed.

Organizations that treat SBOMs as live infrastructure rather than compliance artifacts are already demonstrating faster mitigation timelines and clearer customer communication during active vulnerability events.