Ultimate Guide to Software Supply Chain Security in 2025

What Is Software Supply Chain Security? 

Software supply chain security refers to protecting the processes, systems, and components involved in delivering software from development to its end users. This includes all stages of the software development lifecycle (SDLC), from coding and integrating third-party dependencies to building, deploying, and distributing the software. The objective is to prevent malicious actors from compromising the integrity, confidentiality, or availability of software and its supporting infrastructure.

The growing adoption of open-source software, external libraries, and cloud-based services has increased software supply chain complexity. This interconnectivity makes every linked component a potential attack vector. By ensuring security controls across these stages, organizations can minimize risks and maintain trust in their software delivery processes.

Why Software Supply Chain Security Is Critical

Software supply chain security is crucial due to the increasing complexity and interconnectivity of modern software development. Organizations rely heavily on open-source components, third-party services, and automated build systems, each introducing potential vulnerabilities:

1. Widespread impact of compromises: A single breach in the supply chain can ripple across hundreds or thousands of downstream users. Because compromised components are often integrated and redistributed through automated build systems or package managers, a single point of failure can infect entire software ecosystems. This amplification effect increases the potential damage of any vulnerability, turning a targeted attack into a large-scale incident.

2. Exploitation of trusted components: Attackers often target trusted components within the software supply chain. By compromising widely used libraries or tools, they can insert malicious code that propagates to numerous downstream applications. 

3. Regulatory and compliance pressures: Governments and regulatory bodies are imposing stricter cybersecurity mandates. For example, the U.S. Executive Order on Improving the Nation’s Cybersecurity emphasizes the need for secure software development practices. Non-compliance can result in legal penalties and loss of business opportunities.

4. Operational disruptions and financial losses: Supply chain attacks can halt critical development workflows, delay product releases, and disrupt business operations. Cleanup efforts often involve identifying affected systems, revoking compromised credentials, and rebuilding software artifacts—processes that consume engineering time and resources. Additionally, breach disclosures and customer impact can damage reputation and result in contract losses, fines, and increased insurance costs.

5. Need for proactive risk management: Given the evolving threat landscape, organizations must adopt proactive risk management strategies. This includes implementing security measures across all stages of the software development lifecycle, from code inception to deployment, to mitigate potential vulnerabilities and ensure the integrity of software products.

Core Components of the Software Supply Chain 

Here are the primary components of modern software supply chains and their security considerations.

1. Source Code Repositories

Source code repositories, such as GitHub, GitLab, or Bitbucket, are central hubs where development teams store, manage, and collaborate on code. They serve as the primary input to the software build process and often integrate tightly with testing and deployment tools.

Protecting these repositories is essential, as they contain the logic and configurations that define software behavior. Common risks include unauthorized access, accidental code exposure, and injection of malicious changes. Organizations should enforce access controls, use multi-factor authentication, and audit activity logs to detect and respond to threats. Incorporating signed commits and branch protection rules also helps maintain code integrity.

2. Build Systems and CI/CD Pipelines

Build systems and CI/CD pipelines automate the transformation of source code into deployable artifacts. They include compilers, test frameworks, artifact repositories, and deployment scripts. These tools ensure consistency across environments and speed up software delivery. However, their automation makes them attractive targets for attackers seeking to introduce malicious code during the build or deployment phase. 

A compromised build environment can result in every downstream artifact being infected. To mitigate these risks, organizations should isolate build environments, use reproducible builds, and digitally sign output artifacts. Monitoring pipeline behavior and applying least-privilege access policies are also critical to securing the build process.

3. Third-Party Libraries and Dependencies

Modern software relies heavily on third-party libraries and open-source components to reduce development time and leverage community innovations. These dependencies, managed via package managers like npm, PyPI, Maven, or Go Modules, are often integrated directly into the codebase.

Because these packages can be updated frequently and pulled from external sources, they pose a significant supply chain risk. Attackers can exploit abandoned or poorly maintained packages or publish malicious versions to compromise software at scale. Developers should use software composition analysis (SCA) tools to identify vulnerabilities, monitor for updates, and enforce policies around dependency usage. Dependency pinning and sourcing from vetted registries also reduce exposure to malicious updates.

4. Software Distribution Channels

Software distribution channels deliver the final product to end users, typically through app stores, container registries, public repositories, or over-the-air (OTA) updates. These channels represent the final link in the supply chain, making them a critical control point for ensuring software authenticity and integrity.

