The Ultimate Guide To Software Supply Chain Security

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.

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.