The problem lies in the fact that the software supply chain is both broad and deep, encompassing all the public open source repositories you use, as well as the proprietary software development processes your organization runs. In other words, securing your supply chain from end-to-end is a non-trivial–and expensive–undertaking that most organizations have yet to dedicate the appropriate time and resources to.
But the supply chain threat is real and growing. Sonatype has reported that supply chain attacks grew 650% in 2021 compared to a 430% growth in 2020. Even President Biden was forced to call attention to the growing risk, issuing an Executive Order calling for better open source security practices during 2021. Unfortunately, supply chain security remains an immature practice. While certain aspects like managing open source vulnerabilities are well known and have well-established best practices, securing the software development lifecycle’s import, build and run processes continue to present key challenges.
This blog post can help you understand how your own supply chain security stacks up against your peers, as well as the kinds of best practices you can implement to increase the security and integrity of your software supply chain.
Securing the Open Source Software Supply Chain
We ran our Supply Chain Security survey in order to gauge what organizations are currently doing to limit their exposure to potentially compromised software that they use within their software development processes. Key processes that present security challenges include:
- Import – the process of importing third-party tools, libraries, code snippets, packages and other software resources in order to streamline development efforts.
- Build – the process of compiling, building and/or packaging code, usually via an automated system that also executes tests on built artifacts.
- Run – the process of working with, testing and running built artifacts in development, test and production environments.
For each process, there are a number of best practice security controls that organizations can implement to decrease risk. Survey respondents were asked which controls they currently have in place to mitigate the risk associated with importing, building and running the open source software they use to create their commercial software products. Based on their responses, they were given a grade:
- Poor – assigned to respondents that have implemented a minimum of import, build and run security controls.
- Average – assigned to respondents that have implemented many of the import, build and run security controls.
- Excellent – assigned to respondents that have implemented a majority of the import, build and run security controls.
The above chart shows the software supply chain security rating by size of company, including Small & Medium-sized Businesses (SMB), Mid-Sized Businesses (MSB) and Large Enterprises (LE).
There’s nothing surprising about the results, which indicate that smaller organizations tend to be rated poorly, while larger organizations have better supply chain security ratings. The result merely reflects the fact that implementing security and integrity controls across the entire software supply chain is an expensive and resource-intensive undertaking better suited to deep-pocketed large enterprises.
The above chart shows the software supply chain security rating by geographic region, including North America (NA), European Union (EU, including Great Britain), Asia Pacific (AP) and Rest Of World (ROW).
Supply chain security is a global concern, but the companies in some countries are further ahead in their implementation than others. Case in point is the fact that at least twice as many North American (NA) companies have already achieved an “Excellent” supply chain security rating compared to companies in other geographies. That said, more than 80% of NA organizations still lack a truly robust solution.
Conclusions: When it comes to supply chain security, most of the software industry has a long way to go
In a lot of ways, software supply chain security is not a new concept. We’ve had long-established best practices for dealing with open source vulnerabilities for as long as we’ve been working with open source software. But when it comes to our software development processes, we still lack the same degree of best practice implementation for dealing with:
- Import security issues like:
- Typosquatting – the practice of attackers submitting a package to an open source repository that is named similar to a popular, existing package.
- Dependency Confusion – occurs when a build system pulls in a similarly named dependency from a public repository rather than your private repository.
- Author Impersonation – for example, packages that have new authors all of a sudden should be treated as suspect.
- Build security issues like malicious build/install scripts that can exploit your build system, or dynamic packages that can include remote resources.
- Open source consumption security issues, such as ensuring your developers are only working with signed and verified packages that have been built by trusted vendors from vetted source code, rather than installing unsigned, pre-built binaries from public repositories.
As the data from ActiveState’s survey shows, the industry’s software supply chain security practices continue to lag behind the growing supply chain threat. Much more work needs to be done in 2022 by software development organizations in order to decrease the risk of creating software with compromised development processes and open source packages.
Next Steps:
- Get the full Survey Report: State of Software Supply Chain Security
- Read our datasheet about the ActiveState Platform’s Secure Build Service
- Read our datasheet on Speeding Open Source Vulnerability Remediation
Recommended Reads
