Security operations centers (SOCs) and developers need to share the responsibility for securing the software supply chain. Find out why in ReversingLabs' latest report.
The focus in recent years has been shifting left much of the responsibility for application security. However, software supply chain attacks are ramping up, not only in frequency, but also across the complex set of tools and code sources that make up today's software.
The challenge of modern software supply chain security has become momentous, requiring security operations and software development teams to find ways to secure the software supply chain together.
In Software Supply Chain and the SOC: End-to-End Security is Key, learn about why software developers should continue shifting left — implementing application security into every part of the development process — security operations centers (SOCs) should shift left with them, sharing the responsibility of protecting the software supply chain.
Here are key takeaways from the report, and a look ahead to what your organization needs to do to secure its entire software development lifecycle (SDLC) — and reduce risk from software supply chain attacks to your organization.
[ Get report: Software Supply Chain and the SOC: End-to-End Security is Key ]
The software supply chain security problem
Software supply chain attacks are not a new phenomenon. While they have taken center stage this past year, attacks of this nature date back to at least 1982, when an alleged CIA operation passed compromised software onto Russian intelligence, causing a massive explosion in Siberia. Over the past few decades, these attacks have become more complex and frequent, as can be seen in ReversingLabs A (Partial) History of Software Supply Chain Attacks.
The plentiful history of this problem sets up the state of software supply chain attacks today, with more attacks occurring in the past two years than in the previous 40 years combined. Looking at emerging attacks on open-source software and repositories showcases the magnitude of this growing problem. In ReversingLabs NVD Analysis 2022: A Call to Action on Software Supply Chain Security, attacks on popular public repositories npm and the Python Package Index (PyPI) skyrocketed by 289% in the past four years.
ReversingLabs researchers have discovered several incidents that contribute to this staggering statistic. These include the discovery of malicious packages mimicking the Material Tailwind CSS tool on npm, as well as the discovery of malicious packages on PyPI that deliver a malicious payload if used. Back in July of 2022, ReversingLabs researchers also discovered and named a major supply chain attack on npm called IconBurst, which served malicious packages meant to harvest sensitive data.
This lengthy timeline of attacks, as well as evidence that demonstrates the growth of these kinds of attacks within the last two years, warrants a great deal of consideration for how to best mitigate threats to the software supply chain.
Devs cannot do it alone
Considering the rise in software supply chain attacks, it has become clear to the application security community that security has to be embedded into every stage of the software development process. This has placed responsibility onto developers to perform secure practices as they are creating source code.
Developers have been keeping up their end of the bargain by baking security into their pipelines. This includes the use of traditional application security testing as well as source code analysis. But while these techniques do serve as beneficial, they are not enough to spot security risks, and tend to miss the detection of changes or anomalies in application behavior that arise when a software application is finished.
Similarly, software composition analysis (SCA) practices, which help organizations generate and review software bills of materials (SBOMs), serve as a key first step for software supply chain security, but are not an end-all-be-all solution. Even if development teams rely on these techniques, they are still missing key risks such as software tampering or the injection of malicious components into production code. In a ReversingLabs commissioned survey on risk tampering, it was found that four in 10 software packages currently in production have at least some tampering within them.
A new approach: Bring in the SOC
In ReversingLabs' new supply chain and SOC report, it's clear that on top of shifting left, security needs to be implemented throughout the entire software development and production timeline, bringing focus back to the right. The shortcomings that developers are unable to spot should be taken care of by SOCs, which have the ability to support all ends of the SDLC.
To best secure the software supply chain in your organization, the SOC should take on several duties, including:
- Detect deviations from a certain baseline, which can determine if a software package is falling short of being secure, containing anomalies that bring it below the baseline.
- Scan software packages, allowing them to spot possible malicious components.
And to make the SOC a cross-functional resource for defending against software supply chain attacks, it requires:
- Visibility and understanding of the continuous integration/continuous delivery (CI/CD) development cycle.
Looking forward: best practices
The effort to secure software is a journey, and organizations looking to do better in mitigating threats to the software supply chain will need to take several steps to advance properly. Moving along the secure software journey means establishing end-to-end security in an organization, which can be accomplished by joining the efforts of development teams and SOCs. This collaboration will provide the most effective resilience when dealing with the growing problem of software supply chain attacks.
[ Get report: Software Supply Chain and the SOC: End-to-End Security is Key ]
