Notifications
Clear all
Topic starter
20/08/2026 5:53 pm
TL;DR: Compromised publishing paths, malicious package updates, and registry flaws can turn provenance, dependency trust, and install-time execution into a supply-chain attack surface across npm, NuGet, Composer, and container registries, according to Corgea. The lesson for identity teams is that artifact trust now depends on workflow, token, and branch governance, not package signatures alone.
NHIMG editorial — based on content published by Corgea: LLMjacking and supply-chain findings from the weekly security briefing
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.
Questions worth separating out
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.
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.
Q: What do security teams get wrong about dependency scanning?
A: They often assume a clean manifest means a clean environment.
Practitioner guidance
- 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.
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
👉 Read Corgea's weekly security briefing on supply-chain compromise and poisoned packages →
Trusted publishing abuse in npm and container registries: what now?
Explore further
20/08/2026 6:31 pm
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.
A few things that frame the scale:
- 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.
- 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
A question worth separating out:
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.
👉 Read our full editorial: Trusted publishing can’t prove package legitimacy in supply chains
