Observe
Accelerate
Troubleshoot
If you’re not an IT security expert, then you may be astounded to learn that over 20,000 new software security vulnerabilities were disclosed in just the first half of 2025. Expert or no, new vulnerabilities that threaten your production systems and your software supply chain are increasing exponentially.
AI has a role to play here—AI-generated code is far from perfect. A recent study reveals a 10x increase in security incidents for every 4x increase in code delivery speed, driven by larger batch sizes, larger PRs to review, and developers not fully understanding the code that’s being generated by AI.
Furthermore, attackers are also leveraging AI to develop novel ways of exploiting the software toolchain as well as your production environments. This means that the systems you use to build and deploy your production apps are no longer reliable or secure (and perhaps non-functional altogether), so you can’t even release a new version to counter the threat!
In this article, we’ll take a look at a specific use case—the now well-known ‘s1ngularity’ attack on Nx—and how Develocity can tell you in a few seconds if you were affected by this attack, when you were exposed to the threat, and whether you still have projects containing this vulnerability right now.
Develocity captures comprehensive data throughout the build process, empowering you to detect the ‘unknown unknowns’ so you can apply DORA’s “pervasive security”, reduce risk, and maintain compliance and quality.
What happened with the ‘s1ngularity’ attack on Nx?
On August 26, 2025, bad actors executed a supply chain attack targeting the nx npm package and its auxiliary plugins.
The attackers exploited a vulnerable workflow that allowed executable code injection via specially crafted pull request titles, leveraging the elevated permissions of the pull_request_target trigger to steal the npm publishing token utilized by Nx. This token enabled them to publish malicious versions of Nx packages to the npm registry.
These malicious packages contained code designed to scan file systems, collect credentials (including GitHub, Cloud, and AI secrets), and exfiltrate them to public GitHub repositories. Over 2,349 distinct secrets were leaked, primarily GitHub OAuth keys and Personal Access Tokens, along with credentials for Google AI, OpenAI, and AWS.
A novel element was the exploitation of installed AI CLI tools (such as Claude Code, Google Gemini CLI, and Amazon Q CLI) to search for secrets on developers’ machines, making this an attack vector directed at the supply chain itself.
Were you affected, and if so, where and when?
While the details behind this attack are interesting, the question on everyone’s mind then was “Sh*t, did we get hit?”
Aside from your software toolchain screeching to a halt, how would you find out if your business systems are built using an element of the affected package?
Moreover, can you confirm that you no longer have any vulnerable versions used across your entire project landscape?
Going even further, could you confirm whether a system had been compromised at some earlier point in time? This is crucial because existing security tools require you to actively scan for vulnerabilities at build time or scour through historical changes; but what happens when a toolchain is impacted between security scans, or the vulnerability is not present in the commit history?
You’ve probably guessed that Ctrl+F doesn’t do the trick.
Let’s imagine a couple of scenarios in which traditional security tools can’t help you.
Scenario 1
- A project is upgraded to a vulnerable version, and builds are run.
- The project is later upgraded to a non-vulnerable version.
- You learn about the attack; while no projects are currently affected, the truth is that earlier builds were exposed.
Scenario 2:
- A developer upgrades to a vulnerable version on their local machine (e.g., running npm update).
- The developer does not commit or push their code.
- You learn about the attack; source control shows no projects are impacted, but the local machine was actually exposed.
Within 30 seconds, you can find out if you’re safe or screwed. Let’s take a look in this short video (explained step-by-step below).
Observe, verify, confirm, and go back to sleep
We’ll use Develocity Analytics to identify affected components and versions for CVE-2025-10894, the critical Nx vulnerability that scans users’ systems for sensitive data and uploads it to public GitHub repositories. Among the numerous packages impacted by this vulnerability is @nx/eslint version 21.5.0, so let’s start there.
In the image above, you see that this organization has 39 projects connected to Develocity Analytics. We are now going to look for projects using npm, and select that from the menu.
After selecting npm, the dashboard updates to reveal that 34 of 39 projects use npm. Great…so how many projects are using Nx?
Now we select that namespace by typing in nx.
Adding the nx namespace reveals that 16 projects are included. Now it’s time to search for the eslint name.
Now that we’ve included eslint, let’s see where things stand with the versions used. Remember, we’re looking for @nx/eslint version 21.5.0 specifically. Other versions are not affected by this supply chain attack.
Good news!
No project has been built during the selected time period using @nx/eslint version 21.5.0—later versions of this package are not affected by this particular vulnerability.
You just turned a potential 3AM nightmare fire drill into a few extra hours of well-deserved sleep. Your systems are safe and sound from this security incident. But what is coming next?
If you don’t have this level of instant observability when it matters most, you’ll continue to fear supply chain attacks and other security incidents like this. We can help. Request a Develocity trial to learn more.