As those in charge of security software supply chains within organizations pick their collective heads up from untangling themselves from the aftermath of high-profile, debilitating attacks and scrambling to understand SBOM requirements in the wake of Biden’s Executive Order, they will learn there is still a lot of work to do in 2023. A lot has happened while heads have been down, and attackers have used this time to their advantage.
I know, because my team has been watching them. Phylum analyzes open-source packages’ source code and metadata as they are published into several popular ecosystems: NPM, PyPI, RubyGems, Nuget, Golang, Cargo and Maven. This year, we analyzed 627M source files across 11M package publications. Of these packages, we identified and reported 1,216 malicious packages.
Our findings also show that 99% of malicious open-source packages are designed to attack developer workstations and CI/CD build agents. Developers are the new high-value targets. This year, we have seen developers fall victim to stolen credentials and secrets, compromised workstations, CI/CD attacks and malicious packages that end up in source code.
Why? Because too many heads are down and nobody is looking.
Attackers are experimenting in the open-source ecosystem like rowdy kids on a playground.
By now, I can only imagine that practitioners are exhausted from the constant reactive state of DevSecOps. Between piles of false positives and unfixed vulnerabilities, having to work backwards from every known major breach to determine what has been impacted and being overwhelmed by skills shortages, I would be too.
Meanwhile, bad actors are flooding the open-source ecosystem with widespread simple attacks and easily achieving their goals. They know that most organizations are distracted by patching for Log4J, and only scanning code for license issues and vulnerabilities. So they’ve moved on to things like compromising open-source packages with Malware.
The software supply chain attack surface is a lot more complicated now, and can be compromised at every stage (See Figure 1 below).
In 2023, we’ll see more malicious authors realize the potential of the open-source ecosystem. We’ll see more of the same attacks, but some kids will grow up and get more sophisticated as we’ve already seen attempts at things like Ransomware.
At some point, you need to find a way to stop the bad behavior or you’ll end up spending all your time in the emergency room.
That point in time should not be put off any longer. It’s time to shift your AppSec program from reactive to proactive so you can use your resources more efficiently and keep pace with evolving threats. This is easier said than done – I get it. I have spent years in offensive security and have seen both the landscape and cost of attack execution change over time – more traditional paths (such as exploitation) have become prohibitively expensive, and increased focus in other traditional vectors of attack (such as increased focus on training and better endpoint technologies) have substantially raised the bar for gaining access. The combination of this shift in focus, coupled with changes in how software is developed, have given attackers more incentive than ever to go after the low hanging fruit: the undefended, poorly understood, software supply chain.
The biggest mentality shift needed to shift to an offense AppSec program is to think beyond established practice and compliance. These things are important, of course, but thinking in these terms only ends up making you a softer target, less informed than you could be and in a never-ending cycle of reactiveness. The first step here is to begin with the fundamentals: What is the actual attack surface and risk exposure? How do we fundamentally define the software supply chain? If we don’t first answer these questions, and gain insight into how a compromise might occur, it is fundamentally impossible to mount a suitable defense.
To stay ahead in 2023, focus on things like:
- Knowing which vulnerabilities are impacting your code and which ones are not. Shining a spotlight on the vulnerabilities that are putting you most at risk will stem the bleeding and give you more time and resources to start going on offense.
- Getting more visibility into the development process. Work closer with developers to understand the most vulnerable attack entry points in their process so you can find ways to address security needs throughout the lifecycle.
- Shifting further left to address threats as early in the lifecycle as possible. Instead of scanning source code after it’s built, find ways to address risks before compromised open-source packages are used.
- Implementing automation and continuous monitoring. Things like manual application scanning and even the newly hyped SBOM guidelines only provide snapshots in time.
- Getting ahead of the next regulation. As software supply chain threats infiltrate and impact more business practices, we’ll likely see nebulous things like supply chain risk management controls (as outlined in EO14028 – the Whitehouse initiative mandating SBOMs) become more well-defined, and additional transparency and security measures become requirements.
Source: CPO Magazine
