Timestamping an SBOM

Timestamping an SBOM: How to Prove When Your Software Inventory Existed

An SBOM already contains a timestamp, but the SBOM’s own author writes that value. An independent timestamp is different: you compute a SHA-256 hash of the exact SBOM file, anchor that hash somewhere nobody on your team controls, and later show that the same file produced the same hash at or before the recorded time. For audits, disputes and regulator requests, that outside record is what turns “we say this is what we shipped in March” into something a third party can check.

That is the whole idea. The rest of this article covers where it helps, where it doesn’t, and the small technical details that decide whether verification works two years from now.

The timestamp inside the SBOM is a claim

The 2026 Minimum Elements for a Software Bill of Materials, published on July 29, 2026 by CISA with NSA, FBI and international partners, replace the 2021 NTIA baseline and grow the required data fields from seven to seventeen. A timestamp is one of the metadata fields, alongside the SBOM author, tool name, version and generation context. The new list also includes an SBOM Author Signature. In the 2025 draft, the timestamp was a record of the date and time of the most recent update to the SBOM data, in ISO 8601 format.

Two things follow from that definition. First, the value is whatever the generating tool or the author wrote. Nothing about the field stops someone from regenerating a file next quarter and stamping it with an earlier date, and nothing in the file tells you if they did. Second, the field tracks the latest update, so when an SBOM is revised, the old time is gone from the document itself unless you kept the old version.

None of this is a criticism of the standard. A minimum-elements document describes what an SBOM should say, not how to prove it said it at a given moment. The joint guidance is explicit that checking accuracy, coverage and completeness sits outside the minimum elements. Proving the date is a separate job, and it’s the job an external timestamp does.

What an external anchor adds, and what a signature already covers

The new signature field answers a question about who. If the author signs the SBOM with a key you trust, you get some assurance about origin and about integrity since signing. It doesn’t, on its own, say when the signing happened in a way a stranger can check, unless the signing scheme includes a trusted time source. And signatures depend on key management: keys get rotated, revoked and lost, and years later an auditor may have trouble establishing the key’s status on a given day.

A hash anchor works differently and covers a different question. You are not asserting identity. You are recording that a particular byte sequence existed by a particular time. The two are complementary, so the most defensible setup is usually both: sign the SBOM to bind it to your organization, and anchor its hash to fix it in time.

There’s also a quieter benefit. A component hash is now a required SBOM element (the 2026 update made it mandatory across the board, which also resolved a mismatch for medical device makers). So a well-formed SBOM already contains the digests of the artifacts it describes. Anchor the SBOM’s hash and you have indirectly committed, at that moment, to every component digest listed inside it.

Where audits actually bite

Three situations come up repeatedly.

Regulatory documentation: Under the EU Cyber Resilience Act, Annex I Part II requires manufacturers to identify and document components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. The SBOM belongs in the technical documentation, and that documentation must be kept for ten years after market placement or for the support period, whichever is longer. It goes to market surveillance authorities on a reasoned request and isn’t published. The main obligations apply from December 11, 2027, with vulnerability reporting starting September 11, 2026. Nothing in these provisions requires third-party timestamping. But a ten-year retention duty means that someone, eventually, will be asked about a file written long before, probably by people who didn’t write it.

Customer and procurement reviews: A buyer asks which dependencies were in release 4.2 when a vulnerability was disclosed. You hand over an SBOM. A careful buyer wonders whether it was generated then or reconstructed afterward. An anchored hash lets you answer that without asking them to trust your build system’s clock.

Incident retrospectives and disputes: After a supply chain incident, the question “what did you know, and when?” often decides how the review goes. Showing that an inventory including the affected package existed before the disclosure is evidence of diligence. Showing a file that can’t be dated is much weaker.

Hypothetical walkthrough

Here is an invented example, not a real customer. A company, call it Northgate, ships firmware to European customers. At release time its pipeline produces a CycloneDX JSON file for version 4.2.0, plus a VEX document. The release job then does three things:

1- It signs the SBOM with the company’s release key.

2- It computes the SHA-256 of the final, signed file exactly as it will be stored.

3- It anchors that hash and keeps the resulting certificate details next to the SBOM in the release archive.

Fourteen months later, a regulator asks for the component inventory of 4.2.0 and a customer’s auditor separately asks whether it was prepared before a specific CVE was published. Northgate retrieves the archived file, recomputes the hash, and verifies it against the blockchain record. If the digests match, the file is byte-identical to what existed at the anchored time. If someone had edited even one dependency version since, the digest would not match.

