Scanning an Existing Repository for Undisclosed Copyleft Fragments Added by AI Assistants

Scope the repository and its history first

Dependency-based software composition analysis was built to find declared packages. A snippet pasted into a first-party file has no manifest entry, so a package scan will not report it. The audit therefore has to examine the source files themselves.

Start by deciding what is in scope: the current default branch, long-lived release branches, full commit history, forks, vendored directories and generated code. Full history matters because a fragment removed last quarter may still exist in a shipped release. Then separate custom-developed code from code that came from outside the organisation. Pedigree analysis, as NIST describes it, maps code to an original source, project name and version so licensing questions can be resolved. The same split is useful here: externally sourced code is already a known quantity, and the first-party files are where undisclosed fragments hide.

Write down the audit method before you run it. NIST SP 800-218A (practice PW.7.1) expects an organisation to decide whether code review, code analysis or both will be used. For this audit a hybrid is the practical choice. Tools produce candidate matches at scale, and people judge the ones that matter.

Identify likely AI-assisted changes

Knowing which changes were AI-assisted lets you prioritise files and interpret findings. Useful signals include commit metadata, co-author trailers where teams have used them, assistant configuration files committed to the repository, and IDE or assistant telemetry where your administrators can export it. Commit message conventions and unusually large, uniform changes can also be hints.

Treat each signal as indirect. A developer may paste from a chat window with no trace in the commit. Trailers depend on team habit. Telemetry may cover only some tools or some periods. Absence of a signal does not mean a change was human-authored, so use these signals to rank files for review and never to exclude code from scanning.

Do not rely on assistant vendors to tell you what a model was trained on. Public statements from regulators note that developers often disclose little about training data. The origin of a snippet has to be established from the code and its history.

Choose and combine detection techniques

No single technique covers the problem. Each has failure modes that you should record in the audit method so reviewers know what a clean result does and does not mean.

• Package-level analysis: Reliable for declared dependencies and licences. Blind to fragments pasted into first-party files. Run it as a baseline, not as the answer.
• Snippet-level matching: Compares code fragments against a corpus of known open source code. Short snippets can be too generic to match meaningfully, and modified code may fall below the match threshold. Coverage depends on the corpus.
• Fingerprinting: Hashes normalised code segments for comparison. Efficient at scale, but renamed identifiers, reordering or restructuring can defeat exact fingerprints.
• Similarity analysis: Scores structural or textual closeness to a known work. It tolerates edits, but a low threshold raises false positives on common idioms and a high one raises false negatives.
• Human review: Needed to judge whether a flagged match is a genuine copy, a common pattern or a coincidence. It is slow, so reserve it for prioritised findings.

Triage by licence obligation and exposure

Copyleft licences such as GPL, LGPL and AGPL differ in what they require and in the circumstances that trigger those requirements. Treat the licence family as one input and have legal counsel assess obligations for your situation. Engineers should supply the facts counsel needs: how much code matched, how distinctive it is, where it sits, and how the product is distributed or exposed to users.

A practical ranking uses four questions. What is the licence of the matched project? How substantial and non-generic is the fragment? Is the file in a shipped product, an internal tool or a test? And is the product distributed to customers or offered over a network? A short, common idiom in an internal script is a different decision from a distinctive function in a distributed product.

Remediation options are generally removal, rewrite, relicensing or attribution, and the choice belongs to the code owner and counsel together. Removal is simplest where the code is not essential. A rewrite should be done independently of the matched code, and counsel should confirm the approach. Relicensing or attribution depends on the licence and on whether the rights holder is identifiable. Whatever is chosen, record the rationale, the approver and the date, including decisions to accept a finding as low risk.

Know the limits, then move the check upstream

A retroactive scan is a point-in-time sample of what your tools could recognise. It cannot show that no copyleft fragment exists. Heavily modified code, very short snippets and code absent from the matching corpus can all go undetected, and similarity thresholds trade false positives against false negatives. State these limits in the evidence record. A documented method with known limits is more defensible than an unqualified claim of a clean repository.

The larger weakness is that review after the fact repeats every time assistants add code. Checking provenance when code is generated reduces new exposure. Trussed enforces policy in the execution path for coding assistants, with actions such as allow, redact, block and escalate for human approval. It provides code provenance: the origin, licence and security context of code. Policy is enforced at runtime, not reviewed after the fact, and the enforcement generates audit-ready evidence. This complements the retroactive scan and does not replace it for code already in your repositories.