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.[1] There’s also been an increase in protestware with developers intentionally sabotaging their own open-source components such as the case of the colours and fakers components which resulted in a denial of service attack.[2] And we’ve also seen developers themselves being the target of these attacks, where malicious programs are installed on their machines when they download open-source components such as python libraries.
Below are five important steps that you can do to secure your organisation’s software supply chain.
Maintain a Software Bill of Materials (SBOM)
The first, is to have a software bill of materials (SBOM). This is a list of all the open-source components, including their versions, that makes up your applications. Having an SBOM allows you to quickly understand your organisation’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.
Perform Due Diligence – Scan for Vulnerabilities
The next step is to perform due diligence on all open-source components that your organisation uses. We already do that for commercial software & suppliers and the same needs to be done for open-source components. We need to make sure that the components we use are free from any known defects (vulnerabilities). There are Software Composition Analysis (SCA) tools that can scan your 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. However, given the trend where developer machines are sometimes the target of software supply chain attacks, 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 which 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.
Have a Centralised Artifact Repository – Use Only Approved Software
Your organisation should only be using approval components that have already been scanned for malware and vulnerabilities and having a centralised artifact repository helps with that. Having a centralised 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 organisations also use a centralised 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.
Always Use Latest – Don’t Use Stale Components
When using an open-source component, you should always use the latest version. This would mean you have the latest bug fixes and security fixes. You should also be proactive and patch the components in your production application regularly, whenever newer versions become available. Patch management is crucial in managing your software supply chain and it is one that can very quickly get out of control. If you let your 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 that I’ve seen for this includes having a policy where teams should update all stale components when making new changes, having dedicated time set aside each month and automating the upgrades using tools like Dependabot by GitHub.
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 your development teams require additional time to remediate. Having a Web Application Firewall (WAF) allows you to secure the organisation while the fix is being applied.
Modern applications are mostly made up of open-source components. Unlike the code that your developers write, you have little visibility on the secure development practices of open-source developers. Our dependency on open-source component is going to increase over time and implementing these five steps will help secure your organisation’s software supply chain.
References
[1] https://www.sonatype.com/state-of-the-software-supply-chain/open-source-supply-demand-security
