Organizations are increasingly concerned with the security of their software supply chain, but have trouble navigating the ever-expanding labyrinth of open source and proprietary software solutions that claim to help. In this article, the first of three posts, we look at the software supply chain solutions available for those that want to secure what is often seen as the weakest link in the chain: the import process.
Recall that the software supply chain extends from:
- Imported Code – any open source packages, code snippets, tools, or other third-party software brought into the organization in order to streamline the software development process.
- Build Process – the process of compiling, building and/or packaging code, usually via an automated system that also executes tests on built artifacts.
- Use/Deploy – the process of working with, testing and running built artifacts in dev, test and production.
All of these points along the software supply chain are increasingly under attack, with 2023 featuring twice as many attacks as the past 3 years combined, despite the fact that 2019-2022 saw a 742% increase in software supply chain attacks, year on year.
Securing the import process may be the most difficult hurdle for any organization to surmount, since it requires trusting hundreds or even thousands of open source authors with whom the organization has no relationship, or else putting in place systems and processes to mitigate the risk. Unfortunately, far too many organizations continue to blindly trust the open source dependencies they import. Others apply minimal checks and balances, preferring to focus on security later in the development process using traditional Application Security (AppSec) tools.
Given the growing number of supply chain attacks this status quo needs to change.
How to Securely Import Open Source Software
When it comes to securing the import process, you’ll first need to get a grasp on the breadth, depth and change associated with your software supply chain:
- Breadth – most organizations work with multiple open source languages, and import their code from more than one public repository. Because there are no industry-wide standards in place today, each language and repository may require its own solution.
- Depth – There is a large set of supply chain security & integrity best practices that can help, but only the largest enterprises can hope to implement and maintain them all. You’ll need to find the biggest bang for your buck.
- Change – most software artifacts have a short shelf life before bugs, vulnerabilities, incompatibility with newer systems and other issues crop up. Correcting all these issues is difficult for all but the most dedicated organizations to do in a timely manner. Automated solutions can help.
Dealing with Breadth means ensuring you catch the following issues on import:
- Vulnerabilities – security Issues in imported packages can pose significant risk. Software Composition Analysis (SCA) tools can help here.
- Malware – packages containing malicious code can compromise your development environment or software solution. Code scanners can help in this case.
- Typosquatting – compromised packages named similarly to popular packages hope to trick incautious developers into downloading them. Your import routine can be augmented to detect these.
While numerous open source and commercial solutions exist to help deal with each of these issues, keep in mind that:
- Ecosystem-specific tools tend to be more robust, but will significantly increase costs to implement and maintain if you work with more than one language.
- Commercial solutions tend to be more comprehensive and expensive, but may be more cost-effective in the long run than trying to integrate and maintain multiple, best-in-class open source solutions.
When it comes to Depth, both open source and commercial vendors can help you implement a set of best practices that makes sense for your organization, including:
- Provenance – the origin of imported code should always be verified on import to ensure it has followed best practices when it was developed and built/packaged for distribution. Software Attestations are a key mechanism here.
- Dependency Vendoring – the best way to ensure the security and integrity of imported code is to vendor the source code of all required open source dependencies and build them yourself. Unfortunately, this means you are now responsible for patching and maintaining all of that third-party code, which can overwhelm many organizations. Automated dependency vendoring tools can help here.
- Quarantine – imported software artifacts should be quarantined in a repository during investigation/scanning. You may also want to consider a separate repository for vulnerability identification and a further one for “ready to use” artifacts. You likely already have an artifact and/or code repository deployed.
While Change can be managed using many of the tools already discussed, too many organizations are still reluctant to update their codebase for a number of reasons, including:
- Time & Resources – developers dedicated to fixing issues are developers not available to create new features. Many of the aforementioned SCA tools can help decrease the time developers spend investigating issues by providing auto-updates.
- Breaking Changes – upgrading a package has a cascading effect on its dependencies, requiring multiple updates to your runtime environment which can end up breaking the build, or worse: landing you in dependency hell.
- Look for automated dependency management tools here.
Conclusions – Cost-effective Supply Chain Security
The software supply chain isn’t a new concept, but in a post-Solarwinds world, it’s become the focal point of efforts to improve cybersecurity in general, and software development processes in particular. The market result has been a gold rush as traditional software security vendors have quickly positioned themselves as supply chain security vendors. Making head or tail of their claims can be confusing.
However, avoiding market confusion is not an option since it only makes more and more businesses susceptible to the threat of ransomware, malware, and other security risks. Organizations need tangible solutions that can help them address threats when they first enter the development process – on import – before they can do damage.
Organizations that don’t vendor their dependencies and build them all from source code can only play catch up with supply chain security via traditional AppSec tools – tools that are often working against an incomplete set of dependencies since their dependency graph wasn’t generated at build time. And let’s face it, being behind in security just isn’t acceptable anymore.
Following Biden’s Executive Order on improving national cybersecurity, many are still trying to figure out what that looks like for their own organization. As software supply chain attacks hit unprecedented levels, it’s time to start rethinking whether downloading prebuilt open source makes sense anymore. And while dependency vendoring has always been a non-starter for all but the biggest enterprises, automated solutions like those from ActiveState let any organization do it cost-effectively. It’s time to embrace innovation to stay ahead of software supply chain threats.
Next Steps:
To see how the import process fits into an overall software supply chain security strategy, read our Journey to Software Supply Chain Security eBook.
