AI coding assistants are taking a larger role in deciding which third-party software enters enterprise applications. Developers can now ask an assistant to solve a coding problem and receive working code that already relies on a particular package or library.
A request to parse a file, connect to an API or add a capability can introduce dependencies without the developer specifically searching for or evaluating them first.
Biswajit De, CTO of CleanStart, sees the shortening of that selection process as an emerging software supply chain concern.
“AI coding assistants are collapsing the distance between ‘I need to solve this problem’ and ‘I have added a dependency,’” De said.
“Earlier, a developer would typically search for a library, look at its adoption, maintenance, vulnerabilities, license, and then add it. Now I can ask an AI assistant, ‘How do I parse this format in Python?’ and end up with an import for a package I didn’t specifically go looking for.”
When AI starts choosing the software
Developers have long relied on third-party software, but AI can compress much of the search and selection process into a coding interaction. A developer may specify the capability needed while the assistant influences which package becomes part of the application.
Package recommendations can happen with little friction because they arrive as part of the answer to a developer’s immediate problem. The choice may receive less attention than it would during a separate search for third-party software, especially when the generated code works as expected. As coding assistants handle more routine development tasks, more dependency decisions may happen within these interactions.
“The biggest risk is losing the context behind a dependency decision,” De said.
An AI-recommended package can also pull additional dependencies into an application. Developers may understand the function they requested without seeing every component added along the way.
“Now you have a dependency in your build, but you may not know why that particular package was selected, what alternatives were considered, or what you are actually trusting.”
More software choices taking place within coding tools creates a challenge for organizations that need to understand what entered an application and why it was allowed.
The missing history behind a dependency
Security teams have become better at finding software once it reaches an application. Scanners, software inventories and software bills of materials (SBOMs) can help organizations identify the packages and versions their applications contain.
Those records provide visibility into software composition, but they may begin after the software selection has already occurred.
“Most security teams have reasonably good visibility once software reaches their scanning and inventory systems, but the gap is earlier in the chain,” De said.
Security tooling may identify a package and version without explaining why an AI assistant recommended it or what entered the dependency graph when the developer accepted the recommendation. Earlier scrutiny also requires looking beyond known vulnerabilities when determining whether software should enter an application.
“I would not reduce it to a vulnerability scan. A package can have zero known CVEs and still be a poor dependency choice,” De said. “I would look at where it comes from, who maintains it, its release history, known vulnerabilities, its dependency graph, licensing, and whether there is enough provenance to verify what we are actually consuming.”
Moving verification ahead of adoption
AI-assisted development can shorten the time between identifying a problem and adding software intended to solve it. Because of this, security teams have less time to evaluate a dependency before developers begin building around it.
De argues that organizations should evaluate software while developers still have the option to choose something else.
“AI can recommend a package in milliseconds. The verification process has to be just as easy to invoke.”
Companies can define requirements around the software allowed into development and enforce those policies during dependency selection. Packages that fail those requirements can be addressed before they spread through applications.
“I would put controls at the point where a dependency is selected, not just where code is built or deployed,” De said.
CleanStart applies that approach through Clean Libraries, which evaluates open-source libraries before developers add them to applications.
“That is essentially the gap we set out to address with Clean Libraries. Instead of waiting for a library to show up in an application and then investigating it, we help developers and security teams make that decision upfront.”
Building security for more autonomous AI
Greater autonomy in coding tools could place more software decisions inside automated workflows. Systems that complete larger development tasks will need clear rules governing which components they can use.
Those rules also need to work at machine speed. Requiring manual review for every package recommendation would limit the efficiency organizations seek from AI-assisted development.
“As AI becomes more autonomous, software supply chain security has to become more machine-readable, policy-driven, and verifiable,” De said.
CleanStart sees verified software components as one way to establish those boundaries before development begins.
“At CleanStart, we see this as a shift from securing individual applications to securing the software foundations and components that AI and developers build with. That means knowing where a component came from, what went into it, whether it can be verified, and whether it meets organizational policy before it is consumed.”
As AI assumes more responsibility for software creation, security teams will need to determine which components automated systems can select before those choices become part of an application.
“The larger shift is from ‘scan what the developer built’ to ‘verify what the machine is allowed to build with.’ As AI takes on more of the software creation process, that verification layer becomes infrastructure, not a final security checkpoint.”
