Who is accountable when a package publishing identity is abused?

Why This Matters for Security Teams

Package publishing identities often sit at the junction of source control, CI/CD, registry access, and release automation. When that identity is abused, the impact is rarely limited to one team because the same workflow can sign artifacts, publish packages, and pull secrets that reach deeper into the environment. That makes accountability a governance question, not just a technical incident response question.

NHIMG research shows how often weak NHI hygiene turns into real exposure: 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks with tangible damage. Those conditions are especially dangerous in publishing pipelines, where a single compromised token can be reused across build and release steps. The pattern is visible in incidents such as the LiteLLM PyPI package breach and the JetBrains GitHub plugin token exposure, both of which show how publishing identities can become supply chain entry points.

Current practice still fails when ownership is split informally across platform engineering, security, and application teams without a named controller for release rights, secret handling, and trust decisions. In practice, many security teams encounter accountability gaps only after a package identity has already been abused and downstream consumers are affected.

How It Works in Practice

Accountability should follow control of the publishing workflow, not merely who can see the repository. The team that owns the package registry integration, CI/CD pipeline, signing step, and secret issuance path is the primary accountable party. Security may set policy, but the operational owner must be able to answer three questions at any time: who can publish, which identity is used to publish, and what secrets or tokens that identity can reach.

Good practice is to treat the publishing identity as a non-human identity with a lifecycle. That means documenting the owner, defining the intended scope, issuing least-privilege access, and rotating or revoking credentials when the workflow changes. The Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing NHIs is essential for successful zero-trust implementation, which aligns with standard control guidance in NIST SP 800-53 Rev. 5 Security and Privacy Controls for access control, auditing, and configuration management.

• Assign one accountable owner for the publishing workflow, not just the repository.
• Use separate identities for build, sign, and release functions.
• Prefer short-lived credentials over static tokens stored in CI variables or code.
• Log every publish action with identity, commit, pipeline run, and approver context.
• Revoke release access when the workflow, team, or trust boundary changes.

Where possible, use workload identity and policy enforcement at request time rather than broad standing access. That makes it easier to prove which system acted, on whose authority, and with what scope. These controls tend to break down in fast-moving monorepos with shared release automation because one pipeline often publishes many packages under inconsistent ownership.

Common Variations and Edge Cases

Tighter release controls often increase delivery overhead, requiring organisations to balance faster publishing against stronger separation of duties. That tradeoff becomes visible in shared registries, third-party maintainer models, and outsourced build systems, where several groups may touch the same publishing identity.

There is no universal standard for ownership models in package publishing yet, but current guidance suggests the accountable party should be the team that can actually rotate the identity, change the pipeline, and shut off release rights. If that team cannot do all three, ownership is incomplete. This is especially true when abuse happens through a compromised maintainer account, a stolen CI token, or a malicious dependency update, as highlighted in NHIMG research such as the 52 NHI Breaches Analysis.

Some organisations try to make security the default owner of every publishing identity. That usually weakens accountability because security can define guardrails, but it rarely operates the day-to-day release process. The better model is shared responsibility with clear operational ownership, documented escalation, and auditable trust decisions. Where package publishing spans external maintainers, build vendors, or automated release bots, the ownership line should be written into the release process itself, not inferred after an incident.

Related resources from NHI Mgmt Group

• Who remains accountable when a managed SOC misses an identity-driven attack?
• What breaks when package publishing still depends on persistent maintainer privilege?
• Why do package registries need identity controls as well as malware scanning?
• When does a machine identity become a compliance problem?