Mapping Load-Bearing Transitive Dependencies to Source Licences

Your automated scanner passes because the root manifest says Apache-2.0. The build succeeds, the image pushes to the registry, and everyone assumes license compliance is solved. Then legal requests a full software bill of materials (SBOM) ahead of an enterprise deployment, or an acquiring audit team pulls the source tree apart. That is when you find that an innocent utility module, vendored into the repository three years ago, embeds an AGPL-3.0 helper five hops down its call graph.

A top-level manifest is an assertion of intent, not a record of fact. When you vendor third-party code directly into your repository, package managers lose visibility. Without explicit metadata pinned to individual files, vendoring code without a paper trail is unsecured debt. The directory becomes a folder of hope: you hope the author kept clean boundaries, you hope no transitive dependencies carry reciprocal terms, and you hope the original license grants apply to your exact build target.

Why Shallow Scans Fail

Most dependency scanners inspect only package manifests (package.json, go.mod, pom.xml, or Cargo.toml). This approach fails on vendored code for two distinct reasons:

1. Manifest erasure: When developers drop an upstream library directly into a /vendor or /third_party directory, they often strip nested build manifests, documentation, and LICENSE files to save space or bypass linter rules. The scanner sees your top-level license and assumes it covers the entire tree.
2. Transitive license drift: Even when manifests remain, high-level tools parse declared dependencies rather than resolved entry points. A library declared under MIT may dynamically bundle or statically link a secondary dependency with strict reciprocal copyleft obligations under certain compilation flags.

your-app (MIT)
└── vendored/logger (MIT)
    └── internal/formatter (BSD-3-Clause)
        └── internal/text-buffer (AGPL-3.0-or-later) <-- Load-bearing, untracked

If text-buffer is invoked by any code path compiled into your production binary, its license governs that binary under reciprocal terms. Scanning the root manifest tells you nothing about the liability embedded five levels deep.

Constructing a Verifiable Chain of Custody

Establishing software provenance requires mapping actual runtime call paths to physical source files, then mapping those files back to upstream origin licenses. The process is mechanical:

1. Map the static reachability graph: Trace entry points from your production entrypoints down through all internal modules. If a vendored file is bundled into the distribution artifact, it is in scope.
2. Extract source-level SPDX declarations: Do not rely on directory-level LICENSE files alone. Parse file-level headers across every vendored source file. Upstream projects frequently vendor sub-components under distinct licenses without modifying the root notice.
3. Resolve dual-license and exception clauses: When a file claims multiple licenses (such as MIT or GPL-2.0), trace whether the build configuration relies on features gated behind the restrictive branch.
4. Pin the origin commit and hash: Software provenance requires an unbroken link to the upstream repository commit where that exact file version was published.

This produces a true, load-bearing SBOM: not a list of packages you meant to use, but a verified ledger of every external file compiled into your shipping artifact.

How SHPBL Handles Provenance

SHPBL eliminates vendoring uncertainty at the boundary. Our software catalog is model-independent and computed rather than generated: no AI model executes inside the code, and no runtime behavior depends on model output. Every component is owned outright and sealed with published checksums visible on our root of trust.

Every write passes through a Build Intent gate before inclusion. Licensing terms and structural invariants are resolved in code rather than left to post-hoc review. The certification harness executes each artifact and assigns a terminal status—CERTIFIED, PROVISIONAL, INCONCLUSIVE, or FAILED—so that obligations are known before integration. You can verify your own repository's current exposure through our free repository evaluation.

What to Do on Monday

Do not run another manifest scanner and assume you are compliant. Instead:

• Run an AST or linker-level trace on your main binary entry point to list every physical source file included in the final compilation unit.
• Diff that file list against your root manifest declarations. Isolate every file located under a vendored or third-party path.
• Inspect the file headers of those isolated files for copyleft SPDX identifiers (GPL, AGPL, SSPL, EUPL, CC-BY-SA).

If you find vendored files that lack file-level notices or that trace back to untracked transitive dependencies, quarantine them until you establish where they originated and under what exact terms.