Introduction to Software Supply Chain Security

What is Software Supply Chain Security?

Software Supply Chain describes the tools, libraries, and processes for developing, building, and publishing software artifacts. As the name indicates, Software Supply Chain Security is all about securing the Software Supply Chain against security threads. Securing the Software Supply Chain is part of the shift left approach where you move security considerations early into the software development life cycle. The shift left approach improves security of developed applications and saves cost.

Why is Software Supply Chain Security important? 

The fight between software engineers securing their applications and hackers trying to attack the systems is probably a never-ending story. Attacking the Software Supply Chain is very interesting for hackers, because they could perform various attacks using a single exploit in the Software Supply Chain. For example, they can plant malware into applications at build time. The malware is then hidden inside the application and will be distributed to other companies or consumers. Taking over control of servers or stealing sensitive data are also possible.

A well-known example is the SolarWinds hack from 2020, where hackers managed to infiltrate the build process of the SolarWinds software application Orion and inject malicious code. Orion is an IT- and network management application widely used in the US. All companies that installed the compromised Orion update thus brought the security vulnerability into their IT systems. The malicious code called SUNBURST contained a back door that allowed the hackers to execute commands, read data, or analyze traffic on all servers where the application was installed.  

Another example why Software Supply Chain Security is important was the zero-day vulnerability Log4Shell in the widely used open-source Java logging framework Log4j, which was disclosed in late 2021. The vulnerability allowed attackers to do a remote code execution on affected servers. To find out whether such a zero-day exploit affects the systems of a software development company requires an overview of all applications that use a vulnerable version of the Log4j library. A complete overview including known vulnerabilities of all third-party software libraries used in the developed applications is an integral part of a good Software Supply Chain Security setup. According to the OWASP Top 10 list, this issue has become more critical in recent years. The web application security risk “Vulnerable and Outdated Components” has risen from 9th place in 2017 to 6th place in 2021. 

How can I achieve Software Supply Chain Security? 

Different topics need to be addressed to achieve good Software Supply Chain Security. In this section, an overview of the most important topics is presented.

For applications like single-page web applications, backend APIs, or mobile apps, the following tasks are essential: 

• Scan dependencies for known vulnerabilities: You should have a complete and easy-accessible overview of all 3rd party dependencies used inside your applications. There are databases, such as the National Vulnerability Database, which can be used to check dependencies for known vulnerabilities. It is important to check all direct and transitive dependencies. A basic Angular 16 application has, for example, 22 direct (dev) dependencies and more than 500 transitive dependencies. Keeping track of this number of dependencies is only possible with good tool support.
   
• Automated dependency updates: Keeping all dependencies up to date reduces the risk of using dependencies with known vulnerabilities. If you have more than a handful of applications, keeping all used dependencies up to date is very tedious. Therefore, you should use an automated tool for this task. 

• Scan dependency licenses: There are more than 100 different open-source licenses, some of which have strict rules concerning how to use them. For example, suppose you use a software library that is licensed under the GNU General Public License (GPL) to build an application that is sold to customers. In that case, you must publish the application’s source code under the GPL. Using dependencies without complying with their license terms does not introduce security vulnerabilities but can cause severe legal trouble. Depending on the type of the developed application, it is advisable to set up monitoring of the used licenses.

• Open-source dependency quality scanning: There are millions of software libraries available on the internet. In addition to the function range and license, other criteria are important when you decide to use a new open-source library. These include whether the library is under active maintenance, the number of contributors, the popularity and how long it takes until critical issues are resolved. For simplicity, quality scores can be calculated to summarize the underlying criteria. Libraries with bad quality scores often have a higher risk of security vulnerabilities.

• Generate Software Bills of Materials (SBOM) during build time: Generating and storing an SBOM for every application build is a good practice. The SBOM declares the inventory of a software product and contains information about all direct and transitive dependencies of the built application. This is good for documentation and can later be used to check for vulnerabilities or license issues. A standard format for SBOMs is CycloneDX.

• Secret detection: The application code or configuration files can contain secrets like passwords and API keys, which should not be stored as plaintext in the Git repository. Automatic scanning helps to detect leaked secrets. 

In a modern cloud-native setup, you typically use Infrastructure as Code (IaC) to define and deploy your cloud infrastructure. For this, the following tasks are important: 

• Scan for misconfigurations: The IaC definitions contain security configurations like firewall rules, open ports of virtual machines and exposed services. Therefore, it is crucial to check the IaC definitions for misconfigurations. Otherwise, the system running in the cloud could be vulnerable.

• Secret detection: The IaC definitions should be checked for leaked secrets like passwords and API keys. Hackers or criminal employees can use plaintext secrets in the source code to gain access to systems or steal data.   

Additionally, there are general security tasks like: 

• Access control: Secure the version control repositories, software artefact stores, and CI/CD systems. It must not be possible for unauthorized users to manipulate source code, configuration files or the build servers.

• Artifact manger configuration: Software artifacts should only be loaded from trusted sources. A company with internally hosted libraries must ensure that all package managers on build servers and development computers refrain from trying to load this library from public artefact stores first. Otherwise, you are vulnerable to Dependency Confusion Attacks. 

Conclusion 

We have seen why Software Supply Chain Security is an important topic and should always be considered when developing an application professionally. We saw an overview of important Software Supply Chain Security tasks when you build an application or use IaC. Many of these tasks can be automated by appropriate tools.

In two of our next blog articles, we will present which open-source tools are suitable for improving Software Supply Chain Security (see Open Source Tools for Software Supply Chain Security) and which possibilities the Google Software Delivery Shield offers in this regard (see Software Supply Chain Security with Google Software Delivery Shield).