The threat model that DevSecOps teams have been working from for the last decade was built around accidental vulnerabilities — mistakes that needed to be found and fixed before someone exploited them. That assumption is breaking. Vulnerabilities are increasingly being treated as strategic assets, stockpiled by nation-states and threat actors and held back from disclosure until they’re useful as weapons. That shift changes what “good enough” security looks like across the software delivery lifecycle.
Mike Vizard sits down with Kate Scarcella and Tracy Ragan to dig into what software weaponization actually means in practice for engineering and security teams. Their argument is that the industry has spent years investing in pre-deployment scanning and not nearly enough in knowing what’s actually running in production. The result is sprawling estates of deployed software where teams can’t answer the basic question of which versions, in which configurations, are exposed to a newly disclosed, or quietly hoarded, vulnerability.
They also get into the mechanics of closing that gap. Stronger SBOM practices are the foundation, but only if SBOMs are continuously updated, queryable and tied to the running environment, not parked in a build artifact. From there the conversation moves into automation: using AI-assisted tooling to identify exposed assets fast, prioritize remediation against real exploitability, and push fixes downstream without manual triage at every step.
The other thread is organizational. AI is now both a tool defenders rely on and a source of new risk — data poisoning, model misuse, autonomous agents acting on stale context. Scarcella and Ragan make the case that this is the moment to break down the wall between developers, security teams and data scientists, with shared visibility, shared accountability and a runtime view of the entire software estate as the connective tissue.