Most security leaders still think they are protecting internally built applications. However, they are not. They are instead protecting a constantly changing collection of external code that only looks internal. The Black Duck OSSRA (Open Source Security and Risk Analysis) research reveals why.
The annual OSSRA report, now in its eleventh edition, examines vulnerabilities and license conflicts found in over 900 codebases across 17 industries. The scale matters more than the sectors. When identical dependency patterns appear across unrelated industries, the issue is not developer behavior. It is structural software production.
The average application carries 581 open-source vulnerabilities and 87% of codebases contain at least one vulnerability. At this point vulnerability presence is not an exception state. It is the default operating condition of modern software.
The vulnerability counts are the first measurable symptom that the software supply chain has expanded beyond organizational boundaries, while security oversight has not. Organizations are still governing software as a product they create, while in practice they are operating a system they assemble.
The Supply Chain Is Now Autonomous
AI integration changes software supply chains in a subtle but important way. In previous open-source adoption waves, developers deliberately chose frameworks, packages, and libraries.
Ram Varadarajan, CEO at Acalvio, frames this as a shift in how enterprises evaluate software providers-
“The 2026 OSSRA research data confirms that AI-assisted development has moved from a productivity experiment — think vibe-coding — to a primary source of systemic risk, looking no further than the GTG-1002 attack recently documented by Anthropic.”
He states, “Organizations are going to need to shift from basic security scanning to comprehensive full-spectrum protection and governance. Automated, AI-driven defenses, and also including IP, licensing, and automated dependency management.”
Today, large portions of a codebase are selected through automation:
- Code assistants suggesting libraries.
- Model SDKs pulling dependencies.
- Package managers resolving versions automatically.
- Pretrained AI models embedding opaque components.
The developer is no longer choosing components. The development environment is choosing them on the developer’s behalf.
This is why duplicated dependencies matter more than they appear in the report. A single vulnerable library no longer appears once in an application.
It appears everywhere, sometimes dozens of times, across microservices and containers.
Customer Trust Has a Supply-Chain Dependency
A vulnerability can be patched. A system whose components cannot be identified cannot be defended, audited, or contractually attested. As organizations adopt AI-assisted coding, software composition changes continuously.
Dependencies update automatically, models evolve, and generated components may not be tracked with the same rigor as traditional libraries.
Saumitra Das, Vice President of Engineering at Qualys, attributes the rise in vulnerabilities to expanding transitive dependencies across modern applications-
“While 581 vulnerabilities per application sounds dramatic, it’s largely transitive dependency sprawl, inherited multiple layers deep. The 107% year-over-year increase reflects compounding complexity, not careless development. It is also reflecting the dominance of vibe coding using libraries from wherever it can, as quickly as it can, increasing the code surface.”
Security exposure is no longer proportional to the amount of code a company writes. It is proportional to the number of components it inherits.
Regulation is only one driver. Vendor risk management is becoming the stronger one. Third-party risk assessments now frequently include Software Bill of Materials (SBOM) expectations, provenance documentation, and disclosure timelines.
Buyers are no longer evaluating vendor security practices. They are evaluating vendor supply-chain awareness.
Buyers want evidence that a vendor can respond to a newly discovered upstream vulnerability quickly and accurately. That requirement assumes something many organizations still lack: real-time inventory of their software supply chain.
Governing Machine-Speed Development
Risk is no longer introduced at the moment of coding. It is introduced at the moment of assembly, and is increasingly automated.
The point of failure has shifted from programming errors to dependency selection decisions that no human directly makes.
Randolph Barr, Chief Information Security Officer at Cequence Security, describes this change as a security control problem rather than a developer behavior problem-
“Security programs need to change from controlling things only sometimes to continuously governing things automatically so they can keep up with development that happens at the speed of a machine.”
“To do that,” he added “workflows need to be re-architected, identity and access rules need to be tightened around automation, and security decisions need to be made earlier in the lifecycle. As for governance, AI development won’t stop until it catches up, so security teams need to redesign their programs to work at the same speed instead of trying to make old methods work in a very different way.”
This is the inflection point the report is actually capturing. Software is transitioning from written systems to generated systems.
The Software Supply Chain Is Now the Attack Surface
The report contains a statistic many security leaders will recognize immediately: 65% of organizations experienced a software supply-chain attack in the past year.
Attackers have discovered it is easier to compromise one shared component than thousands of defended applications.
Instead of attacking applications, attackers increasingly attack upstream ecosystems. Black Duck notes that 66% of these incidents involved malicious packages intentionally published to repositories, while others involved legitimate packages that were hijacked.
The repository has become a primary intrusion vector, not a distribution channel.
This explains the doubling of vulnerabilities. Organizations are not writing dramatically worse code. They are inheriting risk. The modern application is a layered dependency graph.
Organizations no longer control the security perimeter of their software. They participate in a shared one.
One vulnerable library propagates across microservices, containers, and distributed systems simultaneously. The breach entry point moves upstream, often outside the organization’s direct control.
Software At Your Company Is No Longer Written by Your Company
The Black Duck research reveals why most security leaders still think they are protecting internally built applications, but they are not.
The average application now carries 581 open-source vulnerabilities and 87% of codebases contain at least one vulnerability.
AI-assisted development has quietly separated authorship from ownership. Companies are now accountable for code they neither wrote nor reviewed.
Modern applications are assembled through code assistants, model SDKs, automated package resolution, and generated snippets that pull in entire dependency trees.
Diana Kelley, Chief Information Security Officer at Noma Security, emphasizes:
“For security teams, visibility is non-negotiable. Organizations must know exactly what is in their software, including open source components, transitive dependencies, and embedded AI models. Accurate, continuously updated SBOMs and AI BOMs, along with automated vulnerability and license management, are baseline requirements.”
Regulation Is Catching Up
The governance gap the report identifies is colliding with regulation.
The EU Cyber Resilience Act and the EU AI Act both emphasize traceability and vulnerability management. Black Duck explicitly notes regulatory pressure makes the traditional “ship and forget” software model untenable.
Meanwhile, U.S. federal procurement rules already require SBOM documentation for certain vendors. Enterprises are adopting similar expectations in third-party risk management.
Organizations must prove they understand what exists inside their software.
Security programs were built to evaluate intentional engineering decisions. They now must govern automated composition.
The OSSRA report is not primarily documenting vulnerable software. It is documenting a mismatch between how software is built and how security programs still assume it is built.
Regulation is not creating new security obligations. It is formalizing the realities the development model already produced.
FAQs
1. How does AI-assisted coding increase software supply-chain risk?
AI coding tools assemble applications by pulling libraries, packages, and model components automatically. The organization inherits vulnerabilities from dependencies it never directly selected or reviewed. Risk shifts from developer mistakes to component provenance.
2. Why are SBOMs becoming mandatory in vendor security evaluations?
Buyers no longer trust security claims alone. They need proof a vendor knows exactly what components exist in its software and can rapidly respond to a newly disclosed upstream vulnerability. An SBOM functions as operational transparency, not compliance paperwork.
3. Why do modern applications show hundreds of vulnerabilities even when development practices are mature?
Most vulnerabilities now originate in transitive dependencies several layers deep in the software stack. Companies are not writing insecure code at scale. They are inheriting insecure components at scale.
4. What changed about the software attack surface in the last few years?
Attackers increasingly target shared upstream repositories and packages rather than individual companies. Compromising one widely used component provides access to thousands of organizations simultaneously, making supply-chain attacks more efficient than direct intrusion.
5. What security strategy replaces traditional application security in AI-driven development?
Security must move from periodic code review to continuous software composition governance. The focus shifts to dependency tracking, provenance verification, automated policy enforcement, and real-time monitoring instead of post-development scanning.
To participate in upcoming interviews, please reach out to our CyberTech Media Room at info@intentamplify.com
