It’s essential for organizations to learn more about the software supply chains they rely on and the steps needed to secure them. In just the past few years, we have seen a major uptick in malicious actors exploiting vulnerabilities in software supply chains to facilitate attacks on organizations. However, it’s important to remember that these attacks are not a new phenomenon. In fact, they’ve been around for decades. Therefore, the need to secure the software we rely on is not new, though the industry turning its attention to this problem is.
Software supply chain attacks are also far from simple. Given the fact that software supply chains are highly complex and made up of a number of constantly changing components, the avenues that malicious actors can take to pull off an attack are plentiful. For example, software artifacts are partially made up of components downloaded from open source software repositories. These platforms have become a favored attack avenue, given how frequently they are used by developers and the trust extended to them by development organizations. According to GitHub, anywhere from 85-97% of enterprise codebases come from open source repositories. Two of these repositories, npm and PyPI, have seen a nearly 300% spike in the number of attacks on their platforms in the past four years, impacting thousands of software supply chains globally.
One example of the kinds of software supply chain attacks that are now common is IconBurst, a major attack from last year where more than two dozen typosquatted packages were discovered on npm. As with other recent attacks, the IconBurst attackers used typosquatting – uploading malicious packages to repositories with names that closely resemble popular and legitimate packages on the same platform. Developers, in a rush to complete their work, are often tricked into downloading these typosquatted packages. In the case of the IconBurst campaign, for example, one of the malicious packages discovered was downloaded over 17,000 times!
Given the significant increase in the number of software supply chain attacks, organizations must make more of an effort to understand how these attacks work and then take steps to secure their software supply chains from compromise.
Say Goodbye to “Shift Left”
To begin with, development organizations need to reevaluate the mantra to “shift left.”
For years, industry leaders promoted the notion of “shifting left” as a call to marry application security with application development: Embedding secure development tools and practices into the continuous integration/continuous delivery (CI/CD) process. But times are changing and the industry is beginning to understand that while shifting left is necessary, it is not sufficient to secure software supply chains.
“Don’t shift left; shift everywhere!” said Tanya Janca, founder and CEO of WeHackPurple. Janca was speaking as a member of a recent Techstrong panel, “Software Supply Chain: It’s All About The Code” at the Predict 2023 virtual event. Janca pointed out the industry’s past fixation on “shift left” and the gaps in security that this caused since threats to the software supply chain not only happen during development but also throughout the entire software release process.
In fact, the notion of shifting left may do development organizations and developers a disservice: Leaving the work of securing applications entirely to them. “It’s unfair to expect developers to write perfect code,” said Jeff Williams, co-founder and CTO of Contrast Security, another member of the panel.
Software engineers are already under pressure to develop software quickly to meet development and project milestones. That makes it difficult for them to implement perfect security measures, like vetting every single line of third-party code they use while also watching out for social engineering attacks.
A New Approach to Secure the Software Supply Chain
For organizations looking to secure the software supply chains they rely on, they must choose the right tools. But much of the secure development and application security testing (AST) technology out there won’t cut it. For instance, tools such as dynamic or static application security testing (DAST/SAST) are critical components of the secure development life cycle (SDLC). However, they don’t provide holistic coverage of all of the supply chain threats out there, including software tampering and the risk posed by compromised open source and third-party libraries. On the other hand, tools such as software composition analysis (SCA) can help vet open source components but often fail to detect malicious modules or provide total security coverage of software supply chains. Knowing that your application depends on a malicious open source package after the fact is of little consolation when you release code at the speed of DevOps.
This is why modern tools that go beyond these capabilities should be considered. “It’s about giving developers the tools they need to be successful,” said GitLab’s CPO David DeSanto at the event. Experts in the space agree that change is needed but that developers and development teams aren’t set up for success as it stands.
According to Mat Matthews, an experienced practitioner in the DevOps space: “While developers are responsible for ensuring clean code, it takes a cross-functional team with a specific focus on security to reduce the attack surface against supply chain attacks.”
To accomplish that, organizations need to look to their security operations centers (SOCs) to take on a greater role in helping to secure software supply chains. Close collaboration between development and SOC teams is the surest way to provide end-to-end security for an organization’s software supply chains. And, supplied with the right tooling, SOCs and development teams working together will be better positioned to scan software packages; achieve greater visibility into development processes; detect deviations from a set baseline; and pursue possible supply chain compromises before they can cause real harm to software publishers and their customers.
As threats and attacks on software supply chains evolve, so must protections. A modern software supply chain security program should aim to protect the entire software development process, from the developer IDEs and their plugins to the open source components, CI/CD workflows and the release pipelines, while also being equipped to spot and pursue compromises at any point in the development life cycle. Only then will development teams be able to prevent harmful attacks like SUNBURST, IconBurst and countless others that have happened since.
