"I've never found it hard to hack most people. If you listen to them, watch them, their vulnerabilities are like a neon sign screwed into their heads." – Elliot Alderson, Mr. Robot
If you're a software developer, you're already a target.
As cyber-attacks continue to grow exponentially worldwide, threat actors have shifted their focus from endpoints and end users to the software supply chain (see SolarWinds, Log4j, and Kaseya). Attackers have come to realize that today's production environments are way more advanced and difficult to hack than before, making the often unsecured build environments the hot new channel for cybercrime.
A good analogy is home burglary: when only your front door is well-protected with high-level security locks, an alarm system, and an outdoor camera, burglars will try to break in through an open window.
Attackers are adding malware-in-disguise to open source repositories by using similar names to the real packages (a practice called "typosquatting") with the goal of tricking software developers into installing them. As an example, we discovered recently that malicious versions of "Requests" (a legitimate, widely used PyPI library) named as "requesys", "requesrs", and "requesr" were found in the repository. Lack of creativity? On the contrary: attackers wanted you to accidentally mistype the "requests" name so that you end up installing their malicious packages containing ransomware.
The growing adoption of open source
One of the main reasons bad actors are targeting open source is because of its high adoption rate in the last decade.
If you look at the evolution of a company like Microsoft you'll notice that they went from hostility towards the open source movement in 1998 to acquiring not only GitHub but recently npm. A company that goes from literally saying "Linux is a cancer" (2001) to "Microsoft loves Linux" (2014) is a good example of how the growth of open source software has forced the tech industry to act and think differently.
It has even affected pop culture: the movie archetype of the genius, lonely programmer that works alone in a dark basement and is the sole creator of a mindblowing piece of software is a bit outdated now (if that's still you, you've earned my respect!). As the market needs are forcing companies to speed up development, today's programming is more of a collective effort: a collage if you will of some proprietary code and about 90% of open source components.
What's great about open source repositories is that they're free and open for all to publish; unfortunately, this also includes bad actors. Software developers – with their elevated access, powerful laptops, and in some cases, a dislike for security processes – became a perfect vehicle for distributing malware in the supply chain. Attackers can then install backdoors, cryptominers, ransomware, you name it... and even pivot to other builds or dependencies.
All this means that you, a software engineer who benefits from open source components, are vulnerable to attacks.
How vulnerable?
Well, it depends on how protected you are.
Securing the software supply chain
If you check for vulnerabilities within your IDE every time you add components to your projects, and you choose the healthiest versions available, you'd be more protected. Following our analogy, your doors and windows will be locked and burglars will have a hard time breaking in.
But if you don't care much about component security, and inadvertently add into your CI/CD pipeline a malicious package from a registry, you might end up deploying malware. With an open window, burglars are more liable to get in. They will break into your home. They will steal from you.
The castle doctrine is a law principle that says that you have the right to use reasonable force to protect yourself against an intruder inside your home. As a software developer, being aware of the dangers of cybercrime, and becoming familiar with the subject, is the best way to fight back against an antagonist that's now bigger than the drug trade.
A good first step is to nail down terminology.
Malware vs. vulnerability
As cybersecurity keeps changing in the public eye from the equivalent of anti-virus and firewall to a multifaceted field with a wide variety of jargon, you often find journalists, technologists, and policy makers getting entangled in terminology that might be ambiguous to understand, let alone act on.
You might be watching the news, casually scrolling through an obscure subreddit, or even listening to a presentation at an industry conference when you notice the terms "vulnerability" and "malware" being used interchangeably.
If you want to make a cybersecurity professional cringe just say "malware" when you’re really talking about a "vulnerability" or vice versa. They're different terms for a reason so let's define them once and for all to hopefully clear up any confusion.
Vulnerability: A weakness in a system that could be exploited by threat actors. In our analogy, the vulnerability is the open window. When the details of the vulnerability are disclosed, they're assigned a CVE (Common Vulnerabilities and Exposures) identification. Some individuals might want to keep their findings private, though, and instead of reporting the vulnerability, they might actively exploit it before a patch is released or implemented. This is what's known as a "zero-day."
Malware: Malicious code or software intentionally inserted into a system and intended to perform an unauthorized process. In our analogy, malware would be the thief exploiting the vulnerability (open window) by getting into the house. Malware can be classified based on its functionality: adware, trojan horse, worm, spyware, virus, ransomware, crypotominer, and even a hybrid. And they're often creatively named.
There's a fun quiz page that shows you names such as Wifisfuneral, Gh0stRAT, and CozyDuke, and you have to decide if they're rappers or malware. Give it a try and don't be afraid of failing: the average score is 70% for rap fans and 61% for cybersecurity professionals. No scores for developers have been reported yet.
Developers like you already have a lot of things on your radar. You don't have to be aware of every malware or vulnerability that gets disclosed. Our stats show they keep growing every week, so having automated defenses against malicious packages is the way to go.
Bad actors are out there trying to take advantage of your build environment.
Are you ready to fight back?
AI-generated image via DALL·E. Prompt: A developer visibly confused staring at a glowing monitor with a dependency tree displayed in a dark room at night time with a large whole wall window displaying a city in the background in the style of Miyazaki.
.jpg)
