Software supply chains: know what you are shipping

An application contains more than the code its team wrote. Dependencies, build tools, runners, and release channels all influence the artifact people install.

SBOM: A software bill of materials: an inventory describing components in a software product.

Inventory answers one important question

A software bill of materials, or SBOM, describes components in a software product. It helps answer whether a reported dependency issue may affect a release. Its usefulness depends on coverage, version accuracy, and a connection to the actual artifact.

An SBOM does not prove that the software is safe or that every listed vulnerability is reachable in this application. Inventory starts an investigation; context determines the response.

Provenance and signatures answer different questions

Build provenance records information about how an artifact was produced, such as its source and build process. A signature can establish that a particular key approved particular bytes, when verification and key trust are handled correctly.

Neither tells you that the signer is honest, the source is defect-free, or the build environment was appropriately controlled. Verification must include a policy for which identities and build conditions are acceptable.

Protect the whole path

Review dependency changes and constrain build-system permissions. Keep release credentials out of ordinary source and restrict who can change workflows or publish artifacts. Pinning versions improves repeatability, but requires a maintenance process so known issues are not frozen forever.

Define how to identify affected releases, rebuild from reviewed source, revoke compromised credentials, and communicate a correction. A supply-chain incident is easier to manage when artifacts and their origins are traceable.

Read a release packet against a written policy

A fictional community app is preparing artifact A42 from reviewed source revision S42. These short labels identify supplied records; in an actual system, artifact digests and authenticated evidence connect the records to the exact bytes. The approved build platform is Maple, and the release policy trusts signing key K2 through a separately managed verification configuration.

For this exercise, acceptance requires an inventory and component review covering A42, verified provenance matching S42 and Maple, and a valid signature by K2 on A42. The component review must resolve applicable findings or document an explicitly accepted limitation. The release owner, Noor, is responsible for later component updates.

Birch-format is an invented library. The candidate’s build record says it uses version 3.2. That change makes the old inventory and review unsuitable as complete evidence for the candidate. It does not, by itself, establish that version 3.2 is defective. Keep “not covered” separate from “known to be vulnerable.”

The signature does not repair the mismatch. It connects the candidate to the accepted signing key under the verification rules. It cannot make an inventory of different bytes become an inventory of this release. Similarly, knowing who built the candidate does not establish that its dependencies satisfy the review policy.

PredictA reviewer proposes renaming I41 to “A42 inventory” while leaving its component records unchanged. Would that close the evidence gap?

No. A label is not evidence that the listed components describe A42. Obtain an inventory tied to the candidate and review the actual component versions. Rebuilding may be necessary if the build itself was wrong, but the supplied facts establish an evidence mismatch, not that particular defect.

State the decision and what would change it

Hold acceptance under this policy. Two requirements have supporting evidence and two do not. Noor should obtain I42 describing A42 and the matching component review; the useful provenance and signature results need not be discarded if the artifact and verification assumptions remain unchanged.

The corrected packet supplies I42 with Birch-format 3.2, tied to A42, and a review of those components reporting no applicable unresolved findings within its stated coverage. The four criteria are now supported, so acceptance against this packet’s policy is justified. This does not certify every application behavior or predict future advisories.

Record the artifact identity, review coverage, decision, and owner together. A newly reported issue can require locating affected releases and reviewing exposure even when versions remain pinned. Repeatability helps identify what shipped; maintenance determines what should happen when knowledge changes.

EXPLORE THE CONCEPT

What does this evidence establish?

A fictional release arrives with three kinds of evidence.

A component inventory

It helps locate dependencies in the release. It is not a certificate of safety.

A verified signature

It binds bytes to a key under your trust policy. Review who controls that key and what they approved.

Build provenance from an accepted builder

It supports claims about the build path. Policy and verification determine whether those claims are sufficient.

A simplified learning model. It connects to no systems and uses no real data.

Turn the idea into a decision

Ask separately what is inside, where it came from, and why that origin is acceptable.