Trusted publishing can’t prove package legitimacy in supply chains

At a glance

What this is: This briefing surveys recent supply-chain and application security findings, with the key pattern that trusted publishing, registry exposure, and malicious packages can all convert software distribution into code execution.

Why it matters: It matters to IAM, PAM, and NHI practitioners because the same OIDC tokens, GitHub workflows, API keys, and registry credentials that move software also move attacker access.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• 4.6% of all public GitHub repositories contain at least one hardcoded secret.

👉 Read Corgea's weekly security briefing on supply-chain compromise and poisoned packages

Context

Software supply chains fail when trust is treated as a property of the publishing path instead of the artifact, and this briefing shows how quickly that assumption breaks down across npm, container registries, and package ecosystems. For identity teams, the intersection is obvious: GitHub OIDC, short-lived tokens, build runners, and registry credentials are the control points that determine whether a package update is legitimate or weaponised.

The article is not just about malicious code in packages. It is about how compromise of source control, workflow permissions, and registry semantics can turn a normal install into execution, exfiltration, or privilege abuse. That makes the topic relevant to NHI governance because the security of non-human credentials increasingly determines whether software delivery remains trustworthy.

Key questions

Q: What breaks when package publish credentials are stolen in a software supply chain?

A: A stolen publish credential turns trusted release infrastructure into an attacker-controlled distribution path. The malicious actor can publish a package that appears legitimate, reach many downstream environments quickly, and bypass user suspicion because the attack comes through normal update channels. The control failure is usually weak secret scoping, poor rotation, and missing release approval boundaries.

Q: Why do build systems and package registries matter to identity governance?

A: Build systems and package registries rely on service accounts, signing keys and deployment tokens that act with organisational authority. If those non-human identities are over-privileged or poorly inventoried, an attacker does not need to defeat application logic. They only need to abuse the trusted identities that move code into production.

Q: What do security teams get wrong about dependency scanning?

A: They often assume a clean manifest means a clean environment. In reality, package managers can resolve transitive code dynamically and execute scripts during installation. A scan can confirm what should have been installed, but it cannot prove what actually ran or what secrets the code reached.

Q: How should teams respond when a trusted package path is abused?

A: Contain the affected pipelines first, then rebuild from known-good sources and rotate every credential exposed to the publishing path. That includes GitHub, cloud, vault, registry, SSH, and signing material. Teams should also review publish workflows as NHI assets because the compromise may sit in the automation identity, not only in the package contents.

Technical breakdown

Trusted publishing abuse and workflow provenance

Trusted publishing uses ephemeral identity assertions, often through OIDC, to let a CI workflow prove it should publish a package without storing long-lived credentials. The weakness is that provenance only answers which workflow signed the artifact, not whether the workflow itself was legitimate. If an attacker compromises a GitHub account, alters workflow permissions, or lands code on an unprotected branch, the pipeline can still produce a valid-looking package that carries malicious logic. That means the control plane is the publishing workflow, not the registry badge.

Practical implication: restrict publish rights to protected branches, inspect workflow changes as code, and treat OIDC-capable pipelines as privileged NHI assets.

Package installation as code execution

Modern package ecosystems increasingly execute code during install, import, or postinstall phases. That means the boundary between dependency resolution and runtime execution is thin, especially in npm and similar ecosystems where scripts, loaders, or build steps can trigger immediately. A malicious package does not need to wait for an operator to run a separate executable. It only needs a developer laptop, CI runner, or build environment to resolve the package and follow the execution path embedded in the artifact.

Practical implication: block unnecessary install scripts, sandbox build environments, and verify whether dependency installation requires the same trust level as production code.

Registry exposure and artifact privacy

Container and package registries often hold more than binaries. They can expose source fragments, lockfiles, internal hostnames, credentials copied into builds, and metadata that helps attackers map an environment. When a registry flaw permits unauthorised reads, the compromise is not limited to intellectual property leakage. It can reveal secrets and infrastructure detail that shorten the path to lateral movement, especially when build artifacts are reused across environments without revalidation.

Practical implication: classify registry contents as sensitive data, not just software assets, and apply access controls and secret scanning to private registries.

Threat narrative

Attacker objective: The attacker wants to convert ordinary software distribution into credential theft, persistence, and downstream compromise of development and cloud systems.

1. Entry begins when an attacker compromises a source-control account, abuses dependency-confusion trust, or publishes a poisoned package into a trusted ecosystem.
2. Escalation follows when package install, import, or workflow execution runs attacker-controlled logic with developer, CI, or registry privileges.
3. Impact occurs when the payload steals secrets, persists on hosts, or uses trusted delivery channels to broaden access across cloud and build environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trusted publishing has become an identity problem, not just a software distribution problem. The briefing shows that the decisive failure is not package upload alone but the non-human identity behind the upload path. OIDC, branch protection, workflow permissions, and registry access together form the trust boundary, and once one of them is weak, provenance can be made to look legitimate. For practitioners, the right question is which workflow identities are allowed to speak for the organisation.

