Software developers in a digital crosshair
I speak about threats that software developers have faced since around 2019. In 2024, I had a break and at the end of 2025, I decided to revisit the topic. Below is a summary of what was happening in 2025 regarding both old and new threats and observed attacks.
Software developers in a digital crosshair
This article is the summary of my talk from the Oh My Hack 2025 conference.
AI wink 😉
Is the AI the source of the new threats? In my opinion, the use of AI has been the biggest change in software development in the last few years. There is no going back now; AI in software development is here to stay.
It did bring new issue types and a lot of new code being written, or should I say, also generated, but it happened before with all technologies that got mass adoption. See my article about the security challenges of an MCP (Model Context Protocol) for more information.
Main characters
I believe that in software development, we face two main challenges that are most impactful on the security of the final software.
Speed and complexity.
Speed (how fast software is delivered) is increasing, making the time for software development shorter and shorter.
Complexity (plethora of components that are needed for the software to be created and to work) is increasing.
And those two are here to stay.
Speed
Some time ago, we delivered software once a year, then once a quarter, and then once a month. Now, several times a day, an hour, or even more frequently, depending on the software. AI also contributes to this, as the general assumption is that it helps move faster (build PoCs, tests, etc.), so the time estimates for a given ticket or task may decrease further.
Complexity
Once, everything could run on the same computer (remember the LAMP stack sitting on the same machine, or even earlier?) and one senior developer understood it all.
Now we have clouds, containers, queues, microservices, external APIs, serverless architecture, and MCP servers (go see the article) and fewer and fewer people can grasp the whole picture of what we build.
For both speed and complexity, I don’t see any signs that anything will change any time soon.
Connect with the author on LinkedIn!
2025 and forward
Are we seeing more attacks or fewer?
In 2025, I believe we saw an increase in the number of attacks. We definitely saw an increase in the complexity of those attacks. I will include more details about some of them below.
Also, I did not see any breakthrough change that may impact the future in a way that we will see fewer attacks.
Attack catalogue
Here, I decided to split the existing threats into three categories:
- Components related to attacks
- Tool-related attacks
- Infrastructure-related attacks
Components
Some years ago, I only had libraries here. Now then, I mean the component: every puzzle you use to build your application/environment. So here we have libraries and extensions/plugins for the various tools you use, as well as Docker images and other pieces on which you build your infrastructure.
We may say that software supply chain failures got the much-needed attention, being included in OWASP TOP 10 2025 and already in TOP 3.
Here is a list of attacks or threats related to components:
- Typosquatting
- Dependency confusion/takeover
- Phishing
- Protestware
- AI package hallucination
At the end, I describe a few interesting cases of supply chain attacks using components.
Typosquatting
That’s a case where, for example, you import some libraries using a command line and make a typo. Attackers publish malicious packages with names like popular ones, hoping that someone will make such a mistake when importing or downloading a library or package.
Of course, it’s not just misspelling; there are other techniques, like adding prefixes, postfixes and separators, as described here.
There is hope, since we have several tools that wrap command-line package managers like npm or PyPi in a way that’s invisible to developers and verify the security of such packages before they’re installed.
This is the way. Security tools should be done this way – do their job without putting more effort into the developers.
Dependency confusion/takeover
Dependency confusion was invented by Alex Birsan. In short, imagine that a package auth-paypal is available only in PayPal’s private package repository, like npm, and does not exist in a public one. An attacker creates and publishes a malicious one named auth-paypal in a public npm. Under some circumstances, the malicious one may be installed instead of the original, private one.
In 2025, I found a few attempts to do this, including one potentially harmful one done by a security vendor.
Dependency takeover is a broader topic. It may be that someone recreates a project with the same name, and that name is still in use somewhere. Example: an attacker takes over a domain that is available and has a JavaScript linked from some site.
Phishing
In 2025, phishing is still a thing. We, as an industry, pushed so hard for 2FA adoption so that phishing attempts use messages related to 2FA setup, like in this case. Successful phishing of a maintainer of a library or an extension is a usual suspect in many cases from 2025, as a way to gain an initial entry point (malicious modification of the maintainer’s libraries).
Protestware
That’s the case when a maintainer decides to express a political, ideological, or other point of view using maintained software.
At some point, you use a popular package and it does the job. Next, your application is not working because the library has been updated.
Here are a few examples: color and faker libraries, nest. js-pino and link-loom.
End of open source?
This problem was not on my 2023 list, but it got here in 2025.
I stumbled upon this and started wondering. If someone maintains an open-source library and it gets popular, then it gets security researchers’ attention. Therefore, there are possibly a bunch of security issues to handle and a day is still 24 hours. Now the number of vulnerabilities can grow massively due to intensive LLM use for core review stuff. And there is no free lunch. So sometimes you just quit. It’s understandable, of course.
From a software development perspective, we should consider how much we depend on open-source libraries and whether a given library will stop receiving security fixes or be developed according to a roadmap we’re waiting for. So, if a maintainer has a sponsorship opportunity, definitely consider it.
AI package hallucination
When a developer falls for typosquatting is one thing; when an LLM hallucinates, a package name is another. Thanks, called package hallucination or slobsquatting.
So, if attackers spot such a package that does not exist in a public package repository, they may create one.
And LLMs, which generate code, hallucinate package names, some more than others. What’s more interesting and what makes this attack more practical is the fact that package names, which are hallucinated, do repeat. It means that when users ask to generate a code like other users’ prompts, the hallucinated package name may appear again.
How cool is that.
Supply chain attacks using components
Below are some interesting cases from 2025 of supply chain attacks in various component ecosystems.
S1ngularity
This is a case of an interesting, first-timer supply chain attack. In this case, what was new was the use of the available victim’s AI capabilities to help steal credentials.
What’s also interesting is that it was a two-step attack – first, it harvested credentials and published them automatically to a public GitHub repository with the s1ngularity-repository prefix. Second – the attacker, using the harvested credentials, either reconfigured private repositories to be public or forked them.
Shai Hulud 1 & 2
Those are definitely the most interesting campaigns of 2025. First and second coming of Shai Hulud.
The first version was the first successful self-propagating worm in the npm ecosystem. Initial access vector was probably linked to the above mentioned s1ngularity.
As for Shaui Hulud 1 capabilities:
- It could inject GitHub Actions
- Exfiltration of data via public repositories
- Attempts to leak private repositories
- And tries to propagate to other maintained npm packages
A total of 500+ package versions were infected.
The second coming went a bit further. Zapier, Postman and PostHog npm packages were compromised and the attack quickly spread further.
To give you some numbers:
- ~20000 malicious repositories created
- ~800 packages compromised
- ~500 GitHub users compromised
- ~800 cloud credentials compromised
That’s huge; it was spreading rapidly. I do recommend reading the linked articles – you’ll find technical details and recommendations there.
Glass Worm
As Shai Hulud was self-propagating through npm, Glass Worm is the first known self-propagating worm in VS Code extensions on the OpenVSX marketplace, with around 36 000 installations. Contains a lot of sophisticated elements like:
- The use of non-visible, unprintable Unicode characters in its source code,
- The use of Solana blockchain as a command-and-control mechanism – to put a link to an IP with the next payload (so no C2 server takedown coming anytime soon),
- AES encryption in HTTP communication with a web server running on that IP address,
- Harvesting credentials, including no less than 49 different cryptocurrency wallet extensions,
- Possibility to drop a sophisticated RAT (remote access tool).
Impressive capabilities for a malicious VS Code extension.
Tools
Here are some stories from 2025 related to tools.
RubyGems
In short, it was a hostile takeover of a GitHub organization. One day, one member with sufficient permissions added a new member, removed all other members, and renamed the organization. New rules, new management quoting Winston from John Wick.
Go see the details as this is an interesting story.
Now, imagine a few years ago you selected some open-source technology or framework for your applications and ka-boom, you’re wondering if the planned roadmap of features will be delivered, or a bug will be fixed. We assume some stability and a certain level of trust in stuff like that.
What now? Such a threat was not on my list. It is now.
MCPoison
Here goes a first MCP-related issue with a logo and fancy name.
Curson is an IDE that gained some attention due to the push to seamlessly integrate with various LLMs. As each new technology gains popularity, a lot of code is written and written fast, and security researchers follow, so a lot of vulnerabilities are being discovered.
One of the most interesting findings is MCPoison.
When a project was opened in Cursor and an MCP-related configuration was discovered, the user was prompted to authorize this configuration (a new MCP server). The problem was when the configuration changed and the user opened the project in Cursor again. There was no authorization prompt for that change.
Connect with the author on LinkedIn!
Infrastructure
Red Hat incident
Attacks on the SDLC infrastructure are growing. One example from 2025 was a security incident related to a Red Hat GitLab instance. Projects related to various Red Hat clients were hosted there, including the financial and defense sectors. The Ransomware group dumped more than 500 GB of these projects.
The internet-facing infrastructure should be strictly monitored and this incident is another reminder about that. The same goes for cloud infrastructure and let me underscore it again: the SDLC infrastructure as well (self-hosted or in the cloud, or a prom provider like GitHub).
We can still see or at least suspect that some of these incidents are related to missing MFA for credentials with broad permissions, or to the fact that the infrastructure is not up to date.
Confused composer
This story by Tenable is interesting. It shows how one cloud service – Cloud Composer uses Cloud Build, another service, underneath, without user control. The other one – Cloud Build has more privileges than it should.
By getting a malicious Python library from PyPi, an attacker could escalate permissions. This situation seems common in the clouds (use of another service underneath) and such scenarios may be repeated.
Closing words
In the complex and quickly evolving world of today’s software development, be ready to move quickly and do not rely only on testing at a late stage. Be warned.
The awareness of all people on board is the first step. If you’re reading this, great, now spread the word to your fellow programmers. Show them examples of incidents.
Components
Finding tooling that will protect developers without forcing them to slow down and do manual checks is possible. Automate components’ security, but with process efficiency in mind.
If you’re a maintainer of something open source, enable MFA whenever possible and be vigilant for phishing attempts.
Tools
Use only what’s necessary, uninstall what you do not use anymore. Update what you have. Make an isolated sandbox (consider a separate VM) for your playground with new stuff. Be aware of the secrets you keep and where exactly you keep them.
Infrastructure
Here’s the same mantra for making it secure: do an inventory, monitor, update, test, and repeat. And of course, automate what you can.
Head of Web Security
