Reading Path6 steps

Software Integrity & Product Trust

Follow the evidence chain from source and build systems through SBOM/VEX, signed release, deployment authorisation and provisioned product state.

One decision a day for five days. The sixth reading extends the evidence chain.

Forproduct-security, PSIRT, software-assurance and engineering leaders
OutcomeDistinguish signed or approved software from software whose provenance, vulnerability state, deployment authorisation and lifecycle evidence can actually be defended.
Decision context

Use this path when a signed or approved software artefact is being treated as sufficient evidence of trust. The decision is whether provenance, vulnerability state, deployment authority and provisioned product state can all be defended.

Email pilot by request

Want one decision in your inbox each day? Ask for the five-part Software Integrity series. We will reply to confirm your address before sending Day 1. The series ends after Day 5.

Request the five emails

This opens your email app. No signup or email is sent by this website. You can also follow the full path here without registering.

01
Day 1 of 5 · Start here · OT & ICS · Supply Chain · Product Security

When Legitimate Engineering Workflows Can Carry Malicious Control Logic

See why the build environment itself belongs inside the product trust boundary.

Decision to take away Which build inputs and privileges must be evidenced before you can trust the released artefact?
→
02
Day 2 of 5 · Vulnerability evidence · Product Security · Supply Chain · Automotive

A VEX Statement Is a Claim That Needs Evidence

Connect SBOM component presence to a scoped VEX exploitability claim backed by reviewable evidence.

Decision to take away Can you tie an exploitability statement to the exact component, product version and supporting evidence?
→
03
Day 3 of 5 · Release state · Automotive · Product Security · Supply Chain

A Valid Signature Does Not Make Vulnerable Firmware Safe

Separate cryptographic authenticity from vulnerability state and lifecycle patchability.

Decision to take away What evidence separates software authenticity from vulnerability state and patchability?
→
04
Day 4 of 5 · Deployment authority · Automotive · Product Security · Software Supply Chain

A Trusted Automotive Update Path Can Become the Malware Delivery Path

See why valid transport, identity and signatures still do not prove that a software artefact is authorised for a specific deployed product state.

Decision to take away Can you prove that this signed artefact was approved for this particular deployed product state?
→
05
Day 5 of 5 · Provisioning · Automotive · Product Security · Supply Chain · OT & ICS

How a Software-Defined Vehicle Could Inherit Compromise Before Delivery

Carry software integrity into the point where a software-defined product receives identity, code and operational authority.

Decision to take away Who can bind device identity, code and operational authority during provisioning, and how is that decision recorded?
→
06
Further reading · Supply-chain traceability · Manufacturing · Supply Chain Security · Product Assurance

NIST IR 8536 Shows Why Supply-Chain Traceability Must Become Verifiable Assurance

Connect component and supplier traceability to evidence that can support a product-level assurance decision.

→
← All Reading PathsSearch the full library →