5 Steps for Securing Your Software Supply Chain


Most modern applications are assembled from open source components with developers typically writing less than 15% of the code for their application. As the demand for open source software grows, there’s also an increase in the number of available open source software. However not all open source components are created equally or maintained properly. As a result, we are seeing an increase in software supply chain attacks. According to the 8th annual software supply chain report, the average growth rate of software supply chain attacks is 742% per year. There’s also been an increase in protestware with developers sabotaging their own open source components such as the case of the colors and fakers components which resulted in a denial of service attack. Developers are also the target of these attacks, where malicious programs are installed on their machines when they download and install open source components such as python libraries.

Below are five important steps to secure an organization’s software supply chain.

1. Maintain a Software Bill of Materials (SBOM)
The first, is to have a software bill of materials (SBOM), a list of all the open source components, including their versions, that makes up all applications. Having an SBOM allows you to understand your organization’s exposure when vulnerabilities are discovered. There should also be an owner for each application to allow for easy determination of who’s responsible for maintaining the code.

2. Perform Due Diligence – Scan for Vulnerabilities
The next step is to perform due diligence on all open source components that an organization uses. We already do that for commercial software and suppliers, and the same needs to be done for opensource components. We need to make sure that the components we use are free from any known defects. There are Software Composition Analysis (SCA) tools that can scan applications for vulnerabilities. As more effect is required to remediate vulnerabilities that are already in production, these SCA tools are often deployed in the build pipeline to ensure that there are no known vulnerabilities before the application is released.

Given the trend where developer machines are sometimes the target of software supply chain attacks, however, these scans should also be done before the components are downloaded onto the developer’s machine. Regular scanning of production applications is also required to detect any newly discovered vulnerabilities. Other due diligence that should be done includes only using components for reputable sources and staying clear of unpopular components or components that have a single developer. Popular components get more public scrutiny with any vulnerabilities more likely to be detected and using components developed by a single person represents a key person risk.

3. Have a Centralized Artifact Repository – Use Only Approved Software
Any organization should only be using approval components that have already been scanned for malware and vulnerabilities and have a centralized artifact repository helps with that. Having a centralized artifact repository provides the assurance that you are downloading the component from its official source. This helps addresses typo-squatting and dependency confusion attacks, which are popular software supply chain attack approaches. It is recommended to use an SCA tool with rules or policies in place to automatically determine when a component is approved for use. Some organizations also use a centralized artifact repository to reduce the number of open source suppliers. Rather than having 15 different components providing the same functionality, they would limit to only using the highest quality component.

4. Always Use Latest – Don’t Use Stale Components
Always use the latest version of an open source component, which would means it has the latest bug fixes and security fixes. Be proactive and patch the components in production application regularly, whenever newer versions become available. Patch management is crucial in managing the software supply chain, and it is one that can very quickly get out of control. If components get stale, it can be quite hard to remediate should a security issue be discovered as there might be many breaking changes in the newer fixed version that will also need to be addressed. Successful approaches include having a policy where teams should update all stale components when making new changes. They should also have dedicated time set aside each month to automate the upgrades using tools like Dependabot by GitHub.

5. Run a Web Application Firewall (WAF)
There are times when fixed versions of open source components are not yet available after a security vulnerability has been disclosed, or when a proof of concept or exploit kit is released. There are also times where development teams require additional time to remediate. Having a Web Application Firewall (WAF) can secure the organization while the fix is being applied.

Modern applications are mostly made up of open source components. Unlike the code that developers write, organizations have little visibility into the secure development practices of open source developers. Dependency on open source components is going to increase over time, but implementing these five steps will help secure the organization’s software supply chain.