• What is the Software Supply Chain?
• What is Software Supply Chain Security?
• Key Components of SSCS
• What are Software Supply Chain Attack Threats?
• What is Supply-chain Levels for Software Artifacts, or SLSA?
• What is Software Bill of Materials (SBOM)
• The Checkmarx Approach to Software Supply Chain Security 
• Conclusion

More on Supply Chain Security

• Addressing Open Source Security Risks With Software Composition Analysis

The proliferation of attacks on third-party software suppliers, open source packages and developer devices is putting organizations at risk of stealthy and highly persistent attacks. Fixing software supply chain vulnerabilities or securing the final software application is no longer sufficient for securing business operations.

Instead, the software supply chain is becoming a strategic point of entry to the organizational codebase. Security leaders and professionals need to prioritize software supply chain security (SSCS) and find a way to secure their development processes and environments, while still allowing developers to code without barriers.

Doable? Yes. Easy? With the right tools. How to get started? Good thing you asked.

This guide provides non-developers with the information they need to understand how development processes and software development components can be exploited and targeted by attackers.

 The guide starts with the basics of what is the software supply chain and its related security practices. Then, it covers which developer components can be attacked and how and explains what SBOM and SLSA are and how they can help. Finally, it shows how to choose a security solution for SSCS, helping you build your SSCS strategy.

Read and discover the best ways to speak with developers about security practices, while empowering and encouraging them to use the right security tools to protect their lives’ work – the codebase.

What is the Software Supply Chain?

The software supply chain is the components, processes, libraries and tools used by the enterprise to develop, build, deploy and maintain software artifacts. This includes open-source components, commercial components, development platforms, distribution networks and more.

The inventory of these components is called an SBOM (Software Bill of Materials). SBOMs can help the enterprise manage and track their supply chain and reduce the usage of malicious components to reduce software supply chain risk (see more about the SBOM below).

What is Software Supply Chain Security?

Software supply chain attacks are cyberattacks that target vulnerable and exploitable elements in an enterprise’s supply chain. In recent years, there have been a number of high-profile cyber attacks on the supply chain. Namely, SolarWinds, which exposed the vulnerability of third-party software, and Log4 Shell, which highlighted the risks of open-source packages.

What’s the risk in the supply chain? Supply chain components can introduce vulnerabilities or malicious code, resulting in data breaches and attacks. Attackers are also aware of this gateway and are developing diverse tactics and deceptive maneuvers to infiltrate systems, like weaponizing popular OSS (open-source) packages.

Pro tip: Don’t confuse vulnerable and malicious packages! Vulnerabilities in packages are just developer mistakes that make the software exploitable. They aren’t intended to be malicious. Conversely, malicious packages contain intentionally added malicious code to cause harm.

Software supply chain security refers to the security practices and strategies employed to ensure the integrity, security and reliability of the software development and deployment process.

This includes:

• Securing code repositories
• Ensuring the integrity of third-party libraries and dependencies, including open-source
• Protecting code integration and delivery processes against unauthorized changes or tampering

Given the increasing reliance on open-source components and third-party services (78% of companies use open source software) in today’s software-driven world, CISOs and Heads of AppSec teams are realizing the importance of the software supply chain security. Therefore, they are increasingly driving the implementation of secure engineering practices, investing in training and including SSCS platforms in their security stack.

Read more about software supply chain security and why CISOs and AppSec should care.

• What makes the software supply chain so vulnerable? Software development is a complex process that relies on multiple, interdependent processes and components. Here are examples of components that can introduce vulnerabilities or malicious code:
• Dependencies – External libraries of code that are reused by developers in the enterprise’s codebase to accelerate the development process. These libraries contain “packages” of source code, which developers implement internally. 
• Package managers – Software tools that are used to manage dependencies and save developers’ time. They can help with downloading, installing, removing and publishing dependencies, among other actions. Common package managers include npm for Javascript, pip for Python, composer for PHP, Maven and Gradle for Java and NuGet for C#.

• Package repositories (registries) – The servers that store the dependency code and metadata for developers to implement. Package repositories can be either public or private. Anyone, including attackers, can sign up to a public registry and publish a package.
• Client CLI – A developer tool used to obtain the list of packages from a package repository, download packages, install them and manage dependencies locally. CLIs are the most straightforward way to perform these activities.

