Link SBOM entries to exact source commits

The failure that keeps you guessing

Your SBOM lists a package, a version, a licence. It does not say which exact file you are shipping. When a vendored file moves across branches or a cherry‑pick rewrites history, the SBOM stays the same. The result is a blind spot in licence traceability. You cannot prove source provenance. Audits stall. Legal risk remains hidden.

Blob hash as the immutable anchor

A Git blob hash is a SHA‑1 of the file’s raw contents. It changes only when the file’s bytes change, not when the file is renamed or moved in the tree. By storing that hash alongside each SBOM entry you gain a permanent link back to the exact source material. The link survives refactors because the hash is tied to the content, not the path. If the same file appears in two branches, both entries carry the same blob hash, exposing duplication instantly.

The failure mode is “SBOM entries lack origin hashes”. The correct posture is “every file entry includes the blob hash that produced it”. The difference is measurable: a tool that can resolve a blob hash to a repository object can answer “what exact bytes were shipped and under what licence” in seconds, not days.

Embedding the hash – a concrete workflow

Assume you generate an SPDX‑compatible SBOM with a standard tool. The tool emits a File element for each source file. Extend the element with an ExternalReference of type vcs that holds the blob hash. The SPDX spec already defines this field, so you stay within the standard.

{
  "SPDXID": "SPDXRef-File-123",
  "name": "src/util/math.js",
  "checksums": [{ "algorithm": "SHA1", "checksumValue": "a1b2c3…" }],
  "licenseConcluded": "MIT",
  "externalRefs": [
    {
      "referenceCategory": "VCS",
      "referenceType": "git",
      "referenceLocator": "git+https://github.com/example/repo.git@b7c9d8e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0"
    }
  ]
}

The referenceLocator concatenates the repository URL, an @, and the 40‑character blob hash. When the SBOM is later consumed, any tool can fetch the repository (or a mirror) and locate the blob object. The file content is reproduced byte‑for‑byte, confirming the checksum and the licence information.

To automate this, add a step after your build that runs git rev-parse HEAD:<path> for each file. A simple script can map paths to blob hashes:

git ls-files | while read f; do
  h=$(git rev-parse HEAD:"$f")   # blob hash of $f at HEAD
  echo "$f,$h"
done > file-hashes.csv

Feed the CSV into your SBOM generator as a custom field. The script is tiny, runs in seconds, and requires no external service. Because the hash is derived from the repository, the process is model‑independent and repeatable.

What the practice buys you

With blob hashes in the SBOM you can answer three critical questions instantly:

• Where did this line come from? The hash resolves to a blob object; the surrounding commit contains author metadata and the licence file at that point.
• Has the file been altered since the SBOM was built? Re‑computing the blob hash and comparing it to the stored value reveals any drift.
• Do two SBOMs reference the same source? Matching hashes across builds expose duplicated vendoring, reducing unnecessary liability.

The approach does not eliminate the need for a full licence audit, but it removes the most opaque layer. It also aligns with the guidance in /blog/why-an-sbom-without-origin-hashes-is-meaningless, which argues that provenance is a prerequisite for any trustworthy supply‑chain analysis.

Monday’s concrete step

1. Open your CI pipeline.
2. Insert a script that writes git rev-parse HEAD:<path> for every source file into a CSV.
3. Configure your SBOM generator to read that CSV and add a vcs external reference to each file entry.

Run the pipeline on a small module today. Verify that the generated SBOM contains the referenceLocator field and that you can locate the blob from the hash. By the end of the week you will have a reproducible, licence‑traceable SBOM that survives refactors and merges.