The Ultimate Guide to Software Supply Chain Security

In today's technology-driven world, software development has become an integral part of almost every business. From small startups to large corporations, every organization relies on software to perform various critical functions. However, with the increasing complexity of software supply chains, the risks associated with it have also increased.

This guide aims to provide you with a comprehensive understanding of software supply chain security and equip you with the knowledge and skills to protect your organization's software supply chain. Whether you are a software developer, a DevOps engineer, or a business owner, this guide will help you understand the various elements of a software supply chain and the security risks associated with them. We will provide you with practical tips and strategies to enhance the security of your software supply chain and protect your organization from potential security threats.

Let's dive in and explore the world of software supply chain security together!

What is the software supply chain?

A software supply chain refers to the sequence of processes involved in the development, deployment, and maintenance of software applications. It covers all aspects required to build a software artifact, from source code development to production deployment. This includes the following key elements:

• Source code writing and management
• Third-party software dependencies and libraries
• Build and packaging processes
• Distribution channels and mechanisms
• Deployment infrastructure and environments
• Monitoring and maintenance procedures

In today's software development landscape, it is becoming increasingly rare for companies to create software completely in-house. Instead, they rely on a range of building blocks, such as open-source libraries, developer tools, cloud-based deployment, software-as-a-service (SaaS), and delivery systems. Each of these components is part of a long supply chain, which encompasses every aspect of IT infrastructure, including hardware, source code, third-party tools, platforms, data storage, and testing and distribution infrastructure.

As developers, we all love open-source libraries and components. They save us time, accelerate development, and enable us to deliver more functionality to our customers. However, it's important to acknowledge that open-source components also come with inherent security risks. Because we don't have direct control over the code that goes into our products, we're increasingly exposed to vulnerabilities that may be introduced by changes outside our control. 

That's why it's crucial to be vigilant about the security of our software supply chain.

Top 5 risks to the software supply chain

DevSecOps speeds up the development and deployment of new capabilities in modern supply chains. However, if security measures are not implemented, attackers can inject malicious code into the trusted baseline. Frequent software updates can also increase risk if not properly managed, as they require more communication with customer networks, potentially giving attackers increased access to target networks.

Following is a list of the top 5 risks to the modern software supply chain:

• Hard-coded secrets in repositories: among many possible human errors that can introduce vulnerabilities, leaked secrets are both the most common and the most impactful. In 2022, 10 million secrets were found hard-coded on public GitHub! They are also involved in a number of recent security incidents. Behind the scenes, attackers are automating secrets detection to find credentials and attack software development tech stacks and delivery pipelines.

• Vulnerable or malicious third-party dependencies: Modern software supply chains often rely on third-party libraries or modules, and if these dependencies contain vulnerabilities or malicious code, they can introduce risk into the system.
• Compromised CI/CD pipelines: Cyber attackers may target Continuous Integration/Continuous Deployment (CI/CD) pipelines to introduce vulnerabilities or malicious code into the software supply chain, which can then be deployed to production environments.
• IAM misconfigurations: Misconfigurations in Identity and Access Management (IAM) policies can allow unauthorized access to sensitive systems and data or even enable attackers to take control of critical systems.
• Insider threats: Insider threats can pose a significant risk to the modern software supply chain, particularly if an employee with privileged access to systems or data intentionally or unintentionally introduces a vulnerability. This can include employees with access to code repositories, deployment tools, or other critical systems. Insider threats can also come from third-party contractors or vendors with access to sensitive systems or data. Organizations should implement proper access controls and monitoring to detect and prevent insider threats, as well as provide regular training and awareness programs for personnel on security best practices.

Examples of software supply chain attacks

It would be difficult to talk about supply chain attacks without bringing up the SolarWinds case, which has become the poster child for the dangers they represent. The case of SolarWinds is one of the worst-case scenarios since the compromised system was not only used with tens of thousands of high-profile clients, such as within the military and other areas within the government but because the software had admin-level access to the networks, it was installed on. 