Byte-level details that decide whether verification works

This is the part generic articles skip, and it’s where most failed verifications come from.

A hash covers bytes, not meaning. Re-serializing the same CycloneDX JSON with different indentation, reordering keys, changing line endings from LF to CRLF, or letting an editor add a trailing newline all produce a different SHA-256, even though the SBOM is semantically identical. So:

* Anchor the final artifact, after signing, compression and any post-processing, and store that exact file.

* Never anchor a pretty-printed copy while archiving the minified original, or the reverse.

* Treat the archive as write-once. If tooling “normalizes” files on upload to a document system, test that the digest survives the round trip.

* Record the hash algorithm in your release notes. SHA-256 is what Certelo uses, but the habit matters for every system you’ll touch over a decade.

You can check any file’s digest yourself with standard tools, for example sha256sum sbom.cdx.json on Linux or Get-FileHash in PowerShell. If your own result matches the value in the record, you’ve confirmed it without relying on anyone’s website.

Also decide what unit you anchor. One hash per release is the simplest and usually enough. Some teams also anchor each regenerated SBOM in a continuous pipeline, which gives a dated trail of how the inventory changed. Anchoring every nightly build produces a lot of records nobody will read, so match the cadence to the questions an auditor might actually ask.

How Certelo handles it?

Certelo calculates the SHA-256 hash locally, so the SBOM file stays on your device and isn’t uploaded just to create the proof. This matters more for SBOMs than for many documents, because an SBOM can reveal internal dependency choices, private package names and version details you may not want in a third-party system. Only the hash is anchored to the Electra Protocol blockchain. Later, the record can be verified using the original file, the hash, or the certificate information.

The flip side deserves plain statement: Certelo doesn’t hold your file, and a hash can’t be turned back into one. The anchor proves a file existed; it doesn’t preserve it. Retention of the SBOM itself, along with its signature and the surrounding release records, remains your responsibility, which is exactly why the ten-year CRA window needs a proper archive policy.

If you want the mechanics of the record itself, see how Certelo anchors and verifies a blockchain timestamp.

Limits worth saying out loud

An anchored hash shows that a digital fingerprint existed at or before the recorded blockchain time. It does not show that:

* the SBOM is accurate or complete (a wrong inventory can be timestamped just as faithfully as a right one);

* the SBOM matches what was really built, which is a build-provenance problem handled by attestations such as SLSA or in-toto;

* a specific person or company authored it, which is what signing is for;

* the timestamp satisfies any particular regulator or court. Admissibility and evidentiary weight depend on jurisdiction and circumstances, and a blockchain anchor is not by itself a qualified electronic timestamp under eIDAS. If a contract or rule requires a qualified timestamp from a trust service provider, you need one of those, and you could keep a blockchain anchor as an additional record.

Also note the CRA and CISA texts say nothing that makes external timestamping mandatory. This is an evidence-strengthening practice, not a compliance checkbox, and anyone claiming otherwise should be asked for the clause.

A practical pipeline pattern

For most teams the lightest workable version looks like this: generate the SBOM at build time (the new generation-context field asks you to say whether it was pre-build, build or post-build, so be honest about it), sign it, compute and anchor the hash as the last release step, then archive the file, signature, VEX and certificate details together under the release tag. Add a periodic restore test: pull an archived SBOM from cold storage and verify it. Teams that never test restores tend to discover the formatting problem described above at the worst possible time.

Questions people ask

Doesn’t the SBOM’s timestamp field already do this?

It records when the author says the data was last updated. It isn’t independently verifiable, and it reflects the latest update only. An external anchor adds a date a third party can check.

Is signing an SBOM enough?

Signing helps with origin and integrity, but the timing of a signature depends on the scheme and on key records surviving. Many teams treat signing and timestamp anchoring as complementary.

Will a different JSON formatting break verification?

Yes. The hash covers exact bytes, so any change in whitespace, key order or line endings produces a different digest. Anchor and archive the same final file.

Does the Cyber Resilience Act require a blockchain timestamp?

No. It requires documenting components with an SBOM in the technical documentation and retaining that documentation. An anchored hash is an optional way to support the record.

Does Certelo see my SBOM?

The hash is calculated locally and the original file doesn’t need to be uploaded to create the record.

Can an anchor prove my SBOM is correct?

No. It supports when a file existed, not whether its contents are accurate.

Does it work for VEX documents and build attestations too?

Any file can be hashed and anchored, so yes, the same approach applies. The same byte-exactness rules apply.