This knowledgebase article will cover:
- Definitions for software supply chain and software supply chain security
- Where software supply chain risks fall on the OWASP Top 10
- Why the software supply chain is vulnerable to attack
- Sources of supply chain security risks
- Best practices for mitigating risk
The software supply chain refers to the network of components, tools, processes, and third-party services involved in developing, building, and delivering software. Recognizing the importance of these tools and components, attackers increasingly target the software supply chain. By focusing attention on software supply chain security, organizations can reduce data breach risks arising from these attacks.
The software supply chain comprises a variety of code, libraries, dependencies, and infrastructure, which is used throughout the development lifecycle.
Key components include:
- Source code: Original code to build the software’s or application’s core functionalities.
- Third-party dependencies and libraries: Proprietary and open-source tools, libraries, and components integrated into source code to save developers time.
- Build and packaging processes: Compiling the code and packages into a deployable software.
- Deployment infrastructure: Releasing the software or application on cloud platforms or on-premises servers so people can use it.
Software supply chain security is the practice of reviewing and protecting every component across the software development life cycle (SDLC) from compromise, tampering, or unauthorized access.
As attackers increasingly insert malicious code into or otherwise compromise third-party libraries, organizations need to mitigate risk by:
- Protecting source code: Securing the original code against unauthorized access
- Identifying dependencies and libraries: Reviewing third-party and open-source components for potential vulnerabilities
- Engaging in real-time monitoring: Leveraging threat intelligence to constantly observe the software supply chain for new threats
- Automating audits: Scanning code and all third-party components to identify and remediate vulnerabilities
OWASP offers several Top 10 lists that highlight key security risks across different areas of application security. The OWASP Top 10 Risks for Open Source Software (OSS) outlines the biggest security risks in open source code, helping address key threats in the software supply chain. The Top 10 OSS Risks include the following:
- OSS-RISK-1 Known Vulnerabilities: Component contains publicly disclosed vulnerabilities, like those published through CVE, GitHub Security Advisories, or other channels.
- OSS-RISK-2 Compromise of Legitimate Packages: Attackers compromise parts of legitimate projects or their distribution infrastructure to inject malicious code.
- OSS-RISK-3 Name Confusion Attacks: Attackers create components with fake but similar names (typo-squatting), suggesting trustworthy authors (brand-jacking), or playing with common naming patterns (combo-squatting).
- OSS-RISK-4 Unmaintained Software: Component or component version is no longer actively updated to provide patches.
- OSS-RISK-5 Outdated Software: Project uses outdated component versions despite a newer version’s availability.
- OSS-RISK-6 Untracked Dependencies: Developers are unaware of a component dependency, like not having it in an upstream component’s Software Bill of Materials (SBOM).
- OSS-RISK-7 License Risk: Component or project lacks a license or uses one incompatible with the developer’s intended use.
- OSS-RISK-8 Immature Software: Project fails to apply development best practices, impacting component reliability and security.
- OSS-RISK-9 Unapproved Change: Changes to components occur without developers noticing, reviewing, or approving them.
- OSS-RISK-10 Under/Over-Sized Dependency: Component provides too little or too much functionality.
Additionally, some examples of OWASP Top 10 Risks related to the software supply chain across other lists include:
- Kubernetes Top 10 (K02): A container can rely on various third-party components and dependencies that can lead to security issues arising from a lack of image integrity, problems with image composition, and known software vulnerabilities.
- Mobile Application Top 10 (M2): Attackers can exploit vulnerabilities arising from a lack of secure coding practices, insufficient code reviews, insufficient or insecure app signing and distribution processes, vulnerabilities in third-party software components or libraries, sensitive data exposure, or insufficient security controls across data, encryption, storage.
- Machine Learning (ML) Model Top 10 (ML06): As the ML supply chain includes more elements than traditional software, attackers can target the traditional supply chain as well as MLOps platforms, data management platforms, model management software, model hubs, and tools for testing and deploying software.
Attackers seek to exploit weaknesses across the development and deployment processes, especially since software supply chains contain complex interactions between different components, libraries, and environments. Vulnerabilities are typically defined across the following areas:
- Infrastructure vulnerabilities: configuration problems in hardware and software systems, including servers, virtual machines, and network devices.
- Software vulnerabilities: flawed code arising from bugs or faults in proprietary and open-source software, often through dependency confusion where systems download malicious code instead of legitimate libraries.
- Codebase vulnerabilities: Harmful code introduced into the underlying software, often through dependency confusion or hijacked updates.
- Human error or malicious insider intent: Tricking people into downloading malicious components, like with typosquatting, or insiders who purposefully introduce vulnerabilities.
- Process vulnerabilities: Flaws in established protocols, like failure to property test or review source code.
Attackers target the software supply chain because the complex, interconnected dependencies across software tools and services create vulnerabilities that are difficult to detect. Some reasons that organizations often face increased risk include:
- Short release cycles and rapid iterations: Agile development practices often mean that application security (AppSec) and DevOps teams struggle to track and manage security issues, especially as the use of open source code expands the risk surface.
- Traditional AppSec processes fall behind: Accelerated SDLCs, complex applications, and everything-as-code trends make identifying and remediating vulnerabilities difficult as AppSec teams need automated tools to address persistent gaps.
- Alert fatigue and software supply chain complexity: High volumes of false positive alerts leave security and AppSec teams struggling to prioritize and respond to issues across complex applications that include third-party components, application programming interfaces (APIs), and open source libraries.
As the software supply chain risks continue to grow, organizations need to ensure the security of all components to mitigate attack risks.
When trying to reduce risk, organizations should consider the following sources:
- Open-source libraries: Lack of change management processes and documentation can lead to hidden vulnerabilities without incorporating automation like software composition analysis (SCA) tools to help identify, manage, and remediate them.
- Secrets leaks: Developers can accidentally leave sensitive information in the source code, including passwords and API keys, that attackers can use to compromise the application.
- CI/CD pipeline: Attackers can exploit vulnerabilities in the continuous integration, continuous delivery (CI/CD) pipeline tools that build and test code, making unauthorized changes to source code.
- Malicious packages in public registries: Attackers increasingly target public registries, like the Python Package Index (PyPI) and JavaScript package manager NPM, so that developers upload malicious packages with seemingly legitimate names.
- Malicious installation scripts: Attackers inject malicious installation scripts into software packages so that they run during setup to compromise entire systems.
Security teams, developers, and AppSec teams need to collaborate effectively and build risk management into all processes, from development to deployment. By following best practices, organizations can mitigate risk across the software supply chain, including those arising from malicious attacks and potential vulnerability exploits.
Integrating security controls for the development environment is similar to how the organization protects the production environment. Some typical risk mitigation strategies include:
- Applying the principle of least privilege by limiting user access to only the resources people need to complete their job functions.
- Integrating security tools and standards into each phase of development.
- Automating security tasks with CI/CD pipelines.
Implementing secure coding standards helps protect against common security flaws. Some actions that organizations can take include:
- Using automated vulnerability detection tools.
- Ensuring software artifact integrity and authenticity with code signing.
- Tracking component versions to ensure they use the most secure ones.
An SBOM acts as a formal record of software components, their relationships, and potential vulnerabilities. Developers can use SCA tools to analyze software applications to identify open-source components and third-party dependencies to expose vulnerabilities that would otherwise be overlooked. When implementing an SCA solution, organizations should ensure that it enables them to:
- Compare open-source packages against vulnerability databases.
- Offer remediation guidance.
- Integrate into developer workflows.
Establish Vulnerability And Patch Management Processes
Between the development environment and the source code, organizations need to implement vulnerability and patch management processes that:
- Use the SCA solution to scan source code for third-party components and libraries that contain known vulnerabilities.
- Scan containers to identify potential vulnerabilities.
- Implement dynamic and static application security testing to look for potential vulnerabilities.
- Prioritize remediation activities based on asset criticality or component reachability
As the organization implements more devices and applications, the third-party vendor risks assessments increasingly need to incorporate monitoring for software supply chain risks. As part of evaluating a vendor, organizations should consider:
- Software development lifecycle processes and controls
- Corporate security posture
- Vulnerability history, including reporting vulnerabilities and providing security updates
- Response strategies, including notifying customers about potential security incidents impacting development environments
VulnCheck enables security teams to manage vulnerability and risk with the largest real-time collection of known exploited vulnerabilities, including additional context into and evidence-based evaluation of exploits. VulnCheck enables developers to integrate SBOMs and vulnerability reporting into their workflows so that they can regularly monitor for and mitigate software supply chain risks.