The attackers targeted an IT infrastructure monitoring software called SolarWinds Orion to install a backdoor into SolarWinds customers, which included Homeland Security, State Commerce and Treasury, FireEye, Microsoft, Intel, Cisco, and Deloitte, to name a few. State-of-the-art security protections were bypassed by exploiting a link with high-privilege access to penetrate and remain undetected for a significant amount of time.

The Orion component was compromised as early as September 2019.  The first traces of code used by the attackers for testing the exploit were injected into the code in October 2019. It wasn’t until February 2020 when the malicious code, known as Sunburst, was injected into Orion and began to be deployed to its 18,000 users in March. SolarWinds did not discover the breach until December 2020.

Codecov - Attack through CI/CD pipeline

This attack concerned software deployment tools, specifically the CI/CD environment. The CI/CD (Continuous Integration / Continuous Deployment) pipeline is a process by which software can be automatically tested before it is automatically deployed. This has become a fundamental part of the software supply chain, allowing developers to streamline the process of building and deploying software. 

In January 2021, an attacker obtained credentials used in Docker image creation involving Codecov software due to an error in the build process. These credentials allowed the attacker to hijack Codecov, a software for testing developers' code coverage, and turn it into a real Trojan horse: since the software is used in continuous integration (CI) environments, it has access to the secret credentials of the build processes.
The attacker was thus able to siphon off hundreds of credentials from Codecov users, allowing him to access as many secure systems. The company only detected the breach a few months later, in April.

Read a full breakdown of the Codecov attack here:

Log4Shell - Widespread open-source vulnerability

In December 2021, a vulnerability affecting Apache Log4j, an open-source logging library widely used in the Java ecosystem, was discovered and disclosed as a proof-of-concept (POC). Attackers could execute Remote Code Execution (RCE) using certain versions of the package, prompting them to scan for vulnerable servers across the Web in large numbers. The danger of Log4Shell lies in the ubiquity of the Log4j 2 library, which is present in major platforms such as Amazon Web Services and VMware, as well as services large and small. Attackers can easily exploit it to remotely take over any internet-connected service using certain versions of the Log4j library anywhere in the software stack.

Although a patch was quickly released, and the vulnerability was only exploitable under specific conditions, its prevalence in the Java ecosystem meant that a significant attack surface had been exposed for thousands of organizations globally. The US Cybersecurity and Infrastructure Security Agency (CISA) described it as "endemic" since it is likely to persist for many years.

How to secure a software supply chain

Securing a software supply chain involves various steps that aim to mitigate the risks and ensure the reliability and safety of the software products. The following are some key practices to secure a software supply chain:

Implement secure coding practices to ensure the integrity and confidentiality of the source code

Use Source Composition Analysis (SCA) to monitor and update third-party dependencies to prevent vulnerabilities and potential security threats

Maintain strict access controls for the build and deployment environment to prevent unauthorized access

Use secure distribution channels and decoys tokens to protect against data breaches and tampering with distribution systems

Conduct regular security audits to identify and address any potential security vulnerabilities and threats

Read also Gartner’s guidelines for software engineers about:

• Hardening the software delivery pipeline;
• Securing the operating environment for software engineers;
• Protecting the integrity of internal and external code;
• Countering the threat of software supply chain attacks.

Software supply chain security checklist

Source Code Security:

• Have automated secrets detection in place
• Standardize code reviews and approvals
• Ensure access control measures are in place for source code repositories

Dependencies Management:

• Identify all third-party dependencies used in the software
• Regularly monitor and update dependencies to ensure they are not vulnerable to known security issues
• Maintain a list of approved and unapproved dependencies

Build and Packaging:

• Have a documented build process that includes all necessary components, including source code, libraries, and tools
• Use cryptographic signatures to ensure the integrity of the software packages
• Ensure only authorized personnel have access to the build environment

