Preparation is Key to Mitigating the Business Impact of Malware Attacks
Introduction
Sonatype recently released its 10th State of the Software Supply Chain Report, and it’s clear that this year’s findings serve as both a progress report and a call to action. There’s no doubt that over the last decade, awareness of the importance of software supply chain security has grown. But as an industry, we’re not doing a dramatically better job today, on average, of taking action. Our research shows that the number of vulnerabilities that remain unfixed and dependencies that aren’t updated hasn’t changed as fast as we’d expect, considering the increased awareness. We know the use of open source has skyrocketed and represents 90% of all modern software development – including both software that organizations produce and what is being consumed. The reality for developers is that you simply cannot develop software without leveraging open source. If you were somehow able to achieve that, you’d be putting yourself at a critical innovation disadvantage. In fact, it’s estimated that more than 6 trillion open source software components have been downloaded this year alone. According to the Harvard Business School, the value companies derive from open source code is almost $9 trillion.
In other words, it’s difficult to overstate the value open source provides in making innovation faster and far less complex. However, it also introduces new threats, with each component introducing new risks and potential vulnerabilities. This reliance is just one of the reasons why security has become a foundational element of most SDLC environments. One of the key trends we’ve seen is the rise of open source malware, with the number of malicious packages growing 156% year-over-year. We know from Sonatype’s own research that malware attacks aimed at open source in public repositories are rising, resulting in a 742% average yearly increase in software supply chain attacks since 2019.
Developers Are Now the Primary Attack Vector for Bad Actors
Malware attacks are on the rise, partly because they present an irresistible target. With open source being such an integral component of virtually all software development, public repositories, and more specifically, the developers that rely on them, have become ground zero for targeted attacks. Hackers know this is where they can amplify their impact and target software that could potentially be distributed to the far reaches of the globe. Incidents like the Crowdstrike outage, even though it was not a security breach, served as a harbinger of what could happen with a coordinated malware attack. We could see multiple systems failing simultaneously, compounding the damage and delaying an effective response. Imagine trying to respond with telephone networks down at the same time as a massive power outage. Crowdstrike and other high-profile incidents have served as a wake-up call for organizations to get practical about the steps they would need in place in order to mitigate potential threats like this. The good news is that technology exists to help, but if it’s not put into place before something happens, it’s too late.
Starting in 2017, we really began seeing the first intentional manipulation of the open source software supply chain specifically for exploitation. These are not simply vulnerabilities that might accidentally cause a problem but components built to do harm. And because of the nature of these malware attacks, traditional security tools aren’t reliably detecting them. The trend has grown – up 156% in just the last year, from around 250,000 known intentionally malicious components to a little more than 700,000. That’s close to a million components put into open source repositories with the express intent of causing harm.
Human error is still one of the most reliable ways to gain access, and these attacks are essentially phishing schemes targeting developers. Organizations that haven't recognized the threat are defenseless because historically, the way we've defended our software supply chains is to focus on the product that we're shipping. We can do a great job assessing our dependencies, performing component scanning on the software we write, and all of the other things to ensure we’re building better software. But malware is intentionally designed to get through our typical defenses. So if you can’t defend the repositories your developers are working from, they will be vulnerable. These malware attacks are not designed to get into the products you’re shipping to your customers but instead do their damage as soon as they make it into your SDLC.
The Consequences of Failing to Secure Your Software Supply Chain
Organizations are consuming more and more open source, and they need to do a better job managing their supply chains. Using outdated dependencies or relying on components that don’t have the support needed to be trustworthy at scale are putting projects at a significantly higher risk. We’ve discussed the widespread impact failure in this area can have. That point has to be underscored with the point that society is more dependent upon technology than ever before.
Security is a productivity problem as well as a technology problem. Managing dependencies, patching vulnerabilities, and license management takes time that would otherwise be used for development. We know that the average software application contains 180 open source components, and managing this at scale is virtually impossible. Added to this, 92% of publicly available vulnerability data requires corrections after deeper review by security researchers. The result is that developers have a false sense of security only to discover the risk after it's too late.
The financial cost of malware attacks can be staggering to companies that are not well protected. Loss of revenue, diminished reputation, and poor user experience will erode public trust and saddle developers with unnecessary pressure.
But we see a better way forward.
Mitigating the Risks of Malware Attacks on Open Source
The emergence of legislation worldwide specifically focused on bolstering the security of open source as having the potential to tip the scales and drive real progress in this area. For example, in Europe, the Product Liability Directive has been updated to address cybersecurity challenges by modernizing liability rules for digital and connected products. Essentially, the update consisted of removing the exclusion that once applied to software. The result is that software is now treated much like any other consumer product in Europe, and companies will be responsible for their products. Cybersecurity vulnerabilities or other software-related issues can now fall under product liability if they lead to harm. Even though this is a European directive, it will certainly drive behavior globally because every software company is potentially doing business in the EU.
These regulations put software bills of material (SBOMs) front and center. For example, PCI 4.0 mandates comprehensive tracking of all software components for entities processing cardholder data to safeguard against security breaches, and the Cyber Resilience Act (CRA) requires the inclusion of SBOMs for software embedded in physical products sold within the EU. We see a correlation between projects that create SBOMs and their overall quality. This isn’t to say that the SBOM improves the quality on its own, but development teams that take the time to produce SBOMs proactively are evidence of well-managed, sound development practices. These regulations also provide an opportunity for more visibility into this problem and, as a result, an opportunity for advocacy.
If organizations are not already in a position to begin addressing these emerging legislative requirements, now is the time to begin. The penalties of these new rules do not go into effect overnight, and the industry is not expected to respond overnight. But these laws are a reality, and organizations will never have more time to prepare than they do right now.
Securing the software supply chain isn’t a challenge that is going to be solved by one tool or one company. It’s an industry issue that will only be addressed as an industry. The emergence of malware is just one of the latest threats we must address. It won’t be the last, but our ability to manage malware in our open source repositories will have a direct impact on our ability to innovate, grow, and ultimately serve our customers.