If attackers compromise distribution mechanisms, they can substitute or alter legitimate software with malicious versions. To prevent this, organizations must implement strong integrity checks, such as signing artifacts and validating hashes before installation. Secure delivery protocols (e.g., HTTPS, TLS), controlled release processes, and tamper-proof distribution systems help maintain trust and prevent tampering during delivery.

Examples of Software Supply Chain Attacks

3CX Supply Chain Attack

In 2023, the 3CX desktop app—used for voice-over-IP (VoIP) communications—was compromised through a supply chain attack. Threat actors infiltrated the software’s build environment and inserted a malicious DLL into the Windows installer. The tampered software was signed and distributed as a legitimate update.

Customers downloaded the infected software, which later activated a second-stage payload to conduct surveillance. This attack revealed the risks of trusting signed software alone and highlighted the need for runtime behavior analysis and build environment hardening to detect such compromises.

MOVEit Transfer Exploitation

In mid-2023, threat actors exploited a zero-day vulnerability in MOVEit Transfer, a file transfer solution used by enterprises and government agencies. The vulnerability allowed unauthorized access and data exfiltration, and was weaponized by the Clop ransomware group to steal sensitive files from numerous organizations.

The campaign affected financial institutions, government contractors, and public-sector agencies. This case showed how vulnerabilities in secure file transfer systems—critical parts of many enterprise workflows—can serve as potent supply chain attack vectors.

Log4Shell

Log4Shell, disclosed in December 2021, was a critical remote code execution vulnerability in Log4j, a ubiquitous Java logging library. The flaw (CVE-2021-44228) allowed attackers to execute arbitrary code by injecting crafted input into application logs, which Log4j would then parse and evaluate.

Because Log4j is embedded in countless software products and services, the vulnerability created a massive, systemic risk. Attackers rapidly began exploiting it to gain control of servers, plant malware, and steal data. The incident illustrated the scale of risk posed by vulnerabilities in deeply entrenched open-source components.

Kaseya VSA Attack

In July 2021, attackers exploited zero-day vulnerabilities in Kaseya VSA, a remote monitoring and management platform, to distribute ransomware via a trusted software update mechanism. The REvil group used the compromised platform to deploy ransomware to managed service providers (MSPs) and their downstream customers.

Although fewer than 60 direct customers were affected, the cascading impact reached up to 1,500 organizations globally. The attack showcased how compromising administrative software used by MSPs can amplify the scope and impact of a single supply chain breach.

Codecov Bash Uploader Breach

In early 2021, attackers compromised Codecov’s Bash Uploader script—a tool used to upload code coverage reports. They modified the script to exfiltrate environment variables, including sensitive credentials and tokens, from CI environments of Codecov users.

The malicious version was distributed through Codecov's CDN for several months before detection. Because the script was integrated into automated pipelines, the breach silently affected numerous organizations. This incident emphasized the risks of integrating external scripts in build pipelines and the importance of monitoring third-party tool integrity.

SolarWinds Orion Compromise

The SolarWinds attack, discovered in December 2020, was one of the most sophisticated and far-reaching software supply chain breaches. Threat actors inserted a backdoor (SUNBURST) into Orion, SolarWinds’ widely deployed network monitoring software. This malicious code was embedded during the build process and distributed via official software updates.

The compromised software was installed by over 18,000 customers, including U.S. government agencies and Fortune 500 companies. The attackers used the backdoor to conduct espionage, moving laterally within networks to exfiltrate data. This attack demonstrated how compromising a single vendor’s build pipeline can impact thousands of downstream targets.

NotPetya

NotPetya was a destructive cyberattack in 2017 that originated as a supply chain compromise of Ukrainian tax software called MeDoc. Attackers gained access to MeDoc's update servers and pushed a malicious software update to users. The malware, disguised as ransomware, rapidly spread across networks, encrypting systems and rendering them unusable.

Though it appeared financially motivated, NotPetya was a wiper designed to cause widespread disruption. It affected multinational corporations, ports, and public infrastructure, causing billions of dollars in damages. The incident demonstrated the devastating potential of software updates as a vector for wide-scale cyberattacks.

Apache Struts Vulnerability

In 2017, a vulnerability in Apache Struts—a popular Java web application framework—was exploited to compromise Equifax, one of the largest credit reporting agencies. Attackers used an unpatched remote code execution flaw (CVE-2017-5638) to gain unauthorized access to Equifax’s systems, exfiltrating sensitive personal data of over 147 million individuals.

This breach highlighted the risks of failing to manage third-party dependencies and the critical importance of timely vulnerability patching. It also underscored the broader risks posed by exploitable flaws in widely used open-source components.

