By Mike Pittenger

For years, software teams have managed open source risk in two familiar forms: licensing obligations and known vulnerabilities. AI coding assistants introduce a third risk that is harder to see.

Related: Where SBOMs fall short

They can place open source snippets directly inside source files without declaring a package, updating a build file or adding anything to a software bill of materials.

These hidden dependencies expose a weakening assumption behind established software controls: that third-party code arrives through a declared component. When it does not, the Software Composition Analysis tools and SBOM processes organizations rely on may never see it.

Where trails break

When a developer uses an open source package, the package normally appears in a manifest or dependency file. That creates a trail. SCA tools can identify the component, check its license and known vulnerabilities, and include it in the resulting SBOM.

An AI coding assistant can bypass that trail. Because models learn from open source and other publicly available code, an assistant may reproduce a familiar pattern directly inside a file. No package is installed and no dependency is declared. Even a careful reviewer is unlikely to recognize that a block of generated code resembles material from one of millions of open source projects.

The obligations, however, do not disappear simply because the trail does. A reproduced snippet may require attribution or a license notice. Copyleft code may raise broader questions about surrounding proprietary code.

Research shows that this is more than a hypothetical concern. The LiCoEval benchmark evaluated 14 popular language models and found that 0.88% to 2.01% of generated functions were strikingly similar to existing open source implementations. Most models failed to supply accurate license information, particularly for copyleft code.

Those percentages sound small until they meet the scale of a working codebase. In an application with 300,000 functions, a one to two percent rate puts 3,000 to 6,000 functions in play, each one a potential attribution or license obligation that nobody recorded.

Our own early review at Insignary points the same direction. Across a small sample of real-world applications generated wholly or partly by AI, open source snippets turned up in roughly a third of generated files, and in more than half the files from applications built entirely by AI. Traditional SBOMs captured well under a quarter of the dependencies that snippet-level analysis surfaced.

Why controls matter

The GitHub Copilot litigation has already brought the removal or omission of copyright and attribution information into court. The district court dismissed the plaintiffs’ principal DMCA claims, and that ruling is now on appeal. Whatever the eventual outcome, development organizations cannot assume that code is free of obligations merely because an assistant produced it.

Do the benefits of AI coding tools outweigh the risks? Of course. But development and risk teams have faced a version of this question before. In the early days of open source, the first instinct was to hunt it down and strip it out. That impulse faded as the benefits became undeniable, and what replaced it was visibility and control: knowing what you had, where it came from and what it obligated you to do. AI-generated code needs the same shift. The goal is not to ban the assistants. It is to treat what they produce with the same scrutiny already applied to code from outside the organization.

That starts with making AI use visible. Engineering leaders should know which assistants are approved, where generated code may enter repositories and how that use is disclosed in pull requests. The developer submitting the code should remain responsible for reviewing it rather than treating the model as its author or approver.

Find, decide, record

Next, inspect the source itself before code is merged or released. Traditional SCA remains necessary for declared components, but snippet-level analysis is needed to find borrowed code embedded inside files. A match should identify the likely project, version, and its license.

Then route the result through an explicit decision gate. Permissively licensed code may be retained once required notices and attribution are restored. Copyleft or uncertain matches should go to the organization’s open source or legal reviewers, then rewritten or replaced.

Finally, record the decision. Update the SBOM or related attestations, preserve the evidence behind the disposition and identify who approved release. Engineering owns the code it ships; security and open source program teams define the controls; legal specialists resolve the exceptions.

AI has accelerated code production without eliminating software accountability. Controls built around declared dependencies now need to account for code that arrives without one. Once hidden dependencies become visible, organizations can evaluate them using the same disciplined process they already apply to the rest of the software supply chain.

About the essayist: Mike Pittenger is chief strategy officer at Insignary, a Toronto-based provider of software composition analysis technology that identifies open-source components, licenses and vulnerabilities in source code and binaries.

September 3rd, 2026 | Essays | Top Stories