What are Software Supply Chain Attack Threats?

Software supply chain threats are cyber threats that aim to disrupt business operations by compromising the enterprise’s software development and distribution process.

Instead of directly attacking the final software product, attackers target the tools, libraries and services that are part of the software’s supply chain.

This can include compromising public code repositories, injecting malicious code into third-party libraries, or attacking the update mechanism of software to distribute malware.

The goal of software supply chain attacks is to exploit trust relationships within the supply chain to gain unauthorized access, steal data, or cause damage and confusion.

The attacker’s advantage when attacking these upstream components is the ability to gain broad impact, while leveraging weaker security practices and tools in the supply chain and bypassing advanced security defenses implemented on the final software product.

These attacks are also often more difficult to detect. This offers attackers a strategic advantage.

But SSC attacks are not necessarily easy to execute. Supply chain attacks are considered to be complex types of attacks. They are often Advanced Persistent Threats (APT) types. This means these attacks are carried out by stealthy, highly motivated, and even nation-state or state-sponsored threat actors, who stay in the network for a long period of time. This makes these attacks all the more risky, which requires appropriate attention and resources, like supply chain security software, in the enterprise security stack and during software supply chain management.

Examples of attacks include:

1. Malicious Code in the Enterprise Source Repository 

The submission of malicious or harmful source code into a project’s code repository. This can lead to a range of negative outcomes for the business. Attack vectors include:

• Developer’s Laptop Compromise – The attacker gains unauthorized access to a developer’s laptop. The compromise could occur through malware, phishing, or exploiting vulnerabilities in the laptop’s software. Once the attacker has control, they can modify the code directly on the developer’s machine or use the developer’s credentials to submit malicious code to the organizational repository.
• SCM Platform’s Developer Account or API Token Compromise – Software Configuration Management (SCM) platforms are used to make changes to documents, programs and other information that is part of the development process. Attackers targeting developer accounts or API tokens can gain unauthorized access to these platforms. By compromising an account or token, an attacker can impersonate a legitimate developer, bypass security measures that rely on authentication and authorization, and submit malicious code.
• Compromised Communication Channel – If an attacker can intercept or manipulate the communication channel between the developer’s environment and the SCM platform, they can inject malicious code into the repository or alter the code that is being submitted. This can be achieved through man-in-the-middle (MITM) attacks, network eavesdropping, or exploiting weaknesses in encryption protocols.

2. A Compromised Source Control Platform 

SCM platforms, such as Git, SVN, or Mercurial, serve as the backbone for version control and collaboration in software projects. They enable developers to manage changes to source code over time, track revisions and collaborate on code development. When such a platform is compromised, it poses a severe risk to the integrity, security, and operation of the software being developed.

An attacker compromising an SCM platform can do so through various methods. This includes  exploiting vulnerabilities within the platform itself, social engineering attacks aimed at obtaining credentials from legitimate users, or through a broader network compromise that provides access to the SCM system.

The impact of such a compromise could include the introduction of malware, codebase tampering and intellectual property theft. An example is hacking PHP’s internal SCM server.  

3. Building from Code that Doesn’t Match Source Control

This threat involves the manipulation of CI/CD processes to produce artifacts that appear to be legitimate, but are actually crafted from altered code bases. The goal is to achieve alteration of source code, injection of vulnerabilities, or deployment of malware. This sort of attack leverages the inherent trust placed in automated build and deployment pipelines and their artifacts.

Attack vectors for this type of threat are sophisticated. They include tampering with build metadata to redirect the build process towards a different SCM platform containing the malicious code or compromising the communication channel between the SCM platform and the build platform.

4. Compromised Build Platforms

In the build stage, raw source code is transformed into executable artifacts ready for deployment. This step takes place across all programming languages. These include compiled languages like C/C++, Java, and Golang, which require conversion into machine code, and interpreted languages such as Python and JavaScript, where code is executed directly but may still be packaged for distribution.

If an adversary gains access to the build platform, they can insert malicious code into the software itself. This intrusion can occur before the compilation process for compiled languages or during the packaging phase for interpreted languages. 

