Why do supplier letters fail as proof of software provenance?

Supplier letters fail because they are assertions made by the supplier, not independently verifiable evidence that the delivered software came from a controlled build, the claimed source tree, or a traceable release process. For provenance, practitioners need artefacts and controls that can be checked against the package itself, not just a statement about it.

What supplier letters can and cannot establish

A supplier letter can be useful as a procurement input, but it does not prove the specific binary you received was produced from the stated source, built in the stated environment, or released without later tampering. At best, it tells you what the supplier claims. It does not by itself create a chain of custody from source to build to distribution.

That distinction matters because provenance is about verifiable lineage, not confidence in the sender. A credible provenance record usually includes signed build artefacts, SBOMs, hashes, release metadata, and traceability that let you compare what was declared with what was actually delivered. Without those artefacts, a letter is only a representation of trust, not a control.

In practice, the weakness is not that supplier statements are useless, it is that they are not independently checkable unless they point to supporting evidence. If a letter names the version, build process, and release date but does not link those claims to signed artefacts or immutable records, it still leaves a gap between assertion and assurance.

What stronger provenance evidence looks like

Software provenance becomes materially stronger when the evidence can be verified outside the supplier’s narrative. That means the delivery package should be tied to signed artefacts, reproducible or traceable build records, component inventories, and release evidence that shows how the binary came to exist. SLSA is useful here because it frames provenance as build integrity and traceable software supply-chain evidence rather than a statement of trust.

For buyers, SBOMs help identify what components were included, but they are not enough on their own if the release chain is opaque. The missing question is whether the listed components, build process, and published artefacts line up consistently. A supplier letter may mention those items, yet only the underlying records can establish whether they are accurate.

That is why provenance checks should focus on three tests: does the artefact verify cryptographically, does the build trail explain how it was produced, and does the release record match the item you installed or deployed? If any of those fail, the letter may still be informative, but it is not proof.

How to assess a supplier claim without over-trusting it

Good due diligence treats the letter as a lead, then asks for evidence that can be independently checked. The most useful follow-up is to require artefact signatures, provenance attestations, SBOMs where appropriate, and release records that can be matched to the delivered package. CISA Secure by Design Pledge and Secure Software Attestation Form Guide is a practical reference for this style of attestation-based assurance, because it centres the evidence expected around secure software claims rather than the claim itself.

When the supplier cannot provide matching artefacts, the right response is usually to lower trust, not to fill the gap with more procurement language. That may mean demanding a verified provenance package before acceptance, restricting deployment scope, or using compensating controls while you validate the software through your own checks.

In other words, the evaluation should not stop at “did the supplier sign a letter?” It should move to “can we independently confirm the software’s origin and integrity from the artefacts we received?” That is the real operational test.

Practitioner Guidance

What to verify: Confirm that the delivered package, its signature or hash, the SBOM, and the release metadata all refer to the same version and build lineage. If they do not align, treat the provenance claim as unproven even if the letter is well-written.

Decision rule: If the supplier cannot produce artefacts that can be checked independently of the letter, do not treat the letter as a control outcome. Use it only as a statement of intent or assertion, and require stronger evidence before acceptance.

Practitioner takeaway: Provenance is established by evidence that can survive independent verification, so the safest procurement posture is to trust letters only when they are backed by artefacts that prove origin, integrity, and release lineage.

Related resources from NHI Mgmt Group

• Why do software signing controls fail even when policies exist?
• Who should be accountable when software trust controls fail?
• Why do API keys and OAuth tokens fail as identity proof for AI agents?
• What breaks when Linux software provenance is not verified?