Abby Kearns is CEO of ActiveState, a veteran tech executive with 25+ years scaling enterprise software companies.
getty
Most boards believe their organization has a working vulnerability management program. And, why wouldn’t they? All the evidence they’re presented with would suggest that to be the case. Scanners run on schedule, reports get filed and audits pass. So, what’s the problem?
The problem is that the evidence outlined above does not accurately confirm what is actually running in production for a growing share of enterprise software. That gap has become a board-level exposure.
Why now? Open source is now in 98% of commercial codebases, and the average number of known vulnerabilities per codebase rose 107% year over year (YoY), with 87% of audited applications containing at least one known vulnerability. Those figures reveal the scary truth about what scanners cannot see. Additionally, around 16% of open-source components now enter applications through channels that legacy scanning tools were never designed to monitor.
Now, with the increased use of AI in everyday workflows, engineers and security teams enter open-source components into everything from copied code to vendor binaries, producing a colossal mountain of AI-generated content and tools. Yet, only 24% of organizations review AI-generated code with anything close to the rigor applied to code a person wrote.
As a result, the assumptions underlying traditional vulnerability management no longer hold. Vulnerability management assumes a finite, knowable inventory. That includes a list of components, a catalog of their flaws and a remediation path that traces back to a maintainer or a patch.
This brings us face-to-face with the elephant in the room: AI-assisted development does not produce a finite inventory. Rather, AI-assisted developments produce a continuously regenerating, uncontrollable inventory. To further complicate matters, an increasing share of production code may never have been explicitly selected by a developer. Some vulnerabilities stem from application logic rather than a named dependency, while effective remediation depends on understanding how the code was generated or introduced—information that often was never recorded.
Discovery is not the only function of vulnerability management challenged in this world of prominent agentic AI use. Remediation is a whole other feat. Verizon’s 2026 Data Breach Investigations Report (DBIR) found that vulnerability exploitation became the leading initial access vector for breaches for the first time in the report’s 19-year history. In fact, exploitation was involved in 31% of breaches. Median time to patch climbed from 32 days to 43, a 34% increase YoY.
Security teams, who were already plagued by alerts before the generative AI era, are increasingly overwhelmed. The volume of identified vulnerabilities now outpaces many organizations' ability to investigate and remediate them, while additional issues continue accumulating faster than teams can address them. While more scanning may seem like a great stride forward at first, it becomes noise, adding to the growing list of too many problems to fix.
Boards should pay attention to this shift for many reasons. Despite a clear, growing challenge plaguing vulnerability and exploit management, they still must meet compliance requirements. Software bill of materials (SBOMs), scanning and documented remediation are necessary, and the regulatory mandates pushing companies toward them point in the right direction. But when nearly one in five components enters an application through a channel with little or no visibility, and fewer than a quarter of organizations review AI-generated code with real rigor, organizations are left with an SBOM built from what the scanner found: an incomplete inventory submitted with the confidence of a complete one.
Historically, boards often treated successful compliance audits as a reasonable proxy for security posture. Today, however, an audit can only validate the controls and assets it actually measures, leaving potentially significant blind spots outside its scope.
As a result, regulators are rightfully asking the harder questions. For example, beginning on September 11, 2026, the EU’s Cyber Resilience Act will require all manufacturers to report actively exploited vulnerabilities and severe incidents, with full compliance required by December 2027.
In the U.S., SEC rules require public companies to disclose material cybersecurity incidents within four business days of determining materiality and to describe their cyber risk management practices every year. Similarly, the Cybersecurity and Infrastructure Security Agency (CISA) is in the midst of developing new requirements for critical infrastructure organizations to disclose any covered cyber incidents (and any ransomware payments they made as a result) to the CISA within a given time period.
While none of these existing regulations ask whether a scan was run, they do ask whether the organization can show it understood and managed the risk before something went wrong, which is a materially higher bar than the one most vulnerability management programs were funded to clear.
The new question worth asking internally before a regulator asks it externally is whether anyone can trace a given piece of code already in production back to where it came from and who, or what, decided it belonged there. Answering that requires treating provenance as a build requirement rather than an audit artifact assembled afterward. It also requires clear ownership of dependency trust decisions, much as organizations already assign ownership for evaluating and approving third-party vendors.
Vulnerability management is not obsolete. No board should dismantle its scanning program because the assumptions behind it are strained. Scanning and patching were always meant to be the layer that catches what slips past a deliberate decision about what belongs in the environment. For a growing number of organizations, that earlier decision is no longer being made by anyone in particular. Until it is, the audits will keep passing, and the exposure they were built to catch will keep showing up anyway.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
>> Home