Distribution:

• Use secure channels for distributing software packages
• Verify the integrity of the software packages before distribution
• Sign distributed software packages

Deployment:

• Ensure the software is deployed in a secure environment
• Use strong authentication and access control measures for deployment
• Regularly monitor the software in production for vulnerabilities and anomalies

Incident Response:

• Have an incident response plan in place in case of a security breach
• Regularly test the incident response plan
• Provide training to personnel on incident response procedures

Compliance:

• Ensure the software complies with all relevant regulations and standards
• Regularly review and update compliance policies and procedures
• Conduct regular audits to ensure compliance

Software supply chain attacks present a real challenge to the resilience of software factories. While it is not possible to prevent all supply chain attacks, implementing these practices can make it more difficult for attackers to infiltrate your system and limit potential damage.

Here are the 6 rules to keep your software supply chain safe:

• only use trusted dependencies within your application and scan open-source software for known vulnerabilities using Open Source Scanning (OSS) software
• patch your systems intelligently,
• segment your network to limit the blast radius in case of an attack,
• implement advanced authentication and least privilege principles to limit the amount of trust that the attacker ultimately has,
• ensure that your repositories are free from secrets by using secret scanning tools like GitGuardian.

Read the complete guidelines here:

Supply Chain Risk Management

Supply Chain Risk Management (SCRM) software is designed to help organizations manage the risks associated with the procurement, development, and deployment of software in their supply chain. These risks may include security vulnerabilities, data breaches, cyber-attacks, and non-compliance with industry standards, regulations, and security requirements.

Here is a proposed model to distinguish between supply chain, third-party, and vendor risk management:

In this all-encompassing model, software vendors’ customers should be taken into account because they could intentionally or not impact the vendor’s security. Indirect providers are the suppliers of the vendor’s suppliers, for example, the cloud service provider of a SaaS application that is used in the development of a software product.

Supply Chain Risk Management Software

Supply chain risk management (SCRM) software typically includes a range of features and functionalities, such as:

1. Risk assessment and analysis: The software helps organizations identify and assess the risks associated with their supply chain, including the risks associated with third-party vendors and suppliers.
2. Threat intelligence: The software collects and analyzes data from various sources to provide organizations with real-time information about potential threats and vulnerabilities in their supply chain.
3. Compliance management: The software helps organizations ensure that their supply chain complies with industry standards, regulations, and security requirements.
4. Vendor risk management: The software helps organizations evaluate and manage the risks associated with their third-party vendors and suppliers.
   Incident response: The software provides a centralized platform for managing and responding to security incidents that occur in the supply chain.
5. Continuous monitoring: The software continuously monitors the security posture of the supply chain and alerts organizations to any anomalies or suspicious activity.

In today's world, the software supply chain is highly complex and made up of many third-party components like SaaS tools, APIs, and libraries that are often sourced from different vendors and suppliers. This complexity creates significant challenges for security operations teams in managing and securing their software supply chain. Even with best practices and Supply Chain Risk Management (SCRM) solutions, security teams often need more visibility and security oversight over these third-party components.

As a result, organizations must go beyond traditional SCRM and adopt new approaches to ensure the security and integrity of their software supply chain. One such approach is intrusion detection, which can help organizations detect when a third-party component has been breached and take appropriate action to mitigate the risk.

Get notified if any suspicious activity is detected on your favorite SaaS tools for free.

Supply Chain Intrusion Detection

Intrusion detection systems (IDS) are a critical component of modern cybersecurity that helps detect unauthorized access, unusual activity, and known or unknown attacks in real time. IDS can monitor and analyze network traffic, system logs, and other sources of data to identify potential security breaches and suspicious activity. IDS can also use honeypots to lure attackers into attacking a decoy system, providing security teams with valuable insights into their tactics and techniques.