Common Threats to the Software Supply Chain

Injection of Malicious Code into Dependencies

Attackers often introduce malicious code into third-party libraries or packages that developers incorporate into their software. Once integrated, the malware spreads further to systems using the affected software. This type of attack capitalizes on trust in widely used dependencies while exploiting their distribution reach.

In some cases, attackers gain control of a legitimate package—often through expired domains, abandoned projects, or compromised maintainer accounts—and then insert malicious functionality. For example, malware might steal credentials, exfiltrate data, or open reverse shells when the package is installed. 

Compromise of Build Tools or CI/CD Pipelines

Continuous integration/continuous deployment (CI/CD) pipelines and build tools are attractive targets for attackers seeking to manipulate final software. If compromised, they can inject malicious components during the build process, making the end product vulnerable or weaponized.

Attackers have exploited insecure build agents, misconfigured environment variables, and shared secrets to gain unauthorized access to CI infrastructure. In some documented cases, malicious scripts were injected into builds that were then signed and published as legitimate software. This compromise bypasses standard verification steps and taints trusted outputs.

Unauthorized Access to Source Code Repositories

Unauthorized access to code repositories allows attackers to steal intellectual property, alter source code, or insert backdoors. A successful breach can have long-term impacts, such as jeopardizing software integrity or exposing sensitive data embedded in the code.

There have been incidents where attackers gained access to repositories via exposed credentials in public repos or misconfigured permissions. Once inside, they’ve injected subtle changes or altered build scripts to include malware. Without strict access controls and continuous monitoring, unauthorized changes may go unnoticed until the software is deployed.

Distribution of Tampered Packages Through Package Managers

Compromised packages uploaded to popular repositories like npm or PyPI can propagate malicious software to thousands of applications. Unsuspecting users often download these packages, unknowingly installing backdoors or harmful scripts.

Malicious actors have published lookalike packages or hijacked dormant ones, embedding harmful scripts that execute during installation. These tampered packages often include post-install hooks or obfuscated code that performs unwanted actions. Developers who install these packages unknowingly introduce backdoors into their applications.

Insider Threats and Credential Theft

Internal employees or compromised user accounts can pose significant risks to the software supply chain. Insiders with access to sensitive systems can intentionally or unintentionally enable attacks by exposing credentials or tampering with components.

Stolen developer credentials or disgruntled insiders can modify code, exfiltrate sensitive information, or disable security controls. For example, attackers have used access tokens harvested from public CI logs or misconfigured containers to alter private repositories. Because these actions may originate from seemingly legitimate accounts, detection is more difficult without behavioral monitoring and strict privilege separation.

{{expert-tip}}

Anatomy of a Software Supply Chain Attack 

A typical software supply chain attack unfolds in multiple stages, targeting weak links in the software development and delivery lifecycle. Below is a breakdown of the attack progression:

1. Reconnaissance and target selection

The attacker begins by identifying high-value targets, often focusing on widely used open-source projects, CI/CD systems, or package registries. Public repositories and metadata about dependencies offer valuable information on potential entry points.

2. Initial compromise

Attackers exploit vulnerabilities in the supply chain. This might involve compromising a developer’s account, injecting code into a third-party package, or gaining unauthorized access to the CI/CD pipeline. Phishing, credential stuffing, or exploiting known CVEs are common methods at this stage.

3. Payload insertion

Once access is secured, the attacker inserts a malicious payload—often obfuscated or disguised to bypass detection—into the targeted component. In open-source attacks, this could mean committing code to a repository or publishing a tampered version of a legitimate package.

4. Propagation

The compromised component is distributed through legitimate channels such as package managers or CI/CD pipelines. Developers or systems integrating the affected software unknowingly propagate the attack further, embedding malicious code across downstream applications.

5. Execution and impact

The payload activates once deployed in target environments, enabling data exfiltration, privilege escalation, or remote access. Because the malicious code is embedded deep in the supply chain, detection is delayed, increasing the attacker’s dwell time and impact.

6. Persistence and evasion

To maintain access and avoid detection, attackers may use techniques like backdoors, code obfuscation, or triggering payloads conditionally. Some campaigns aim to persist across software updates or avoid triggering static analysis tools.

Tools and Technologies for Supply Chain Protection

There are several types of tools that organizations can use to secure their software supply chains.

1. Software Composition Analysis (SCA)

Software composition analysis tools scan applications to identify open-source components and third-party libraries. These tools map all dependencies, flag known vulnerabilities, and help ensure license compliance. SCA is essential for visibility into software components, enabling teams to detect risks early in development.

