The AI Coding Assistant Is Now Part of Your Software Supply Chain
Autocomplete writes a growing share of production code, and it happily suggests hallucinated packages, outdated crypto and credentials copied from a neighbouring file. Governance has not caught up.
Ask an engineering leader what percentage of merged code was authored by a model and the honest answer in 2026 is usually "we don't measure it, but it's a lot." That is a supply-chain input with no owner, no provenance and no review standard beyond the same pull-request process that was already stretched thin.
Four failure modes we see in real repositories
1. Slopsquatting
Models confidently import packages that do not exist. Attackers watch for the recurring hallucinated names and register them. The first developer who accepts the suggestion and runs an install pulls attacker-controlled code into a build container with network access.
2. Context bleed
The assistant reads an adjacent file containing a real key and helpfully inlines it into the new module. It is not exfiltration by the vendor; it is a secret propagating because the tool did what it was asked.
3. Confidently outdated patterns
Training data skews to what was common, not what is correct. MD5 for tokens, string-concatenated SQL, permissive CORS and disabled certificate verification all still appear as top suggestions in specific framework contexts.
4. Silent licence contamination
Verbatim reproduction of copyleft snippets in a commercial codebase is a legal exposure that no scanner in your pipeline is currently looking for.
A governance baseline that fits an existing SDLC
- Dependency allowlisting at install time, not review time. A package that is not in the internal registry does not resolve, so a hallucinated name fails loudly on a developer machine instead of quietly in CI.
- Secret scanning on the pre-commit hook, because the assistant generates secrets into files faster than a nightly scan finds them.
- A required, machine-readable provenance note on pull requests that were substantially model-authored, so review depth can be set accordingly.
- Targeted SAST rules for the specific bad patterns your assistant produces. Sample 200 accepted completions, find the recurring three, and write rules for exactly those.
- Licence scanning at the snippet level, not only at the dependency level.
The measurement that changes the conversation
Instrument acceptance rate against defect rate. Once a team can see that model-authored diffs carry a measurably different bug profile than human-authored ones, the governance argument stops being philosophical and becomes a routine quality decision.
The assistant is not the risk. Shipping its output through a review process designed for a slower, more hesitant author is.
