Hardened container delivery (Chainguard from base image to admission)
What this design covers, and what it leaves
The same field every pipeline is drawn on. A reference design is a position taken on it, so the cells it does not fill are as much a part of the position as the ones it does — this one is deliberately deep in some streams and silent in others.
- GOV Governance and assurance
- The stream that decides what blocks, and proves it blocked.
- SUP Open source and third-party supply
- Everything you did not write, arriving faster than you can review it.
- DEV Design and development
- Where the cost of a fix is lowest and the attention is shortest.
- DEL Build and delivery
- The machine that makes the thing, and the largest single target in the chain.
- VER Testing and validation
- The stream that finds out whether any of the others worked.
- OPS Runtime and platform
- The last place to stop something, and the most expensive.
- OBS Detection and continuous observation
- The only stream whose answer changes while nothing else does.
The figure is how many controls the field places in that cell and the wash behind it is how much of the cell you have decided — 38 targeted, 0 ignored, 295 still open, of 333. A ring means the cell is closed. Your 24 controls account for 38 of those, because a control that belongs at build and again at deploy is two decisions about where it runs rather than one. Ignoring a control counts as decided and leaves the denominator, so coverage measures what you said you would do rather than everything that exists.
The dashed rules are the two boundaries every pipeline has, whatever its platform: intake at build and release at release. Both default open — nothing is refused unless something was configured to refuse it.
The columns are drawn as a row here and as a loop elsewhere, and the same eight phases are the eight color groups a player walks around the DevSecOpoly board, in these same colors. The shape is a convenience. What is real is that each phase is a set of activities, and an activity is only worth doing because it enables a capability.
Stages and gates
Each control is a link to the products that provide it, and each of those opens its full profile. Blocking gates fail the build; advisory, monitor and manual ones do not.
This is a reference design, so no products are assigned to its stages. Each control links to the products that provide it, and where two or more of those carry evaluation scores you can compare them head to head.
- 01
Base image selection
02Code3 controls · 3 blocking
- 02
Automated migration and equivalence testing
03Build3 controls · 1 blocking
- Minimal Hardened Base ImagesAdvisory · Container SecurityCompare2 scored of 14
- Automated Remediation Pull RequestsAdvisory · Developer Security & Secure CodingCompare7 scored of 12
- Security Unit & Regression TestingBlocking · Developer Security & Secure CodingNo product
- 03
Build, scan and attest
03Build5 controls · 3 blocking
- Container Image Vulnerability ScanningAdvisory · Container SecurityList only1 scored of 20
- Container Malware ScanningBlocking · Container SecurityOne product1 product
- SBOM GenerationBlocking · SBOM & Component VisibilityCompare4 scored of 28
- Build Provenance AttestationBlocking · Build Integrity & Cryptographic TrustCompare3 scored of 15
- Image Layer & Provenance AnalysisMonitor · Container SecurityList only2 products
- 04
Sign and publish by digest
05Release5 controls · 5 blocking
- Keyless Signing with Transparency LogBlocking · Build Integrity & Cryptographic TrustList only1 scored of 8
- Artifact SigningBlocking · Build Integrity & Cryptographic TrustCompare3 scored of 11
- SBOM Signing & AttestationBlocking · SBOM & Component VisibilityCompare3 scored of 4
- Immutable Artifact VersioningBlocking · Package Registry & Provenance SecurityList only9 products
- Artifact Promotion ControlBlocking · Package Registry & Provenance SecurityOne product1 product
- 05
Admission verification
06Deploy5 controls · 5 blocking
- Signature & Provenance Admission EnforcementBlocking · Package Registry & Provenance SecurityList only5 products
- Kubernetes Admission ControlBlocking · Runtime & Kubernetes ProtectionList only6 products
- Artifact Digest Integrity VerificationBlocking · Build Integrity & Cryptographic TrustNo product
- Attestation Policy EvaluationBlocking · Build Integrity & Cryptographic TrustList only6 products
- Workload Runtime HardeningBlocking · Runtime & Kubernetes ProtectionList only5 products
- 06
Freshness and drift management
07Operate4 controls · 1 blocking
- Continuous Image Rebuild & Freshness ManagementMonitor · Container SecurityCompare2 scored of 6
- Base Image CVE Remediation AutomationAdvisory · Container SecurityCompare2 scored of 12
- Container Drift PreventionBlocking · Runtime & Kubernetes ProtectionList only6 products
- Runtime Component InventoryMonitor · SBOM & Component VisibilityList only3 products
Framework coverage
Controls these capabilities let you evidence. Partial is the normal case; the remainder is the work.
ASVS 5.0
1 of 17
OWASP Application Security Verification Standard (ASVS) 5.0.0
V13
CI/CD Top 10
3 of 10
OWASP Top 10 CI/CD Security Risks
CICD-SEC-1 · CICD-SEC-3 · CICD-SEC-9
S2C2F
7 of 25
OpenSSF Secure Supply Chain Consumption Framework (S2C2F)
AUD-3 · AUD-4 · INV-1 · REB-2 · REB-3 · REB-4 · UPD-2
SLSA 1.2
6 of 16
Supply-chain Levels for Software Artifacts (SLSA) 1.2
Build L1 — Provenance generated and distributed · Build L2 — Consumer validates provenance · Build L2 — Signed provenance · Build L3 — Signing secrets isolated · Source L2 — Continuous immutable history · Verification — Verification Summary Attestation
SSDF 1.1
8 of 42
NIST Secure Software Development Framework 1.1 (SP 800-218)
PS.2.1 · PW.4.1 · PW.9.1 · RV.1.1 · PS.3.2 · PW.8.2 · RV.2.2 · RV.3.3
Scorecard
3 of 20
OpenSSF Scorecard Checks
Pinned-Dependencies · SBOM · Signed-Releases
Coverage by phase
Code
0 countered · 4 open of 4
Build
1 countered · 10 open of 11
Release
1 countered · 3 open of 4
Deploy
1 countered · 0 open of 1
Operate
1 countered · 12 open of 13
Attacks this pipeline faces
Techniques modeled against the phases this pipeline covers, ordered by how many documented real-world incidents used them.
Trusted Supplier Compromise
Open12 real incidentsCommon · Operate
Nothing in this pipeline counters it. The graph knows 5 capabilities that would: Commercial Software Binary Composition Analysis, Continuous Vendor Risk Monitoring, Nth-Party Dependency Mapping, SaaS & CI/CD Integration Governance, and others.
Maintainer Account Takeover
Open10 real incidentsCommon · Release
Nothing in this pipeline counters it. The graph knows 6 capabilities that would: Developer & Maintainer MFA Enforcement, Maintainer & Publisher Risk Analysis, Malicious Package Detection, Minimum Release Age Enforcement, and others.
Stolen Publishing Token
Open9 real incidentsCommon · Release
Nothing in this pipeline counters it. The graph knows 7 capabilities that would: Access Token Scoping & Least Privilege, Deployment Environment Protection, Engineering Platform Audit Log Monitoring, Leaked Credential Validation & Revocation, and others.
Artifact Tampering After Build
Countered7 real incidentsCommon · Release
Countered by Artifact Digest Integrity Verification, Artifact Signing, Build Provenance Attestation, Immutable Artifact Versioning, Keyless Signing with Transparency Log.
CI Runner Secret Exfiltration
Open5 real incidentsCommon · Build
Nothing in this pipeline counters it. The graph knows 4 capabilities that would: Build Egress Control & Network Monitoring, Pipeline Permission Minimization, Pipeline Runtime Anomaly Detection, Secrets Detection in CI Logs & Artifacts.
Exploitation of Known Vulnerable Component
Countered5 real incidentsVery Common · Operate
Countered by Container Image Vulnerability Scanning, Minimal Hardened Base Images.
Leaked Secret Abuse
Open5 real incidentsVery Common · Operate
Nothing in this pipeline counters it. The graph knows 5 capabilities that would: Dynamic Short-Lived Credentials, Leaked Credential Validation & Revocation, Secret Push Protection, Secrets Detection in Source Code, and others.
Malicious Install-Time Script
Open5 real incidentsVery Common · Build
Nothing in this pipeline counters it. The graph knows 3 capabilities that would: Install Script & Package Behavior Analysis, Install Script Execution Restriction, Malicious Package Detection.
Abandoned Package or Domain Takeover
Open2 real incidentsCommon · Release
Nothing in this pipeline counters it. The graph knows 2 capabilities that would: Maintainer & Publisher Risk Analysis, Open Source Project Health Scoring.
Adversary-in-the-Middle MFA Phishing
Open2 real incidentsVery Common · Operate
Nothing in this pipeline counters it. The graph knows 3 capabilities that would: Developer & Maintainer MFA Enforcement, Multi-Factor Authentication, Phishing & Business Email Compromise Protection.
Build Cache Poisoning
Open2 real incidentsEmerging · Build
Nothing in this pipeline counters it. The graph knows 2 capabilities that would: Build Cache Poisoning Prevention, Untrusted Workflow Trigger Isolation.
Dependency Confusion
Open2 real incidentsCommon · Build
Nothing in this pipeline counters it. The graph knows 4 capabilities that would: Dependency Confusion Prevention, Dependency Curation & Allowlisting, Namespace & Package Name Reservation, Private Registry Proxy & Curation.
21 further techniques with no documented incidents
Not in this comparison
- Does not apply to this kind of pipeline
- phases A reference pipeline has authored stages rather than a phase grouping.
- gaps Gap analysis compares a stage's capabilities against the products that stage uses, and only a client pipeline records products in use. A reference pipeline models the design, not an estate.
How this was produced
Every figure above was read from the Gantry knowledge graph, version 7.1.0, and computed when you opened this page — in 700 ms on 2026-10-27. Nothing here is a cached verdict or a dataset assembled for marketing: it is the same model our engagements run on.