Leading SCA tools integrate with CI/CD pipelines to automate vulnerability detection and alert developers before affected packages enter production. Many also offer remediation advice or automated patching. By continuously monitoring dependencies, SCA supports proactive risk management and reduces exposure to supply chain threats.

2. Software Bill of Materials (SBOM)

A software bill of materials (SBOM) is a formal, machine-readable inventory of all components in a software product, including libraries, packages, and metadata. SBOMs provide transparency into what’s in a software package, making it easier to identify risks and respond to vulnerabilities.

SBOMs enable faster incident response when zero-day vulnerabilities like Log4Shell emerge, allowing security teams to determine exposure quickly. Organizations can generate SBOMs during builds using tools like Syft, CycloneDX, or SPDX formats. Regulators and industry groups increasingly mandate SBOMs to improve accountability and software trustworthiness.

3. Dependency and Package Management Security

Package managers like npm, PyPI, and Maven simplify dependency management but also pose risks if compromised. Security features such as package signing, two-factor authentication for publishers, and scoped access reduce these risks. Organizations must ensure dependencies are pulled from trusted sources and locked to specific versions to prevent tampering.

Using private or vetted mirrors and enforcing dependency policies through lockfiles (e.g., package-lock.json, Pipfile.lock) helps maintain control. Automated tools can ensure safe updates, flagging vulnerable packages and ensuring upgrades follow organizational guidelines.

4. Threat Intelligence and Vulnerability Databases

Real-time threat intelligence feeds and curated vulnerability databases help identify known risks in software components. Sources like the NVD (National Vulnerability Database), OSS Index, GitHub Security Advisories, and vendor-specific feeds offer critical insights into emerging threats.

Integrating these sources with SCA tools and CI/CD systems enables automated alerts and prioritization based on CVSS scores, exploitability, and affected assets. This contextual intelligence empowers security teams to act decisively and minimize time to remediation.

5. Runtime Protection and Monitoring

While preventive controls are critical, runtime security adds another layer by detecting malicious behavior during execution. Runtime application self-protection (RASP), extended detection and response (XDR), and container security tools monitor application behavior for anomalies and policy violations.

These tools can block unexpected network access, unauthorized system calls, or modifications to code and memory. Integrating runtime monitoring with SIEM systems improves incident detection and enables rapid response. Runtime protection is essential for uncovering threats that bypass static analysis or are introduced post-deployment.

6. Application Detection and Response 

Application detection and response (ADR) tools monitor the behavior of applications, detecting anomalies that static code analysis or pre-deployment testing might miss. These tools leverage telemetry from running applications—such as file access patterns, system calls, and network behavior—to identify potential threats. 

By flagging unexpected behaviors (e.g., a build tool initiating an outbound network connection), ADR solutions can quickly surface indicators of compromise that stem from supply chain tampering. ADR systems also integrate with threat intelligence feeds and behavioral baselines to improve detection accuracy. 

Key Standards and Frameworks for Supply Chain Security

SLSA (Supply Chain Levels for Software Artifacts)

SLSA, short for Supply Chain Levels for Software Artifacts, is a security framework developed by Google to improve the integrity of software artifacts throughout the development lifecycle. It provides a maturity model with four progressive levels (SLSA 1–4), each defining stricter security controls for source integrity, build provenance, and dependency management.

SLSA is based on the concept of verifiable build provenance—metadata that proves how, when, and by whom a software artifact was built. Higher levels of SLSA require build environments to be tamper-resistant and generate cryptographically signed attestations. By following SLSA, organizations can prevent unauthorized modifications and detect tampering before software is deployed.

NIST Guidelines

The National Institute of Standards and Technology (NIST) has published multiple documents to guide organizations in securing their software supply chains. Notably, NIST SP 800-161 Rev. 1 focuses on supply chain risk management (SCRM) practices for federal systems, and NIST Secure Software Development Framework (SSDF) provides detailed practices to integrate security into the software development process.

NIST guidelines emphasize identifying critical suppliers, securing development environments, assessing third-party software, and maintaining a thorough incident response plan. These documents serve as foundational resources for aligning with regulatory requirements and implementing supply chain risk management strategies.

ISO/IEC 27001 Extensions for Supply Chains

ISO/IEC 27001 is a widely recognized standard for information security management systems (ISMS). While the core standard outlines high-level controls, its supporting standard ISO/IEC 27036 addresses supply chain information security. It outlines practices for securing information exchanged between organizations and their suppliers. 

