Teams should pin versions, review indirect dependencies, and require provenance checks before build-time execution. They should also strip unnecessary secrets from build agents so a compromised package cannot harvest credentials that were only present for convenience. Dependency control and secret minimisation have to work together.
Why This Matters for Security Teams
Transitive dependencies are where CI/CD risk becomes harder to see and easier to abuse. A direct package may look trusted, while one nested dependency, postinstall hook, or build plugin quietly expands the attack surface and can run with the same privileges as the pipeline itself. That matters because pipeline compromise often turns into secret theft, artifact tampering, and downstream deployment trust loss. NIST’s Cybersecurity Framework 2.0 is clear that supply chain risk has to be managed as part of the broader security function, not as an afterthought. NHIMG’s CI/CD pipeline exploitation case study shows how quickly build trust assumptions fail once an upstream component is compromised. In practice, many security teams discover transitive dependency exposure only after a build agent has already executed hostile code and pulled secrets it should never have seen.
How It Works in Practice
Reducing transitive dependency risk starts with making builds deterministic and observable. Pin versions, use lockfiles, and require a review path for indirect dependency changes so a nested update cannot slip in through a routine package refresh. For ecosystems that allow it, prefer provenance verification and signature checks before any build-time execution. That means validating where the package came from, whether it was built by the expected workflow, and whether the artifact matches the declared source. The Guide to the Secret Sprawl Challenge is a useful reminder that dependency hygiene alone is not enough if build agents still carry broad access to tokens, cloud keys, or deployment credentials. GitGuardian’s State of Secrets Sprawl 2026 found that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners, which is why secret minimisation has to be treated as a build-control issue, not just a vaulting issue.
- Keep build-time secrets short-lived and scoped to the job that needs them.
- Separate dependency resolution, testing, and release signing so one compromised step cannot reach everything.
- Block arbitrary outbound network access from runners unless the job explicitly needs it.
- Prefer private mirrors, approved registries, and integrity checks for all transitive pulls.
- Record the full dependency graph and review diffs when nested packages change.
Where this guidance breaks down is in fast-moving polyglot pipelines with legacy package managers, because inconsistent lockfile behaviour and plugin execution rules make provenance enforcement uneven.
Common Variations and Edge Cases
Tighter dependency controls often increase build friction, requiring organisations to balance release speed against trust in third-party code. There is no universal standard for this yet across every package ecosystem, so best practice is evolving. Some teams will be able to enforce signature verification at the registry layer, while others will need compensating controls such as offline mirroring, restricted build containers, and manual approval for high-risk dependency families. NHIMG’s Reviewdog GitHub Action supply chain attack illustrates why “trusted action” does not mean “safe forever” when transitive updates and maintained-by-someone-else workflows are involved. The right control set also depends on whether the dependency is used only at test time, at build time, or in the deployed runtime. Build-only tools still matter because they often run with broader credentials than application code, and a compromised transitive package can harvest those secrets before any runtime defence has a chance to help. The operational rule is simple: if a dependency can execute during the pipeline, treat it as part of the trusted computing base until proven otherwise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-1 | Supply chain risk management fits transitive dependency control in CI/CD. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Build agents often expose secrets that transitive packages can steal. |
| NIST AI RMF | AI RMF governance supports risk-based control decisions for automated pipelines. |
Classify pipeline dependencies by impact and apply stronger review to higher-risk paths.
