Treat the combined path as a high-risk release boundary and split it up. Installation, testing, secret injection, and publishing should not all happen under one identity or one permission set. If they do, a single compromised dependency can pivot into broad release-system access.
Why This Trust Path Becomes a Release Boundary Problem
When package installs and CI/CD secrets live behind the same trust path, the issue is not only “too much access”, it is that the build and release process no longer has a clean separation between code consumption, execution, and secret handling. That turns ordinary dependency work into a potential release-system control plane.
In practice, teams should treat that path as an attack surface that can be exercised by a malicious package, a compromised maintainer account, or a poisoned dependency update. Once the same identity can both fetch code and receive secrets, a compromise in one step can cascade into publishing or infrastructure access.
That is why secret handling needs to stay separate from install-time trust. The safer model is to keep dependency acquisition, test execution, secret injection, and publishing under different permissions and, where possible, different runtime contexts.
How to Break the Shared Path Without Slowing Delivery
The practical fix is to split the pipeline into distinct trust zones. Build and test jobs should run with the minimum permissions needed to resolve dependencies and verify the package, while secret-bearing steps should be isolated to later stages that only execute after stronger checks have passed.
Use short-lived, narrowly scoped credentials for the smallest possible step, and do not let the same token or role survive across install, test, and release boundaries. The point is not only rotation, but blast-radius reduction: if a package or plugin is compromised, it should not be able to reach the secrets needed to publish or deploy.
Where feasible, move from broad shared secrets to workload-specific identity and purpose-built secrets delivery so that the release job does not inherit credentials just because it shares a runner or workflow. That gives you a cleaner line between “this code was fetched” and “this code may now perform privileged release actions”.
What Good Separation Looks Like in a CI/CD Release Path
A healthy design makes privilege changes obvious. The install stage can read dependencies, the test stage can observe behaviour, and only a later gated step can access release secrets or signing material. If a package install needs secrets to finish, that is usually a signal the flow is over-coupled.
Good separation also means preserving auditability. Teams should be able to show which step accessed which credential, why it needed that credential, and whether the credential was valid only for that execution window. If a runner can touch secrets before the release decision is made, the control boundary is already too loose.
For build ecosystems, the safest pattern is usually to move from ambient trust to explicit trust grants. A package install should not inherit the ability to publish artifacts, and a publishing job should not reuse the same credential path that was exposed to untrusted dependency code.
Risk and Threat Considerations
Shared trust paths make dependency compromise far more valuable to an attacker because the malicious package does not need to “win” a separate secrets theft step after execution. If the installation context can reach CI/CD secrets, the attacker can pivot from code execution to release-system access, artifact poisoning, or downstream environment compromise.
Failure mechanism: A package or build dependency executes in a context that also holds secret injection or publishing authority, allowing the dependency to read, relay, or abuse those secrets before detection.
Impact: The blast radius can extend from one build job to release pipelines, signing material, cloud access, or production deployment controls, especially when the same permission set is reused across jobs.
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 and OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8, NIST Zero Trust (SP 800-207) and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Shared package and secret paths raise secret exposure risk in CI/CD. |
| NHI-05 — Overprivileged NHI | One identity handling installs and releases often has excessive permissions. | |
| NHI-07 — Long-Lived Secrets | Release paths become unsafe when secrets persist across build stages. | |
| Recommendation — Separate dependency execution from secret injection and prevent untrusted code from reaching secrets. Reduce pipeline identity scope so install jobs cannot publish or access release credentials. Use short-lived secrets and rotate or revoke any credential that spans build boundaries. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | A shared trust path often means weak separation between authenticated steps. |
| API5 — Broken Function Level Authorization | Build identities should not be authorized for release functions they do not need. | |
| Recommendation — Require distinct credentials for install, test, and publish actions. Enforce function-level authorization so build jobs cannot perform publishing actions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Pipeline identities and secrets need controlled lifecycle and scoped access. |
| Recommendation — Inventory CI/CD accounts and remove any access that crosses install and release duties. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The response depends on removing implicit trust between pipeline stages. |
| Recommendation — Design pipeline stages as separate trust zones with explicit verification at each handoff. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Package install and release trust boundaries are core supply-chain integrity concerns. |
| Recommendation — Adopt stronger provenance and separation controls before allowing release actions. | ||
Practitioner Guidance
What to prioritise: First identify every place where untrusted package execution and secret-bearing operations share the same runner, role, or workflow token. Those are the highest-value boundaries to split because they create direct pivot opportunities.
What to verify: Check that the credentials used for install and test stages cannot publish artifacts, read long-lived secrets, or modify release definitions. If a secret is necessary, confirm it is injected only into the smallest job that genuinely needs it.
Common mistake: Teams often harden the secret store but leave the pipeline trust path unchanged. That still leaves the real problem intact, because the weak point is the combined privilege path, not just secret storage.
Practitioner takeaway: Treat package execution and secret access as separate trust decisions. If one identity can do both, compromise of the supply path becomes a release compromise problem, not just a dependency problem.
Related resources from NHI Mgmt Group
- How should teams respond when package trust is compromised in CI/CD?
- How should security teams respond when a widely used package is published from a compromised maintainer account and malicious code reaches CI/CD systems?
- How should organisations respond when an IDE extension attack targets cloud tokens, CI/CD secrets, and AI coding assistant credentials at the same time?
- How should teams respond when package-based malware can touch developer and CI secrets?