Like a digital version of human dating, where interacting with one partner means exposing yourself to the sum of their dating history, developers need to trust the entire open source ecology behind the package they want to use. In other words, having a fling with a new open source package means not only trusting that the package’s code hasn’t been compromised but also trusting every upstream code supplier since most open source software incorporates other open source components from multiple ecosystems (such as when Python code includes C libraries, for example).
But just as with human transmissible viruses, there are steps software developers can take to protect or even immunize themselves against contamination:
- Limit your social circle – which in the world of software means sourcing higher quality components from fewer suppliers.
- Check out your partners, and their partners – the easiest way to do this with software suppliers is to demand their Software Bill Of Materials (SBOMs).
- Get vaccinated – ensure your systems are equipped with the antibodies they need to recognize and deal with bad components.
- Get boosted – if you build the components you work with from source code, consider implementing a secure build service to help immunize your DevOps practice.
- Health Check – no matter the precautions you take, infection is still possible. Put in place best practices to audit your packages as well as your import/build processes.
Multiple reports (GitHub, Sonatype, and Enisa) show that software supply chain attacks are increasing at an exponential rate year on year. It’s no longer a question of whether you’ll be affected, but when and how badly. Don’t let your businesses come to a standstill because essential open source components or software development processes get compromised. Shift left the right way by vaccinating your organization against compromise. Here’s how.
Software Supply Chain Partner Management
Software supply chain vendors include not only commercial vendors but also the authors and maintainers of the open source language components your developers work with. Standardizing on fewer commercial vendors and employing a distro-less approach to open source software (i.e., limiting packages only to those that are essential for the project) are key.
When it comes to commercial vendors, there are two best practices that should be followed:
- Assess the vendor’s software development practice, including secure development practices, cybersecurity training, threat modeling, code analysis, security testing, vulnerability scanning, and so on.
- Establish a follow-up process when a risk or threat has been detected.
When it comes to managing open source authors, the complexity of the software supply chain is often used as an excuse to avoid dealing with this vector of infection. The problem lies in the fact that open source supply chains are closely interlinked. For example, one codebase’s supply chain may contain n number of open source components. If that codebase is then incorporated in another open source codebase that has its own supply chain, that’s nn supply chains. In other words, an endless supply of chains to trace and secure all the way down. This kind of multi-layered approach means there may be codebase contributions by bad authors that remain invisible to you. SBOMs can help.
Maintaining Software Bill Of Materials
Too many organizations have yet to adopt SBOMs, and therefore have only limited (i.e., top level dependency) visibility into their software supply chain. But open source projects can embed code from other open source projects (i.e., dependencies of dependencies), resulting in hundreds or even thousands of packages by hundreds of different authors.
A Software Bill Of Materials (SBOM) can provide organizations with an inventory of all the software components that make up an application, service, API, or runtime environment. Without this level of detail, there is no way to grok the threat profile and risk of the software you use.
Source: XKCD
Use this datasheet to understand how, unlike other Bill of Materials (BOM) solutions, the ActiveState Platform can:
- Track transient dependencies and linked C libraries
- Identify dependencies of dependencies
- Visually represent changes to the dependency tree before you commit to the change
Vaccinating Your Software Development Processes
If you’re worried about the open source your developers are using to build your applications, you’re not paranoid. The software development processes your organization uses to import open source packages and/or build packages from source code are highly susceptible to supply chain attacks like typosquatting, dependency confusion, and compromised CI/CD implementations.
If you’re currently not sourcing your open source components from a trusted vendor, you should have controls in place to verify key criteria like the URL, author, reviewers, etc for the code you import. Build systems also need controls to ensure the security and integrity of the artifacts they produce. Unfortunately, the shift to a DevOps culture has created not only complexity but also key differences in how security needs are met. For example, modern DevOps practices emphasize velocity over security, which often allows low-security shortcuts to flourish.
Instead, consider evaluating Google’s SLSA, which stands for Supply chain Levels for Software Artifacts. It offers a security framework and common language that can allow you to implement increasing levels of software security and supply chain integrity for your build system. Each level provides an increasing degree of confidence that the artifacts you build haven’t been compromised, and can be securely traced back to their source.
Running Open Source Software Health Checks
No matter the precautions you take, it’s impossible to be 100% secure. This is especially worrisome when it comes to supply chain attacks because most software vendors do not regularly audit their development systems. As a result, they’re usually the last to know that their dev, test, CI/CD or delivery system has been compromised, typically when a customer informs them.
Attacks can range from compromised IDEs to upload tools to build processes, and so on. The point being one vector is all it takes for a bad actor to penetrate your development environment and introduce malware/trojans that can move downstream to compromise your customers. Unfortunately, 80% of projects treat securing their software supply chain as a one-and-done process, never updating their dev environment tools or their project’s runtime environment unless a critical vulnerability forces them to. But the reality is that your supply chain is only as secure as the weakest link.
Auditing your development and delivery systems for compromise should be a regular undertaking for any software vendor. While there are numerous security and integrity best practices that emphasize important features like “least privilege” permissions and multi-factor authentication, the key is implementing a model of continuous supply chain security, which includes active risk assessment and risk management.
Much like COVID, software supply chain attacks have gone from an epidemic in 2020 to a pandemic in 2022, with no signs of ending anytime soon. As a software vendor, you are the front line of security for all your customers.
While it’s true that you can never fully trust any code you didn’t write yourself, the days of applications featuring only proprietary code are long gone. It’s time to get vaccinated against the growing software supply chain threat by shifting security left:
- Immunize your organization against the inputs to your software development teams through careful vetting of your trusted partners and open source components.
- Immunize your development processes by putting in place a DevSecOps framework that lets you identify and manage risk.
- Check and test to make sure your development systems haven’t become infected by putting in place a continuous risk assessment framework.
Keep in mind that as a software vendor, you are now the front line of security for all your customers. Trust has always been a critical component of any brand, but it’s increasingly becoming a differentiator for software vendors. In 2022, trust means not only that the software and services you provide do what you say they will, but also that they won’t jeopardize your customer’s business by compromising their security.
Next steps? Learn how to shift security left with the ActiveState Platform by getting a quick demo. Here are some useful resources to share with your team meanwhile.
- Read our datasheet: Shifting Security Left with the ActiveState Platform
- Read our whitepaper: Business Leader’s Guide to Establishing Software Supply Chain Trust
- Learn from our survey results: State of Software Supply Chain Security