The threat is significantly amplified in the context of compiled languages, because detecting unauthorized alterations post-compilation is exceedingly challenging. It often requires reverse engineering the resulting artifact, which is both time-consuming and requires a high degree of expertise. This complexity makes it difficult for developers and security professionals to identify and rectify the compromised code.

5. Compromised Dependencies

As mentioned above, software relies on external libraries and frameworks, each of which may also depend on additional packages. This layered dependency structure enables developers to build complex, feature-rich applications efficiently so the enterprise can maintain a competitive advantage. However, this interconnectivity also significantly expands the attack surface.

Compromising this dependency chain with malicious code can compromise the developer consuming the library, and also any downstream projects that transitively include the compromised component.

6. Compromised Packages and Package Repositories

Upon completion of the build process, artifacts are stored in repositories for future use by developers, automated build platforms and other stakeholders.

Attackers can take advantage of this distribution stage to introduce malicious code into the software ecosystem. For example, they can upload a malicious package directly to a repository, compromise an existing package within the repository, replace legitimate packages with malicious ones, or split malware across multiple packages to make each individual package seem less suspicious.

Once a malicious artifact is successfully uploaded, any downstream system or user that retrieves and uses this package becomes a potential victim, executing compromised code. This method of attack not only undermines the security of individual projects and the software supply chain as a whole.

These repositories vary in their architecture, ranging from cloud-based object storage solutions like Amazon S3 buckets to traditional file systems. This diversity in storage solutions and the underlying software supply chain architecture introduces variability in supply chain security security practices and potential attack surfaces, making them challenging to protect.

7. Tricking Developers into Using Compromised Packages

This method exploits the interaction between developers and the package managers they rely on. Attackers deploy various tactics, like social engineering or flaws in dependency management processes, to run the attacker’s code on the victim’s machine. This allows them to effectively bypass the security measures that might catch a malicious package upon execution of its functions.

Example attacks include:

• Typosquatting – Attackers create packages that closely resemble legitimate, well-known domains. They do so by exploiting typographical errors made by internet users, in an attempt to deceive them into visiting malicious websites or downloading harmful software.

There are many strategies for generating typo permutations. For example:  

• Adding or removing dash or dot. webrequests becomes web-requests. Users may not remember the correct name and may use it with or without the dash/dot. 
• Replacing a letter of the package name with letters to the immediate left and right on the keyboard. 
• Changing the order of letters. 
• And many more 

This type of attack is not aimed at a specific victim or group of victims. Anybody can make typos while installing a library. Therefore, it’s used by attackers whose aim is spreading widely to get data or add bots to a botnet. 

• StarJacking – Attackers gain control over a popular software project’s repository (often on platforms like GitHub), usually by tricking the original maintainers into transferring ownership or by exploiting security vulnerabilities. Once in control, they can alter the project’s code to include malicious elements, potentially compromising any software that depends on the project. This method leverages the trust placed in the project’s popularity and its “star” rating, hence the term “star jacking.”

Just like typosquatting, starjacking is aimed at a wide target, because anybody can choose a malicious library.

• RepoJacking – The malicious takeover of a software repository, but with a specific focus on exploiting abandoned or less actively maintained repositories. Attackers target these repositories because they often still have users or projects that depend on them, making them valuable for inserting malicious code. Once an attacker gains control, either by assuming maintenance of the neglected repository or by exploiting security weaknesses, they can introduce harmful changes or dependencies.

Similar but not the exactly same is digital grave robbing, which is when attackers take over neglected digital assets, revive them and inject malicious code.

• Dependency Confusion –  Exploitation of the way package managers prioritize package sources. In this attack, an adversary creates a malicious package with the same name as an internal package used within a company’s private repository. But, they upload it to a public package repository with a higher version number. When developers build their software, the package manager might fetch the malicious, higher-versioned package from the public repository instead of the intended internal package. This allows the attacker’s code to be executed within the victim’s system or software build process, leading to potential data breaches or further exploitation.

Read more about SSCS threats and what you can do about them here.

What is Supply-chain Levels for Software Artifacts, or SLSA (“salsa”)?

What is SLSA?

Supply-chain Levels for Software Artifacts, or SLSA (“salsa”), is a popular security framework designed to ensure the integrity of software artifacts throughout the software supply chain. It is a scalable and incrementally adoptable methodology for ensuring that software artifacts are securely developed, built and distributed.

