Gartner has suggested that Software Supply Chain Security (SSCS) has entered the Trough of Disillusionment on their 2024 Hype Cycle for Open Source Software (OSS). The Hype Cycle is meant to showcase new and emerging technologies, and track their acceptance in the market. In Gartner’s model, innovative technologies that gain traction become subject to inflated expectations which inevitably lead to disillusionment as early adopters fail to reap promised rewards. Finally, more realistic expectations are set leading to greater success. This blog looks at the reasons why SSCS implementations may not be delivering expected results. 

Let’s start with why SSCS became a thing in the first place, to whit: while open source threats in general are on the rise, SSCS attacks have grown exponentially over the past two years:

SSCS Attacks over Time

Source = Statista

These attacks, like the software supply chain itself, span the software development process, beginning with the open source software being imported into the organization, through the build process or CI/CD system to how developers consume open source software when building applications. Each point along the way represents one or more potential points of attack.

For example:

  • Import Threats – malware-infected packages in 2023 totaled more than twice the total number discovered for all years combined since 2019, according to Sonatype’s State of the Software Supply Chain report.
  • Build Threats – CI/CD systems are susceptible to compromise as was seen most disastrously with Solarwinds back in December 2000, but also more recently with JetBrains’ TeamCity and CircleCI. 
  • Consume Threats – any time a developer deploys an open source package that is unverified (i.e., downloaded from a public repository), they put at jeopardy your entire customer base. For example, 3CX’s as well as Justice AV Solutions’ compromised installers affected >600K users. Similarly, Dollar Tree’s use of a compromised SaaS service affected at least 7K customers.

As a result, multiple governments and regulatory agencies are encouraging Independent Software Vendors (ISVs) to improve their security posture by devoting resources to securing their software supply chain. It started with Executive Order 14028 in May 2021, but was followed quickly by a number of initiatives centered around secure software development in general, and SSCS specifically. 

One of the aspects of SSCS that governments have advocated for is improving the remediation of vulnerabilities. To that end, the US Government has created a Known Exploited Vulnerabilities (KEV) database that contains only those open source software vulnerabilities known to have been exploited in the wild (as opposed to merely theoretical exploits). 

Unfortunately, the fact that many critical KEVs come with SLAs as short as 4 days has resulted in ISVs becoming overly fixated on vulnerabilities. After all, the average remediation time for critical vulnerabilities continues to be between 35 to 61 days. ISVs have looked to SSCS solutions to help close the gap with little success. While some solutions can help with reachability (i.e., determining whether a vulnerability is actually executed in the context of the application), or automatically prioritizing vulnerabilities, or even the automated creation of Jira tickets, the bulk of the work remains manual. 

We contend that this is the primary reason why organizations have not seen the benefits they expected from the implementation of SSCS solutions, and a key driver of why SSCS is now entering the Trough of Disillusionment.

On the other side of the trough, though, is the Slope of Enlightenment, where organizations will come to realize that SSCS has always been more focused on addressing emerging threats within the software supply chain as a whole, rather than focused on helping with traditional AppSec threats like vulnerability management.

How To Gain The Benefits of Software Supply Chain Security

ISVs, and any organization, really, that builds and maintains software, can gain benefits from SSCS solutions today by leveraging them for what they were meant to address, namely threats within the import, build, and consume processes of their software development lifecycle. Many of these processes are poorly served by existing solutions that were never created with software supply chain security in mind. 

For example, the import process is dominated by the importation of open source software, which forms as much as 80% of modern codebases. Traditional solutions like artifact repositories import prebuilt open source components, and then employ binary scanners to try to identify threats. I’ve discussed elsewhere why scanners are problematic and actually increase cybersecurity risk from such attack vectors as typosquatting, malware, dependency confusion, author impersonation, and more. 

In contrast, SSCS solutions like ActiveState build all open source components from vetted source code, providing the following benefits:

  • Eliminate Phantom Dependencies – since all open source components are built from source code, including any linked libraries, you get a complete Software Bill of Materials (SBOM) including dependencies, transitive dependencies, OS-specific libraries, and even build dependencies.
  • Eliminate Naming Exploits – importing prebuilt binary components leaves the organization open to package naming exploits like typosquatting, brandsquatting, Dependency Confusion, and more. Building from source eliminates these attack vectors.
  • Eliminate Malware – hackers are getting more and more creative in how they hide malware in binary components from scanners. Building components from vetted open source dramatically increases the chance of identifying malware and eliminating it.
  • Eliminate Public Repository Exploits – project ownerships change; authors may be impersonated; malicious contributions may go uncaught, etc, all of which increase the risk of downloading prebuilt components compared to using components built from vetted source code.

Beyond overcoming software supply chain import risks, SSCS solutions can also help with vectors of attack that originate in the build process. ActiveState focuses on building open source components securely, but can also securely build first-party code using a hardened, tamper-proof build service that avoids common attack vectors like build script tampering, remote resource inclusion, build environment contamination, and more. 

ActiveState’s secure build service adheres to the Supply chain Levels for Software Artifacts (SLSA) Build Level 3, providing: 

  • Tamper-proof Scripts – build scripts are automated, eliminating a common vector of attack like editing interactive build scripts. 
  • Isolated Build Steps – each build step has a single responsibility, such as retrieving source code, building an artifact, etc. When that responsibility is fulfilled, the output is checked and, if required, passed to the next step. 
  • Ephemeral Environments – each build step requires an environment, such as a hardened container in which to execute. Once the step is complete all those resources are discarded, preventing contamination of subsequent steps. 
  • Minimized Infrastructure – in order to shrink the potential attack surface, the runtime environment in each build step is minimized, meaning the container only includes components (such as the appropriate compiler) that are absolutely required for that step. 
  • Provenance – each build step is dependency complete, and each dependency is traceable to its originating source. An out-of-band Provenance Attestation can be used for independent verification. 
  • Hermetically Sealed Network – the dedicated build service runs on a locked down system within a segmented network with no internet access, thereby limiting local exploits (such as when a build step oversteps its bounds and attempts to exploit common OS services), as well as remote tampering/intrusion (such as when a dependency attempts to include remote resources during its build step). 

The output is always a reproducible build, in which the bits input result in the same bits output. Some of the “bits” output also include SBOMs and Provenance Attestations – key documentation that you can use to help verify the security and integrity of open source components at the consumption stage. 

Conclusions – Software Supply Chain Security By Design

While SSCS includes vulnerability management, it’s really just the tip of the iceberg when it comes to software supply chain threats. Unfortunately, that kind of visibility means vulnerabilities get a skewed amount of attention and resources at the expense of other software supply chain vectors of attack, resulting in increased risk to the organization.

ActiveState’s curated OSS catalog can provide you with pre-vetted, securely built OSS packages that are safe to use, enabling developers to not only take a secure by design approach to their project, but also ensure their software supply chain remains secure over time by taking advantage of vulnerability and update management capabilities.

While it would be a mistake to ignore vulnerability management, securing your software supply chain should be your first priority in order to avoid being blindsided by emerging OSS import, build and consume threats. 

Next Steps

Watch our webinar on why SAST, DAST and IAST Are Not Enough (to Cover Your Ass), and learn how to secure the entire software supply chain – not just the tip of the iceberg.