The Open Source Security Foundation (OSSF) has recently come up with a number of guidelines for organizations concerned with the threat of attack vectors originating from their software supply chain.

The OSSF is a project of The Linux Foundation whose mission is “to inspire and enable the community to secure the open source software we all depend on.” They recognize the growing threat that bad actors pose to the users of open source software generally (in other words, every developer on the planet), and security-conscious enterprises specifically. And they also recognize that the key difference compared to traditional open source vulnerability exploits is the scale: a single attack on a software vendor’s supply chain can potentially impact hundreds or even thousands of their downstream customers.

The problem is essentially twofold:

  • Builders of Software – traditionally focus on vulnerabilities and exploits in the open source software they import and work with, rather than attacks on their dev, test and CI/CD infrastructure.
  • Users of Software – have recently been focused on exploits that make the enterprise vulnerable to attacks like ransomware, rather than exploits in the signed, third party software they install from their trusted vendors.

The result is that both software vendors and their customers have been blindsided by a novel set of exploits originating in their software supply chain. But just because it’s new doesn’t mean there aren’t a set of best practices you can follow to help keep your organization protected. This blog post discusses some of the top recommendations from the OSSF and traditional industries that can help you mitigate emerging software supply chain threats. 

The Growing Supply Chain Threat

The poster child of this new kind of supply chain attack is SolarWinds whose build infrastructure was compromised in December 2020. As a result, SolarWinds distributed the attacker’s malware within their Orion product to thousands of customers, which included Fortune 100 enterprises as well as the US Government. Because the Orion security product was run at a high level of trust, end users were essentially caught with their pants down.

Since then, a growing number of software vendors have also been targeted in similar ways. The difficulty lies in the breadth and depth of an ISV’s supply chain, which stretches from the open source language dependencies they import in order to build their offerings through to the distribution channel for their end product.  

Securing every step along the way is almost a fool’s game given the complex web of relationships that must be trusted/verified starting from the very first imported open source language package, which can have multiple dependencies, each of which, in turn, may have multiple transitive dependencies, each of which may rely on OS-level dependencies, and so on down the rabbit hole. And of course, each imported open source component was built by multiple third party developers, all of whom must also be trusted/verified.

Given this intertwined web of complexity, it’s no wonder that the vast majority of organizations choose to acknowledge and accept the risk inherent in their supply chain rather than try to tackle it head on. But all is not hopeless. Traditional industries have long wrestled with their own supply chains and have much to teach software vendors. While the nuances of an automotive or food services supply chain differ greatly from that of software, some of the key best practices are widely applicable, including:

  • Ingestion: traditional industries limit the number of component suppliers to a few, high quality ones in order to decrease exposure to risk.
    • Software vendors might think about sourcing their dependencies from a single trusted vendor instead of multiple public repositories, for example.
  • Creation: traditional industries ensure the integrity of their assembly line infrastructure and processes through regular maintenance, inspections and reviews.
    • Similarly, software vendors can mitigate weaknesses across their Software Development LifeCycle (SDLC) through regular audits and updates of their development and build infrastructure. 
  • Verification: traditional industries create a Bill of Materials (BOM) checklist that identifies every component/task in the creation of their end product/service, allowing for both validation of correct assembly and traceability of defects.
    • The equivalent of a BOM for software vendors is a Software Bill Of Materials or SBOM, which serves much the same purpose.

How to Threat Model Your Supply Chain

The software supply chain for most software vendors looks similar to:

Threat Infrastructure
Credit: security.googleblog.com

Potential threats exist at every point, but whether they apply to your organization’s SDLC will be made clear only after performing an end-to-end threat model to identify key weaknesses. In general, however, the ingestion process is typically the weakest link in every organization’s supply chain. Unfortunately, it can also be one of the most challenging areas to secure. As a result, it may be more expedient to start with easy wins, which can be had by securing your source control, binary repository and developer workstations using traditional security practices.

When it comes to securing your supply chain, the OSSF recommends starting by:

  1. Strengthening Software Ingestion – Enterprises spend significant time and resources to ensure that the commercial software they purchase is secure, well maintained and originates from a credible vendor. Unfortunately, this approach is difficult to scale to the hundreds or even thousands of third party open source packages developers need to work with. Still, some validation must be implemented to ensure an open source component is sufficiently trustworthy. For example, organizations should consider:
    • Validating whether or not the component has a reported vulnerability. There are any number of vulnerability management tools that can help automate this process.
    • Validating whether or not the component is trustworthy based on key criteria, such as those covered by the OSSF’s risk analysis scorecard.
    • Validating that the component’s direct and transitive dependencies are also free of vulnerabilities, and that they score well against risk criteria. Again, there are any number of tools for this purpose, such as Software Composition Analysis (SCA) software or emerging SBOM services.
  2. Strengthening Asset Inventory – You can’t secure software you don’t know about. Organizations that are not adamant about keeping a detailed asset inventory of the open source software they use are often surprised to find outdated frameworks in development environments, vulnerable tools in test & CI/CD, and scripts based on EOL languages being run on employee desktops.
    With a comprehensive inventory in place, including the owner of each asset, the next supply chain vulnerability can be mitigated far more quickly and easily.
  3. Identifying Entry Points for Software – Software development processes are rarely hermetically sealed. Developer desktops and CI/CD systems typically have access to the internet, affording points of ingress for software that may not be approved for use in the enterprise. Some organizations also often provide points of access for customers to upload issues, including code. Identifying and monitoring these ingestion points can help improve control.

These three initiatives represent the low hanging fruit that every organization can do to get started securing their software supply chain.

Next Steps:

The ActiveState Platform is another initiative you can easily adopt to help secure your open source supply chain because it integrates seamlessly with most enterprise SDLCs. By adopting the Platform, you can ensure your developers are always working with dependencies built from source code using a secure cross-platform build service that always generates reproducible artifacts that can be deployed together without conflicts.

You can try the ActiveState Platform by signing up for a free account using your email or GitHub credentials.

Found this useful? Read, download and share these related resources with your team: