Dependency defense line (Socket at four control points)
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 — 37 targeted, 0 ignored, 296 still open, of 333. A ring means the cell is closed. Your 24 controls account for 37 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
AI assistant package check
01Plan3 controls · 1 blocking
- Hallucinated Package DetectionBlocking · Dependency ManagementOne product1 scored of 1
- AI Coding Assistant Security GuardrailsAdvisory · Developer Security & Secure CodingCompare3 scored of 6
- Secure Library & Safe Default RecommendationsAdvisory · Developer Security & Secure CodingOne product1 scored of 1
- 02
Pull request dependency review
02Code6 controls · 2 blocking
- Malicious Package DetectionBlocking · Dependency ManagementCompare3 scored of 14
- Install Script & Package Behavior AnalysisAdvisory · Dependency ManagementList only1 scored of 2
- Typosquatting DetectionBlocking · Dependency ManagementList only1 scored of 3
- Maintainer & Publisher Risk AnalysisAdvisory · Dependency ManagementList only1 scored of 2
- Open Source Project Health ScoringAdvisory · Dependency ManagementList only1 scored of 4
- Open Source License ComplianceAdvisory · Dependency ManagementCompare3 scored of 12
- 03
Install-time firewall
02Code5 controls · 5 blocking
- Malicious Package DetectionBlocking · Dependency ManagementCompare3 scored of 14
- Minimum Release Age EnforcementBlocking · Dependency ManagementList only1 scored of 5
- Install Script Execution RestrictionBlocking · Dependency ManagementNo product
- Dependency Confusion PreventionBlocking · Dependency ManagementList only3 products
- Dependency Curation & AllowlistingBlocking · Dependency ManagementList only1 scored of 5
- 04
Build-time resolution and triage
03Build6 controls · 4 blocking
- Software Composition AnalysisBlocking · Dependency ManagementCompare7 scored of 23
- Reachability AnalysisBlocking · Dependency ManagementCompare4 scored of 8
- Dependency Pinning & Lockfile Integrity VerificationBlocking · Dependency ManagementNo product
- Transitive Dependency ResolutionMonitor · Dependency ManagementCompare2 scored of 4
- SBOM GenerationBlocking · SBOM & Component VisibilityCompare4 scored of 28
- VEX Authoring & ConsumptionAdvisory · SBOM & Component VisibilityList only1 scored of 9
- 05
Continuous monitoring and response
08Monitor5 controls
- Continuous SBOM Vulnerability MonitoringMonitor · SBOM & Component VisibilityList only5 products
- Compromised Component Blast-Radius AnalysisMonitor · SBOM & Component VisibilityList only3 products
- Supply Chain Incident ResponseManual · Detection & ResponseOne product1 product
- Private Fix Backporting & Upstream ContributionAdvisory · Dependency ManagementCompare2 scored of 5
- Automated Dependency UpdatesAdvisory · Dependency ManagementList only1 scored of 3
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
V15
CI/CD Top 10
2 of 10
OWASP Top 10 CI/CD Security Risks
CICD-SEC-3 · CICD-SEC-5
S2C2F
17 of 25
OpenSSF Secure Supply Chain Consumption Framework (S2C2F)
AUD-1 · AUD-3 · ENF-1 · ENF-2 · FIX-1 · ING-3 · INV-1 · INV-2 · REB-3 · SCA-1 · SCA-2 · SCA-3 · +5 more
SSDF 1.1
8 of 42
NIST Secure Software Development Framework 1.1 (SP 800-218)
PW.4.1 · PW.9.1 · RV.1.1 · RV.2.1 · PS.3.2 · PW.4.2 · RV.2.2 · PW.4.4
Scorecard
7 of 20
OpenSSF Scorecard Checks
Contributors · Dependency-Update-Tool · License · Maintained · Pinned-Dependencies · SBOM · Vulnerabilities
Coverage by phase
Plan
Not modeledNo attack techniques are modeled against this phase yet. That is a gap in our model, not evidence the phase is safe.
Code
2 countered · 2 open of 4
Build
4 countered · 7 open of 11
Monitor
Not modeledNo attack techniques are modeled against this phase yet. That is a gap in our model, not evidence the phase is safe.
Attacks this pipeline faces
Techniques modeled against the phases this pipeline covers, ordered by how many documented real-world incidents used them.
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
Countered5 real incidentsVery Common · Build
Countered by 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
Countered2 real incidentsCommon · Build
Countered by Dependency Confusion Prevention, Dependency Curation & Allowlisting.
Mutable Tag Hijack of CI Actions and Images
Countered2 real incidentsCommon · Build
Countered by Supply Chain Incident Response.
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
Countered2 real incidentsEmerging · Build
Countered by Compromised Component Blast-Radius Analysis, Install Script Execution Restriction, Malicious Package Detection, Minimum Release Age Enforcement, Supply Chain Incident Response.
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
- 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 57 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.