Software supply chain becomes an architectural concern the moment third-party code gets the right to be built, signed, and executed inside your environment.
The chapter connects SBOMs, dependency governance, hardened CI/CD, artifact signing, and provenance verification into one defensive line from build to deployment.
In interviews, it helps you discuss artifact trust, third-party dependency risk, pipeline compromise scenarios, and visibility into system contents as architecture concerns.
Practical value of this chapter
Design in practice
Design the artifact path from source to deployment: dependencies, build, signature, registry, and policy checks.
Decision quality
Validate whether artifact provenance, software contents, and image immutability can be proven before production execution.
Interview articulation
Frame the answer around the chain: dependency, build, attestation, signature, registry, deployment admission.
Trade-off framing
Make the cost of strict checks explicit: release speed, operating cost, false positives, and recovery complexity.
Context
Secrets Management Patterns
A hijacked CI/CD pipeline ships a malicious build that still looks legitimate — so supply chain defense starts with credentials and trust boundaries.
Supply Chain Security protects the path from source code to runtime — and the weak link is usually not the code itself but how it gets built and shipped to production. So the trust here sits not in the build process but in verifiable artifacts: every delivery stage runs its checks automatically, so one compromised step does not turn into a system-wide incident.
This chapter connects software supply chain security with SBOMs, artifact provenance, build attestations, artifact signing, artifact registries, policy gates, dependency governance, short-lived CI/CD credentials, and blast-radius reduction.
Supply chain layers and controls
Source and dependencies
Dependency pinning, allow-lists, vulnerability scanning, signed commits and tags, and branch protection.
Build and CI/CD
Ephemeral runners, least-privileged CI tokens, isolated build steps, and build attestations.
Artifacts and registries
Artifact signing, immutable digests, SBOM publication, and policy checks before promotion.
Deploy and runtime
Admission policies, image signature verification, provenance verification, anomaly detection, and rollback readiness.
Key practices
- Maintain SBOMs for critical services and compare them with the artifacts that actually run in production.
- Sign container images and binaries, then require signature verification during deployment.
- Record artifact provenance and build attestations: who built it, from which sources, and through which pipeline.
- Reduce the blast radius of CI/CD secrets with short-lived credentials, scoped permissions, and separate trust zones.
- Run dependency governance, CVE triage, and patching cycles based on vulnerability severity.
Typical threat scenarios
Compromised external dependency
Risk: Malicious code from a third-party package reaches production.
Control: Dependency pinning, supplier allow-lists, provenance verification, and fast eviction of the risky version from release.
Artifact substitution in a registry
Risk: A different image or binary is deployed than the one that passed review and tests.
Control: Mandatory artifact signing, immutable digests, and verification policies before deployment.
CI runner or token takeover
Risk: An attacker produces a malicious build that still looks legitimate.
Control: Ephemeral runners, short-lived CI tokens, scoped permissions, separated trust zones, and isolated secret delivery channels.
Release automation compromise
Risk: Policy checks are bypassed and an unchecked artifact is promoted further through the chain.
Control: Mandatory policy gates, audit trails, and four-eyes approval for critical promotion operations.
Policy gates by pipeline stage
The check belongs before publication or deployment, not after: if signature, provenance, software contents, or admission policy fail, the pipeline stops. Otherwise an unverified artifact is already in production by the time the alert fires.
CI/CD pipeline with policy gates
Commit and merge request
Signed commits, mandatory review, SAST, and license checks
On failure: Block the merge and open an accountable security ticket.
Build
Reproducible build, SBOM, artifact provenance, and build attestation
On failure: Stop the pipeline and prevent artifact publication.
Artifact registry
Required signature, immutable digest, and policy for critical CVEs
On failure: Quarantine the artifact and block promotion.
Deployment
Admission policy, signature verification, and provenance verification
On failure: Reject deployment and keep the previous version.
Runtime
Integrity monitoring, anomaly detection, and rollback readiness
On failure: Run containment, roll back, and revoke compromised credentials.
Control points:
Operational metrics
Signed artifact coverage
Target: >= 95%
Shows how many release candidates actually move through a trusted supply chain.
SBOM coverage for critical services
Target: 100%
Without SBOMs, teams cannot assess the blast radius of a new CVE quickly enough.
MTTR for supply chain incidents
Target: < 2 hours
Limits the exposure window of a compromised artifact in production.
Critical CVE response time
Target: < 24 hours
Shows whether dependency governance, CVE triage, and patching cycles work in practice.
Validation
Testing Distributed Systems
Security drills and compromise simulations are just as important as functional tests.
Maturity model
Level 1: Visibility
Dependency and artifact inventory, basic vulnerability scanning, and clear supply-chain ownership.
Level 2: Control
CI/CD policy gates, mandatory code review, artifact immutability, and secret hygiene.
Level 3: Verifiability
Signing, attestations, deploy-time verification, and full traceability from commit to runtime.
Level 4: Resilience
Regular drills, compromise simulations, fast containment, and rollback without manual chaos.
Rollout plan
Phase 1 (0-30 days)
Focus: Inventory and visibility
Outcome: Dependency catalog, baseline SBOMs, and owners for critical supply-chain paths.
Phase 2 (30-60 days)
Focus: Mandatory policy checks
Outcome: CI/CD policy gates and blocking of unsigned or unverified artifacts.
Phase 3 (60-90 days)
Focus: End-to-end verifiability
Outcome: Artifact signing, build attestations, and deploy-time verification for all critical services.
Phase 4 (90+ days)
Focus: Operational resilience
Outcome: Regular drills, compromise simulations, and measurable SLOs for supply chain security.
Typical antipatterns
CI/CD uses long-lived admin tokens without permission segmentation.
Artifacts are deployed without signatures, provenance, or build attestations.
`latest` tags and unpinned dependencies are used in critical services.
SBOMs are produced for reporting, but release policies never use them.
References
Related chapters
- The Untold Story of Log4j and Log4Shell - Shows a real software supply chain incident and the practical consequences of a compromised dependency.
- Secrets Management Patterns - Connects to CI/CD hardening: secure secret storage and rotation reduce pipeline takeover risk.
- API Security Patterns - Complements artifact delivery defenses with authorization, rate limiting, and abuse controls.
- Data Governance & Compliance - Extends the topic with auditability, traceability, and controls for sensitive data handling.
- Security Engineering Overview - Provides the broader secure-by-design frame where SLSA, SBOMs, artifact signing, and policy gates fit.