docs: add 2025 software supply chain compromises to catalog #1497
Conversation
✅ Deploy Preview for tag-security ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
yfolias
force-pushed
the
catalog-updates
branch
from
47597ef to
cd9bea2
Compare
evankanderson
left a comment
evankanderson
left a comment
There was a problem hiding this comment.
Hi, this is one point of view, but I suspect that other TAG-SC members will have additional interesting takes that I don't want to preclude here.
| This is an _Attack Chaining_ type of attack as the attacker combined multiple | ||
| weak links in the software delivery process. |
There was a problem hiding this comment.
If the attack uses the attack chaining technique, we should call out the underlying weaknesses (Dev tooling, publishing infrastructure, and malicious maintainer).
| This compromise falls under _Publishing Infrastructure_ category as the | ||
| attackers were able to compromise the underlying automation layer used to build | ||
| and publish software. |
There was a problem hiding this comment.
If the attackers compromised GitHub user accounts to inject malicious workflows, I think this is a "malicious maintainer":
This category includes attacks from experienced maintainers going rogue, account compromise, and new personas performing an attack soon after they have acquired responsibilities.
| The Widespread npm Supply Chain Attack, which began around September 8, 2025, | ||
| was a multi-phased incident. The initial phase involved a phishing campaign that | ||
| compromised maintainer accounts, leading to the injection of a | ||
| cryptocurrency-stealing payload into dozens of popular packages (like chalk and | ||
| debug). This was quickly followed by the discovery of the "Shai-Hulud" worm | ||
| campaign, which used a self-propagating credential-stealing malware to | ||
| compromise over 500 npm packages. |
There was a problem hiding this comment.
Is this a single attack, or is this combining multiple attacks by distinct actors over the same time period with similar techniques?
There was a problem hiding this comment.
Good question. Many reports like this, suggest the phishing campaign and Shai-Hulud worm were linked phases of the same broader compromise, not separate incidents. Both targeted npm maintainers and abused publishing credentials within the same timeframe, so I’ve grouped them under one attack for clarity.
| and persistent access in CI/CD environments. The incident exposed the fragility | ||
| of transitive dependency trust and underscored the urgency of enforcing 2FA for | ||
| maintainers, signed package publishing, and dependency integrity verification | ||
| across the npm ecosystem. |
There was a problem hiding this comment.
I'm not sure that the "lessons learned" here line up with the impact. The initial phishing campaign could have been thwarted by strong 2FA (i.e. passkey / FIDO), but I'm not convinced that the worm had the same constraints.
NPM did react by preparing to move to stronger credentials, but I'm not sure what "dependency integrity verification" references here. If the worm ran in a CI environment with access to publishing credentials, I can imagine it performing signing using the same credentials that an intentional publish would have. Maybe we need a "build environment hardening" compromise type?
| This is an _Attack Chaining_ type of attack as it required multiple levels of | ||
| compromise. |
There was a problem hiding this comment.
If this used the attack chaining technique, let's call out the underlying types of failures. According to StepSecurity's writeup, it sounds like the initial attack leveraged a vulnerable CI workflow, which would mean this was a "Dev Tooling" attack.
| This is a _Publishing Infrastructure_ type of compromise as the compromise | ||
| occurred within Red Hat’s internal GitLab environment, which is part of its | ||
| development and collaboration infrastructure. |
There was a problem hiding this comment.
Again, I think this is a supply chain attack, but it's not clear that it's a software supply chain attack, despite the compromised infrastructure being a source control repository in this case. (The same attack could be applied against a consulting firm's Sharepoint or Google Workspace accounts with equivalent effect.)
There was a problem hiding this comment.
Agreed, I totally see your point. Do you think that adding a new category such as "3rd Party Vendor" type would make more sense for describing this type of incidents?
|
And, thanks for doing this! |
Many thanks for your comments. I will review everything and make the changes required |
yfolias
force-pushed
the
catalog-updates
branch
from
9c22234 to
a97b9d5
Compare
Signed-off-by: Yannis Folias <[email protected]>
yfolias
force-pushed
the
catalog-updates
branch
from
28378a3 to
5df03cd
Compare
2 participants
No description provided.