Defining A Software Supply Chain Security Platform & Exploring New Techniques, Part 2
What defines a successful software supply chain platform? Exploring new techniques like reachability analysis, secrets, and open-source communities.
This is my final deep dive into the software supply chain ecosystem. Across 3-reports, I’ve provided a full breakdown of this ecosystem, covering, and analyzing over 20+ companies. I have spoken to many founders and security leaders on this topic. I have some exciting topics that will be published over the upcoming weeks exploring newer categories, like Next-Gen SIEMs / Security Analytics, Identity and SOC automation platforms in cybersecurity. Today’s piece provides a discussion on software supply chain security platform vendors and provides a core spotlight on several solutions being adopted within the industry.
On Thursday, I will be a guest at this event titled ASPM—Deep Dive with Chris Hughes, where we will discuss some of these software supply chain topics and what defines a full ASPM vendor.
Actionable Summary
After 8 months of research into many vendors across the software supply chain security ecosystem, I’ve observed that to become a full and successful software supply chain vendor - you need to either specialize in a few areas in which you have a core competitive advantage or provide the full breadth of solutions across the supply chain.
Many of the successful platforms in this ecosystem have implemented this framework. The large SSCS solutions that have been successful (based on revenue) cut across source code, build, and artifacts all the way to deployment in the cloud, including Cycode, Ox, Apiiro, and Cider (Palo Alto networks). There are some that have been successful as AppSec orchestrators, like ArmorCode and Jit. However, some successful vendors like Chainguard have specialized in being exceptionally good at a few areas, e.g., containers and base images.
In Part 1 of our SSCS report, we introduced SSCS and its basics and highlighted a few vendors solving problems for various parts of the supply chain. For example, we discussed the importance of artifact repos with vendors like Kusari and some vendors with strong capabilities in container security and malware detection, like Chainguard and Xygeni. We also discussed vendors with strong pipeline posture security, SBOM and reporting capabilities like Scribe security.
In Part 2, our final piece on SSCS, we aim to focus on a few vendors that offer solutions in a different category from those we featured in early versions. Some of the new techniques include secrets detection (include vendors like GitGuardian), developer security workflows and open source community (Stacklok) and reachability analysis highlighting vendors like Backlash security and EndorLabs. At the end, we discuss vendors who provide a full range of solutions across the ecosystem.
Defining A Complete Software Supply Chain Platform
Many people would call a vendor that covers every aspect of SSC an ASPM provider (much later this week), but for the sake of this report, I want to focus on vendors that primarily secure all the core components required to create and deploy software.
A complete vendor would cover every aspect of code, build pipeline and the package component closer to deployment. First, starting with code, these vendors are good at SAST, SCA, IaC scanning, and container security. They further cover all aspects of the build, CI/CD and pipeline security - which could include Secrets detection/scanning and API security. It can detect malicious and known dependencies. Closer to deployment within the package, you have solutions that are strong with an artifact repository, code provenance/signatures, and SBOMs (runtime and static). Fundamentally, across all these categories, the core question that needs to be answered is: Does a company have full visibility across its software development process? secondly, does it make the developer experience easy and simple?
Software Supply Chain Ecosystem Map
Why Attacks Keep Happening Despite Many Solutions?
The Story of the XZ Trojan Attack disclosed on March 29, 2024
One of the prominent questions I keep getting asked is why do cybersecurity or supply chain attacks keep happening despite a wide proliferation of software supply chain vendors. It’s a difficult question amidst the nature of these attacks. For example, one of the largest software supply chain attacks on an open source project recently happened. It involved the XZ Trojan attack on xz-utils package, a popular open source compression tool. The XZ Trojan attack exemplifies a sophisticated software supply chain attack using social engineering tactics to compromise open-source projects. This specific targeted attack was conducted by compromising a long-time maintainer, Lasse Collin.
The attackers created several fake developer accounts, or "sock puppets," which began to pressure Collin by critiquing his pace of updates and the need for more project integrations. This pressure, compounded by Collin's personal issues cited as "long term mental health" problems, led him to look for assistance in maintaining the project. This scenario was exploited by one particular account, "Jia Tan" (JiaT75), who had gradually become an active contributor. Over time, and under sustained pressure, Collin was persuaded to hand over control of the project to Tan. Once in control, Tan was able to introduce malicious code into the XZ Utils codebase. Concurrently, other sock puppet accounts started urging the maintainers of major Linux distributions to include the compromised versions of XZ Utils in their releases, further propagating the malicious code.
This case illustrates the vulnerabilities inherent in the open-source ecosystem, where trust and community collaboration can be weaponized. Attackers used minimal effort to create a superficial credibility for these accounts, making it challenging for developers and project maintainers to distinguish between legitimate contributors and malicious actors. Key strategies to detect such threats include monitoring for unusually active new accounts, scrutinizing operational security details of contributors, and examining the code for potential signs of malicious intent like typosquatting or obfuscated code.
Here is a timeline of even all the more supply chain attacks that have happened over the past year. The big question is how most of these issues would be solved:
SSCS Tools and Frameworks
In our last report, we highlighted some of the common industry tools and frameworks used aimed at solving many of the issues. We discussed:
Supply-chain Levels for Software Artifacts (SLSA)
Secure Software Development Framework (SSDF)
Sigstore
GUAC, Graph for Understanding Artifact Composition
Below are a few other tools and frameworks that we didn’t highlight:
Exploit prediction scoring system (EPSS) (3.0)
SPDX, 3.0 Release Candidate
CycloneDX
OWASP Top 10 for LLMs (relevant for AI software)
Open software supply chain attack reference (OSC&R)
Newer Approaches & Techniques
In this particular report, I want to focus on a few components of the software supply chain that has been receiving more and more attention in recent months.
Secrets detection and scanning
Open-source and developer-focused security
Next Gen SCA & Reachability analysis
Players across the full SSCS landscape
Secrets Detection
Early into the software supply chain security challenge, there were industry experts who wouldn’t “fully” consider secrets detection as a core component of the supply chain. However, in recent years more and more practitioners have come to realize its importance.
According to ReversingLabs, 2023 saw an explosion of leaked development secrets persist across almost every major open-source platform ReversingLabs monitored. Developer secrets have long been a target for malicious actors, and 2023 began with a high-profile hack of the CI/CD vendor CircleCI, which led to the theft of development secrets and an urgent warning by the company for organizations using the CircleCI platform to rotate any secrets stored in code. ReversingLabs regular scans of platforms including npm, PyPI, RubyGems, and NuGet reveal that secrets leaks tend to congregate (not surprisingly) with popular applications and hosting platforms such as Slack, AWS, Google, GitHub, and Azure. For example, npm, accounted for 77% of the more than 40,000 secrets ReversingLabs detected across the four major open-source platforms: npm, PyPI, RubyGems, and NuGet. Of the more than 31,000 secrets detected on npm, the majority (56%) were used to access Google services, whereas 9% were attributed to Amazon’s AWS cloud services.
According to the report, a similar pattern was observed on PyPI, which accounted for 18% of the secrets leaks ReversingLabs observed in 2023. Tokens to access Google services accounted for just over 24% of the secrets detected. The secrets related to AWS accounted for around 14% of the total discovered on PyPI. For full details of the report, visit state of software supply chain attacks 2024.
Secrets In The Software Supply Chain: What Are Secrets?
Secrets detection refers to the process of identifying sensitive information—such as passwords, API keys, private cryptographic keys, and tokens—that might have been inadvertently included in source code or other components within the software supply chain. The goal is to ensure that these secrets do not end up in version control systems or become part of distributed software packages where they could be accessed by unauthorized parties.
One of the most challenging aspects of building software is balancing speed and security. Most software development teams nowadays are being asked to do a lot more at faster speeds to unlock new customer experiences and business opportunities. In a high speed environment where developers are being measured on quality, time, and incidents they resolve, it is likely that they will take shortcuts. Add to that, the complexity of training every developer in good security practices and enforcing guardrails, it is highly likely that mistakes will happen.
As a result in the software supply chain, developers may unintentionally expose secrets such as passwords, private keys, OAuth tokens, API keys, and more. These secrets are attractive targets for attackers and can be leaked through CI/CD pipelines, code repositories, open-source packages, file stores, chat apps, and SaaS tools. The accidental exposure often stems from developers inadvertently leaving keys in code, hardcoding secrets in public repositories, copying secrets into code, or making private repositories with secrets publicly accessible. Additionally, secrets may be accidentally printed in logs or pushed to other repositories. The resulting 'secret sprawl' presents a significant security issue, as even a single exposed secret can allow an attacker to move laterally within an organization's systems.
Identifying the responsible user (developer), leak stage, and exposed secret location is challenging due to a lack of knowledge or non-adherence to best practices. With the global rise in coding and new methodologies like AI adoption increasing secret exposure risk, secret sprawl is a growing significant challenge necessitating stricter secret management across the software supply chain. Based on a recent research across 1M popular web domains, the exposed secrets included hundreds of Stripe, GitHub/GitLab tokens, RSA private keys, OpenAI keys, AWS tokens, Twitch secret keys, cryptocurrency exchange keys, X (formerly Twitter) tokens, and Slack and Discord webhooks. Managing these secrets is easier said than done, and as we can see in the graphic below, secret detection and management in 2024 isn’t a solved problem:
Major Vendor In Secrets Detection
GitGuardian
There are many vendors within supply chain who cover secrets scanning as part of their solution like Staclock, Scribe and a number of other solutions, but its important to specifically highlight one major vendor who covers most of the category.
GitGuardian is one such company that has built an entirely new category in enterprise security around secrets detection, has expanded this concept to the entirety of the software supply chain, and is well on its way to building a platform that has integrated offerings in scanning beyond secrets across source, build, package and deploy stages.
Started as a public monitoring service that scans for secrets in public repositories and sends pro bono alerts, GitGuardian is now the #1 security app on the GitHub marketplace used by over 500,000 developers and multiple organizations who rely on their enterprise offering to monitor their internal environments. The company has been tracking secrets across the internet for the past 4 years via their annual State of Secret Sprawl report which reports that in 2023, 12.8M secrets made their way in public repos which is a 4x increase in 4 years. With their recently announced partnership with CyberArk, they have created a joint solution to enable enterprises to manage secrets securely at scale, as illustrated by the graphic below.
Capabilities
While they may have started with secret scanning, GitGuardian (GG) understands the core needs of Application Security, Developers, and DevOps teams, and has built an innovative SSCS platform with new features that address code security requirements for an enterprise, while enhancing their suite of secrets security products. This includes the following:
Secrets detection at scale: GG’s solution is centered on its detection engine which can scan for over 390 types of secrets, gather context, and confirm their validity at any level of the development cycle as specified by the organization leveraging their githooks.
Public monitoring threat intelligence: Secret detection in public facing GH repos has been GG’s flagship offering, now a useful feed for Security Operation Centers (SOC) and threat intelligence teams in the enterprise and often developers who share the burden of remediation.
Honeytoken deception: Honeytokens bring deception-oriented intrusion detection to the software supply chain i.e. decoy credentials acting as tripwires, revealing attack patterns and fingerprints (e.g., IP Address, User Agent, Location, etc.) without granting access to real customer resources. When a hacker triggers these decoys during a secret scan, it alerts the SOC team to a potential security incident.
Software Composition Analysis: Recently released, GG’s newest product SCA identifies software dependencies and their licenses being used in code across GitHub and GitLab. CVEs are complemented with EPSS scores to help teams prioritise remediation.
Partnerships and integrations: Besides CyberArk and Snyk partnerships, GG’s platform is extensible and supports customer requirements to share detections via Webhook APIs, and integrates with software supply chain and code security toolsets.
Differentiation and unique value proposition
As the secrets detection space isn’t overly crowded, it sometimes does appear to be a feature rather than a product, and this is where GitGuardian’s unique capabilities highlight the value they are bringing to the ecosystem:
Developer-friendliness: Yes, most secrets are leaked inadvertently by developers, but no one likes to be told they are doing a crap job. Security may be most interested in solving this problem, but the fact that developers are easily able to collaborate to view incidents and provide context in GitGuardian’s enterprise offering builds a lot of trust. Besides the free offering for teams under 25, GitGuardian has its own open source product ggshield to scan for secrets and IaC security issues in code, as shown below.
Enterprise orientation: There are several open-source secret scanning alternatives including your popular Source Code Management (SCM), yet none of them can provide such detection capabilities across several applications in a hybrid cloud multi-SCM environment often found in an enterprise. Additionally, the scanning engine is language agnostic yet flexible to support unique detection patterns as required.
Focus on remediation: Even a single leaked secret can lead to an epic compromise, so it is critical that enterprises prioritize speedy remediation as soon as secrets are detected, confirmed, and triaged. As often security teams end up fatigued with alerts, GitGuardian’s platform enables grouping, scoring and prioritization for convenient consumption complemented with detailed investigation timelines and playbooks to automate effective response steps.
Moving forward, GitGuardian is building an enhanced code security platform and has a feature enhancements coming up, notably their upcoming IaC security scanning product, and integrations to detect secrets across Confluence, JIRA, and Slack history. To learn more about this space, you may find Enterprise Buyer’s Guide for Secrets Detection useful as it includes the essential capabilities and features to take into account when choosing a secrets detection and remediation platform.
Developer Security Workflow & Open Source
Stacklok Security
Highly sophisticated attacks on critical components such as open source implementation of critical libraries such as SSH via XZUtils showed that this problem won’t be solved solely by enterprises deploying traditional SCA tooling that focuses on CVE detection only.
Stacklok is taking a new approach in this space. Rather than focusing primarily on CVE detection for dependency security, Stacklok looks more holistically at supply chain risk factors like contributor behavior, project health, and proof of origin to rank dependency safety and trustworthiness. Stacklok provides a platform to proactively apply policies based on that data, and to apply policies for other areas of supply chain security, like GitHub Actions security and source repository management.
With its founders’ strong roots in founding, developing and scaling open source platforms and security tools, including Kubernetes and Sigstore, Stacklok is building security products that are aligned with open source and community standards, and that build on concepts of declarative configuration and automation popularized by Kubernetes to help secure code repositories, build pipelines, and software artifacts.
Capabilities
It is notable that while Stacklok hasn’t built any native code security scanners, they integrate with free community scanners like OSV.dev and GitHub-native tooling. They take a developer-centric approach by focusing on developer-centric security earlier in the workflow to provide timely feedback before issues reach production. Their two products, Minder and Trusty, are free to use for open source communities and developers, and include capabilities below:
Minder security platform and policy engine: With its brand-new SaaS offering (free for public repos), Minder is a platform that makes it easier to adopt open source tools and community standards to secure software supply chains. It includes pre-configured policies to secure source code repos; GitHub Actions and CI/CD workflows; dependencies; build artifacts; and AI-generated code, and supports automatic remediation to enable faster and secure decision making for developers.
Trusty dependency risk analyzer: Addressing provenance gaps in the SCA scanner ecosystem for open source software artifacts, Trusty vets open source package risk by using factors like author and repo activity, and known deprecated or malicious status, along with validation of a package’s source of origin, to provide an overall score with context to help developers make better decisions. It also includes alternative suggestions powered by Generative AI. An example of a Python dependency is shown below for context.
Developer-workflow integrations: Built with the intention of being developer-centric, Stacklok’s products are intended to align with developer workflows. Trusty includes an IDE extension to flag risky dependencies, and Minder integrates with GitHub to automate remediation actions like re-enabling disabled settings and opening or commenting on pull requests with suggested fixes. Minder is also extensible i.e. users can write their own custom rules in yaml or Rego, and use APIs to embed Minder into their existing workflows. To add to all this, their documentation is extremely easy to follow and consumable - a much needed developer feature for security products.
Differentiation and unique value proposition
It is early days for Stacklok as a company, but they are building in public and both Trusty and Minder are starting to show promise in solving hard security challenges for the open source ecosystem as well as enterprise software development teams alike. Here are a few things that set them apart:
Developer centricity and commitment to open source: Both Trusty and Minder can help developers catch and address security risks early in their native workflows, which many traditional security tools claim but fail to execute on. Examples include highlighting risky dependencies native actions like commenting or opening PRs with proposed fixes. Stacklok is an OpenSSF member, and has made these products frictionless to access and free to use for the open source community, which is amazing!
Platform sensibilities: As its founders have experienced the plight and delight of maintaining OSS first hand, Minder draws on unique principles such as continuous monitoring and enforcement of policies across repos with proactive alerting and automatic remediation options.
Data-driven supply chain risk intelligence: Stacklok collects unique signals around OSS to determine if it is malicious or deprecated, whether it has no verifiable link to its source code, presence of a sustainable community behind it, etc. which are extremely critical for the security of the entire enterprise software supply chain, and are rarely collected by other tools in this space.
Stacklok aims to expand with integrations beyond GitHub and other commercial security tools, especially scanners with Minder, while continuing to enrich the security intelligence in Trusty. Their commercial product will require private repository support, and will be geared towards security-minded software development teams. The company is passionate about the mission to secure the open source supply chain that underpins so much software development. If you’d like to learn more about Stacklok or try their products, visit their website: https://stacklok.com/
Next-Gen Software Composition Analysis (SCA) & Reachability Analysis
This has been a hot topic across the industry. In Part 1, we briefly touched on SCA, but it’s important to go a little deeper into the concept here. SCA was meant to be the core pillar of the software supply chain ecosystem. They 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?
As my friend at tldr-sec says, 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).
In general, SCA tools are an important tool in securing a company’s use of third-party dependencies. Its important to note that SCA tools look for known vulnerable dependencies, and generally do not look for malicious dependencies, except for dependencies that have already been determined to be malicious. 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 in which no development team can handle all of them. This brings us to the evolution of SCA solutions.
Future of SCA: Reachability Analysis
Reachability Analysis has been deemed as the future of SCA. It has grown in popularity in recent years and are almost becoming a must-have feature for AppSec and developer teams because it helps distinguish real exploitable risks from false positives - essentially reducing noise in the environment.
Reachability analysis in the context of application security is about understanding and tracing the path that data flows through an application. It focuses on determining whether identified vulnerabilities are actually accessible or "reachable" by an attacker from an external input. 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.
There are broadly two types of SCA solutions:
Static SCA solutions perform analysis on source code including libraries, and dependencies allowing for early detection of vulnerabilities before software is executed. They review code to determine how dependencies are integrated, revealing which parts of third-party libraries are referenced and potentially vulnerable.
Dynamic SCA solutions scan for vulnerabilities at runtime, allowing developers to understand how an application utilizes external dependencies in runtime environments. It observes the application during runtime to capture real-time data on dependency interaction and usage, offering insights into reachability and runtime vulnerabilities.
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. 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 risks discovered much later in the development cycle could be more costly and take longer to fix (vs being within developers’ existing workflows). Secondly, It’s possible that the vulnerable code is exploitable, but via infrequently called edge case code, so it may not be observed at runtime.
There are also SCA solutions that analyze Manifest files and lock files.
SCA tools that analyze manifest files (ie. a file that contains metadata about the application or project. This metadata includes information about the project's dependencies, such as libraries) to identify used open-source components, offering a basic view of dependencies but has no insight into how the application utilizes them.
Meanwhile, Lockfile (ie. a file that is automatically generated by package managers to record the exact versions of each dependency that were installed at the time of generation) provide a detailed snapshot of specific versions of dependencies used, providing accurate version tracking but not insight into their actual execution or reachability in the application.
Endor Labs and Semgrep were one of the earlier to create reachability analysis, but there are some emerging vendors attacking this problem such as backlash security. First of all, let’s discuss the five major types of reachability analysis according to James Berthoty who write an insightful article for Endor Labs.
Function-Level Reachability (SCA): It involves analyzing how functions within libraries or packages are actually used within the application’s codebase. For example, a jQuery XSS vulnerability might be present but only exploitable if certain functions are used together in a particular way that is uncommon or against recommended practices.
Package Baselining (SCA and Container): It refers to the analysis of normal behaviors and actions of a package and alerting or blocking when these behaviors change or deviate from a baseline. This can be crucial for identifying suspicious activities like a logging package attempting to execute code, which it typically should not do.
Internet Reachability (SCA and Container): It assesses the exposure of application components to the internet and prioritizes vulnerabilities based on their accessibility from external sources. It is based on the idea that components exposed to the internet should be prioritized for patches and security updates due to their higher risk of being targeted by external threats.
Dependency-Level Reachability (SCA): This type of reachability looks at whether the packages or libraries imported into an application are actually being called or used. This helps in determining if a vulnerability in an unused package poses any real threat to the application
Package Used in Image (Container): This approach focuses on determining if a package that is part of a container image is actively being used by the application. Like package baselining, it helps in identifying unnecessary packages that could be removed to minimize the risk.
Each type of reachability analysis has its strengths and limitations, and their effectiveness can vary based on the specific application context and security requirements. Function-level reachability stands out as particularly valuable for its potential to precisely identify exploitable vulnerabilities, thereby significantly reducing the workload on security teams by enabling them to focus on true positives. Other types, like internet reachability and package baselining, provide additional layers of security by helping prioritize vulnerabilities based on their practical impact and preventing the misuse of functionalities respectively.
Vendors In Reachability Analysis
Although vendors like EndorLabs, Ox Security, Semgrep and Coanna have shown capabilities within reachability. I believe there is another vendor worth spotlighting to showcase their capabilities here.
Backslash Security
Backslash Security is a security provider that specializes in providing a next-gen SAST (Static Application Security Testing) and SCA (Software Composition Analysis) primarily through an advanced reachability analysis. They are good at analyzing the attack surface of applications based on code, emphasizing a more integrated and comprehensive approach to securing applications.
Their products primarily focus on identifying and managing vulnerabilities in application codes and open source software (OSS) packages. The connect to application code repositories to perform static analysis without requiring deployment. They analyze application flows and code vulnerabilities, focusing significantly on reachability analysis to prioritize security risks that are actionable.
Backslash Reachability Analysis
This is a critical feature where Backslash Security differentiates itself. They focus not only on identifying vulnerabilities but on determining if a vulnerability is reachable and exploitable from an external input. This reduces the noise of irrelevant alerts, allowing security teams to focus on the most pressing issues.
Reachability analysis is a critical capability within the domain of application security, particularly when dealing with static analysis and managing open-source software (OSS) vulnerabilities
Backslash Security performs a static analysis of the application code to map out the business logic, application flows from APIs/functions and data flows without needing to execute the code. This involves creating graphs of both control flow (order in which individual statements, instructions, or function calls are executed) and data flow (tracking the path that data takes through the code) which helps to visualize an application’s behavior.
By analyzing these flows, they can pinpoint the exact lines of code that might be vulnerable and assess whether these lines are reachable from external inputs such as user forms or API endpoints. This helps in understanding whether a vulnerability can be triggered from outside the application. For OSS vulnerabilities, Backslash Security not only identifies vulnerabilities in declared and transitive dependencies but also analyzes whether the application’s code actually invokes these vulnerable packages. This means they don’t just report all vulnerabilities present in any package included in the project; they focus on those that are effectively reachable and used by the application.
Backslash Transitive Dependency Analysis
Beyond just scanning for known vulnerabilities in declared OSS packages, Backslash Security analyzes transitive dependencies—packages that are included indirectly by the primary packages. This helps in understanding the actual exposure of an application to vulnerabilities that might not be immediately apparent. Backslash Security also differentiates in how it handles open-source software vulnerabilities. They analyze not just the declared packages but also transitive dependencies – those brought in indirectly by other packages. This allows them to provide a more accurate assessment of which parts of the OSS are actually used and exposed to risks, leading to more precise remediation recommendations. Most of this product capability helps to reduce the number of alerts received by security teams. By determining the reachability of vulnerabilities, Backlash Security helps organizations prioritize which vulnerabilities to address first based on their actual threat level.
They believe in strong prioritization mechanisms and providing security teams with tools that integrate well with their operational workflows. They have a policy-driven visibility and remediation solution that allows security teams to create customized policies that help define the severity of vulnerabilities based on their specific context. This policy-driven approach ensures that only the most relevant issues are highlighted, aligning with the specific security posture and policies of an organization.
Beyond their product capabilities in reachability analysis, they provide the core basics of Static Application Security Testing (SAST) and Code Analysis. The solution connects to application code repositories (like GitHub) with read-only access to analyze the code without the need for deployment. This analysis includes examining the structure and logic of the application to understand its business logic and potential vulnerabilities. The platform is designed to integrate seamlessly into existing development and security workflows without disrupting them, emphasizing the importance of non-intrusive security practices. To learn more about backlash security, please visit here, https://www.backslash.security/
Vendors Tacking The Full SSCS Tool Chain
I will be writing more ASPM later this week and going deeper, but there are a number of vendors with significant product depth and breadth in covering multiple categories of application security. I categorize them into three areas:
Established vendors: These include are Snyk, Checkmarx, Veracode, Fortify, and Mend-io.
Emerging large ASPM vendors: Cycode, Ox Security, Legit Security, Apiiro, Cider (Palo Alto Networks), Jit, Arnica.
There are some up-and-coming vendors, such as malicious dependency companies like Socket and Xygeni. Also, newer companies like Scribe and full 8-in-1 companies like Aikido are gaining traction, but we’ll focus on the first two categories discussed above.
Cycode
Cycode is a vendor that has been recognized by Gartner for their SSCS capabilities. Their solution offers comprehensive capabilities to secure the software supply chain by focusing on automated SDLC discovery with real-time security coverage across your end-to-end environment including: code, components, dependencies, libraries, assets, infrastructure, tools, people, processes, security controls, and more. Its AI-powered Risk Intelligence Graph (RIG), the ‘brain’ behind the platform, provides visibility and traceability across the entire SDLC using natural language. In addition, Cycode allows you to secure your entire CI/CD pipeline through various layers of security (including its eBPF technology), but also protects against secrets in any of your environments from code, cloud, and beyond to ensure complete resiliency of every software release. They provide visibility into an organization’s software supply chain both at an executive level and an operational level. They bring all the discoverability and visibility into all your assets, tooling infra, etc and risk associated.
Aikido Security
Aikido Security is a developer-friendly application security platform for small & medium-sized software engineering teams. It scans your code, containers & cloud in 10 different ways, showing you which security issues and vulnerabilities are actually important to solve. We speed up triaging massively by cutting out the false-positives, and making things human-readable.
They secure a company’s entire technology stack - code, open-source dependencies, infrastructure, and more integrate into an existing workflows to provide visibility and control across your entire application infrastructure. Their goal is to simplify security for developers through features like auto-triage of vulnerabilities, tied to whether the vulnerable code is actually used. This cuts through the noise, enabling engineering teams to focus on what matters most. Cycode and Ox basically do what they do, but have a lot of bells and whistles that enterprises will care more about. But Aikido trumps them in simplicity and price, Ox and Cycode are the kind of tools people can spend all day in, Aikido just does the scan and gets it to the devs. It's a simple workflow that works well.
Ox Security
OX Security's utilizes an approach they call “ACTIVE” Application Security Posture Management (ASPM) which emphasizes CI/CD pipeline security. They pioneered the concept of PBOM (Pipeline Bill of Materials), where a signed knowledge graph, also called PBOM, is created for each pipeline build. This graph acts as a dynamic Bill of Materials (BOM) that documents the software's lineage throughout its development lifecycle. Essentially, it's a continuously updated map that contains all the elements typically included in an SBOM, in addition to a comprehensive record of the infrastructure the software has traversed, such as pipeline branches, builds, pull requests, tickets, and known issues. OX Security's Single Source of Truth and CI/CD workflow automation specifically enhance the traceability and visibility of all components throughout the build and pipeline phases.
In addition to their contributions to software supply chain security, OX Security has also co-developed the Open Software Supply Chain Attack Reference (OSC&R), an open-source framework that helps in understanding and mitigating threats to the software supply chain. Although not covered in-depth, Ox security’ platform has good reachability analysis capabilities with the ability to perform analysis in runtime and at the code level. They combine a range of tools like static analysis, SAST, secrets scans, container scans, and IaC scans, they identify risks or misconfigurations during the build process.
Other Vendors Worth Mentioning
Due to time limitations, there are several vendors not featured in this report, but worth highlighting / giving shoutouts that we’ve heard are doing well. Some of them include Snyk, Legit security, Apiiro, Mend and Rapidfort.
Summary
The software supply chain continues to be an essential category of the larger application security and cybersecurity industry. After researching this space, we’ve realized that SSCS companies are either born to be developer-centric or are not. Besides code hosting and collaboration software providers such as GitHub and Gitlab, companies like GitGuardian and Stacklok have always solved security problems keeping developer’s workflow and non-security experience, yet there are other companies esp ASPMs like Cycode and Ox who may also integrate with developer workflow but are meant to solve enterprise security reporting and management challenges directly rather than those faced by developers. We have noticed a shift towards assisting Cloud/DevOps teams for many security companies, but most vendors in the SSCS space have products primarily catered towards application security teams.
What is Next?
This wraps up my series on software supply chain security. I have some exciting topics that will be published over the upcoming weeks exploring newer categories, like Next-Gen SIEMs / Security Analytics, ASPM, Identity security landscape and SOC automation platforms in cybersecurity.