Notifications
Clear all
Topic starter
18/08/2026 2:54 pm
TL;DR: Five supply chain attacks in 48 hours hit developer laptops, GitHub Actions, npm, PyPI, and GitHub itself, with about 3,800 internal repositories exfiltrated and traditional scanners unable to stop the activity, according to StepSecurity. The pattern shows that pipeline security fails when organisations rely on one layer of control instead of runtime visibility across development, build, and package ecosystems.
NHIMG editorial — based on content published by StepSecurity: 5 Supply Chain Attacks in 48 Hours: Why Securing One Layer Is Not Enough
By the numbers:
- Five distinct attacks targeted every layer of the development pipeline in just 48 hours.
- GitHub disclosed that approximately 3,800 internal source code repositories were exfiltrated.
- Microsoft's durabletask PyPI package was attacked with three malicious versions in 35 minutes.
Questions worth separating out
Q: What breaks when software supply chain security relies only on SCA scanning?
A: SCA-only programmes generate visibility without decision quality.
Q: Why do compromised developer tools create identity risk as well as code risk?
A: Developer tools often hold the same credentials that access source control, cloud services, package registries, and password vaults.
Q: How should security teams reduce the blast radius of compromised CI/CD tools?
A: Limit each pipeline to the minimum credentials it needs, separate build from deploy permissions, and remove long-lived secrets from execution environments.
Practitioner guidance
- Inventory developer-side secrets exposure Map IDE extensions, package managers, cloud CLIs, and password manager integrations across developer endpoints so you can identify where a compromised tool could collect tokens or API keys.
- Add runtime controls to CI/CD runners Monitor process memory, outbound network destinations, and shell execution on ephemeral runners because attack detection at the manifest layer will not stop secret theft in runtime.
- Treat action tags and package versions as privileged inputs Block or review workflows that reference mutable tags, recently published packages, or unverified action commits so trusted automation cannot silently inherit malicious replacements.
What's in the full article
StepSecurity's full blog post covers the operational detail this analysis intentionally leaves for the source:
- Detailed attack timelines for the Nx Console extension, malicious GitHub Actions, Shai-Hulud, and Microsoft's durabletask compromise
- Environment-specific detection and blocking controls across Dev Machine Guard, Harden Runner, and Compromised Actions Policy
- The full incident matrix showing which StepSecurity control applies to each attack vector
- IOC and remediation detail for teams that need to confirm exposure or response steps
👉 Read StepSecurity's analysis of five supply chain attacks in 48 hours →
Five supply chain attacks in 48 hours: are your controls layered enough?
Explore further
18/08/2026 3:37 pm
Pipeline security has become an identity problem as much as a code problem. The article shows that attackers are not just exploiting software defects, they are abusing trusted identities inside build and delivery systems. Once credentials are stolen from developer tools, runner memory, or package workflows, the attacker is operating as a trusted principal rather than a noisy intruder. Practitioner conclusion: governance must track where secrets flow, who can reuse them, and which identities remain trusted after compromise.
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.
- Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when a compromised package credential is used to spread malicious artefacts?
A: Accountability sits with the organisation that owns the publishing authority and the surrounding identity controls, not just the developer who used the tool. Publishing access is a privileged identity path, so governance must cover ownership, monitoring, and revocation with the same seriousness as other elevated access.
👉 Read our full editorial: Five supply chain attacks in 48 hours exposed pipeline blind spots
