Dependency Chain Abuse
OWASP Top 10 CI/CD Security Risks · CICD-SEC-3
Builds fetch dependencies automatically, and the resolution process itself can be manipulated. If a build can be induced to fetch a package the attacker controls — by claiming an internal name on a public registry, by taking over an abandoned package, or by registering a plausible misspelling — the attacker gets code execution inside the build with the build's credentials.
How it shows up in the real world
- Dependency confusion, where an internal package name is resolved from a public registry an attacker has claimed.
- A typosquatted package name pulled in by a mistyped dependency.
- A maintainer account takeover on a widely used transitive dependency.
- Malicious install scripts executing during dependency resolution.
How to mitigate it
- Resolve dependencies only through an internal proxy or registry, and scope internal namespaces so they can never resolve publicly.
- Pin dependencies by digest with a committed lock file, and review lock-file changes.
- Disable or sandbox install-time scripts where the ecosystem allows it.
- Fetch dependencies in a network-restricted step and scan them before use.
Practice this topic
Test your knowledge of Dependency Chain Abuse with exam-style practice questions.
Rest of the CI/CD v1.0 list
CICD-SEC-1Insufficient Flow Control Mechanisms
Flow control is what stops a single change from reaching production unreviewed. Where those controls are missing or bypassable, anyone with commit access — or anyone who obtains it — can push code straight through to deployment. The problem is usually not the absence of a review process but the existence of paths around it: unprotected branches, direct registry pushes, or the ability to trigger a deployment without an approved artifact.
CICD-SEC-2Inadequate Identity and Access Management
CI/CD environments accumulate identities: human accounts, service accounts, bot users, integration tokens, and third-party app installations, spread across source control, build systems, registries, and cloud providers. They are rarely reviewed, frequently over-permissioned, and often outlive the person or project that created them, so the effective access of the whole system is far larger than anyone's model of it.
CICD-SEC-4Poisoned Pipeline Execution (PPE)
Pipelines execute configuration and scripts that live in the repository, which means influencing the repository can mean executing code in the build. Where a pipeline runs against untrusted contributions — most notably pull requests from forks — an outsider may be able to modify what runs and read the secrets available to that job. Variants differ in whether the pipeline definition itself is modified or a file it invokes is.
CICD-SEC-5Insufficient PBAC (Pipeline-Based Access Controls)
Pipeline jobs run with whatever access their execution environment provides, and that access is frequently far broader than the job needs. A single compromised step therefore reaches credentials, networks, and artifacts belonging to unrelated parts of the system. Shared, long-lived runners make this worse by letting one job leave state, or secrets, behind for the next.
CICD-SEC-6Insufficient Credential Hygiene
CI/CD systems handle a large volume of secrets, and those secrets have a strong tendency to spread — into repositories, build logs, container image layers, environment variables, and artifact metadata. Long-lived static credentials are the core problem: they are copied between places, they outlast their purpose, and a single exposure remains exploitable until someone notices and rotates it.
CICD-SEC-7Insecure System Configuration
The CI/CD platform is itself production infrastructure holding credentials for everything, yet it is often configured with convenience in mind and patched on a slower schedule than the systems it deploys to. Self-hosted instances, runners, and orchestrators carry the usual hardening burden, and permissive defaults in the platform's own settings can undermine every control layered on top.
CICD-SEC-8Ungoverned Usage of 3rd Party Services
Modern pipelines integrate readily with external services — marketplace actions, code-quality tools, bots, and reusable workflows — and those integrations are typically granted broad, standing access to source and build environments. Because they can usually be added by any developer without security review, the set of third parties with write access to production code drifts well beyond what anyone has approved.
CICD-SEC-9Improper Artifact Integrity Validation
Between a reviewed commit and a running workload, an artifact passes through build, storage, promotion, and deployment. If nothing verifies at each handoff that the artifact is the one the pipeline produced from that commit, an attacker who can write to any intermediate store can substitute their own and have it deployed through the legitimate process, with no code change visible in review.
CICD-SEC-10Insufficient Logging and Visibility
Attacks on delivery infrastructure look like ordinary engineering activity, so distinguishing them depends almost entirely on telemetry. CI/CD logging is often thin, scattered across several tools, short-lived, and not forwarded anywhere that performs detection. That combination means a pipeline compromise can proceed without alarm and, afterwards, without enough evidence to establish what was built and shipped.