Notifications
Clear all
Topic starter
18/08/2026 2:29 pm
TL;DR: Developer workstations, runners, and publishing identities now sit on the same attack path, according to Corgea. The practical lesson is that package provenance alone does not protect the execution boundary when install-time code can steal secrets or republish malicious payloads.
NHIMG editorial — based on content published by Corgea: the weekly security briefing covering package compromises, kernel flaws, and library issues
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: What breaks when a compromised package can run code during install or import?
A: The trust boundary around software installation breaks first.
Q: Why do CI runners and publishing tokens make package compromise worse?
A: Because they convert a one-time execution event into durable access.
Q: How do security teams know if package-based secret theft is happening?
A: Look for unusual DNS activity, recent dependency installs, and new access attempts from accounts that should not be active on the affected endpoint.
Practitioner guidance
- Minimise secret exposure in build paths Remove long-lived tokens from developer and runner environments, and replace them with short-lived credentials that cannot be reused outside the intended job scope.
- Separate publish, build, and cloud identities Use distinct non-human identities for source access, package publication, and cloud operations so a compromised dependency cannot inherit all three trust domains.
- Harden runner and workstation execution paths Block unnecessary install-time and import-time execution where possible, then constrain file, network, and process access for package tooling on self-hosted systems.
What's in the full report
Corgea's full briefing covers the operational detail this post intentionally leaves for the source:
- Per-incident technical breakdowns of the compromised npm and PyPI packages, including installation and import-time behaviour
- Source-level mapping of the package chains, payload structure, and downstream exposure paths that matter for incident response
- The briefing's broader week-by-week remediation context across package compromise, kernel escalation, and library flaws
- The article's cross-reference set for teams comparing this wave with earlier supply-chain incidents and second-stage privilege escalation
👉 Read Corgea's weekly briefing on package compromises and supply-chain risk →
Package compromises in CI and dev tooling: what IAM teams need to know?
Explore further
18/08/2026 3:17 pm
Package compromise is now an identity problem as much as a code integrity problem. Malicious dependencies succeed when build systems hand them access to the same secrets used by developers, CI runners, and publishing workflows. That means the practical control boundary is not the repository alone, but the non-human identities that execute the software supply chain. Teams that still separate AppSec from IAM will miss the actual abuse path.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a malicious dependency enters a build pipeline?
A: Accountability is shared across engineering, security, and platform teams, but the control owner should be clear. Dependency intake, script execution, and publishing credentials are all governance points. In practice, the teams responsible for CI/CD, package policy, and non-human credential lifecycle must define who can approve, who can execute, and who can revoke.
👉 Read our full editorial: Weekly package compromises expose CI and developer identity risk
