In our last two installments, we’ve learned how two new, AI-enabled forces are working together against defenders. Machine-speed exploit development has collapsed the cost of building an attack, and that collapse has enabled attackers to generate a list of vulnerable targets simply by looking for known vulnerable code. Either force, alone, would strain a security program, but together they capitalize on a weakness that organizations have never been able to solve, and the pressure on that weak spot makes this moment different from the steady escalation in threat that security leaders have managed for years.
Simply, enterprise technology teams cannot provide a current and complete list of all the applications running in their environments. The configuration databases meant to track deployed systems consistently lag operational reality, shadow applications appear faster than governance can catalog them, and acquisitions absorb entire application portfolios that nobody ever inventoried during diligence. Even more troublingly, users are downloading apps and development teams are standing up cloud services that never enter any formal registry. The high-level inventory assumption and the facts on the ground quickly drift apart, and the gap in awareness grows in the dark.
None of this is negligence, but the accumulated result of decades of reasonable decisions made when application visibility was an important control, not an existential requirement. When cost compression shrinks the time to vulnerability exploitation, and scale of attacks is driven at machine speed, the enterprise visibility gap becomes the precise opening that AI-assisted adversaries are optimized to exploit.
The Gap Is Measurable
Vanta, whose platform tracks application usage across its enterprise customer base, found that 55% of the average enterprise's applications operate outside formal IT governance. . These are not the common trope of abandoned test systems. They are production applications that process business data, carry vulnerable components, sit reachable from networks, but are invisible and unaccountable to the teams responsible for protecting them. They include new and leading technologies from @anthropic, @openAI, and @cursor, to name a few.
Even when applications are being tracked, they carry exposure that isn’t seen. The Black Duck 2025 Open Source Security and Risk Analysis Report found that 97% of commercial codebases contained at least one open-source component, and 81% contained a vulnerability rated high or critical. Nearly half of those high and critical flaws arrived through transitive dependencies, components no developer explicitly chose, pulled in automatically by other parts of the application. Of all the open-source components in a typical codebase, only one-third were deliberately included; the rest arrived the same way.
Layers No Developer Chose
Sonatype's analysis shows that the average enterprise application carries more than 180 third-party open-source components, and that 75% of vulnerable dependencies go unpatched for over a year, despite a fix being available for nearly all of them. Even when the fix is available, the enterprise awareness that it’s needed is not.
Log4Shell, in 2021, showed this mismatch at full scale. More than 80% of the packages affected by the Log4j vulnerability depended on the compromised component indirectly, and the exposure was invisible to every defender who had never had reason to look that deeply. That was a single event in 2021. The new potentially AI-accelerated campaigns will be built to find exactly that kind of invisible dependency across any application that touches a public network.
Four Commitments to Real Change
A compounding problem resists any single fix, so an appropriate response will need to be explained, championed, and sustained beyond the reach of the security team.
The enterprise, first, must understand and acknowledge the technical estate is larger than the documentation. This is a leadership call, because chief information and security officers need to stop measuring risk against the easy and known subset of applications in their records and deliver visibility into the full environment as it actually exists. The exercise will uncomfortably expose scope that governance never accounted for, but that visibility is now a table stake because adversaries can act against that full attack surface.
Defense against vulnerable applications must move upstream, not downstream. Official advisories commonly arrive well after the security community has described a vulnerability. The reality of that is described in detail in my recent post on AI acceleration. Security commits in public repositories are the canary in the coal mine, and an organization watching the upstream sources recovers time that downstream advisory monitoring has already given away.
Application visibility and transparency must become part of application and service procurement, now. Requiring a Software Bill of Materials (SBOM), a comprehensive inventory of every application component, as a condition of each new contract and renewal costs nothing to mandate. Paired with clear contractual terms for patching and disclosure, it stops new blind spots from forming, and while it may not fix the legacy of transparency debt, it also tells vendors exactly what the organization now expects.
Exposure and interoperability between applications and services must be audited and rationalized. Every application pulled back from direct internet reachability, or isolated from unrelated systems, raises the attacker difficulty and expense to find and attack it. For most organizations this is the highest-leverage action available while the deeper visibility work proceeds.
Information asymmetry is the attacker’s advantage. An AI-assisted adversary scanning public repositories does not need to understand your application inventory, it only needs to read the public code, identify the exploitable conditions, and target whoever has pulled that software down. The weakness is obvious to the attacker and invisible to the defender. Organizations that close that gap, that build current visibility into their real application estate, watch the upstream signals that precede published advisories, and treat component transparency as a governance requirement rather than a compliance checkbox, will have something to work with when the next wave arrives. The rest will keep learning about their vulnerable applications when someone else shows them.
