As more and more organizations rely on various external tools and software providers to provide services to their customers, the complexity of the software supply chain only increases, making it vital to understand how these components interact and affect the overall system.

This article will break down parts of the software supply chain, their vulnerabilities, and solutions on how to secure it against hackers and other malicious actors.

Software supply chain security steps

  1. Vendor assessment
  2. Continuous monitoring
  3. Implement SBOM
  4. Encryption and secure communication
  5. Regular audits and testing
  6. Perform automated security testing
  7. Dependency management
  8. Security training

What is a software supply chain?

A software supply chain refers to all processes, tools, and third-party components that make up the development, production, and delivery of software products. It ranges from code the developers write down to open-source libraries, third-party applications, and cloud services.

Key elements of a software supply chain

An infographic that lists down the key elements of a software supply chain.
  • Developers and development tools: Integrated Development Environments (IDEs), source code repositories, and version control systems.
  • Open-source software and libraries: Third-party dependencies that are incorporated into the software.
  • Third-party vendors: Third-party tools and software providers that integrate solutions with the core application.
  • CI/CD pipelines: Automation of systems that test, construct, and then deploy the software.
  • Cloud infrastructure: Hosting environments and cloud services used in the final product.

Why is software supply chain security so important?

Software supply chain security is important because most modern software heavily relies on third-party tools and open-source libraries, among others provided by external vendors. A single weak point within a supply chain might leave an organization open to serious cyber risks, hence making the supply chain part of general cybersecurity.

The rising number of supply chain attacks indicates where organizations should emphasize security through the lifecycle of the software. An effective supply chain security strategy fosters a culture that pegs vulnerabilities in third-party tools and libraries to be first fixed and mitigated before they have an impact on the whole software ecosystem.

Examples of software supply chain attacks

Each of the following incidents roughly illustrates how attackers have taken advantage of software supply chain vulnerabilities to produce a wide-range impact.

SolarWinds attack

The SolarWinds attack was one of the most well-known and devastating software supply chain attacks in recent history. It occurred in 2020 and involved a sophisticated attack on SolarWinds’ Orion IT monitoring and management software.

This attack highlighted the vulnerability of the software supply chain, in particular, issues within the domain of trusted relationships that are there between vendors and their customers. This has brought more awareness of continuous monitoring and robust security practices, even with well-established vendors.

NotPetya attack

The NotPetya attack, which happened in June 2017, is a classic example of a destructive software supply chain attack that crippled companies the world over. Unlike other attacks, NotPetya was not focused on data theft but rather designed to cause maximum disruption.

Once released, the malware spread with ease from network to network, building on weaknesses in the Microsoft systems that were unpatched. NotPetya encrypted users’ data and then presented a ransom message requesting payment in Bitcoin. NotPetya’s total financial damage was estimated at more than $10 billion, making it one of the most financially destructive cyberattacks in modern history.

CodeCov attack

Early in 2021, the CodeCov attack served as a reminder of how even trusted software development tools can be compromised to launch wide-scale supply chain attacks. CodeCov was a widely used tool for developers to measure code coverage, and it suffered a malicious breach that went undetected for several months.

The attackers were able to infiltrate the CI/CD environments of multiple organizations, potentially exposing highly sensitive intellectual property, credentials, and infrastructure secrets. It was a breach that really rang alarm bells for the security of the CI/CD pipeline and the need to have stronger controls in terms of security with development tools.

What are the security risks to the software supply chain?

There is a whole string of critical risks related to the software supply chain, including:

  1. Compromised open-source libraries: Attackers usually target open-source libraries because they know such libraries are widely used across industries.
  2. Malicious third-party vendors: Unscrupulous vendors can introduce backdoors, malware, or insecure practices.
  3. Compromised CI/CD pipelines: Insecure automation pipelines may be used by attackers to inject malicious code.
  4. Insecure software updates: Attackers can intercept software updates or alter them with the intent of spreading malware, or even gaining unauthorized access.

Risk #1: Open source software

Open source software (OSS) plays a critical role in modern software development, with many organizations relying on it to speed up development and reduce costs. 

However, where OSS differs in creating unique risks for the software supply chain is that it is normally developed by communities, not dedicated security teams. Attackers realize this and now actively target open source components in attempts to insert vulnerabilities or malware.

Why is open source software vulnerable?

  • Unvetted code: Open source libraries and components may not go through the same level of security testing as commercial software.
  • Outdated dependencies: Most open-source projects are not actively maintained, meaning vulnerabilities may be included in the code for an extensive period of time.
  • Supply chain attacks: Attackers can compromise popular open-source libraries by gaining access to the repository or injecting malicious code into updates.

Risk #2: Third-party vendors

Third-party vendors are a part of any given software supply chain; however, they do come with some risks since their security practices have an effect on the integrity of your software.

Third-party risk is one created in your system due to third-party applications, libraries, services, or even physical hardware. One weak security posture by a vendor can strategically expose your entire supply chain to unauthorized access, data theft, or malware injection.

Why are third-party vendors vulnerable?

  • Poor security habits: Not all vendors have the same security standards; a few of them are more vulnerable to an attack.
  • Lack of transparency: Vendors do not always disclose their security practices, and therefore the nature of the risk they bring in is hard to assess.
  • Unmonitored code: When the vendors develop code contributions, that code may include secret vulnerabilities that can be exploited.
  • Compliance issues: Using third-party vendors that do not comply with regulatory requirements could lead to legal issues and fines.

Risk #3: CI/CD pipelines