Package ecosystems now behave like runtime attack platforms. Install hooks, import-time execution, and build-time code paths mean that a dependency can execute before conventional review processes have any chance to intervene. This shifts control priority from after-the-fact scanning toward policy at resolution time, which aligns with NIST CSF and access-oriented controls in NIST SP 800-53. For practitioners, dependency trust must be enforced before code reaches a runner or workstation.

Registry content should be governed as sensitive operational data. Private packages and container images often reveal more than source code, including credentials, environment assumptions, and internal service names. That creates a governance gap where organisations protect the registry perimeter but not the content stored inside it. For practitioners, registry hygiene has to include secret scanning, access review, and rebuild discipline, not just retention policy.

Supply-chain provenance is only as strong as the weakest publishing identity. A valid signature or trusted publisher path cannot compensate for compromised source control, overbroad GitHub token scope, or unprotected workflow branches. This is where OWASP-NHI concepts become relevant: the publishing workload is a non-human identity with lifecycle, privilege, and revocation requirements. For practitioners, provenance checks must be paired with NHI lifecycle governance.

Dependency abuse is converging across ecosystems, so control models must be ecosystem-neutral. The article spans npm, NuGet, Composer, and container registries, which is a warning that attackers are not loyal to one package format. What matters is whether the organisation has consistent controls for package trust, workflow identity, and artifact inspection across every delivery path. For practitioners, fragmented governance will continue to create blind spots.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• For a related NHI breach pattern, review The 52 NHI breaches Report for how compromised identities and exposed credentials recur across incidents.

What this signals

Workflow identities now need the same lifecycle discipline as human and machine accounts. If a pipeline can publish packages, request OIDC assertions, or reach a registry, it is part of the identity estate and should be governed that way. The practical shift is toward scoped branch protection, short-lived tokens, and continuous validation of which automation identities can speak for the organisation.

Secret exposure in software delivery remains a race condition for defenders. Once a credential reaches a public repository, package manifest, or build artifact, time-to-abuse can collapse to minutes rather than days. That is why secret scanning, rebuild discipline, and isolation of build runners must be treated as operational controls, not optional hygiene.

Artifact trust and NHI governance are converging into the same control problem. Teams that already manage non-human identities should extend that model to publishing workflows, registries, and CI systems, because those components now act like high-privilege machine identities. The broader signal is that software supply chain resilience increasingly depends on identity-centric governance.

For practitioners

• Protect publishing workflows as privileged identities Limit package publishing to protected branches, require reviewed workflow changes, and separate build from publish permissions so a compromised developer account cannot directly ship artefacts.
• Audit OIDC and GitHub token scope Review every workflow that can request OIDC tokens, confirm branch and environment conditions, and remove idle permissions from repositories that no longer need publish access.
• Treat dependency install as code execution Block unnecessary install scripts where possible, isolate runners, and validate whether package installation is permitted to execute in the same context as production workloads.
• Scan registry artefacts for embedded secrets Apply secret scanning and rebuild controls to private packages, container images, and build outputs because registries often preserve credentials, hostnames, and other sensitive metadata.
• Rebuild and rotate after supply-chain compromise If a trusted-publishing path or malicious package is confirmed, rebuild from known-good sources and rotate GitHub, npm, cloud, Vault, Kubernetes, Docker, PyPI, SSH, and GPG credentials from clean systems.

Key takeaways

• This briefing shows that supply-chain compromise is increasingly an identity abuse problem wrapped inside a package workflow.
• The evidence points to a recurring pattern of workflow compromise, install-time execution, and secret exposure across multiple ecosystems.
• Practitioners should govern publishing identities, restrict execution paths, and rebuild affected systems as soon as trusted delivery paths are contaminated.

Key terms

• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
• Dependency Confusion: A supply chain attack in which a build system resolves a malicious public package instead of an intended internal one because of naming, versioning, or registry precedence. The risk is not only code substitution but automatic execution inside trusted pipelines that already contain valuable credentials.
• Package install execution: Package install execution is the point at which dependency installation runs code on a developer machine or build runner. In supply chain attacks, that execution step becomes the entry point for secret theft, persistence, and propagation because it inherits trust before the workload is fully inspected.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full report

Corgea's full briefing covers the operational detail this post intentionally leaves for the source:

• Package-by-package breakdown of the affected Red Hat Cloud Services npm artefacts and the compromise path used to publish them
• Specific workflow abuse details, including how GitHub Actions permissions and OIDC token requests enabled trusted publishing
• Security research references and attribution chain connecting the package list, payload behaviour, and trusted-publishing abuse
• Remediation guidance for teams that need to validate repository workflows, package consumers, and affected build runners

👉 The full Corgea briefing covers affected package lists, attack paths, and remediation priorities.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners apply identity controls to the automation and delivery paths that modern software depends on.