A specific kind of honeypot is a honeytoken (also known as canary tokens). Honeytokens are credentials that look like real secrets but are not valid against any service, but when used, they will trigger an alert and report on the user's address. The honeytoken is designed to lure attackers into attacking it, giving security teams an opportunity to detect and analyze their techniques and tactics.

Honeytokens are useful for intrusion detection because they can:

1. Provide early warning of attacks: Honetokens are often targeted by attackers early in the attack cycle. By detecting and analyzing these early attacks, security teams can gain valuable insight into new or emerging threats and take appropriate action to protect critical systems.
2. Enable detailed analysis of attacks: Because honeytokens are designed to be attacked, they are instrumented with extensive logging and monitoring capabilities. This enables security teams to closely examine the attack methods used by attackers and identify weaknesses in their own defenses.
3. Limit the impact of attacks: Honeytokens not allowing access to any real service, so attackers cannot use them as a jumping-off point to launch attacks on valuable systems and might lose precious time while trying to. This reduces their operational time window and reduces the risk of lateral movement.
4. Be deployed automatically and at scale: Organizations can deploy honeytokens across their entire infrastructure without a significant amount of effort or cost. They can be deployed in various ways, such as in source code files, messaging systems, continuous integration pipelines, and other places where attackers may look for credentials.

One way to consistently deploy honeytokens is to make them a part of your automated environment builds, leveraging tools like Terraform and our open-source project ggcanary. Honeytokens can be created and deployed in your CI/CD pipelines, as well as code repositories or project management systems.

Supply chain security automation

Supply chain security automation involves automating security-related tasks, such as vulnerability scanning, patch management, and access control, in the software supply chain to improve its security posture. One critical aspect of software security in the supply chain is attestation, which is an authenticated statement or metadata about a software artifact or collection of software artifacts. Attestation provides evidence of compliance with security frameworks and standards and helps organizations validate the authenticity and security of their software, ensuring that it is free from vulnerabilities and has not been tampered with.

Supply chain automated attestation is the process of generating attestation metadata as part of the build process. Thanks to CI/CD pipelines, the build process can generate and produce attestation metadata for all built artifacts, making it easier to validate the authenticity of the software and the security of the machine they were built on. Therefore it is a prevention measure against code that has been injected with malware or build servers that have been overtaken.

Automated attestation is becoming increasingly important, especially for public sector organizations, due to the emerging attestation requirements that demand organizations protect against software tampering and add minimal build integrity guarantees.

Not only that, but automated attestation verification and signing is certainly one of the keys to improving the global security of the open-source ecosystem due to the network effect's effectiveness. 

Learn everything about Sigstore, a promising set of new tools aiming at establishing a new standard for software practitioners for signing, verifying, and protecting software, and its code signing tool Cosign with this tutorial: 

Software supply chain security frameworks: NIST, SLSA, Microsoft, OSC&R

Software supply chain security frameworks are crucial for organizations to navigate the many aspects of supply chain risk assessment and evaluate mitigation priorities. 

The National Institute of Standards and Technology (NIST) provides guidelines for secure software development and supply chain security, including the NIST Secure Software Development Framework:

With a different approach, the Supply Chain Levels for Software Artifacts (SLSA) framework defines four security levels, which are incremental and actionable milestones corresponding to integrity guarantees, to improve supply chain security:

With a different approach, the Supply Chain Levels for Software Artifacts (SLSA) framework defines four security levels, which are incremental and actionable milestones corresponding to integrity guarantees, to improve supply chain security: Secure Supply Chain Consumption Framework (S2C2F)

Finally, with the entire software supply chain being increasingly targeted by threat actors, there emerged the need for a MITRE ATT&CK-like security framework that would allow experts to establish a common language and structure for understanding and analyzing techniques, tactics, and procedures (TTPs) used by adversaries to compromise the security of software supply chains.

This is the goal of the Open Software Supply Chain Attack Reference (OSC&R), a MITRE-like framework covering containers, open-source software, secrets hygiene, and CI/CD posture.