ISO/IEC 27036 emphasizes the importance of supplier vetting, contractual security requirements, and ongoing monitoring of third-party relationships. By extending an organization’s ISMS to cover the supply chain, ISO standards help ensure consistent and enforceable security controls across all vendors and partners.

5 Best Practices for Securing the Software Supply Chain

Here are some of the ways that organizations can ensure a successful supply chain security strategy.

1. Source Code Integrity and Access Control

Maintaining source code integrity starts with controlling who can access and modify code repositories. All repositories should enforce multi-factor authentication (MFA) to prevent unauthorized access, especially from compromised credentials. Use role-based access controls to restrict actions based on user roles—for example, limiting who can merge to main branches or trigger deployments.

Enforce branch protection rules to require peer reviews before merging changes, and mandate that all commits be signed with GPG or SSH keys. This cryptographic validation ensures the identity of the contributor and guards against tampered commits.

To further strengthen integrity, monitor repositories for unusual activity—such as sudden privilege escalations or unauthorized access attempts. Tools like GitHub’s audit log or GitLab’s activity feed can assist in tracking changes and detecting potential breaches early.

2. Build System and CI/CD Pipeline Hardening

The CI/CD pipeline is a common attack vector because it automates trusted workflows that lead to production. To harden these systems, run CI/CD jobs in isolated environments—ideally on ephemeral virtual machines or containers that are spun up for each build and destroyed afterward. This reduces the risk of persistence and contamination across builds.

Use infrastructure-as-code tools (like Terraform or Ansible) to define and version pipeline infrastructure, enabling consistent, auditable configurations. All secrets—tokens, API keys, database passwords—should be stored in secure vaults (e.g., HashiCorp Vault, AWS Secrets Manager) and accessed dynamically at runtime.

Limit network access from build environments to only essential services, and regularly patch build images and agents to eliminate known vulnerabilities. Additionally, enable runtime scanning of CI/CD jobs to detect unexpected behavior, like outbound connections to suspicious domains or unauthorized package downloads.

3. Log and Audit All Build Steps

Visibility into the build process is crucial for detecting tampering or misconfigurations. Every step—from fetching source code and dependencies to compiling and packaging—must be logged with precise detail. These logs should include timestamps, input parameters, executed commands, generated outputs, and the identities of users or processes initiating each step.

Store logs in a centralized, append-only system (e.g., using ELK stack or cloud-native solutions like AWS CloudTrail). Apply access controls to log data to prevent tampering or unauthorized review.

Link logs to artifacts using build IDs and hashes, making it possible to trace any binary back to its build history. Regularly audit these logs for signs of compromise, and use automated tools to trigger alerts on anomalies such as unusual package versions, failed integrity checks, or skipped tests.

4. Track Artifact Lineage

Knowing exactly how a software artifact was built, and from what sources, is key to diagnosing and responding to supply chain risks. Maintain a complete chain of custody for every artifact—this includes documenting all inputs (source code, libraries, build scripts), the exact build process (tools, environments, parameters), and the output (checksums, binary names, deployment targets).

Generate software attestations during the build process using tools like in-toto, Tekton Chains, or Sigstore. These records cryptographically link the artifact to the build metadata, ensuring that even if the binary is altered later, the tampering can be detected.

Use a software bill of materials (SBOM) to enumerate all components included in the artifact. This enables security teams to quickly assess exposure during incidents involving vulnerable libraries or compromised components. Store SBOMs and build provenance data alongside the artifact in the artifact repository (e.g., JFrog Artifactory, Nexus, or GitHub Packages).

5. Automate Vulnerability Alerts and Triage

Vulnerability management must keep pace with modern development speed. Integrate software composition analysis (SCA) tools into the development pipeline to automatically scan dependencies for known CVEs at every commit or build.

Configure alerting systems to distinguish between critical vulnerabilities that require immediate action and lower-severity issues that can be scheduled for later. Alerts should include actionable remediation guidance, such as fixed versions or available patches.

Create triage workflows to assign responsibility to the appropriate development or security teams, track status through ticketing systems, and enforce SLAs for remediation. For high-severity findings, implement blocking rules that prevent deployments until the issue is resolved.

Software Supply Chain Security with Oligo

Oligo helps organizations secure their software supply chain with real-time visibility into open source and third-party applications and components. By monitoring application behavior in production, Oligo accurately identifies vulnerable or unused components, prioritizes risks based on actual usage, and delivers a real-time SBOM to help customers continuously monitor supply chain vulnerabilities. This approach reduces false positives and maintains compliance with industry standards.