Software composition analysis answers which known components appear in a build and which published vulnerabilities may apply. Supply-chain trust asks a wider question: can the organisation prove that reviewed source, authorised dependencies and controlled build steps produced the artifact that reached production?

Attackers do not need a vulnerable open-source library if they can alter a workflow, steal a signing identity, replace an artifact, poison a cache, change an image tag or bypass deployment verification. These paths cross developer, CI, package, registry and runtime boundaries, so no single scanner sees the complete chain.

A practical assessment combines process and configuration review with safe canary validation. It tests whether controls prevent or detect unauthorised source-to-runtime substitutions without inserting malicious code into production. Evidence should be reproducible and should not expose live signing keys, tokens or proprietary source.

Map the source-to-runtime chain

Inventory repositories, branch protections, CI runners, workflow definitions, build dependencies, package managers, artifact stores, registries, signing services, deployment controllers and runtime verification. Include third-party build and release systems that can change the final bytes.

Identify who can approve source, edit workflows, administer runners, publish packages, move tags, sign artifacts, change deployment manifests and bypass policy. Model both compromised developer credentials and compromised automation identities.

  • Source repositories, protected branches, reviews and workflow files.
  • Hosted and self-managed runners, build images, caches and network dependencies.
  • Package namespaces, lock files, private registries and dependency proxies.
  • Artifacts, container images, signatures, attestations and provenance.
  • Deployment manifests, GitOps controllers, admission verification and runtime inventory.

Test trust transitions across the delivery chain

Each transition should state the expected producer, consumer and verification. Use harmless canaries or isolated pipelines to test control behaviour.

Source approval and workflow authority

A contributor who cannot merge application code may still alter a workflow that exfiltrates secrets or changes the build. Review ownership and branch rules for workflow files, then use a test repository or proposed harmless change to observe approval and execution controls.

Evidence standard: Show the identity and policy path; do not attempt secret extraction.

Runner and build isolation

Persistent, privileged or shared runners can retain credentials, accept untrusted jobs or influence later builds. Inspect runner scope, lifecycle, network and secret injection; use synthetic markers to test workspace and cache separation.

Evidence standard: Record whether the marker crosses jobs or trust levels and which control should have isolated it.

Dependency and namespace trust

Confusion, typosquatting, mutable versions and compromised publishers can introduce code even when no known CVE exists. Review resolver order, namespaces, locks and integrity data; test a reserved synthetic package name in an isolated project.

Evidence standard: Demonstrate resolution and verification behaviour without publishing deceptive packages to public ecosystems.

Artifact integrity and provenance

Tags and files can be replaced after scanning or approval, disconnecting the deployed artifact from reviewed source. Check immutability, digests, signatures and attestations; attempt a harmless unsigned or mismatched canary through a non-production gate.

Evidence standard: Capture the artifact digest, producer identity, verification result and enforcement point.

Deployment and runtime verification

A secure build can still be bypassed by manual deployment, policy exceptions or mutable runtime references. Trace approved artifacts into manifests and runtime inventory, then test whether an unapproved canary is blocked and logged.

Evidence standard: Connect source revision, build record, artifact digest, deployment change and running workload.

Gaps dependency scanners cannot resolve

SCA remains necessary for component risk, but it usually trusts the artifact it is given and cannot prove who produced it or whether deployment used the scanned copy.

Prioritise weaknesses that allow unreviewed code or artifacts to reach a privileged runtime, expose durable release credentials, or make tampering invisible. Treat missing metadata separately from a demonstrated bypass.

  • Workflow files lack protected ownership and can access release secrets.
  • Long-lived tokens or signing credentials are shared across projects and environments.
  • Builds use mutable base images, packages or tags without integrity verification.
  • Self-hosted runners persist across untrusted and privileged jobs.
  • Registries permit overwrite or deletion of released artifacts.
  • Provenance is generated by the same untrusted step it claims to describe.
  • Deployment policy can be bypassed through manual credentials or emergency paths without review.

