- Well maintained
- Properly licensed for commercial use
- Vulnerability free (at least at the time of import)
And so on. While these checks can help manage traditional governance, compliance and security risk, they ignore the emerging risks associated with the software supply chain. Open source supply chain threats extend far beyond just identifying and managing vulnerabilities to include:
- Open source repository threats, such as typosquatting, dependency confusion, packages that contain malware, etc.
- Open source build threats, such as hacked build scripts, compromised build environments, remote inclusion of unexpected packages, etc.
While vulnerability threats have been with us for decades, supply chain threats have been growing exponentially since 2020 for the simple reason that bad actors have discovered economies of scale. Previously, they had to target hundreds of corporations individually. Now they’ve realized they can target a single software vendor whose thousands of customers then install a compromised update providing them a potential point of entry. In other words, a single attack can compromise thousands or even tens of thousands of corporations.
This marked increase in supply chain attacks is reflected in a recent Anchore study, which shows more than 70% of software organizations have had their development efforts directly impacted during 2021. More importantly, they’re 5x more likely to suffer significant impact:
As a result, President Biden called for fundamental changes in the way we build and secure software created with open source components, including the need for:
- Software Bill Of Materials (SBOM), which provides a list of all the software ingredients in an application.
- Automated (rather than manual) vulnerability remediation in order to decrease Mean Time To Remediation (MTTR).
- Ability to establish source code provenance so issues can be tracked back to their ultimate source.
While these initiatives are important, software vendors should be aware of a number of other best practices that can help better secure their open source supply chain, starting with what they import into artifact repositories like JFrog Artifactory.
You are What You Ingest: Import Open Source Packages Securely
Most organizations already have an open source vulnerability process in place, typically automated by things like Software Composition Analysis (SCA) tools. But while vulnerability tracking is important, it’s only the tip of the iceberg.
To better establish trust in the open source components you import, consider adopting additional best practices, including:
- A series of checks and controls, such as verifying each packages’ URL, timestamp, author, reviewers, etc.
- A quarantine zone to isolate suspicious packages since public repositories are quick to remove compromised packages once notified.
As an example, consider our ActiveState platform, which incorporates an open source import pipeline. This automated system regularly checks upstream open source language repositories like PyPI, CPAN, RubyGems, etc. When we find resources we don’t already hold in the ActiveState Platform’s catalog, we:
- Download both the source code and associated metadata.
- Perform a static analysis on the code to ensure our data about it is complete before inserting it into our catalog.
- Check popular vulnerability databases so we can augment our package metadata with CVE information.
- Regularly monitor the source code we ingest, and remove it from the catalog/pipeline if it is found to contain a trojan, malware, etc.
But these kinds of controls take extensive time and resources to implement and maintain. As an alternative, you might want to consider importing the packages your developers require from a trusted vendor instead. Just keep in mind that this solution is not necessarily a silver bullet.
Trusting the Trusted Vendor: Secure Open Source Builds?
It is by now customary to trot out the example of SolarWinds to prove a point: not only can your software build process be hacked, but you may also be signing the compromised output and distributing it to your customers who install it as a secure update from a trusted vendor.
Could never happen to you? Maybe, but we know from our Software Supply Chain survey that while 80% of organizations build at least some of the open source packages they use from source code, very few have implemented security and integrity controls (see chart below) to ensure the artifacts they build have not been compromised. Worse, only 22% of them are capable of creating reproducible builds, making it difficult to ascertain whether the original components were themselves secure.
In contrast, the ActiveState Platform provides a secure build service that automatically builds user-requested packages on-demand from source code and features:
- Heavy use of caching to ensure reliable, consistent, and performant results.
- An offline cache of source code to ensure continual availability, preventing issues such as occurred when NPM modules were removed from the repository.
- Build scripts, which are automatically generated from an internal “recipe” and treated as immutable resources, preventing tampering.
- Containerized builds in which each container is composed of only essential resources in order to reduce the attack surface (i.e., a bare OS, and just the build tools required).
- Each build step is performed in its own container, isolating builds from one another and preventing one build from actively modifying another.
- Hermetically sealed and ephemeral containers, which means they’re free from external influences and discarded after the step is completed. In other words, they don’t rely on access to the internet or resources not present in the container.
- Deep dependency resolution beyond what may be recorded in the upstream repository. For example, if a Python module depends on a C library that PyPI knows nothing about, we will still build it from source and ship it in the runtime so you don’t need to install 3rd party packages from anywhere else.
- Merkle tree hashes of dependency graphs, which identify all the artifacts that result from our builds. If a dependency changes in any way (such as a new version being released), the ActiveState Platform will rebuild everything that depends on it in order to ensure that what we ship is consistent and unlikely to suffer from incompatibilities.
- Verifiable artifacts, meaning that every artifact output by the Platform comes with a secure checksum and complete logs of the build process.
- Provenance for all artifacts, which is the ability to trace the ingredients that went into the creation of the artifact back to their source. This allows users to verify that their packages are produced in the most secure way possible. A build system should output this information as documentation on everything that has happened from source code import through dependency resolution to producing the installable binary.
- The ActiveState Platform currently follows these guidelines, and will shortly output provenance attestation for all steps in our secure build service.
In this way, the ActiveState Platform generates verifiably reproducible builds in which not only do the same inputs always produce the same outputs but the artifacts produced can be traced back to their source.
Conclusions – Trusted Repository of Open Source Artifacts
Your applications are only as secure as the building blocks from which they’re made. That may seem like a platitude, but it’s surprising how many organizations willfully ignore the ramifications of the statement, preferring to bury their heads in the sand than implement an effective solution. Why? It’s not their core business. Time and resources spent on securing a software supply chain that does not generate revenue is time and resources NOT spent on coding software solutions that do.
But supply chain security doesn’t have to be a zero sum game.
The easiest way to secure your software supply chain is to start secure by importing only packages from a trusted partner that have been built with a secure build service and vetted for maintainability, security and use in commercial applications. This is what ActiveState’s Trusted Artifacts Subscription is designed to provide via the ActiveState Platform, along with:
- Vulnerability alerts and automated vulnerability remediation so you can resolve security issues faster.
- A machine-readable Software Bill of Materials that includes transient dependencies (i.e., dependencies of dependencies) and OS-level dependencies, as well.
In a similar way, we can securely build the Java, JavaScript, .Net and other open source language packages your developers require, and then populate and maintain them in your JFrog Artifactory instance on a regular basis.
Best of all, your developers can continue to work with Artifactory in exactly the same way they do today. Keeping in mind the fact that 80% of projects never update third-party libraries after including them in a codebase, it’s more vital than ever to ensure your teams start secure before they even write their first line of code.
Next steps:
Understand how ActiveState can help you decrease the risk and overhead of managing open source language packages in JFrog Artifactory. Let us walk you through how the solution can fit your team’s (or teams’) needs.
Want to learn more? Read about how we can help you:
- Shift Security Left with the ActiveState Platform
- Establish Software Supply Chain Trust
- Automate vulnerability remediation
Recommended Reads:
Introducing Trusted Open Source Artifact Subscription for JFrog Artifactory
How to go from untrusted open source components to trusted artifacts
