Auditing Vendored Source Trees for Missing Attribution

Someone copied a 400-line utility or an entire sub-package into src/vendor/ or internal/compat/ three years ago to avoid adding a runtime package dependency. The commit message reads "import helper". The upstream root LICENSE file was omitted because the developer copied only the individual source files. Those files contain no top-level copyright header.

Today, that code is embedded in your shipping build. When a downstream customer demands an SBOM audit or external counsel reviews your repository during due diligence, you have a software provenance hole. You cannot prove whether that code is licensed under MIT, BSD-3-Clause, AGPLv3, or a proprietary repository with all rights reserved.

Dropping third-party files directly into your tree severs the connection between the code and its legal terms. Recovering that paper trail requires locating the exact upstream commit and formalising the attribution in-tree.

The Anatomy of the Attribution Gap

When developers ingest third-party source directly, they discard two critical pieces of metadata: the upstream repository's commit SHA and the parent directory's licensing context.

Most permissive open-source libraries do not enforce per-file header comments. They place a single LICENSE or COPYING file at the repository root. When an engineer copies a subdirectory from that repository into your codebase, those individual files become orphaned from their governing license. In isolation, a source file without an explicit copyright and license notice defaults to standard copyright protection: all rights reserved by the original author.

Treating vendored code without a paper trail as an internal implementation detail creates latent compliance debt. If you cannot identify the exact upstream commit from which the code originated, you cannot verify that the author held the right to license it, nor can you verify transitive license obligations triggered by modifications made to that file.

Fingerprinting Orphaned Sources

Reconstructing provenance requires searching for the original file across public source indexes before local modifications were introduced.

Start with Git object hashes. Git computes a SHA-1 over blob <size>\0<content>. If the file was copied verbatim without formatting changes, the hash matches the upstream blob exactly:

git hash-object src/vendor/helper.go

You can query this hash directly against the Software Heritage archive (SWHID) or public code search APIs. A hit on swh:1:cnt:<sha1> returns the original repository, commit graph, and directory context immediately.

If the file was modified during ingestion or altered by local code formatters, blob hashes will fail. In that case, isolate invariant tokens:

1. Unique string literals and error messages. Search for exact string constants or panic messages across global code search engines.
2. Structural signatures. Strip comments and whitespace, then extract the ordered sequence of exported function signatures and type definitions.
3. AST normalization. Parse the file into an abstract syntax tree, discard identifier names if minified, and generate an n-gram fingerprint of the control flow nodes.

Once you identify candidate repositories, locate the fork point by running a three-way diff between your file and the candidate file across its git history:

git log -p -S "unique_helper_function" -- path/to/upstream/file.go

Find the specific commit where the diff between the candidate file and your imported version is minimal. The remaining delta represents your team's local modifications.

Deterministic Verification

Finding a similar repository is insufficient; you must prove the legal status at the exact moment of ingestion.

1. Verify the commit timestamp and tree. Clone the identified upstream repository. Check out the candidate commit SHA. Confirm that the candidate file matches your baseline before local edits.
2. Inspect the root license at that commit. Verify that the root LICENSE file existed at that specific commit SHA. Upstream repositories occasionally relicense; the license applied to your build is the one valid on the commit date the code was imported.
3. Verify author provenance. Check whether the author of that commit was a maintainer or if the code originated from an unmerged pull request with questionable lineage.

If the upstream source cannot be located or the history reveals ambiguous ownership, the code is unlicensable. You must quarantine the file and replace it with an independently authored implementation.

Remediating the Tree

Once provenance is proven, record the metadata directly in your tree so future audits do not repeat the forensic process.

Every vendored file must carry an explicit SPDX header pointing to its governing license. In addition, place a PROVENANCE.md or machine-readable manifest in the vendored directory:

## src/vendor/PROVENANCE.yaml
files:
  - path: helper.go
    upstream_url: "https://github.com/example/helper"
    commit: "4f8a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a"
    retrieved_at: "2023-04-12T10:00:00Z"
    license: "MIT"
    local_modifications: true

Code ownership requires proof of origin. If you cannot produce the commit SHA and the governing license for every line in your binary, you do not own the artifact you are shipping. Resolve the attribution debt before an external audit forces the issue.