The majority of open source supply chain attacks are still perpetrated on the public repositories, but there’s a growing trend toward attacking the development environment of software vendors. If you build software in your organization, assessing your import, build and consume processes is a great starting point to ensuring your supply chain remains secure. This article provides you with a checklist of controls that will help harden your software supply chain.

Establishing Open Source Trust 

The open source ecosystem consists of millions of packages created by hundreds of thousands of authors, contributors and reviewers. No single organization or implementable solution can be expected to validate all of them, so how can you establish trust?

One method is to just blindly trust the public repositories. In fact, preliminary results from our Open Source Supply Chain Security Self-Assessment that was ran from August to October 2021, shows that ~50% of developers implicitly trust public repositories. 

Follow our social media or sign-up to our newsletter for the full report in December

While this may seem frightening at first blush, most repositories take their responsibilities seriously, and are quick to clean them up in response to vulnerability disclosures and user feedback. Just like open source vulnerabilities are essentially crowd sourced, making open source much more secure than proprietary code due to the input of the millions of developers that use them, public repositories (over time) are generally good sources of clean code. 

Unfortunately, “eventually secure” is no guarantee of security at any one point in time. For example, a single typosquatted package (ie., matplatlib instead of matplotlib) could be downloaded tens of thousands of times before it’s caught and remediated. 

But you don’t need to blindly trust public repositories. There are a number of controls you can  implement across the import-build-consume process that can help improve the security of your open source supply chain. 

Software Supply Chain “Import” Controls

The vast majority of supply chain attacks are still aimed at compromising public repositories since they accept submissions from anyone, and tend to have fewer security controls in place than most commercial organizations. 

While you have no direct control over the public repositories you use, there are a number of  controls that can help you create a secure import process:

Threat	Best Practices
1. Typosquatting*	Check Timestamp of Submission  Check Revision History Most typosquatted packages are identified and removed within a few days. Quarantining never before released packages can be an effective strategy.
2. Author Impersonation	Validate Uploader / Reviewer Identities Packages with no reviewers, or fewer than two reviewers should be treated as suspect. As should packages that have new authors all of a sudden.
3. Dependency Confusion**	Validate URL/ Use an Immutable Reference Because public repositories don’t support name spaces, you need to always ensure that you’re pulling dependencies from the proper location.

*the practice of attackers submitting a package to an open source repository that is named similar to a popular, existing package.

**can occur when a build system mistakenly pulls in a similarly named dependency from a public repository rather than your private repository.

Software Supply Chain “Build” Controls

Attackers have recently shifted their focus from targeting unpatched vulnerabilities in applications to infiltrating software vendor development environments. The logic is simple:

A single compromised software vendor can result in thousands or even tens of thousands of compromised customers that install infected patches, updates or upgrades. 

Your dev environment is now the security frontline for your customers. Here’s some best practices that can help you protect them:

Threat	Best Practices
4. Malicious Build/ Install Scripts	Scripted Builds with No Manual Intervention Ensure build scripts cannot be accessed and modified in your build service to prevent exploits.
5. Unconstrained Packages	Use a Secure Build Service  Using a purpose-built system designed to only build packages (rather than a developer’s machine) prevents malicious code from overstepping the bounds of the service.
6. Dynamic Packages Include Remote Resources	Separate Build Steps Ensure all build steps are run in ephemeral, isolated and hermetic (ie., no network access) environments.

Software Supply Chain “Consume” Controls

If you’ve done your homework to secure your import and build processes, running code in development, test and production environments should also be secure.

7. The best way to validate this is to always consume signed packages, whether those packages are signed by your secure build process, or else signed by a trusted vendor.

Note that most public repositories do NOT provide signed packages at this point in time, which makes importing their pre-compiled binaries a risky process.

Conclusions: The Software Supply Chain Can be Fixed

The good news is that there are best practices you can implement to ensure your organization’s open source supply chain is secure. The bad news is that implementing all of them can be both time and resource intensive. 

The shortcut most organizations rely on is to pick a trusted vendor and exclusively use their signed packages. Unfortunately, this method can be compromised when:

• Developers install a package directly from the public repository, rather than wait for it to be imported/approved for general use, or made available from your trusted vendor.
• Attackers compromise the development environment of trusted vendors prior to the signing service, such as happened with SolarWinds and Codecov.

Instead, consider using the ActiveState Platform to secure your Python, Perl and Tcl supply chains. It implements many of the best practices listed here in order to create verifiably reproducible builds in which the provenance (ie., the origin) can be established for each artifact.

Rather than cobbling together custom code and multiple solutions from multiple vendors, organizations can implement the ActiveState Platform as an out-of-the-box, end-to-end solution that provides open source supply chain security and integrity, saving considerable time, resources and money.

---

The ActiveState Platform can act as a model for developing secure processes since we provide:

• An open source catalog that contains Indemnified Python, Perl and Tcl packages, which have been checked to ensure they are well maintained and suitably licensed for commercial use.
• A secure build service that offers “verifiably reproducible” builds for Python, Perl and Tcl, where each component can be traced back to its source (aka provenance). Developers no longer need to install/run local build tooling on their individual machines, reducing the development environment attack surface.
• Checksum verification of all build artifacts throughout the steps that culminate in the final package in order to ensure builds haven’t been compromised.

Ready to see for yourself? You can try the ActiveState Platform by signing up for a free account. Or contact Sales for a free demo and let us show you how you can secure your open source supply chain today.

Need more information about open source supply chain security? Try these:

Survey Report: State of Software Supply Chain Security

Webinar: The Frontline of Attack – Securing Your Python, Perl and Tcl Supply Chains

3 ways the ActiveState Platform can secure your open source supply chain

President Biden: Secure Your Software Supply Chain