When AI Chooses Your Dependencies, Verification Matters More Than Ever

Every AI-generated application begins with a software supply chain decision. 

A developer asks an AI coding assistant to add OAuth authentication to a new application, and within seconds, the assistant produces a working implementation, selects the libraries required to support it and introduces the dependencies needed to make everything work.

The developer reviews the result, verifies that it behaves as expected and moves on to the next task. 

What often goes unnoticed is that the AI has already made several decisions in the software supply chain. It has selected open-source libraries, introduced direct and transitive dependencies, and shaped part of the software foundation long before traditional security controls became involved. 

For decades, those decisions were made deliberately by developers, so every new dependency represented a conscious engineering decision supported by research, documentation, community experience, and organizational standards. 

Software is increasingly being selected by machines and accepted by humans, which is completely changing an important assumption about software supply chain security.

Developers now find themselves asking, “How do we establish trust in software that AI increasingly selects for us?” Security teams can no longer rely on reviewing software after it enters an application, so trust needs to be built into the selection process itself. 

Security Starts With Visibility. Trust Must Start Earlier.

Organizations have invested heavily in technologies that improve software supply chain visibility. Software composition analysis (SCA), vulnerability scanners, software bills of materials (SBOMs) and policy enforcement tools help security teams understand what software exists within an application and identify known risks before deployment. 

These capabilities remain essential, but they all begin evaluating software after it has already entered the development lifecycle.

By the time an unapproved dependency is identified, developers have often written code against it, integrated it with other components, tested the application and validated its functionality.

Replacing that dependency frequently requires code changes, compatibility testing and additional engineering effort that could have been avoided if trust had been established earlier. 

Developers historically decided which libraries and frameworks belonged in an application. AI increasingly participates in those decisions, often selecting software much faster than traditional review processes were designed to handle. 

AI Optimizes for Working Software, Not Trusted Software

A single prompt can introduce authentication libraries, messaging frameworks, API clients, database drivers, serialization packages and dozens of transitive dependencies.

Package managers automatically resolve the rest, expanding the software supply chain before anyone intentionally evaluates every component. 

Most recommendations are technically sound because they are based on publicly available code and widely adopted open-source projects, which makes the software useful. 

But, it would be a mistake to assume that they automatically make it trustworthy. 

This is a reflection of AI’s purpose. Large language models are designed to solve engineering problems by identifying patterns that produce successful implementations. 

They are not designed to evaluate enterprise security policy, licensing obligations, software provenance, regulatory requirements or an organization’s trust model.

Expecting them to make those decisions without guidance is asking them to perform a task they were never intended to solve, and that responsibility hasn’t changed. 

Instead of just reviewing dependencies after they enter development, rules need to be established that govern software selection before developers or AI systems begin building. 

Govern Software Selection, Not Individual Packages

It would be incredibly time consuming to ask developers to review every package AI introduces into an application.

Manual dependency reviews were already difficult before AI, and they become impractical when software selection happens continuously across hundreds of developers and thousands of repositories. 

Enterprises already govern where applications run and how software reaches production. Extending the same discipline to software entering development is simply the next step.

The focus should shift from governing individual packages to governing how software is selected. 

Developers and AI systems should source software from trusted repositories and approved registries containing verified software artifacts that already satisfy organizational security and governance requirements.

Trusted software becomes the default rather than something developers must discover and evaluate for every project. 

Continuous monitoring remains essential, because vulnerabilities emerge, maintainers change and software evolves.

However, monitoring a curated ecosystem of verified software is fundamentally different from governing every package available in a public repository. 

Starting with trusted software reduces unnecessary review, limits downstream remediation and gives developers approved components from the outset. 

Verification Creates Trust

Known vulnerabilities represent only one dimension of software risk. Security teams increasingly need evidence showing where software originated, how it was built, whether it has been modified and whether it satisfies enterprise security and compliance requirements before it becomes part of an application. 

Verification provides the evidence needed to establish trust. It establishes software provenance, validates integrity through signed attestations and demonstrates build integrity through reproducible builds.

Together, these capabilities allow security teams to evaluate software based on known vulnerabilities and on whether the software itself deserves trust. 

This distinction becomes even more important in AI-assisted development. Developers may never know why a particular dependency appeared in an AI-generated response, but enterprises can still define the evidence software must provide before it becomes part of their development environment. 

Even if AI can influence the software selection, only the organization should define its trust model. 

Make Trust Invisible

The most effective security controls are the ones developers rarely notice. Developers should not have to research every dependency an AI system selects or investigate the provenance of every package they use.

Those responsibilities belong within the software ecosystem itself. 

When development tools operate within environments built on verified software artifacts and governed by organizational policy, developers continue building at AI speed while security teams maintain confidence in the software entering their applications. 

AI is changing how software is created, but it should not change how enterprises establish trust. 

The future of software supply chain security will be defined by ensuring that every application begins with software that has already earned trust through verification.

At the end of the day, trust must still be earned through verification.  

Author:

Biswajit De is the Co-Founder and Chief Technology Officer of CleanStart, where he leads the company’s technical vision and product strategy for securing modern software supply chains and cloud-native environments. With more than 17 years of experience in cybersecurity and platform engineering, Biswajit has led the development of innovative security platforms and foundational systems across product engineering, security operations, and large-scale enterprise infrastructure.