Compose a pipeline
Pick the domains you are responsible for. Every control the graph holds for them is placed into the lifecycle phase where it belongs, with the frameworks it evidences and the attacks it stops.
Domains
- Static Code Analysis×
- Dependency Management24
- Container Security24
- Exposure & Vulnerability Management15
- Endpoint Protection6
- Secrets & Identity Security24
- Build Integrity & Cryptographic Trust19
- CI/CD Pipeline Security10
- Runtime Application Validation25
- Runtime & Kubernetes Protection24
- AI Model & Agent Security16
- Identity & Access Management16
- Cloud Security Posture14
- Package Registry & Provenance Security13
- API Security12
- Detection & Response12
- SBOM & Component Visibility12
- Vendor Governance12
- Infrastructure-as-Code Security×
- Developer Security & Secure Coding10
- Secure Design & Threat Modeling10
- Governance, Risk & Compliance8
- Source Control Security8
- Data Protection2
- Email & Collaboration Security1
Maturity ceiling
Controls carry the maturity level a program needs to run them. Raising the ceiling adds depth and volume; level 3 is a realistic target for most teams.
- 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 — 7 targeted, 0 ignored, 326 still open, of 333. A ring means the cell is closed. Your 4 controls account for 7 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.
4 capabilities appear 7 times, because a control can belong at more than one point in the lifecycle. Digest verification, for instance, is enforced at build and checked again at deploy — the same capability doing a different job.
- 02
Code
4 capabilities
- Incremental Diff ScanningSAST · level 2 · 3 controlsCompare8 scored of 8
- Static Application Security TestingSAST · level 2 · counters 2 · 16 controlsCompare19 scored of 21
- IaC Misconfiguration ScanningIAC · level 2 · counters 1 · 9 controlsList only1 scored of 9
- Kubernetes Manifest & Helm Chart ScanningIAC · level 2 · counters 2 · 4 controlsList only6 products
- 03
Build
3 capabilities
Framework coverage
What this selection alone would let you evidence.
ASVS 5.0
3 of 17
OWASP Application Security Verification Standard (ASVS) 5.0.0
V1 · V5 · V13
SSDF 1.1
4 of 42
NIST Secure Software Development Framework 1.1 (SP 800-218)
PW.7.1 · PW.9.1 · PW.7.2 · RV.1.2
Scorecard
1 of 20
OpenSSF Scorecard Checks
SAST
Coverage by phase
Code
0 countered · 4 open of 4
Build
0 countered · 11 open of 11
What this selection leaves open
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.
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.
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.
Mutable Tag Hijack of CI Actions and Images
Open2 real incidentsCommon · Build
Nothing in this pipeline counters it. The graph knows 7 capabilities that would: CI/CD Configuration Scanning, Curated Hardened Action Catalog, Image Digest Pinning Enforcement, Immutable Artifact Versioning, and others.
Pwn Request (Privileged Trigger Abuse)
Open2 real incidentsCommon · Build
Nothing in this pipeline counters it. The graph knows 1 capability that would: Untrusted Workflow Trigger Isolation.
Self-Propagating Package Worm
Open2 real incidentsEmerging · Build
Nothing in this pipeline counters it. The graph knows 6 capabilities that would: Compromised Component Blast-Radius Analysis, Developer Workstation Hardening, Install Script Execution Restriction, Malicious Package Detection, and others.
Unauthorized Commit Injection
Open2 real incidentsCommon · Code
Nothing in this pipeline counters it. The graph knows 5 capabilities that would: Branch Protection & Ruleset Enforcement, Code Review Enforcement, Commit Signing & Verification, Unauthorized Code Change Detection, and others.
Workflow Script Injection
Open2 real incidentsCommon · Build
Nothing in this pipeline counters it. The graph knows 2 capabilities that would: CI/CD Configuration Scanning, Workflow Injection Detection.
Unsafe Model Deserialization
Open1 real incidentEmerging · Build
Nothing in this pipeline counters it. The graph knows 1 capability that would: AI Model File Scanning.
Malicious IDE Extension
OpenEmerging · Code
Nothing in this pipeline counters it. The graph knows 1 capability that would: Developer Workstation Hardening.
Poisoned Pipeline Execution
OpenCommon · Build
Nothing in this pipeline counters it. The graph knows 5 capabilities that would: CI/CD Configuration Scanning, Engineering Platform Audit Log Monitoring, Untrusted Workflow Trigger Isolation, Workflow Change Review Enforcement, and others.
3 further techniques with no documented incidents
Not in this comparison
- Does not apply to this kind of pipeline
- stages A composed pipeline has no authored stages; its capabilities are grouped by lifecycle phase.
- gaps Gap analysis compares a stage's capabilities against the products that stage uses, and only a client pipeline records products in use. A composed 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 317 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.