The SLSA framework helps AppSec teams gain visibility into application components. It also provides them with an analysis of which components are at risk, how to remediate them and ongoing monitoring capabilities to identify emerging threats.

SLSA focuses on 3 key areas:

1. Build integrity of the developed software
2. Source code integrity
3. Dependency integrity 

SLSA Levels of Assurance

SLSA is structured around a series of levels, each representing an increasing degree of security control and assurance:

• SLSA Level 1 – This initial level focuses on basic integrity guarantees. It requires automated building of artifacts and the generation of provenance (a record of the origin and history of an artifact). The goal is to ensure that artifacts are not tampered with manually and that their history is traceable.
• SLSA Level 2 – Level 2 adds an emphasis on version control and protected build environments to the requirements, ensuring that the source and build platforms are secure against unauthorized access. This level starts to address the risk of source or build process tampering.
• SLSA Level 3 – Level 3 introduces requirements for more comprehensive security controls, including stricter provenance, reproducible builds (ensuring that builds can be independently verified), and enforced review processes for changes. This level aims to significantly reduce the risk of malicious code insertion by increasing the transparency and auditability of the software development and deployment process.
• SLSA Level 4 – The highest level demands the most rigorous controls, including two-person reviewed contributions, hermetic builds (fully self-contained builds that are not influenced by external states) and advanced security measures for the build process. This level is designed to protect against the most sophisticated threats, ensuring the highest degree of trustworthiness in software artifacts.

Read more about spicing up your software supply chain security strategy with salsa (SLSA) here.

What is Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) is an exhaustive inventory or list that details all the components, libraries and modules contained within a piece of software, along with their corresponding versions and licensing information.

The primary purpose of an SBOM is to enhance visibility into the software supply chain. It enables users, developers and organizations to quickly assess risks for software supply chain risk management, manage vulnerabilities, comply with licensing requirements and secure their software environments. By knowing exactly what components a software includes, stakeholders can more effectively identify if they are affected by newly discovered vulnerabilities in third-party components, making it easier to respond to potential or existing security threats.

In addition, SBOMs can assist with due diligence, migrations, product research, vulnerability scanning, VEX documents, license tracking, complying with US government regulations, enabling SLSA level 4 and more SBOM example use cases.

SBOMs are usually automatically produced by supply chain security software. They use a standardized structure, such as CycloneDX, SPDX, or SWID. There is not yet a single definitive standard for SBOM formats. However, NTIA (National Telecommunications and Information Administration) defined the minimal requirements to include:

• Who created the artifact
• SBOM creation tool
• SBOM generation timestamp
• Component name
• Component version
• A unique identifier ( CPE / PURL / SWID, etc.). 
• Relationship with other components

The SBOM could also contain information like licensing, repository information, description, owner, and more.

NIST also defines the required practices for maintaining SBOMs. These include:

• Updating after any product change
• Containing all product dependencies, direct and indirect
• Detailing if missing information is unavailable or unknown
• Accessible by humans and machines
• Implementing access control

One of the most effective ways to ensure the SBOM remains up-to-date is to integrate it into CI/CD workflows. This ensures every application release is accompanied by an accurate inventory of its supply chain for SBOM management, while also saving time and increasing the organizations’ security posture.

President Biden’s Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity, issued May 2021, orders the implementation of initiatives to secure the software supply chain. One of these is the mandatory inclusion of the SBOM by all organizations supplying software to the US government. It is expected that this directive will have a snowball effect, leading to similar requirements by other governments and the private sector for SBOM security.

Read more about SBOM best practices for the enterprise here.

The Checkmarx Approach to Software Supply Chain Security 

Checkmarx provides organizations with confidence and assurance that they are strongly protected against software supply chain threats, including open-source software for open source supply chain security, commercial components, and more. Going beyond the SBOM, Checkmarx’s SSCS solution couples development process components with the development environment and understands them, as part of the SLSA framework. This unique approach provides true visibility and helps close the gap to SLSA compliance.

Key capabilities include:

Secrets Detection  to Prevent Data Leakage 

Secret Detection removes hard-coded passwords from the software supply chain and protects the enterprise from exfiltration of this confidential data. By evaluating developer communication, shared tools and components used across the supply chain, Secret Detection safeguards this attack vector, protecting your organization.

