Who should be accountable when compromised npm packages spread through CI and developer systems?

Accountability should sit with the teams that own workflow identity, dependency governance, and secret management together, because the failure spans all three. Security, platform engineering, and application owners need a shared response model for package poisoning, credential rotation, and publishing control. That shared ownership is what prevents a supply-chain issue from becoming an open-ended identity incident.

Why This Matters for Security Teams

Compromised npm packages do not stay inside the build pipeline. They can reach developer laptops, ci runner, artifact stores, and publishing workflows, where a single poisoned dependency can expose tokens, tamper with releases, or pivot into broader NHI compromise. The real issue is not just malware in a package registry. It is that package trust, workflow identity, and secret exposure are usually managed by different teams with different controls.

NHIMG’s research shows why that gap matters: Ultimate Guide to NHIs — Why NHI Security Matters Now reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks. In a supply-chain incident, that means the blast radius often includes credentials that were never meant to touch a package install at all. Current guidance suggests treating package compromise as an identity event, not only a dependency event.

In practice, many security teams encounter the identity side of package poisoning only after secrets have already been exfiltrated from developer systems or CI logs, rather than through intentional dependency governance.

How It Works in Practice

Accountability works best when it follows control ownership, not just incident visibility. Platform engineering typically owns CI runners, workload identity, token issuance, and publishing permissions. Application owners usually own dependency approval, lockfile discipline, and build hygiene. Security owns policy, monitoring, and response standards. When compromised npm packages spread, all three domains need to act on the same timeline.

A practical response model starts with reducing what a package can reach. That means short-lived credentials, isolated build identities, and no long-lived publishing tokens on developer machines. Use workload identity for CI jobs so the pipeline proves what it is at runtime, instead of relying on static secrets embedded in scripts or environment files. This aligns with the broader NHI guidance in The 52 NHI breaches Report, where identity compromise repeatedly turns into downstream access abuse. For implementation detail, the CISA Secure by Design approach reinforces reducing exposed secrets and hardening defaults before incidents occur.

• Give CI jobs ephemeral, scoped credentials for install, test, and publish steps.
• Separate dependency ingestion from release authorization so a poisoned install cannot sign a release.
• Monitor for secret access, unusual package lifecycle actions, and token use outside expected runners.
• Revoke and rotate any credential that touched the affected environment, including developer caches and local registries.

The most effective control is runtime policy: a build should be allowed to fetch only what it needs, when it needs it, and only from approved contexts. Current best practice is evolving toward policy-as-code and workflow identity attestation, but there is no universal standard for this yet. These controls tend to break down in permissive monorepos with shared runners and cached credentials because the same identity can touch build, test, and publish paths without clear separation.

Common Variations and Edge Cases

Tighter dependency controls often increase build friction, requiring organisations to balance release speed against containment. That tradeoff becomes sharper in developer-heavy environments, where local installs, fork-based testing, and self-hosted runners make package trust harder to centralise.

One edge case is third-party CI integrations that inherit broad permissions from the parent repo. Another is organisations that pin dependencies but still allow developers to execute postinstall scripts locally, which can turn a package compromise into workstation compromise. A third is release workflows that reuse the same token for package install and package publish, creating a single point of failure.

Best practice is evolving, but the pattern is clear: accountability should include whoever can change identity scope, secret exposure, or publishing authority. That usually means platform engineering for runtime controls, application owners for dependency policy, and security for detection and escalation. Anthropic’s report on the first AI-orchestrated cyber espionage campaign report is a reminder that automated tooling can scale abuse quickly once credentials are exposed. The governance question is therefore not who owned the package, but who controlled the identity and secret paths the package could reach.

Related resources from NHI Mgmt Group

• Who is accountable when AI tool use happens through unmanaged browser sessions?
• How can organisations reduce the blast radius of compromised agent identities?
• How can organizations manage unauthorized agents in their systems?
• How should security teams think about a compromised integration like Drift?