Continuous integration/continuous deployment (CI/CD) pipelines are the backbone of modern software development for automated code integration, testing, and deployment.

However, all these benefits come with considerable security risks in the software supply chain. If not well secured, the pipelines of CI/CD become a very attractive target for an attacker interested in tampering with the development by planting malicious code in them.

Why are CI/CD pipelines vulnerable?

  • Automated access to critical systems: CI/CD pipelines automatically have access to code repositories, testing environments, and production systems. If an attacker would happen to access the CI/CD pipeline, undetected manipulation of the software build or deployment could be performed.
  • Lack of security controls: Most organizations prioritize the speed of their CI/CD pipelines over security. The resultant effects are weak or missing access controls, insufficient logging, and not testing for security vulnerabilities.
  • Integration with third-party services: A normal CI/CD interacts with third-party services and integrations, such as testing frameworks, cloud services, and code scanning tools, among others. Each integration point becomes a potential entry for an attacker if those tools have weaknesses or poor security practices.
  • Secrets management: Pipelines use sensitive information such as API keys, tokens, and passwords to connect a plethora of different services. Poor storage and exposure of these secrets within the pipeline allow attackers to use them in breaching other portions of the environment.

Risk #4: Software updates

One of the most overlooked but significant risks to the software supply chain is insecure software updates. Software updates are done on a regular basis to keep up the performance of the software, add new features to it, and most importantly, patch vulnerabilities.

However, when these updates are given an insufficient security posture, they can become a critical attack vector, which may provide a way for the attacker to distribute compromised software directly to end-users.

Why are software updates vulnerable?

  • Trust in the update mechanism: Most users and organizations inherently trust that software updates provided by the vendor are legitimate and secure. Attackers can exploit this trust by inserting malicious code into the update process.
  • Man-in-the-Middle (MiTM) attacks: The attacker can hijack the communication channel between a software provider and its users, substituting malicious versions of updates instead of the legitimate ones. 
  • Supply chain compromise: An attack on the vendors themselves, especially those with weak security postures, to compromise their update servers. The attackers can distribute malware through what looks like a legitimate software update and bypass traditional security measures based on the vendor’s reputation.
  • Unsigned or improperly signed updates: Unsigned or improperly signed updates: Digital signatures ensure software updates are authentic. When these updates are unsigned or improperly signed—or if the signing keys have been stolen—hackers are able to distribute malicious updates down the chain as if they came from a source one trusts.

Supply chain risk management and DevSecOps

Supply chain risk management involves determining and mitigating risks from third-party vendors and the external components used within the software development.

DevSecOps is an approach to application development that embraces security throughout the entire software development lifecycle, from design to deployment. It emphasizes collaboration between development, security, and operations teams to ensure that security is prioritized alongside functionality.

How to secure a software supply chain

Securing a software supply chain requires a multi-layered approach that combines people, processes, and technology. These are key steps you can take to enhance the security of your supply chain:

  1. Vendor assessment: Conduct in-depth analysis of third-party vendors and their security practices.
  2. Continuous monitoring: Use tools to monitor the supply chain for vulnerabilities and suspicious activity.
  3. Implement SBOM: Use a Software Bill of Materials (SBOM) to track all the components involved in the software supply chain at every level.
  4. Encryption and secure communication: Strong encryption standards should be used to protect in-transit and at-rest data.
  5. Regular audits and testing: Continuously audit and test your software supply chain for possible vulnerabilities.
  6. Perform automated security testing: Integrate tools at development time that carry out both static and dynamic analysis.
  7. Dependency management: Employ tools that track and update third-party libraries automatically.
  8. Security training: Keep developers informed of state-of-the-art security practices.
  9. Principle of least privilege: Never grant more rights than necessary for users and services in order to minimize exposure to the system’s security.

What is a Software Bill of Materials (SBOM)?

The SBOM is a formal record of all components, including the third-party libraries required to produce a given software product. An SBOM is critical in tracking dependencies to ascertain if any of these components remain safe and up-to-date. 

SBOMs give an organization insight into the origin of its software and swift action when there is a vulnerability found in third-party libraries or dependencies. They are essential in supply chain security methodologies since they allow much-needed transparency into the software development process.

Automated security testing tools

Automated security testing tools help in the early identification of vulnerabilities during the development process in order to minimize risks that could lead to the deployment of insecure software.

Software Composition Analysis (SCA)

SCA tools are capable of detecting and controlling open-source libraries used in a given project by searching for disclosed vulnerabilities and license issues and ensuring only secure and compliant components are in use.

Static Application Security Testing (SAST)

SAST tools analyze source code for potential security flaws before the software is executed. It gives insights that enable developers to fix vulnerabilities early in the development cycle.

Dynamic Application Security Testing (DAST)

DAST tools test running applications for vulnerabilities. They run simulated attacks against the software to find weaknesses an attacker might well exploit. 

Software supply chain security vs. application security

While both software supply chain security and application security aim to protect software from threats, they focus on different aspects.

Software supply chain security focuses on protecting the components and vendors that contribute to the software development process. It involves evaluating third-party tools, securing CI/CD pipelines, and managing open-source dependencies.

Application security focuses on protecting the final software product, including the code, data, and infrastructure. This involves vulnerability assessments, penetration testing, and securing APIs.

In essence, supply chain security looks at the external contributors to software security, while application security focuses on securing the software itself.

To extend your security perimeter, consider Verimatrix XTD, a comprehensive solution designed to detect and respond to supply chain and application threats in real time. Learn more here.