State of the Software Supply Chain Security: Market Glance

Software supply chain security (3SC) is quickly becoming more than just a buzzword. Case in point: IDC has just released their 3SC Market Glancethat takes a wider view beyond what we commonly talk about in this blog (namely supply chain security for open source software), such as:

  • Design– including emerging software supply chain standards and best practices, as well as threat modeling in the software supply chain.
  • Identity & Access Management (IAM) – including the proper management of secrets, and enforcing privilege management.
  • Source Code Security – including secrets detection, proper code review, and avoiding source code leakage.
  • Chain of Custody– including provisions for provenance and signing of software artifacts, as well as the generation of deterministic builds.
  • Infrastructure and configuration– including Infrastructure as Code (IaC) security, pipeline security and Cloud Security Posture Management (CSPM).
  • Container Security– including the creation of secure images, container registries and Kubernetes Security Posture Management (KPSM).
  • Open Source Components– including tools like Software Composition Analysis (SCA) and Software Bill Of Materials (SBOMs), as well as OSS management.

IDC Market Glance
The breadth of the report is really a reflection of the fact that software supply chain attacks can target any stage of your software development lifecycle. As should be obvious from the tsunami of supply chain attacks (>740% growth YoY) and the fact that >60%of enterprises were affected by a supply chain attack in 2022, systems across the dev lifecycle often have poor cybersecurity controls and/or lack sufficient protections, allowing hackers to gain access, conduct espionage, enable sabotage, etc.

Unfortunately, that means that any one of the areas highlighted in the report could represent the weakest link in your software supply chain. While it’s difficult to address all of these functional areas at once, this blog post can help you prioritize where you should focus your efforts.

Prioritizing Software Supply Chain Security

IDC’s Market Glance includes both traditional and emerging security solutions. As such, it would be surprising if many of the solutions highlighted in the report aren’t already in place at most enterprises. However, there are some significant new entrants that security-conscious companies should consider prioritizing.

For example:

  • Under Secure by Design, Supply-chain Levels for Software Artifacts or SLSA is a new security framework that specifically addresses the shortcomings of traditional Secure Software Development Frameworks (SSDFs) when it comes to the software supply chain. Learn more about SLSA.
    • Note that when it comes to threat modeling, most of the existing solutions were never created with supply chain threat modeling in mind. However, you can still create your own supply chain threat model template using tools like SAP’s risk explorer and Google’s Threat Map.
  • Under Custody, the category of “Provenance and Signatures” includes a number of new entrants that are aimed at managing the risk of working with built software artifacts through the use of attestations. Put simply, attestations are metadata about where an artifact was sourced from and how it was built. Learn more about attestations.
    • If you use GitHub, TestifySec Witness has a number of GitHub actions that you can use to automatically generate attestations for your software artifacts.
    • Chainloopprovides an open source declarative attestation process that allows developers to generate attestations, and allows DevOps teams to validate those attestations at time of use (for example, within a CI/CD workflow).
  • Deterministic Buildsis also key to ensuring software supply chain security. For a build to be deterministic, the same “bits” input must always result in the same “bits” output. If they don’t, there is no guarantee that the artifacts you’re working with haven’t changed from build to build. Most organizations currently do not create deterministic builds since it involves vendoring all of your dependencies, which is both time and resource intensive. Learn more about deterministic builds.

However, the majority of supply chain security efforts are being done around open source software, which makes sense if you consider that the software supply chain is dominated by open source. After all, >80% of most software application codebases these days are composed of open source code.

For example:

  • Software Bill Of Materials(SBOMs) are everywhere, primarily driven by the addition of SBOM generation capabilities to traditional AppSec tools like Software Composition Analysis (SCA) that are widely used today. SBOMs list all the ingredients from which an application is built, making it faster and easier to find code libraries that present a risk. Learn more about how to work with SBOMs.
  • Managed Open Sourceallows organizations a measure of control and insight over the OSS components in their applications. For example, vendors here may offer a catalog of pre-vetted components, track vulnerabilities, automatically manage dependency trees, and so on. Learn more about managing and mitigating open source supply chain risk.
  • OSS Project Intelligencegives organizations the ability to proactively monitor the open source ecosystem. For example, solutions may provide a risk rating based on author/maintainer reputation, project maintenance history, vulnerability incidents, and other metadata that reflect the health of a project.

Conclusions – Software Supply Chain Security is more than AppSec

IDC has cast a wide net with their Market Glance by including traditional software security vendors. But many of these solutions were blindsided by the advent of software supply chain attacks that routed around traditional security controls.

Security-conscious organizations have likely already implemented many of the traditional security vendors listed here. Organizations concerned with the emergence of supply chain threats should be looking at the new vendors in the Market Glance that directly address these novel risks.

The ActiveState Platform can provide organizations with a leg up on implementing many of the controls associated with the securing the software supply chain, including:

  • SLSA – the ActiveState Platform provides SLSA Build Level 3 compliance for open source languages.
  • Provenance– the ActiveState Platform provides both Provenance Attestations and Verification Summary Attestations (VSAs) for runtime environments.
  • Deterministic Builds– the ActiveState Platform imports source code from numerous open source repositories and automatically builds them using a secure, reproducible build service.
  • SBOMs – the ActiveState Platform generates both an SPDX and JSON SBOM for each runtime environment built.
  • Managed Open Source– the ActiveState Platform allows you to vendor all your project’s dependencies, build them securely and remediate vulnerabilities faster.

Sign up for a free ActiveState Platform account and test out our software supply chain capabilities for yourself.

Next steps:

The adoption of software supply chain security is a journey not a destination. Read our Journey to Software Supply Chain Security eBook to better plan your journey.

Read Similar Stories

Why Traditional AppSec Tools Fail at Software Supply Chain Security

AppSec Tools focus on the tip of the Software Supply Chain threat iceberg. Learn about new tools required to counter supply chain threats.

Learn more >

Introducing SLSA 1.0: Securing the Code You Import & Build

The SLSA 1.0 specification provides verifiable controls and best practices to help you secure your software supply chain. Learn how.

Learn More >

Outsourced Dependency Vendoring

Everything You Need to Know About Dependency Vendoring

Dependency vendoring helps reduce security risks and avoid version conflicts, but it’s time and resource intensive. Outsourcing can help.

Learn More >

Recent Posts

Webinar - Walking Dead Past Python EOL
Walking Dead Past Python EOL

Stuck living with zombie applications running on Python 2, 3.7 or other past-EOL software? Learn the case for maintaining vs. upgrading, and how you can adopt a culture of getting current and staying current, with lessons from our customers.

Read More
Scroll to Top