Manage Your Organisation’s Software Supply Chain Risks or Risk Being the Next Target
By: Mike McGuire, Security Solutions Manager, Synopsys Software Integrity Group
Software development teams rely on a mix of proprietary and open source code, communication APIs, protocols, and business logic to assemble modern software applications. Many teams often do not maintain an accurate inventory of all the components in their software supply chain, due to the complexity and the pressure to deliver code faster.
As we’ve seen in recent headlines, the risks of not knowing what’s in your software can do more than just slow down your production time. Major incidents like SolarWinds and Log4Shell demonstrate the devastating impact they can have on an organisation’s bottom line, including financial and reputational implications. For this reason, understanding the components in your software is critical to managing your supply chain risks.
Let’s explore a few key considerations around why software supply chain attacks have become low-hanging fruit for cyber criminals and what organisations need to understand about their supply chain to avoid becoming the next target.
Why have software supply chain incidents such as those involving SolarWinds and Log4Shell become so attractive to cyber criminals?
Software supply chain attacks aren’t new. They have long been a concern for cybersecurity professionals, but the conversations surrounding software supply chain risk management have only become more mainstream due to recent headlines detailing such highly disruptive attacks.
The reason why such attacks have become so attractive to cybercriminals is because it is easy to hit many companies in one go — the impact area is widespread, and so are the rewards. Both SolarWinds and Log4Shell are perfect examples illustrating the massive impact they can have downstream in the software supply chain.
In the past couple of years, organisations have been forced to go through digital transformation efforts, while also opening up their systems to remote employees so as not to compromise productivity during the ‘COVID era.’ This also effectively means that the attack surface has changed drastically, and more assets and data are in the cloud, potentially vulnerable to compromise. Meanwhile, cybercriminals are becoming smarter, faster and equipped with better tools and technologies to exploit vulnerabilities.
What do organisations need to know about the components in their software supply chain?
The software supply chain involves everything from the idea of the application all the way through to customers using it. Organisations need to know the components being utilised within their software. After all, you can’t secure what you don’t know you have. It is critically important to have visibility into the software that’s running your business because security is only as strong as its weakest link.
In essentially all applications in use today, third-party components are used as building blocks to assemble the application. These components are very often open source software components. It’s clear that the security of these components has a direct impact on the security of the assembled application. Software composition analysis (SCA) tools like Synopsys’ Black Duck® help development teams to keep track of their components and manage risk from both a vulnerability perspective and a licensing perspective.
However, managing risk in the software supply chain also means security must be considered at the time of component selection. When developers are creating new functionality, they might select from a variety of components to be included in the application. The development process needs to have some safeguards so that when developers make their decision, they base that choice on risk and not solely on functionality.
Furthermore, where do the components come from? Developers have available to them a variety of technologies that easily retrieve components, such as npm or Maven. Can you trust these? What if the component repository is compromised? How do you know you’re getting the thing you asked for? A comprehensive security process addresses these questions.
Is there a way for businesses to lower their supply chain risks?
For many organisations, understanding how open source components are used is a critical first step toward software supply chain risk management. The overwhelming majority of software applications are a conglomeration of hundreds or thousands of open source software components held together by a little bit of code. In other words, developers grab significant chunks of functionality by using open source components, and then implement them into a specific application by writing code that uses those components.
Having a clear picture of the broader software supply chain gives organisations the opportunity to apply appropriate processes and tools evenly, resulting in an overall reduction of risk. You can use a software composition analysis (SCA) solution to assemble a Software Bill of Materials (SBOM). A good one will enable you to report on known vulnerabilities associated with the components you’ve used, giving a quick view into which components might expose security vulnerabilities in your application. In addition, it can identify which licenses go with which components and can quickly let you know if the components you used have licenses that are compatible with how you want to sell and deploy your software.
After you’ve established a baseline for understanding what’s involved with your software supply chain, branch out to cover the entire surface. For first-party code, incorporate static application security testing (SAST). If your SCA tool has binary analysis capabilities, you can use it to understand the composition of container images you are using for application deployment. Any infrastructure-as-code that you are using for your application can likewise be scanned with a SAST tool.
Remember that the supply chain extends all the way to when the user interacts with your application, so make sure you understand the scope and breadth. Then make plans to reduce risk holistically.