1 Introduction / Executive Summary
In recent years, several well-known software supply chain attacks have raised significant attention, such as the SolarWinds Supply Chain attack in late 2020 through a compromised SolarWinds' software development process which allowed malicious code to be injected into their Orion platform updates. Shortly after, in 2021, a Codecov Bash Uploader breach occurred when a popular code coverage tool script had been compromised, through which attackers gained unauthorized access to Codecov's infrastructure and modified the Bash Uploader script to collect sensitive environment variables and send them to an external server. This attack potentially exposed credentials and other sensitive data from organizations using Codecov. These and other software supply chain attacks led the U.S. government to issue an Executive Order on Improving the Nation's Cybersecurity by modernizing cybersecurity practices such as taking a zero-trust posture, improving its detection and response to cyber threats, and having the ability to investigate and recover from cyber-attacks. In one of the steps, the Executive Order calls out explicitly the documentation of a Software Bill of Materials (SBOM) for software products. An SBOM creates a machine-readable inventory of the components of a given software product. However, a Software Composition Analysis (SCA) is typically performed before generating an SBOM. An SCA analyzes the software components used in an application or system to identify and track their origins, licenses, and any known vulnerabilities or security issues. It gives insights into understanding the composition of the software and its dependencies. Once the SCA gathers the information about the software components, an SBOM can be generated.
Knowing what a software application or service is composed of is a good first step in ensuring software integrity, especially considering the increased use of third-party software within modern applications. When shifting left in a Software Development Life Cycle (SDLC), ensuring software source integrity should include a range of capabilities to provide the source code's security and authenticity are checked and reduce the risk of unauthorized modifications. This not only includes SCA and SBOM but also code monitoring, code tampering detection & prevention, identifying known Common Vulnerabilities and Exposures (CVEs), and embedded secrets such as passwords in the source code and other software artifacts, as some examples. As such, support for popular code source repositories integrations is also needed.
When testing the security of software applications, software Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) are commonly used but are not the only methods. SAST involves analyzing an application's source code, byte code, or binary code without executing it. It examines the code structure, logic, and patterns to identify potential security vulnerabilities, such as coding errors, insecure configurations, or unsafe coding practices. SAST allows for early detection of vulnerabilities during the development process, provides detailed vulnerability information, and can be integrated into the development environment, allowing developers to receive immediate feedback on security issues. Support for the programming and script languages used within the software should also be considered. DAST involves testing an application in a running state by interacting with its interfaces, such as web forms, APIs, or container services. By testing the application in its actual runtime environment, DAST can detect vulnerabilities dependent on specific runtime conditions, and provide a realistic assessment of an application's security posture.
Within the SDLC is a practice of software Continuous Integration/Continuous Delivery (CI/CD) that involves a set of tools to enable frequent and automated delivery of software changes to production environments. CI/CD pipeline security must also be considered in secure software development. CI/CD pipelines are subject to vulnerabilities that can enable cybercriminals to perform malicious code injection or data exfiltration during the software development lifecycle. These vulnerabilities can emerge from the insecure configuration of CI/CD tools and infrastructure, including code repositories, build servers, and artifact registries. In addition, as part of the CI/CD process, integrations with popular CI/CD tools for build automation, for example, should also be supported.
Overall, the security of the Software Supply Chain should be based on a set of prioritized risks. The ability to detect risks and vulnerabilities, prevent code tampering and leakage, ensure authentication and the principle of least privilege, identify anomalous and suspicious user activity, and governance of access and evaluation rules and APIs, as some examples, should be configurable through security policies.
In this Leadership Compass, the term “Software Supply Chain Security (SSCS)” refers to the ability to secure the software development lifecycle (SDLC) process throughout the development, testing, deployment, and maintenance phases – at every point along the way, including along the whole CI/CD pipeline. This also means having end-to-end visibility, at a granular level, at each phase of the software supply chain process.
Figure 1: End-to-End Software Supply Chain Security
Highlights
- The SSCS market is still evolving to provide end-to-end SSCS capabilities.
- Solutions in today’s SSCS market tend to focus on certain portions of the software supply chain SDLC.
- Source code integrity capabilities are provided by the majority of vendors in this Leadership Compass
- Over half of the SSCS vendors provide good build integrity abilities
- Strong API or container security features are offered by half of the SSCS vendors evaluated
- Leaders in this Leadership Compass cover most of the end-to-end SSCS capabilities of the solutions evaluated
- It is expected that the SSCS market with continue to grow with solutions covering more of the entire SDLC security pipeline
- The Overall Leaders are (in alphabetical order) Aqua Security, Data Theorem, and Veracode
1.1 Market Segment
The SSCS market is still relatively new. Some products cover only point solutions along the Software Supply Chain, such as focusing on static source code analysis to discover code errors or vulnerability scans during the build and test cycles. In contrast, other products provide a more comprehensive range of capabilities to address most, if not all, of the complete end-to-end Software Supply Chain Security solution.
Integration options should include utilizing agents, APIs, SDKs, or CLIs to connect to a wide range of source management and CI/CD tools. Also, a good set of industry standards and technology protocols should also be supported. Because of the depth and breadth of the Software Supply Chain, workflows, automation, orchestration capabilities, and a level of intelligence through AI/ML or analytics should be available to minimize the complexity of the tasks involved.
SSCS solutions that cover the end-to-end SDLC pipeline are continuing to develop. However, KuppingerCole expects to see the SSCS market become more competitive and mature as the threats and attacks on the Software Supply Chain continue to grow.
