Secure coding just can’t stay abreast with AI adoption, much less pull ahead, leaving a yawning risk gap that threatens software supply chains, new research shows.  

Virtually every organization (95%) now use AI tools in software development but just 24% put AI-generated code through rigorous security paces, Black Duck’s Navigating Software Supply Chain Risk in a Rapid-Release World report found. This, at a time when the company says the software supply chain is “under siege,” with the last year seeing 65% of organizations victims of an attack.  

Noting that by 2030, “95% of code is expected to be AI-generated” and even now is around 30% at large enterprises and “close to 90-95% at small startups,” Saumitra Das, vice president of engineering at Qualys, there “is more code being generated than humans can reasonably even review for correctness, functionality, readability and security issues.”  

For the study, UserEvidence probed 540 software security leaders and practitioners, found security fell far short of where it needs to be—three quarters of those surveyed do check AI for security risks, but just a quarter actually run AI-generated code through IP, license, security, and quality evaluations. 

“Organizations should assume that AI-generated code expands their software supply chain risk, not just their development speed,” says Jason Soroko, senior fellow at Sectigo, who says the gap between AI adoption and security rigor “leaves large blind spots in provenance, obligations, and exploitable flaws.”  

Black Duck CEO Jason Schmitt urged organizations to “prioritize robust security frameworks,” focusing on AI-generated code and dependency management if they want to build resilient software supply chains. 

“AI can amplify dependency sprawl and introduce opaque third-party components that traditional AppSec programs were not built to inventory or govern at rapid-release cadence,” says Soroko, resulting in a widening gap “where shipping gets easier while accountability and assurance get harder, and the downstream cost shows up as security exposure, compliance friction, and slower incident response when something breaks.” 

The resiliency that Schmitt eluded to is not out of reach. The study pointed to dependency management as key to being prepared. The findings showed that 85% of organizations astute at tracking and managing open source dependencies are “significantly more prepared” when it comes to security open source software than the average (57%). 

Automation, too, can play a significant role by compelling faster remediation. Among those organizations that perform continuous monitoring, three in five respondents say it takes a day or less to remediate critical software vulnerabilities, far better than the overall of 45%. 

The study also found that organizations that validate Software Bills of Materials (SBOMs) from external suppliers see a sharp improvement in evaluating third-party software and responding to critical vulnerabilities. Just over three in five of the respondents who focus on SBOM validation say they’re “highly prepared” to evaluate third-party software, with nearly as many (59%) claiming to respond to critical vulnerabilities within a day regularly. 

While compliance is not security—and companies struggle to understand and operationalize complex regulatory requirements (35%)—it can certainly improve remediation. Black Duck’s research shows that it behooves organizations to have compliance controls in place—those that do, remediate critical software vulnerabilities more efficiently. For example, 49% of those with three compliance controls in place take only a day to remediate flaws, while even more (54%) do so when there are at least four compliance controls in place.  

The sheer volume of AI-generated code has given rise to code review companies “that use AI models to review code, because humans cannot scale,” says Das, who believes “we will need new architectures for dealing with the kind of issues discussed in the report.”

Those architectures, he says, must include: 

• AI models that are diverse in their training datasets to review the generated code 

• Automation via, for example, MCP that can take any code being compiled and send it to vendor A for security reviews, understand the findings, and use vendor B to automate the patching of the issues found. Agentic workflows will be needed to fix issues found with large generated codebases with minimal human intervention. 

• QA will need to evolve to better test various scenarios with AI-generated harnesses and test cases. 

• To better understand if AI-generated code violates a license, AI model providers must provide better guarantees on what code they have used to train their data. This is similar to how image generation models must avoid generating copyrighted characters. 

Soroko believes security teams can close the gap “by treating AI output like third-party software and enforcing the same controls by default inside the developer workflow.” He recommends starting with dependency management “because organizations that track and manage open source dependencies well report far higher preparedness” and then “harden the pipeline with automatic continuous monitoring to accelerate remediation, since teams with automation fix critical vulnerabilities within a day much more often, and much more quickly.” 

SBOM validation should be “non-optional for suppliers,” and compliance maturity should be raised by implementing multiple controls. “Put these requirements into CI with clear pass fail gates, codified policy, and audit-ready evidence so security becomes repeatable at AI speed instead of negotiated release by release,” Soroko says.