Secret Detection supports Confluence, Slack and Discord integrations and allows for customizing rules and policies.

Automated SBOM for Streamlined Accountability

Checkmarx allows AppSec teams to automatically generate SBOMs directly from the UI, in SPDX and CycloneDX formats. This saves teams time and overhead, ensuring they always have an up-to-date inventory of third-party packages being used within the organizational software supply chain.  

Historical SBOMs can also be created, based on Checkmarx’s historical record of performed scans. This is a cost-effective approach that helps meet compliance and incident response needs.

Checkmarx supports a wide array of languages and package managers, meaning there’s no need to implement, maintain or update multiple SBOM solutions per project or per language. 

Scorecard Engine for Security-driven Prioritization

Scorecard Engine enables enterprises to easily see the most vulnerable or at-risk projects, so they can prioritize which ones to tackle first. The “security score” is auto-generated based on checks that cover the source code, build, and dependencies. Example checks include:

• Binary Artifacts – Is the project free of checked-in binaries?  
• Branch Protection – Does the project use branch protection?  
• CI (Continuous Integration) Tests – Does the project run tests in CI, e.g., GitHub Actions, Prow?  
• Code Review – Does the project practice code review before code is merged?  
• Dangerous Workflows – Does the project avoid dangerous coding patterns?  
• Vulnerabilities – Does the project have unfixed vulnerabilities?  

Threat Intelligence for Automated Malware Detection 

The Checkmarx research team has inspected over 8 million open-source packages for various threats. The results: 200,000+ malicious packages identified. This threat intelligence is available to Checkmarx users through the UI, directly in developers’ IDE, or through an API-based threat intelligence feed. 

Containerized Application Security

The Checkmarx Container Security Solution identifies, prioritizes, and addresses security flaws across the SDLC to preempt issues in production workloads. This includes:

• Container Image Scanning – Scanning static container images to identify vulnerable code in open-source software and remediating issues before they are deployed. 

• Runtime Insights Correlation – Correlating pre-production and runtime data to identify exploitable vulnerabilities in running container images, reducing noise by up to 95%, and prioritizing remediation efforts.

Software supply chain attacks have become widespread, and supply chain security problems can have a significant negative impact on the organization’s codebase and operations. Since modern organizations rely on external components to develop faster and remain competitively relevant, security leaders and professionals need to invest resources in securing the supply chain with software supply chain security toolsf, incorporate SLSA principles, ensure they have an SBOM and engage with developers on security practices.

This guide has shown how multifaceted SSCS is, ranging from dependencies and package managers to compromised build platforms and malicious code injections. CISOs and Heads of AppSec can use it to build a robust strategy for managing SSCS. In addition, they can use it to improve communication with engineering teams, and use technical language and understanding to advocate for the implementation of security practices.

By leveraging the insights and strategies in this guide, organizations can strengthen their own defenses against supply chain attacks and cultivate a more secure, resilient software ecosystem. With the right tools, practices and efforts we can protect the very foundation of our digital world.

For further reading, check out these software supply chain reports:

White Paper

Don’t Take Code From Strangers: An Introduction to Checkmarx Supply Chain Security

https://checkmarx.com/resources/whitepapers/whitepapers-sca-scs-don-t-take-code-from-strangers-v3-190123/? 

White Paper

Software Supply Chain Security: Why You Should Care

https://checkmarx.com/resources/whitepapers/software-supply-chain-security-why-you-should-care/? 

Solution brief: 

Optimize AppSec With a Holistic View of Vulnerabilities and Risks

https://checkmarx.com/resources/data-sheet/solution-brief-fusion-checkmarx-correlation-engine/? 

Solution Brief

Supply Chain Security

https://checkmarx.com/resources/data-sheet/solution-brief-scs-checkmarx-supply-chain-security/? 

Report:

ESG Research: Comprehensive Open Source Supply Chain Security

https://checkmarx.com/resources/reports/comprehensive-open-source-supply-chain-security-going-beyond-sca-and-sboms/? 

E-Book:

Dropping the SBOM: Why the Industry Must Unite to Defend Against Software Supply Chain Cybercrime

https://checkmarx.com/resources/ebooks/whitepaper-dropping-the-sbom-v2-190123/?