- tl;dr sec
- Posts
- Software Supply Chain Vendor Landscape
Software Supply Chain Vendor Landscape
An analysis of over 20 supply chain security vendors, from securing source code access and CI/CD pipelines to SCA, malicious dependencies, container security, SBOMs, code provenance, and more
Hello there! A quick note from me (Clint Gibler), the creator of tl;dr sec.
Welcome to Part 2 of tl;dr sec’s supply chain security guide!
In Part 1, we provided an overview of the core areas of supply chain security.
This report focuses on analyzing the current approaches taken by over 20 software supply chain security (SSC) vendors to secure the various aspects of the software supply chain.
I’ll pass it off to Francis Odum, the primary author of this report, who is also the author of the software analyst blog and co-creator of a cybersecurity & SaaS bootcamp on Maven.
Actionable Summary
Software applications are no longer built solely from custom code. Instead, they consist of a complex web of open-source components and libraries. This dependency chain allows developers to use their preferred tools and enables teams to quickly deliver functional software to users. However, it also exposes organizations and their customers to vulnerabilities introduced by changes outside of their direct control.
As discussed in part 1 of our overview of software supply chain, we highlighted the prevalence of open source in modern applications and the increasing urgency around it. Open-source components have become a popular target for software supply chain attacks.
Part 2 of this report focuses on the key vendors in this market and their different approaches to securing the software supply chain. This report primarily examines new and emerging vendors founded in recent years.
Due to the complexity of the modern software supply chain, there has been a surge in the number of vendors created over the past 3-5 years. Many of these companies have developed their solutions based on the SLSA framework, NIST Secure Software Development Framework (SSDF), or OpenSSF Scorecard.
Compliance and regulation have been major drivers for the increase in the number of vendors and demand for software supply chain solutions. President Biden's executive order to improve the nation's cybersecurity mandates that organizations wanting to do business with the US Government or its agencies must provide a Software Bill of Materials (SBOM). There has been a growing focus on attestations due to emerging Federal software supply chain requirements. In September 2022, the US Office of Management and Budget issued a memo requiring federal agencies to obtain a self-attestation and SBOM from software suppliers, as necessary. Software consumers are also increasingly demanding assurances of secure software development practices. As one of the largest consumers of open-source solutions, the US Government engages with numerous enterprises that must demonstrate compliance with the executive order.
In addition to the public sector, there is also increased demand for software supply chain solutions among enterprises, especially in highly regulated sectors. As discussed in part 1, NightDragon's software supply chain report revealed that over 96% of CISOs stated they are currently using or considering implementing SSC solutions within the next 12 months. This further supports the growth of software supply chain vendors.
Part 1: An Overview To Software Supply Chain
In our initial report, we laid out a definition for software supply chain and discussed the major phases that needs to be secured. We defined software supply chain security as measures to secure and prevent a malicious party from tampering with the steps and artifacts required to build a software product.
We categorize supply chain attacks into three broad areas that can be intertwined across: source, build, and deployment and package layer. In each of these stages, malicious actors can manipulate or introduce steps to modify the software output. This can be done through malicious third-party dependencies or due to a developer's mistake during the software development lifecycle.
Part 2: Software Supply Chain Vendors
This report focuses on analyzing the current approaches taken by SSC vendors to secure all aspects of the software supply chain. While most vendors have similar offerings, we observed a few differences in how these vendors approach the problem. This report focuses on providing a discussion around emerging vendors.
Inclusion and Exclusion Criteria
There are over 30+ companies focused on securing different aspects of the software supply chain. Due to the large number of vendors, we couldn’t cover every one of them.
The vendors discussed in this report are all samples or examples of solutions that address unique aspects of the software supply chain.
We recognize some vendors offer multiple products that cater to multiple categories of the software supply chain. However, in this discussion, we will specifically focus on a core feature of their product line to illustrate how each component of the supply chain can be secured.
We have placed more emphasis on emerging startups founded after 2018, as they bring unique and modern approaches to solving software supply chain challenges.
Many of the solutions discussed in this document involve analyzing source code or the source code management (SCM) or CI/CD platforms surrounding it.
Application Security Posture Management (ASPM): It’s important to note that some vendors discussed categorize themselves as Application Security Posture Management (ASPM). Gartner defines ASPM as vendors that enable the correlation of security data from multiple sources, triage all the data and offer a more comprehensive view of security risks across an application. This provides teams with insight into the overall status of a complete system. These offerings serve as a management and orchestration layer for security tools. Increasingly, ASPM solutions are being categorized as software supply chain vendors. However, it is important to note that while ASPM provide SSC security features, they should not be categorized as full SSC vendors.
Legacy Platform Vendors
We provide a brief discussion on the legacy software supply chain vendors. We recognize it is important to acknowledge they play a key role within software supply chain and many enterprises still rely on these solutions.
Veracode, Checkmarx, and Synopsys were all established prior to 2007. They were developed before cloud and open-source tools became widely used among developers. Initially, their focus was on serving a market where organizations primarily wrote code on-premises. These vendors specialize in Application Security Testing (AST) and offer tools and solutions to help organizations identify, assess, and mitigate vulnerabilities in their software applications, covering SAST, DAST, and IAST. In recent years, many of these legacy vendors have acquired emerging start-ups and adapted their platforms to cater to cloud-native environments and modern SCA solutions.
These vendors continue to be popular in the market due to their established reputations and strong vendor lock-ins. Many large and highly-regulated organizations rely on these solutions across their technology stack, making it challenging for new emerging startups to replace them. These vendors have acquired start-ups and developed solutions that integrate popular open-source tools. These incumbents have capitalized on their large customer base to upsell their solutions, which startups struggle to do in the current market that emphasizes vendor consolidation. We believe that these vendors may retain non-trivial market share within the next 1-3 years and should not be overlooked.
Modern Platform Vendors
Snyk was founded in 2015, and gained notable traction initially with Snyk open-source geared around SCA. They’ve expanded their platform to cover SAST, DAST as well as cloud security with the acquisition of Fugue. Despite recent trouble, laying off 15% of its workforce a few months after laying off 5% in late 2022, and seeing its valuation plunge over 50% in secondary deals in 2023, we believe Snyk will continue to remain a platform play for some large cloud-native enterprises looking to consolidate a number of application security solutions in one platform.
Modern Software Supply Chain Vendors
Source Code Layer
💡 In part 1 of our report, we discussed the importance of securing source code management (SCM) systems. This includes managing access to code environments and enforcing source code reviews, as these systems serve as the central hub for developers.
Developer environments represent a primary attack vector for malicious actors attempting to carry out SSC attacks. It is crucial for software teams to have visibility into every element of their applications, from source code to third-party dependencies.
Many of the vendors mentioned in the source code play a vital role early in the development lifecycle. They offer code monitoring, prevent code tampering, detect source code leakage, and alert developers to triggers or warning flags. We observed that many of these solutions are integrated with Git, GitHub, GitLab, and BitBucket, allowing them to perform these security actions within the developers' core environment.
GitLab and GitHub
It would be impossible not to begin with a discussion on the central components for millions of software developers. GitLab and GitHub revolve around the Git version control system, enhance collaboration, support repo hosting and are hubs for open-source projects. Due to the urgency of software supply chain attacks in recent years, these vendors have started to offer solutions that help secure source code all the way to securely using third-party dependencies. GitLab has its dependency scanning features and SCM solutions for developers. GitHub has its advanced security, which performs SAST on first party code, SCA for third-party code, and secrets scanning. GitHub has largely acquired companies for its security offerings - primarily Dependabot and Semmle in 2019. Whereas GitLab largely wraps open source tools like Semgrep, Clair, Trivy, and Grype to offer many of its security solutions, although it has acquired some small security start-ups in recent years.
Arnica and Jit.io
Both vendors have relative similar product characteristics with a core focus on tightening the loophole between security and development teams. However, they both have different approaches to their technical features.
Arnica
Arnica tackles the SSC problem using several approaches. Arnica's platform tracks every action performed by developers through its behavioral graph, enabling it to identify compromises in source control systems and identify any vulnerable code or unauthorized access to source code repositories. Once identified, Arnica notifies the code author, pusher, or any designated team in real time using ChatOps (usually Slack or Teams). For instance, developers can receive immediate notifications on their native communication platforms if they inadvertently push code containing exposed secrets, along with step-by-step instructions on how to rectify the issue.
Secondly, Arnica runs and maintains all real-time code scanning capabilities into their platform, which helps the customer avoid deploying multiple individual SCA or SAST solutions. Arnica utilizes what they call a 'pipeline-less' approach, which means they reduce the need for their customers to integrate multiple CI/CD tool to secure their pipeline. Arnica uses its built-in code security features (that combines SAST, SCA & IAC) in one to provide full coverage/context for their customers.
Another core feature of the platform worth noting as it relates to source code is managing developer access and behavioral analysis. Arnica’s automated developer permissions feature takes the approach of identifying potential injection of bad code through anomaly detection and strict branch protection policies. Arnica’s dynamic developer access management sets up behavioral profiles for all developers and applies least privileged access to minimize unauthorized users from abusing source code or systematically adjusting developer permissions based on historical access patterns.
Jit.io
Jit.io is an open product security orchestration platform that allows for the integration of multiple security tools to secure various stages of the SDLC. Their platform supports popular open-source tools for SAST, SCA, secret detection, cloud scanning, and DAST. Jit addresses the software supply chain problem through a concept called Jit security plans. This approach takes into consideration the business goals and requirements when securing all aspects of the software supply chain. The company offers security plans that guide users in achieving specific business goals while ensuring certification readiness. These include AWS Foundational Technical Review (FTR), Jit MVS for AppSec, and the OWASP Top 10 compliance framework for applications. Jit can help an engineering team comply with these frameworks from code to cloud.
Unlike solutions like Arnica, Jit allows users to use their own SAST and SCA tools. Jit assists with integrating and orchestrating these tools throughout the development lifecycle. Another unique aspect of Jit is its breadth and openness. Jit collaborates with other SSC and ASPM vendors in an open manner. Users can connect different security tools to the Jit platform, which then orchestrates and executes them primarily within GitHub. Users have the flexibility to add their own security tools by specifying the input, output, and execution methods.
The Build & Pipeline Layer
💡 Vulnerabilities in CI/CD can arise from insecure configurations of CI/CD tools and infrastructure, such as insecure build servers, artifact registries, and containers. The discussed vendors provide CI/CD pipeline security, build artifacts provenance checks, and code validation before a major build. Compromising any of these steps or environments can impact the integrity of the software artifacts that are produced and distributed.
Our analysis primarily focuses on vendors within SCA (Software Composition Analysis) that address issues related to third-party dependencies, whether they are unintentionally included as transitive dependencies or introduced within the pipeline. We also cover the deployment of containers and registries. Many of the solutions discussed integrate with popular build automation tools and CI/CD tools such as Jenkins, CircleCI, Azure DevOps, and GitHub Actions. Additionally, we discuss vendors that specialize in securing containers and their registries.
Software Composition Analysis (SCA)
Software Composition Analysis (SCA) tools were developed to identify and scan all open-source software and third-party dependencies in codebases to ensure compliance with licensing requirements and find dependencies with known security vulnerabilities.
How Do SCA Tools Work?
At a high level, most SCA tools are composed of two parts:
A database of known vulnerabilities (CVEs) that are associated with specific versions of third-party dependencies.
An engine that can examine a code repository, detect the dependencies it uses and what versions, and then compare those to its database of known CVEs.
SCA tools inspect package managers, source code, binary files, container images, and other code components. Essentially, SCA tools examine your code and say, “I see you’re using lodash version 4.17.20, and I know that’s vulnerable to CVE-2021-23337.“ SCA tools are able to provide an inventory of all the open-source code components used in the code build and evaluate them against a vulnerability databases like the National Vulnerability Database (NVD) and Open Source Vulnerability Database (OSVDB).
Some SCA tools aim to make it even easier for developers to resolve identified issues by automatically creating Pull Requests (PRs) that update a dependency to a version that is no longer vulnerable.
However, there’s a problem with the straightforward, SCA 1.0 approach. In practice, many organizations will receive thousands to tens of thousands of warnings about vulnerable dependencies. No development team can handle all of them.
How do you know which to prioritize? Enter: reachability analysis.
What is “Reachability Analysis”?
At the time of this writing, “reachability” is the latest advancement in SCA. Instead of warning users about thousands of “vulnerable” dependencies with no regards to their risk, SCA tools that perform “reachability analysis” determine not just if a repository is using a dependency at a vulnerable version, but also if the first party code is actually invoking the vulnerable function in the third-party library. Initial evidence suggests that “reachability” reduces >90% of SCA alerts, saving security teams and developers from wasting time doing work that minimally reduces risk.
At the time of this writing, it appears that only Semgrep Supply Chain and Endor Labs are meaningfully pursuing reachability analysis in SCA.
SCA Vendors
Dependabot
Dependabot (acquired by GitHub in 2019) was one of the earlier players in the SCA space, is free for open source repositories, and requires an Advanced Security plan for private repos. Dependabot can issue PRs to easily update vulnerable dependencies, supports exporting SBOMs, and ensuring license compliance.
Snyk
As discussed earlier, Snyk has grown rapidly over the past few years, with Snyk Open Source, their SCA product, being their original driver of revenue, which they used to buy a number of companies with complementary products (e.g. SAST, container scanning, etc.) to scale their business horizontally. Snyk has their own vulnerability database, and similar to Dependabot, supports auto-generating fix PRs, license compliance, and exporting an SBOM.
💡 Though their product pages and documentation are not explicit on how their analysis works, it appears that Dependabot and Snyk may work by simply comparing a project’s listed dependencies and versions with their CVE database. That is, they may not leverage a full-fledged code analysis engine that can effectively reason about code, resolve method calls, etc.
This would explain why Dependabot (source) and Snyk (source) discussed doing reachability analysis, but in practice they do not appear to have prioritized this work in their products, despite the clear user value in allowing developers to focus on upgrading the dependencies that meaningfully reduce risk.
Semgrep
Semgrep Supply Chain has focused on reachability analysis to help users focus on the dependencies that matter, that is, dependencies that may be exploited due to the fact that an application’s first party code is calling the vulnerable function in the dependency. Semgrep Supply Chain (and Semgrep’s other products) is free for up to 10 monthly users.
Semgrep Supply Chain also supports license compliance, SBOM export, and dependency search, which lets you search across every codebase in your organization for any dependency at any version, on demand. This can save hours or days of person-time in the case of a new, high-profile vulnerability dropping, such as log4shell, in which you need to know where you’re affected as soon as possible.
Semgrep also has Semgrep Code, a SAST product that extends their popular open source engine with more advanced analyses and additional security coverage, and recently launched Semgrep Secrets, which leverages Semgrep’s code analysis capabilities to go beyond regex when finding secrets in source code and can automatically validate if detected secrets are currently live.
Endor Labs
Endor Labs similarly uses program analysis to perform reachability analysis of CVEs in a project’s dependencies. Some applications can fail to properly declare all dependencies in their manifest file, instead assuming they’re already installed in the local dev environment. Endor compares manifest files to the imports an application makes in source code to determine dependencies that are imported but never used (SCA “false positives”) as well as imports that are not in the manifest (false negatives). Endor can also export an SBOM that includes Vulnerability Exploitability eXchange (VEX) information, which includes metadata on if a vulnerability is reachable or not.
Endor Labs uses several other mechanisms to prioritize alerts, including EPSS, fix availability, change impact analysis, and more. With a rego-based policy engine, customers can author fine-grained policies to take disruptive action (i.e. break builds) when the risk justifies it across multiple dimensions - reachable, fixable, exploit maturity, deployed in production, etc.
Oligo
Oligo uses eBPF to provide runtime visibility into the OSS libraries an applications relies on and how the libraries interact and behave. Using runtime data, Oligo can inform users of which vulnerable dependencies are live and may be exploitable. Further, Oligo has a database of baseline behavior profiles of OSS libraries, which they then compare to live package behavior, and alert when a library deviates from its expected activity, as that may indicate a successful attack.
Contrast Security
Contrast SCA provides a runtime SCA approach that watches code execute and tracks how libraries are invoked. This allows it to provide feedback on libraries that are totally unused, which they report to be ~62% on average. As Contrast SCA operates at runtime, it knows which libraries are present in the running app, including libraries not present in code repos and manifests (e.g. appserver libraries and runtime platform libraries), and includes code loaded by plugins, dynamic loading, instrumentation, and custom schemes. Finally, Contrast says that this approach handles complex reachability cases, like inversion of control, reflection, and inheritance.
💡 Software Composition Analysis (SCA): Static vs Dynamic Approaches
It is useful to highlight the differences between Static vs Dynamic SCA solutions.
Static SCA performs analysis on source code including libraries, dependencies, and custom code, allowing for early detection of vulnerabilities before software is executed. Meanwhile, a dynamic SCA tool scans for vulnerabilities at runtime, allowing developers to understand how an application utilizes external dependencies in runtime environments.
One potential trade-off between the approaches is that static tools may report issues in libraries that are not used at runtime, which are effectively “false positives,” in that they are not exploitable. More recently, some SCA tools have been adding reachability analysis, that are able to only flag CVEs in dependencies for which the actual vulnerable function is called. Further, the runtime configuration of an application may make practically exploiting a vulnerability impossible.
Meanwhile, a dynamic SCA tool could be able to only flag vulnerable third-party code that is used at runtime (fewer “false positives”), but a) risks discovered much later in the development cycle could be more costly and take longer to fix (vs being within developers’ existing workflows), and b) it’s possible that the vulnerable code is exploitable, but via infrequently called edge case code, so it may not be observed at runtime.
In general, SCA tools are an important tool in securing a company’s use of third-party dependencies.
Note: SCA tools looks for known vulnerable dependencies, and generally do not look for malicious dependencies, except for dependencies that have already been determined to be malicious.
Malicious Dependency Vendors
In this section, we will discuss several vendors who specialize in identifying malicious third-party dependencies in popular open source packages.
Socket
Socket approaches the supply chain problem by providing a platform that detects vulnerable packages in real time. It enables developers to understand the nature of the dependencies they are using through Socket dependency search, dependency risk assessment, and content-based analysis for detecting capabilities.
Through its native integration with GitHub, Socket can provide developers feedback directly on PR comments about a dependency’s behavior and security risk. These dependency overview comments provide a quick summary of which dependencies were added or updated, what “capabilities” or API usage a dependency has (e.g. accesses the file system, makes network requests, runs shell commands, etc.), and the number of new transitive dependencies. This helps engineering teams understand and make informed decisions about the impact of code changes in their applications.
Socket has also written about leveraging large language models (LLMs) to detect malicious dependencies here and here.
Phylum
Phylum approaches the problem of software supply chain security by leveraging big data and machine learning to automatically identify and mitigate attacks and other risks associated with open-source software. They achieve this by continuously monitoring package publications in major open-source ecosystems, including npm, PyPI, RubyGems, Maven, Nuget, Crates.io, and Golang.
In real-time, Phylum examines the source code, authors, metadata, and other factors of newly published packages. They use heuristics, analytics, and machine learning to determine if a package exhibits suspicious behavior indicative of malware. This year alone, they are projected to analyze nearly a billion files across 15 million package publications, providing comprehensive coverage of popular open source solutions used by developers. By cataloging and classifying this vast number of packages, Phylum can offer organizations insights into attacker behavior.
Phylum believes in a defense-in-depth approach to software supply chain security works. They recognize that developers, with access to source code and production infrastructure, are high-value targets. Therefore, Phylum goes beyond blocking attacks during CI/CD (with integrations for popular CI providers like Github and Gitlab) and also focuses on ensuring developers' safety during the development process. To this end, they have open-sourced a sandbox (Birdcage) that restricts network, disk, and environment access.
Datadog’s GuardDog
GuardDog is a new open-source solution announced by Datadog earlier this year that allows developers to identify malicious Python packages using Semgrep for static analysis and package metadata analysis. GuardDog introduces support for scanning not only PyPI, but also npm packages. GuardDog can be integrated into a continuous integration (CI) pipeline and scan new dependencies introduced by pull requests. Datadog open sourced a number of malicious packages they found during their research.
Endor Labs
Though it’s not clear if Endor Labs is currently looking for direct malicious behavior like Phylum or Socket, Endor’s open source governance does similarly report potentially risky metadata for packages (not maintained appropriately, has risky maintainers), as well as suspicious code behavior like executing OS commands, writing to the file system, and making network requests. Built on that risk data-set is DroidGPT - a conversational AI interface that lets you find OSS package versions quickly, and understand the associate risks. Simply ask "what are good alternatives for Log4j?" or "what Python ML packages have the most permissive license?" Endor has shared some blog posts about prototyping malware detection using LLMs here and here.
CI/CD Pipeline Security
OX Security
OX Security's approach to supply chain security focuses on the software CI/CD pipeline. OX introduced the term PBOM (Pipeline Bill of Materials). For every pipeline build, OX generates a signed knowledge graph called PBOM, which creates a dynamic Bill of Materials (BOM) showing the software lineage throughout the development lifecycle. Essentially, it is an continuously updated map that includes everything an SBOM would have, along with a record of the infrastructure that the software has passed through (e.g., pipeline branches, builds, pull requests, tickets, known issues). OX Security ASOC Single Source of Truth and CI/CD Workflow automation and security posture specifically help achieve traceability and visibility of all components throughout the build and pipeline stages.
OX Security co-created the Open Software Supply Chain Attack Reference (OSC&R), an open-source framework for understanding and evaluating threats to the software supply chain including tactics and techniques for addressing these issues. OX security built their product using this framework which is why they have solution catered across the supply chain.
OX examines code repos and maps pipelines to find security flaws and incorrect setups. OX deploys various security tools like static analysis, SAST, secrets scan, containers scan, and IaC scan to identify risks or misconfigurations during a build. It then generates a benchmarking application risk score after analyzing code scans, secrets hygiene, packages, and pipelines.
Cycode
Cycode specializes in CI/CD security and build hardening through its source control feature. Cycode utilizes a lightweight eBPF (Extended Berkeley Packet Filter) security solution that can detect attacks during the build process. They can manage supply chain breaches by scanning for compromised pipeline runners and monitor against attacks such as typoSquatting or malicious dependencies in the build. Cycode also offers a source code leakage detection product that reduces the likelihood and risk of code leakage. It alerts on suspicious behavior and identifies actual leaks of proprietary code, enabling quick containment.
Tromzo
Tromzo addresses supply chain security through what it calls Product Security Operating Platform (PSOP). This means they go about solving SSC issues by bringing visibility across a company’s software asset inventory and all aspects of the CI/CD pipeline. They provide customizable security policies in CI/CD (that cuts across secure defaults, code ownership, and scan coverage) to enable teams to build security systems. In addition, Tromzo offers a CI/CD (Continuous Integration/Continuous Deployment) posture management solution that ensures build servers require authentication, limits the ability to create public repositories, and sets security keys to expire by default. The company also addresses potential vulnerabilities in the pipeline by restricting risky development practices, such as executing third-party resources before verification or referencing images in a build that may be externally altered.
Their platform is more targeted for ASPM buyers due to the breadth of coverage closer to the deployment stage. Security teams utilize Tromzo's proprietary Intelligence Graph to identify critical software assets, including ownership and lineage, and address the vulnerabilities that pose the highest risk to the business.
Cider Security (now part of Palo Alto Networks, Prisma Cloud)
The original Cider product, now sold as Prisma Cloud, utilizes a graph-based database to provide a consolidated inventory of a company’s CI/CD pipeline in a single view. The product specifically scans for exposed credentials in webhooks or pipeline logs that could be abused. Due to Palo Alto’s wide product range, they are able to correlate disparate signals across codebases, scanners, orchestration and automation tools to centralize visibility and control over a developer’s workflow.
Container Security
Chainguard
Chainguard Images offers a suite of security-first container base images without extraneous packages that allow developers to build upon this clean image signed by Sigstore. Throughout the process, developers can generate SBOMs during the build process using Chainguard. The images for platform teams reduce overall scanner noise, are designed to help users to increase their SLSA assurance levels and stop manual patching by taking care of updating images. They can be used to ensure continuous verification, ensuring packages in development remain in compliance with no vulnerabilities even post-deployment.
Aqua
Aqua Security offers a broad set of software supply chain features that includes SBOM generation with popular industry formats. However, its core strength lies in its container security product. They can scan containers running on VMs, and serverless containers such as Fargate and Azure Container Instances (ACI). Aqua’s provides image scanning as well as the ability to provide dynamic analysis of images. Their solution integrates with a wide range of container registries and Kubernetes platforms.
Rapidfort
Rapidfort has taken a container-based approach to tackle the problem. They introduced the concept of "RBOM" (Real Bill of Materials), which is an SBOM (Software Bill of Materials) post-container optimization technique aimed at reducing noise to minimize vulnerability alerts during scanning. Rapidfort automatically optimizes containers to include only what is necessary. Developers can provide fine-grained configurations or use vendor-provided recommendations, and the solutions offer post-optimization analyses that detail which files, packages, and vulnerabilities were removed.
The Packaging & Deployment Layer
💡 The packaging & deployment layer discusses vendors that focus on code provenance, code signing, SBOM generation/management and artifact repository. Many of the vendors provide visibility across software assets, compliance and important software metrics.
Software Bill of Materials (SBOMs) / Code Provenance / Code Signing
Chainguard
Chainguard Enforce provides policy management following the SLSA and NIST frameworks, and utilizes compliance automation tools to generate SBOMs. They further help identify and investigate policy violations, and production insights to allow users see live views of production environments. With this approach, Chainguard helps developers exert control and enforce policy, reducing the risk of injection of malicious submits, commits, artifacts, or dependencies.
Legit Security
Legit Security takes a core approach to software supply chain security by focusing on SBOM compliance. It offers developers an Application Security Posture Management (ASPM) tool that provides observability and visibility into all critical aspects of code-to-cloud deployment.
At the source code layer, Legit integrates with all source code repositories and ensures that accessing source code requires multi-factor authentication. It protects source code through code reviews and branch protection, and it audits third-party integrations that have access to the source code. Legit's code-to-cloud traceability features provide context from source code repositories involved in building the source artifact.
Legit Security prioritizes continuous SBOM compliance for companies. Their SBOM supports leading regulatory frameworks like the SBOMs in CycloneDX format. Their SBOMs help companies identify compliance gaps, aggregate multiple sources of SBOMs, and distill the differences among different SBOM formats.
According to Kuppinger Cole, Legit Security's Build Integrity products rank among the highest on the market. Their solution performs various container security checks before a software build, such as image compliance, detecting drifts in software artifacts, and preventing the release of potential hard-coded secrets. Legit integrates with all major build automation tools and provides support for a variety of programming and script languages.
Apiiro
Apiiro approaches SBOM using a comprehensive approach called Extended Bill of Materials (XBOM). This product, built around a graph-database, includes all the core SBOM features that look for vulnerable dependencies. However, it goes beyond that by providing additional visibility across a company's application stack, pipeline components, Infrastructure as Code (IaC), container images, and APIs. Apiiro also aggregates, prioritizes, and fixes risks by deduplicating alerts, linking each risk to a code owner, and triggering remediation workflows. While Apiiro offers products aimed at application development and cloud security, they also provide visibility, prioritization, and remediation across software supply chain pipelines. This includes analyzing developer behavior and using a risk graph to detect malicious packages in open-source solutions.
Special Mentions
Anchore provides a container-based and cloud-native software supply chain security solution.
ArmorCode AppSecOps platform integrates and correlates data from security, CI/CD, and cloud infrastructure tools, as well as ticketing and collaboration solutions in an organization's IT ecosystem
Lineaje offers an SBOM 360 product with a CLI/SCA tool that supports SPDX and CycloneDX formats. The tool analyzes software from different sources, and uses its Lineaje's Deep Learning Engine (LDLE) to break down and map software components. Lineaje's strength is in providing businesses with advanced SBOM data, which is valuable for companies requiring strict SBOM compliance.
Concluding Thoughts
Solving the software supply chain issue is complex and hard. It will take time for companies to get it right. As an industry that only evolved less than five years ago, it will take time to fully operationalize across organizations.
A common similarity among all vendors is their tight integration with source code repositories and CI/CD solutions such as GitHub and GitLab. They offer solutions that enhance access control to IDE and source code environments. Additionally, they are capable of detecting known malicious dependencies in packages and libraries, promptly alerting developers. Perhaps due to the recent executive order, many vendors provide the ability to generate SBOMs for customers regardless of the format.
We believe that the greatest value lies in vendors who can seamlessly bridge the gap between security and engineering teams, minimizing context switching for developers.
The software supply chain category is already highly fragmented, with nearly 30+ startups addressing related issues. As this sector continues to grow with a multitude of new solutions, the topic of vendor consolidation is often discussed. For instance, Palo Alto networks acquired Cider Security last year. This year, we’ve observed more ASPM acquisitions. Snyk acquired Enso Security and Crowdstrike recently acquired Bionic.ai. It is anticipated that as this market evolves and certain vendors mature, leading application security vendors may consider acquiring some of these companies to enhance their larger platforms.