TL;DR: Recent supply chain attacks against npm, PyPI, CI workflows and AI-assisted development tools show that attackers are chaining developer trust, package publishing and secret theft faster than many organisations can detect, according to Boost Security. The real problem is not just malware in packages, but the widening governance gap between code intake, credential exposure and downstream blast radius.
NHIMG editorial — based on content published by Boost Security: Developers under attack is the new black
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when supply chain attacks can steal secrets as well as publish malware?
A: The biggest failure is that code compromise turns into identity compromise.
Q: Why do package ecosystem attacks create such large blast radius risk?
A: Because one trusted publishing identity can reach many downstream teams through normal dependency updates.
Q: What do security teams get wrong about CI secrets in supply chain incidents?
A: They often treat CI secrets as temporary configuration rather than durable access.
Practitioner guidance
- Treat developer and pipeline credentials as governed identities Map npm tokens, GitHub workflow credentials, CI secrets and cloud keys into the same inventory so ownership, expiry and revocation are explicit.
- Separate build trust from publish trust Require stronger controls on release workflows than on ordinary build execution, including protected signing steps, branch protections and restricted package publishing permissions.
- Add secret discovery before and after publication Scan repositories, workflows and published artifacts for secrets before release, then repeat scanning after release when packages are updated or mirrored.
What's in the full article
Boost Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Attack-by-attack breakdowns of the recent Nx, Qix, Shai-Hulud and GhostAction incidents and how each one was executed
- Examples of advanced detection techniques used to spot malicious package behaviour before it reaches runners
- Discussion of ecosystem hardening features such as minimum release age in package tooling
- References to the author's attack trees, open source scanners and incident-response tooling for supply chain security
👉 Read Boost Security's analysis of recent supply chain attacks across npm, PyPI and CI →
Supply chain attacks across CI and packages: what defenders are missing?
Explore further
Supply chain compromise is now an identity governance problem, not just a code integrity problem. The attacks described here rely on abused maintainer accounts, tokens and CI credentials, which are non-human identities with delegated authority. Once those identities are treated as operationally important, the control question changes from package scanning alone to lifecycle control, least privilege and revocation discipline across the software factory. Practitioners should govern publishing identities with the same seriousness as production service accounts.
A question worth separating out:
Q: How should organisations respond when a developer account or workflow is compromised?
A: Contain publication paths first, then rotate every token and credential that the account or workflow could have reached. Review package signing, branch protections and runner permissions before resuming releases. The key is to assume secondary theft has already happened, because supply chain attackers frequently use one compromise to seed others.
👉 Read our full editorial: Supply chain attacks are accelerating across CI, packages and AI tools