Who is accountable when a malicious dependency steals secrets from CI runners?

Accountability usually spans engineering, platform, security, and the team that approved the publishing or build workflow. The control gap sits across software supply-chain governance, secrets management, and identity lifecycle discipline. Frameworks such as NIST CSF, NIST SP 800-53, and OWASP NHI all touch different parts of that shared responsibility.

Why This Matters for Security Teams

When a malicious dependency steals secrets from CI runners, the failure is not just “a bad package.” It is a governance break across build trust, secret handling, and workload identity. The runner is often privileged enough to sign artifacts, publish images, or reach internal APIs, so one poisoned dependency can turn a routine build into a credential harvesting event. NIST SP 800-53 Rev 5 treats system and information integrity, access control, and auditability as distinct control areas, but CI/CD incidents collapse them into one blast radius.

NHIMG research on the CI/CD pipeline exploitation case study shows how quickly build-time trust can be abused once a runner is allowed to execute unvetted code. The control problem is usually not absence of policy, but absence of runtime constraint: the runner has too much standing access, secrets live too long, and approvals happen before the dependency is actually executed. In practice, many security teams discover this only after the build system has already been used as the easiest path to secret theft rather than through deliberate adversary simulation.

How It Works in Practice

Accountability is shared because the exposure chain crosses team boundaries. Engineering owns the dependency choice and build logic. Platform engineering owns the runner image, isolation model, and outbound network controls. Security owns secret issuance policy, detection, and revocation expectations. The approving team owns whether the workflow should have been allowed to access production-grade secrets at all. That division matters because a stolen secret is often a symptom of excessive standing privilege, not just a malicious package.

Current guidance suggests treating CI runners as short-lived workloads with narrowly scoped identity, not as reusable service accounts. That means ephemeral tokens, task-specific secrets, and workload identity controls that bind access to the exact job context. NIST CSF and OWASP Non-Human Identity Top 10 both support the principle that secrets should be issued and revoked around the workload lifecycle, while NHIMG guidance on static vs dynamic secrets makes the operational point explicit: static credentials survive long after the job that exposed them is gone.

• Use per-job credentials with tight TTLs, not runner-wide secrets baked into images or environment variables.
• Separate build permissions from release permissions so a compromised dependency cannot publish artifacts by default.
• Log secret access, package execution, and network egress together so incident response can reconstruct the chain.
• Revoke and rotate secrets automatically when a pipeline job terminates unexpectedly or fails integrity checks.

For teams evaluating control maturity, the practical benchmark is whether a dependency can read only what the current task genuinely needs, and whether that access disappears immediately after execution. These controls tend to break down in monolithic pipelines with shared runners, cached credentials, and long-lived deploy tokens because the same identity is reused across unrelated jobs.

Common Variations and Edge Cases

Tighter build isolation often increases pipeline complexity and developer friction, so organisations have to balance blast-radius reduction against delivery speed. That tradeoff becomes sharper in high-throughput environments where one runner image serves many repositories, or where compliance teams require manual approval for secret rotation but not for dependency updates.

There is no universal standard for every CI pattern yet, but best practice is evolving toward context-aware authorisation and JIT secret issuance. In reusable runner fleets, the main edge case is credential residue in caches, artifacts, and logs. In self-hosted runners, the harder issue is whether the host itself should ever see production secrets at all. NHIMG’s Guide to the Secret Sprawl Challenge is relevant here because the question is not only where the secret lives, but how many places can inherit it once a build starts.

Another edge case is malicious transitive dependencies that only trigger under specific build conditions, which makes pre-approval reviews incomplete by design. The safer pattern is runtime policy enforcement with explicit allowlists for network destinations, artifact signing, and secret retrieval, rather than assuming dependency vetting alone is sufficient. That guidance breaks down when teams cannot separate build and deploy trust domains, because one compromised workflow then inherits the authority of all the others.

Related resources from NHI Mgmt Group

• How should teams respond when CI or developer secrets are exposed?
• Who is accountable when a trusted dependency steals build-time secrets?
• Who is accountable when a CI runner leaks credentials after a test-tool vulnerability?
• Why do CI test runners increase the impact of command-injection flaws?