Protect the path from source change to deployed artifact. Dependencies, build identities, release evidence, and verification belong in the same design.
Published and sources reviewed: October 26, 2026 · Practical architecture guide
Map the delivery trust chain
A release depends on source control, external packages, build runners, artifact storage, signing services, and deployment identities. List those dependencies and identify where untrusted input becomes executable code or privileged action.
NIST’s Secure Software Development Framework provides practices that can be integrated into development lifecycles. SLSA adds a structured way to reason about supply-chain assurance and provenance. Neither a framework label nor one scanner proves that a release is secure.
Keep four kinds of evidence separate
| Evidence | What it helps establish |
|---|---|
| Source review | Which change was reviewed and approved. |
| SBOM | Which components are declared in the delivered software. |
| Build provenance | How and from what inputs an artifact was produced. |
| Signature verification | Whether the artifact matches a trusted signing identity and policy. |
An SBOM is not a vulnerability verdict, and a valid signature is not evidence that the signer’s build process was trustworthy. Verification must connect the evidence to the artifact being deployed.
Worked example: a service release
Illustrative scenario: a reviewed change enters an isolated build environment. The build resolves approved dependencies, performs meaningful tests and security checks, records the artifact digest, and publishes provenance and an SBOM alongside the artifact.
A separate deployment identity verifies the expected artifact, evidence, and release policy before changing production. Avoid allowing an untrusted pull request to obtain production credentials or rewrite trusted pipeline definitions.
Operate after release
Keep an inventory linking deployed versions to artifacts and component records. When a dependency issue appears, identify affected workloads, assess reachability and exposure, and prioritize remediation with owners. Retain the ability to roll back to a known, compatible release.
Test policy failures and compromised-input scenarios. A check that has never rejected anything may be incorrectly wired. Review exceptions and emergency releases rather than treating them as permanent bypasses.
Implementation checklist
- Map source, dependency, build, and deployment boundaries.
- Restrict untrusted pipeline inputs.
- Use isolated builders and scoped credentials.
- Record immutable artifact digests.
- Generate and retain SBOM and provenance.
- Verify release identity and evidence before deployment.
- Test rejection, rollback, and emergency release paths.