AI Coding Tools Pick Your Dependencies. Put Control at the Source.
ActiveState
October 14, 2026
Share post:
A developer accepts a coding assistant's suggestion to add a package. The package arrives with its own open source dependencies, and each of those arrives with more. One accepted suggestion brings an entire dependency tree into your build, and nobody chose most of it.
That is how a growing share of software now gets built. AI coding tools and agents make sourcing decisions that used to belong to a person, and they make them at machine speed, inside an editor, with no record of who approved the source. For the CISO, the job is to say yes to AI. The risk in that job is owning decisions you never saw.
Key takeaways
AI coding tools and agents now choose open source dependencies, and one accepted suggestion brings a whole dependency tree that nobody reviewed.
Security leaders carry the accountability for those choices, including what AI pulls into production.
Adding review capacity after the install grows your ability to react and leaves the decision where it was.
The control point for AI-era development is the source: decide what gets in once, and every developer and agent inherits that decision.
Scanners stay as the backstop, with less to find and a cleaner signal.
Who chooses your open source dependencies now?
For most of the history of open source, a person picked each dependency, and that pace gave review a chance to keep up. AI coding tools changed the chooser. An assistant suggests an import, an agent runs the install, and the package manager resolves everything underneath. The mechanisms are specific:
An accepted suggestion pulls in a direct dependency and its full tree of transitive dependencies.
Generated code skips the manual review that used to catch a bad package.
An assistant can suggest a package that does not exist, one registered to match that hallucination (slopsquatting), or one compromised since it was last trusted.
A package compromised since it was last trusted is the hardest of these to spot, and one surfaced last week. On October 8, 2026, a malicious release of tensorlake, the npm SDK for a platform that provides sandboxes for AI applications and agents, went live as version 0.5.144.[1][2] According to the Cloud Security Alliance's research note, its payload ran from a preinstall hook, so it executed "when the package is installed, before any application code imports the SDK."[2] It went after cloud and CI credentials and the configuration files of AI coding tools.[1][2] The package reported more than 100,000 lifetime installs, and npm has since removed the malicious version.[1][2]
The timing is the lesson for a security leader. The decision that mattered was the install, and once it happened, every remaining control was a response. Software development changed when AI started choosing dependencies. The control model has to change with it.
What AI-chosen dependencies cost the security leader
Each unreviewed package turns into a charge somewhere else: rework in engineering, a blocked release, an audit finding, an incident response. Each lands in a different team's budget, so no single owner sees the total. On a new finding, the first question is often the hardest to answer: who owns this?
The accountability has already moved to the security leader. Splunk's CISO Report 2026, a survey of 650 global CISOs, found that 96% of CISOs now oversee AI governance and risk across the enterprise.[3] In coverage of the same report, 78% of CISOs said they are concerned about their own liability for security incidents.[4] You're accountable for every decision AI makes on your behalf, including what it pulls into production.
Auditors and regulators ask the same question in their own terms. They expect you to know and control what is in your software, and regulation is making companies answerable for the open source they ship. Reasonable care means a record you built at the time of the decision, before anything went wrong.
Why more review after the install can't keep pace
The standard response is reasonable. Add scanners, add reviewers, write tighter policy, and train developers on what to accept. The strongest version of that view says AI-aware scanning in the editor and at the pull request can catch a bad suggestion before it merges. Scanners do real work, and they belong in the stack.
The limit sits in the model around them. Detect and react grows your capacity to respond and leaves the decision where it was made: at the moment of install, by whoever or whatever ran it. With AI tools choosing dependencies at machine speed, every install adds to the queue, and the queue grows with your teams' output. The tensorlake payload ran during installation, so a finding that arrived afterward could start the response and could not undo the install. That is the accountability gap AI coding opens when sourcing goes ungoverned. Scanners tell you what got in. Control at the source decides what gets in.
Move the decision about what gets in to the source
Software supply chain security is a sourcing problem before it is a scanning problem. The control point for AI-era development is the source: the place every developer and every agent pulls from. Make the safe decision once, there, and every developer and agent inherits it.
In practice, the model has three parts. Teams pull open source from one trusted source, vetted before anything reaches the build. The approved source is the default source, so following policy becomes the path of least resistance. Scanning stays as the backstop, with less to find and a cleaner signal.
This is the model ActiveState built. The ActiveState Curated Catalog is a private, vetted repository of open source components, and the dependencies AI coding assistants request resolve from it. ActiveState builds open source from source in a SLSA Level 3 build environment, so you know where your packages came from. Developers keep their native commands (pip, npm, and maven) and the artifact managers they already run. Teams that keep their scanners see about 68% less scanner noise from false positives.
What changes for the security leader
The decision moves from after the install to before it, and that changes what you can approve. You can say yes to AI coding tools across engineering, because the packages they request come from a source you already approved. When the board asks what AI brought into production last quarter, you have a record built at the time of each decision, which is what reasonable care looks like.
Engineering gains too: fewer last-minute release blocks and nothing new to learn. That matters, because security can't mandate how developers pull packages. The engineering case is its own conversation, and this look at how AI coding speed affects roadmap reliability is a good place for your engineering leader to start.
Less preventable work ever starts. That is the outcome: work that never has to happen. Control at the source. Keep the speed.
The decision to make this quarter
Ask your engineering leader one question this week: when an AI coding tool requests a package, where does it resolve from, and who approved that source? If the answer is a public registry, the decision about what gets into your software belongs to whoever published last.
Then pick one service and trace the open source dependencies added in the last 30 days. Count how many arrived through an AI suggestion or an agent, and how many anyone reviewed before install. That count shows where your control point sits today, and whether it belongs at the source.
About ActiveState: ActiveState has secured open source for enterprises since 1997. Secure Open Source for the AI Coding Era.
How do AI coding tools introduce open source dependencies?
An assistant suggests an import or an agent runs an install, and the package manager resolves the full tree of transitive dependencies underneath it. One accepted suggestion can bring in many packages that no person chose directly. Generated code also skips the manual review that used to catch a bad package.
What is slopsquatting?
Slopsquatting is an attack in which someone registers a package name that AI coding tools tend to hallucinate. When a developer accepts a suggestion for that name, the install pulls the attacker's package. Governing which packages can be installed at the source closes that path before any code runs.
Where do scanners fit when AI chooses dependencies?
Scanners stay as the backstop: they report what entered the build. Control at the source decides what can enter in the first place, so scanners have less to find and a cleaner signal.
What does control at the source mean for a CISO?
It means the decision about which open source components are allowed is made once, at the source every developer and AI agent pulls from, and every install inherits it. That gives the CISO a defensible record of reasonable care, built before an incident.
How should a security leader start?
Ask engineering where AI-requested packages resolve from and who approved that source. Then trace one service's open source dependencies from the last 30 days to see how many arrived through AI tools and how many were reviewed before install.
.png)
.png)
.png)