Software Supply Chain Security

The software supply chain consists of the people, tools, components, infrastructure, activities, practices, and processes involved with the design, development, testing, deployment, and delivery of software. Software supply chain security is the discipline focused on securing every aspect of the software supply chain, to minimize the risk that accidental or intentional actions may harm an organization, its customers, its employees, or its business partners.

The large and ever-growing number of software supply chain security attacks over the past few years have made it critical for enterprises to invest more resources in securing their software development and deployment processes, from end to end. Modern commercial applications depend heavily on third-party open source software, which has unfortunately become a successful attack vector for lone-wolf, organized, and even state-sponsored bad actors. In addition, APIs, collaboration tools, CI/CD tools, virtualization platforms, and many other commonly used platforms have also proven susceptible to attack.

Software composition analysis (SCA) solutions are designed to reduce open source software (OSS) risk, by discovering all open source libraries used by an application, and determining which ones pose danger. Basic SCA tools simply compare the OSS packages listed in manifest files with publicly available vulnerability databases, whereas more advanced SCA solutions can discover any OSS, including those referenced as dependencies of dependencies (transitive dependency scanning), in binaries (when manifest files are not available), and in private package managers. Advanced solutions can also identify malicious packages, prioritize the most important risks to mitigate first (using techniques, such as exploitable path analysis and runtime data), and provide actionable remediation guidance. Learn more here: Checkmarx SCA.

A software bill of materials (SBOM) is a file, in an industry-standard format, that provides a formal record of the details and supply chain relationships of various components used in building software. SBOMs help organizations keep track of the OSS packages they are using, to help in threat detection and remediation. SBOMs provide software component transparency between an organization and its customers and business partners. Governments have begun mandating the use of SBOMs; for example, the US now requires SBOMs from anyone selling software to the US federal government and its agencies (Executive Order 14028). Learn more here: Checkmarx SBOM.

Secrets are any private or sensitive information that an application needs to function, but that could potentially introduce an attack vector if exposed to unauthorized parties. These include credentials (such as usernames or passwords that can grant a user or system access to resources or services), API keys or tokens (unique identifiers to authorize access to an API or web service), private keys or encryption keys (such as those used to encrypt/decrypt sensitive data or secure communication protocols), and certificates (codes used to establish trust between two entities, such as between a server and a client). Secrets can be exposed in a wide variety of places, including source code, configuration files (e.g., IaC files), CI/CD pipelines, developer productivity tools, collaboration tools, wikis, and generative AI tools. To minimize potential vulnerabilities of the software supply chain, enterprises need to identify, remove, and change any secrets exposed in any non-private location.

Open Supply Chain Information Modeling (OSIM) is a technical committee formed by OASIS Open, the global open source and standards organization, to standardize and promote information models crucial to software supply chain security. OSIM is an information model and unifying framework that sits on top of existing SBOM data models. Its goal is to bring clarity to software supply chain partners, mitigate vulnerabilities and disruptions, and reduce security risks. Checkmarx is a member of the OSIM technical committee, alongside other industry leaders, such as Cisco, Google, IBM, Microsoft, and SAP, and the US government’s Cybersecurity and Infrastructure Security Agency (CISA).

Supply-chain Levels for Software Artifacts (SLSA), pronounced “salsa”, is a cross-industry collaboration focused on improving software supply chain security, through standards and guidelines to be used by both software producers and consumers. SLSA is organized into a series of levels that describe increasing security guarantees, including tamper-resistant evidence for securing each step of the software production process, to prevent three classes of supply chain threats: source threats (e.g., unauthorized change, compromised source repo), dependency threats (e.g., compromised build or runtime dependency), and build threats (e.g., compromise build process, compromised package registry).

Software supply chain security requires a comprehensive set of tools that can provide visibility, risk detection, and proactive risk mitigation regarding all points of vulnerability in the software supply chain. The most common ones include:

• SBOM (Software Bill of Materials) which inventories all third-party components, including open source
• SCA (Software Composition Analysis) which identifies vulnerabilities in open-source dependencies and guides remediation
• Malicious Package Protection which detects and helps remediate dangerous and suspicious third-party packages
• Container Security, which detects vulnerabilities and malicious code in container images and layers
• GenAI Code scanning, which validates the safety of AI-generated code and referenced open-source libraries
• Secrets Detection, which discovers the presence of sensitive credentials to prevent the dangers of accidental exposure

It is recommended to choose tools that are integrated within a single platform, to improve triage and risk management, and with developer and CI/CD workflows, to increase efficiency and build DevSec trust.

Common software supply chain attack vectors include malicious code injected into open-source libraries (via means such as dependency confusion, typosquatting, and repojacking), breached developer accounts and source code repositories, compromised CI/CD processes, and system penetration through the exploitation of exposed credentials.

1. Start with creating an SBOM, an inventory of all components in use, including their versions, licensing terms, etc. It is recommended to automate the process, to ensure it is always up to date.
2. Use SCA to regularly analyze all third-party code in use, including its dependencies and dependencies of dependencies, for vulnerabilities and malicious packages.
3. Detect secrets, such as hard-coded passwords, in source code and supply chain components.
4. Secure code repositories and CI/CD processes.
5. Scan container images and image layers to identify malicious code and exploitable vulnerabilities.
6. Utilize an ASPM solution that incorporates all these capabilities into a complete AppSec security platform, ensuring holistic protection across the entire application lifecycle.

One of the biggest threats to software supply chain security is the widespread reliance on open-source software, where vulnerabilities can propagate across thousands of applications. Attackers exploit the lack of visibility into transitive dependencies, leading to severe impacts when a popular library is compromised. 

The speed of software delivery in modern DevOps environments increases risk, as security controls may be overlooked in favor of rapid releases. To overcome this risk, enterprises can implement solutions like SCA, Malicious Package Detection, Container Security, and Secrets Detection to implement security protocols that protect applications without compromising developer speed or productivity.