Evidence that supports a defensible conclusion

Evidence should make the expected trust statement and observed break explicit. Use digests, identities, timestamps and verification logs rather than screenshots alone. Redact tokens and key material, and test with synthetic artifacts that cannot be mistaken for production software.

  • Source revision and workflow version associated with the build.
  • Runner identity, isolation boundary and secret exposure conditions.
  • Dependency resolution, integrity and namespace policy.
  • Artifact digest, signature or attestation and immutable storage result.
  • Deployment verification event and final runtime digest.
  • Exceptions, manual paths and unavailable third-party evidence.

How WIMD would assess supply-chain trust safely

WIMD would build a trust graph from repository to running service, then choose canaries at boundaries where one identity or system hands authority to another. We would avoid public namespace interference and never attempt to retrieve real release secrets.

Configuration review, controlled pipeline experiments and runtime reconciliation would be labelled separately. Findings would explain the durable policy and the attacker position required.

  1. Identify critical services and trace their exact source-to-runtime path.
  2. Map human, automation, publisher, signer and deployment identities.
  3. Review approval, isolation, integrity, immutability and verification controls.
  4. Design synthetic packages, artifacts and signatures for isolated canary tests.
  5. Validate enforcement and detection at selected trust transitions.
  6. Retest the control and reconcile the final deployed digest to authorised provenance.

Make trust verifiable and difficult to bypass

Protect workflows as code, isolate ephemeral runners, minimise scoped credentials, pin and verify dependencies, make released artifacts immutable, produce trustworthy provenance and enforce signature or attestation policy at deployment.

Retest both the normal path and controlled exception paths. Confirm failed verification blocks deployment and creates an actionable event, while legitimate emergency processes remain time-bound and reviewed.

  • Separate build, signing and deployment authority where practical.
  • Use short-lived workload identities instead of shared static tokens.
  • Bind provenance to artifact digests and a protected build service.
  • Eliminate mutable production references and uncontrolled manual deployment.
  • Monitor policy overrides, artifact replacement and release-identity changes.

Decide how much supply-chain assurance is enough

Depth should follow the consequence of code substitution and the number of external trust dependencies. Internet-facing SaaS, security-sensitive agents and privileged enterprise integrations justify deeper producer and deployment verification.

A useful report states which repositories, build paths, registries, artifacts, environments and exception mechanisms were assessed. Absence of a successful canary is meaningful only when the test path and enforcement evidence are complete.

  • Can every production artifact be traced to reviewed source and a protected build?
  • Which identities can change workflows, artifacts, signatures or deployment policy?
  • Are released artifacts immutable and referenced by digest?
  • Does runtime admission verify trustworthy provenance?
  • Are exceptions controlled, logged, expiring and retested?

Questions security, engineering and assurance teams ask

Is an SBOM enough for supply-chain security?

No. It supports component transparency but does not prove source review, build integrity, publisher identity, artifact immutability or deployment enforcement.

How can dependency confusion be tested responsibly?

Use reserved namespaces, private test registries or isolated resolvers. Do not publish deceptive packages into public namespaces that could affect unrelated organisations.

Should penetration testers access signing keys?

They normally should not. Review key architecture and use a synthetic signer or non-production policy test to prove enforcement without exposing high-impact credentials.

What is the right retest?

Repeat the rejected canary at the original trust boundary, verify enforcement and logging, then reconcile an authorised artifact from source revision through its running digest.

Authoritative and technical references

Turn the delivery pipeline into an evidence chain

Supply-chain assurance improves when each system produces verifiable evidence for the next rather than relying on mutable labels and shared credentials.

Preserve the trust graph and canary tests as the pipeline evolves so new tools and exceptions do not silently reopen the path.

Ask WIMD to assess your source-to-runtime trust chain with safe canaries and remediation-ready evidence.