Software supply chains keep becoming more complex — and more vulnerable. Developers have adopted faster and more modular ways to build software, but this approach has a clear downside: a growing number of dependencies, third-party tools, and unknown risks outside direct control. And that is a huge security risk.
In the past year alone, more than 75% of organizations experienced at least one software supply chain attack, according to a 2024 BlackBerry survey. These attacks didn’t always target source code — they often involved compromised libraries, malicious updates, or insecure vendor systems.
The challenge is no longer just about securing your own systems. It’s about managing the risk embedded in every component, tool, and service used to build, test, deploy, and maintain your software.
The Many Parts of the Software Supply Chain
The software supply chain is everything that contributes to building and delivering an application or digital service. That includes:
- Source code and open-source packages
- Third-party libraries and dependencies
- Build systems and compilers
- CI/CD pipelines
- Infrastructure-as-Code (IaC) templates
- Container images and registries
- Cloud platforms and storage services
- APIs, SDKs, and integration plugins
- SaaS tools and developer platforms
- AI models
- Third-party services used in deployment, monitoring, or analytics
Securing the supply chain doesn’t stop at checking code. It means assessing the integrity of every external dependency and tool — even if it’s maintained by someone else.
This is where the idea of inherited risk comes in. By using someone else’s code, platform, or integration, you also inherit their risks. A vulnerable third-party tool can become your entry point for an attacker. And because many of these systems operate outside your environment, it’s often hard to detect when something goes wrong — until it does.
Software supply chain security is about making that invisible risk visible — and manageable.
It all starts with visibility, as it’s impossible to secure something if you don’t know it exists. According to the same Blackberry report, 74% of supply chain attacks originated from parts of the software supply chain that organizations did not monitor before the breach.
That underscores the importance of using asset discovery tools for supply chain risk management.
Threats and Attack Vectors in the Software Supply Chain
Software supply chain attacks target the trusted tools, libraries, and services developers rely on every day. Because modern applications depend on third-party components—many maintained or hosted externally—attackers often look for vulnerabilities in these dependencies rather than going after systems directly.
Below are some of the recent software supply chain attack examples illustrating the grim reality of how big the threat is:
1. Malicious Open-Source Packages
Attackers can inject malicious code into open-source packages and wait for it to be included in builds downstream. This approach takes advantage of the widespread reuse of community-maintained code.
Example: In 2018, the popular npm package “event-stream” was hijacked when an attacker took over maintenance and added an obfuscated payload. In fact, that’s an attack on a supply chain of a supply chain, because the attacker originally targeted a package called “flatmap-stream,” which was used as a dependency of a much more popular “event-stream.”
2. CI/CD Pipeline Compromise
Continuous integration and deployment (CI/CD) tools often have deep access into systems and environments. If these pipelines are misconfigured, exposed to the internet, or contain reused secrets, they become ideal targets for attackers.
Example: In 2021, attackers modified Codecov’s Bash Uploader script to exfiltrate environment variables, including tokens and credentials, from customer CI environments. The breach went undetected for over two months.
Example 2: The SolarWinds attack (2020) remains one of the most significant supply chain incidents in history. Attackers compromised SolarWinds’ build environment and inserted malicious code into its Orion software updates. Those updates were digitally signed and distributed to more than 18,000 customers, including government agencies and major enterprises. The attack demonstrated how a single trusted vendor compromise can ripple across thousands of organizations globally.
3. Insider Threats and Rogue Maintainers
Some of the most difficult threats come from trusted contributors or insiders. These actors can introduce malicious code or backdoors while posing as legitimate maintainers.
Example: In 2024, a contributor added a backdoor to XZ Utils, a core compression library used in many Linux distributions. The attacker spent months building trust in the project before introducing malicious code designed to enable remote access to systems.
4. Dependency Confusion
Also known as namespace confusion, this technique tricks internal systems into downloading malicious public packages that share the same name as private ones.
Example: Security researcher Alex Birsan demonstrated this by publishing packages to npm and PyPI with names used internally by major companies. Their build systems automatically fetched the attacker’s public packages, giving him access to their internal networks and data.
5. AI Supply Chain Compromise
As AI development accelerates, machine learning models themselves have become part of the software supply chain — and a new target for attackers. Threats may involve tampered models, poisoned training data, or malicious pre/post-processing scripts.
Example: In 2023, researchers at JFrog discovered that pre-trained models available on public repositories like Hugging Face could be modified to execute arbitrary code during loading. In one case, a compromised model triggered a reverse shell as soon as it was imported by an application — without any indication to the user.
Best Practices for Defending the Software Supply Chain
Securing the software involves safeguarding the systems, tools, and dependencies used throughout the entire software development lifecycle — many of which are maintained or hosted outside your organization.
Below are the best practices to help reduce risk and improve visibility across your supply chain.
Use Software Bills of Materials (SBOMs)
An SBOM is a structured inventory of all components in your application, including open-source libraries and metadata like version numbers and licenses. SBOMs improve transparency and make it easier to detect vulnerable or unauthorized components.
Best practices:
- Generate SBOMs during your build process. There are free and open-source tools for that (such as Syft or Trivy).
- Keep SBOMs versioned and tied to each software release.
- Treat SBOMs as living documents — update them regularly: either with each release or, if using continuous deployment, at fixed time intervals.
Secure the Build Environment
Build systems and CI/CD pipelines have access to sensitive code, credentials, and deployment infrastructure. If compromised, they can become a direct path to inserting malicious code into production software.
Best practices:
- Use isolated, minimal environments for builds.
- Remove unused or legacy components in your CI systems.
- Sign build artifacts.
Use Dependency Scanning and Software Composition Analysis (SCA)
SCA tools analyze your codebase to identify known vulnerabilities in the open-source packages you use, as well as licensing issues.
Best practices:
- Integrate scanning into your development pipeline (using open-source tools like OSV-Scanner or Dependency-Check).
- Monitor and review transitive dependencies.
- Automate notifications for vulnerable packages based on public advisories.
Enforce Access Controls and Least Privilege
Software supply chain attacks often take advantage of over-permissioned systems or exposed secrets. Implementing least privilege reduces the damage a compromised user or tool can cause.
Best practices:
- Restrict CI/CD permissions to the minimum required.
- Use short-lived credentials and rotate secrets regularly.
- Audit access to third-party services and integrations.
Monitor for Changes in the Attack Surface
Software supply chains constantly evolve. New dependencies, vendors, or tools can be introduced without a formal review process—expanding your attack surface over time.
Best practices:
- Track new subdomains, ports, and services using attack surface management tools.
- Review DNS, TLS, and hosting changes regularly.
Why Securing the Software Supply Chain Is So Hard
Securing the software supply chain isn’t just a technical challenge — it’s an organizational one.
Most teams already have security controls for code, networks, and applications, yet supply chain attacks continue to succeed. The main reason is that the supply chain extends far beyond what most security teams can directly control. But that’s not the only problem.
The Unavoidable Reliance on Third-Party Code and Services
Modern software is built on layers of external code and services — open-source libraries, frameworks, APIs, and development tools. This reliance enables speed and innovation, but it also creates unavoidable exposure. Each dependency represents an inherited trust relationship, meaning your security partly depends on someone else’s practices.
Even well-maintained packages can introduce risk through:
- Compromised maintainers or hijacked repositories
- Malicious updates or injected dependencies
- Vulnerabilities in transitive (indirect) components
The reality is that no organization can function without third-party code. The challenge is managing that reliance responsibly — knowing what you’re using, where it comes from, and how it’s maintained. When that insight is missing, attackers can exploit weak links that appear safe on the surface.
Complexity of CI/CD Environments
Continuous integration and delivery pipelines are the backbone of modern development, but they’re also complex systems that connect dozens of tools and services. Each integration — build runners, artifact repositories, cloud deployments — adds potential weak spots.
Security teams often struggle to apply consistent policies across these systems, especially when they include both self-hosted and managed services. This complexity makes it difficult to monitor and control every component of the pipeline, creating space for misconfigurations or unnoticed intrusions.
Fast Development Cycles
Speed is a top priority in software development, but it often comes at the expense of thorough security checks. Frequent releases, automated updates, and continuous deployment mean that new code and dependencies are introduced daily.
Security controls that can’t keep pace with development are often bypassed or delayed. Vulnerabilities can move from “discovered” to “deployed” in minutes, giving teams little time to assess or respond before exposure increases.
Balancing agility with assurance remains one of the toughest challenges in modern DevSecOps.
Visibility Gaps
Perhaps the most fundamental obstacle is the lack of visibility. Many organizations simply don’t know all the components, tools, and services involved in building and operating their software. Untracked dependencies, outdated build images, and forgotten cloud resources create blind spots that attackers can exploit.
Without clear visibility, it’s impossible to apply consistent controls, detect anomalies, or measure true exposure. Effective supply chain security starts with understanding what’s actually in your ecosystem — and what’s visible to others.
Supply Chain Security Regulations, Standards, and Compliance
As software supply chain threats grow, governments and industry bodies are setting clearer expectations for how organizations should secure their software ecosystems. Some are voluntary, some are actual compliance requirements that companies in certain industries or regions are obliged to follow.
U.S. Executive Order 14028
Issued in 2021, the Executive Order 14028 on Improving the Nation’s Cybersecurity established the foundation for supply chain security requirements across U.S. federal systems and contractors.
It directs agencies and software vendors to:
- Implement secure software development practices
- Provide a Software Bill of Materials (SBOM) for all software sold to the U.S. government
- Report vulnerabilities and security incidents promptly
- Verify the integrity and provenance of software through digital signatures and attestations
While aimed at federal procurement, many private-sector organizations follow its principles to strengthen internal security maturity.
NIST Secure Software Development Framework (SSDF)
The NIST SSDF (SP 800-218) offers detailed guidance for building software securely and consistently. It organizes best practices into four key areas:
- Prepare the Organization: Define security roles, responsibilities, and coding policies.
- Protect the Software: Secure source code, build environments, and dependencies.
- Produce Well-Secured Software: Integrate testing and review throughout development.
- Respond to Vulnerabilities: Handle findings and coordinate disclosures efficiently.
The SSDF now serves as a cornerstone for federal compliance and industry best practices.
SLSA (Supply-chain Levels for Software Artifacts)
The SLSA Framework (pronounced “salsa”) defines a structured model for improving build integrity and artifact provenance. Created by Google and maintained by the Open Source Security Foundation (OpenSSF), it helps ensure software is built in a controlled, tamper-resistant environment.
Core principles:
- Provenance: Every build should have a verifiable record of sources and steps.
- Reproducibility: Identical inputs should always produce identical outputs.
- Isolation: Builds must be shielded from external interference.
SLSA provides a clear maturity path—from basic source verification to fully automated and cryptographically verified builds.
ENISA Guidelines (EU)
The European Union Agency for Cybersecurity (ENISA) offers comprehensive guidance on managing software supply chain risks in Europe. Its recommendations include:
- Identifying all actors and dependencies in your supply chain
- Evaluating suppliers’ security posture
- Applying zero-trust principles to external software
- Promoting transparency through SBOMs and vulnerability disclosure
These guidelines align closely with the EU’s broader cybersecurity laws, including the NIS2 Directive and the upcoming Cyber Resilience Act.
It’s always important to remember that adhering to compliance standards and maintaining a strong security posture are two different things. While compliance standards are, of course, made to guide you towards doing so, you need to be proactive and committed with your approach to software supply chain security. Otherwise, there would still be blind spots and untracked dependencies.
Conclusion
Software supply chain security isn’t a single project or policy — it’s an ongoing commitment to visibility, verification, and responsible dependency management.
As organizations increasingly rely on third-party code, cloud services, and automation, their attack surface expands in ways that traditional controls can’t always reach. The most effective defense lies in knowing what’s in your ecosystem, where it comes from, and how it changes over time.
Frameworks such as the U.S. Executive Order 14028, NIST SSDF, SLSA, and ENISA’s guidelines provide valuable structure, but compliance alone isn’t enough. Real security comes from continuous awareness — maintaining an up-to-date inventory of your code, dependencies, tools, and internet-facing assets, and treating every connection as a potential point of entry.
