Area of expertise
Software supply chain security
An organisation can remediate application vulnerabilities while remaining unable to explain how an artefact was built, which dependencies it contains, or who could alter its build chain.
Operational definition
Software supply chain security protects source, dependencies, build identities, artefacts, and promotion paths, then makes provenance and integrity verifiable.
Problems actually encountered
-
01
Artefacts promoted without verifiable provenance
-
02
Direct and transitive dependencies poorly understood
-
03
Over-privileged or persistent CI runners
-
04
Signatures produced but never verified at deployment
Decisions involved
- Define trust boundaries and assurance levels
- Choose required attestations and verification
- Prioritise hardening of source, builds, or deployment
Common errors
- Reducing the topic to SBOM generation
- Signing with long-lived secrets in CI
- Applying the same assurance level to every artefact
Signals that external expertise becomes useful
- A binary cannot be traced to source and build
- A CI compromise would have an unknown blast radius
- Evidence is collected only before audits
Omnivya method
-
1.
Map actors, identities, systems, and promotion
-
2.
Model threats and compromise paths
-
3.
Verify controls and evidence on a real artefact
-
4.
Define a proportionate assurance progression
Possible deliverables
- Supply-chain and trust-boundary map
- Threat analysis and missing controls
- Provenance, signing, and verification profile
Evidence of reasoning
- Provenance verified through deployment
- Short-lived, bounded build identities
- Compromise scenarios tested on the selected scope
Explicit limits
- No presenting an SBOM as proof of integrity
- No maximum assurance imposed on every product
- No certifying a chain without independent verification
Related mission formats
- Technical risk review
Qualify risk beyond ticket or CVE volume.
- Platform audit
Assess what a platform actually enables teams to decide and operate.
- Expertise on a critical programme
Provide senior expertise on an already committed programme, without taking it over.
Frequently asked questions
- Is an SBOM sufficient?
- No. It describes composition if generation is trustworthy, but proves neither build integrity nor policy enforcement.
- Should we target the highest SLSA level?
- Not by default. The level depends on threat, criticality, and acceptable cost for each artefact class.
- Where should we start?
- With one critical artefact and its complete path, so trust breaks are observed before scaling.
Verify a software build chain
If this tension is yours, let’s frame the decision before widening the scope.