Software supply chain (SSC) attacks continue to be one of the most discussed topics in the cybersecurity industry as of late — and for good reason, with some sources showing these attacks rising more than 742% over the past three years.
With such continued growth, organizations continue to look for ways to mitigate the risks of SSC attacks, and various industry organizations continue to publish guidance to help organizations. The latest release comes from the US National Institute of Standards and Technology (NIST), in its special publication 800-204, also known as “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines.”
Today’s software development and delivery companies are increasingly leveraging cloud-native environments and technologies to do so, such as CI/CD pipelines and the utilization of DevSecOps methodologies.
This combination of technologies and practices allows organizations to streamline the software development process, automate tasks, and integrate security tooling and practices through the software development lifecycle (SDLC) to mitigate risk. That said, when these environments and technologies aren’t properly secured, exploitation can occur, having a downstream impact on those consuming the software.
Arming organizations to mitigate software supply chain risks
The NIST guidance strives to arm organizations with recommendations to mitigate those risks and bolster software supply chain security. Protecting software in the CI/CD context means ensuring that the software is not compromised through the various stages of build, test, package and deploy.
As NIST points out, SSC includes not just the output of specific activities but also assurances that the various activities that were carried out to create and deliver software were not compromised and have supporting artifacts and attestations to prove it.
SSC attacks will continue to rise because of the economies of scale the supply chain offers malicious actors. Rather than target a single organization for exploitation, attackers can target a widely used vendor, service, or OSS component or project and have a massive downstream impact across a large range of victims.
Part of the challenge on the defensive side of the SSC is that the modern SSC involves many different stakeholders, organizations, industries, technologies, and communities, making it incredibly difficult to implement a single unified approach to governance and security.
Risk factors in the software supply chain
NIST defines an SSC attack as a three-phased scenario:
- Artifact, step, or actor compromise
- Propagation
- Exploitation
When dealing with modern software development environments, there are various entities and risk factors at play. These include the development environment, threat actors, attack vectors, and targets and the types of exploitation that are being carried out. These factors may look different across organizations and industries, but ultimately play a part in any SSC compromise scenario.
Developer environments represent a primary attack vector for malicious actors looking to carry out SSC attacks. This is particularly challenging due to the nature of the modern distributed workforce, bring your own device (BYoD) scenarios and the combination of SaaS and self-hosted source code management systems. Organizations must have measures in place to mitigate risk from the compromise of a development environment, developer account, and their associated endpoints.
Software supply chain attacks come from within and without
Threat actors include a combination of external and internal attackers. The external attackers may vary depending on the reason for the malicious activity from everything from a cyber activity to a full-on nation-state looking to impact foreign adversaries and their national institutions and critical infrastructure.
They can also include malicious insiders driven by factors such as dissatisfaction or extortion and bribery. These attacks often utilize a variety of attack techniques to compromise software in the supply chain, such as phishing, malware and social engineering.
The attack vectors threat actors can take ranges as well, depending on the target environment, organization, and scenario. They can include malware, social engineering, or network and physical-based attacks. Each of these attack vectors warrants a corresponding appropriate mitigation control/technique, making it difficult for large complex organizations in particular to mitigate every attack vector at all times.
Attack targets include source code, credentials and sensitive data. Types exploits vary from activities such as the injection of vulnerabilities and malware, stolen credentials and injecting malicious code into repositories. NIST lists a robust set of mitigation measures from fundamental activities such as patch management and access control to auditing and monitoring as well as aligning with applicable regulatory frameworks.
CI/CD pipelines – trust, goals, and secure outcomes
Modern DevSecOps environments use CI/CD platforms and technologies to facilitate iterative software development and delivery. As software passes through the various phases of build, package, test, and deployment, these phases produce metadata that can facilitate assurance around the provenance of the software and the steps and measures that went into producing it.
A compromise of any of the steps, as well as the underlying CI/CD environments and platforms can have a downstream impact on the integrity of the software artifacts that are produced and distributed.
Organizations must take security measures for both internally developed (first-party) code, as well as third-party components, such as open source software, which are increasingly making up the bulk of modern software, at least from a source code perspective.
Organizations are ultimately looking to ensure that attackers cannot tamper with the software production process, introduce malicious software updates, or compromise the integrity of CI/CD pipeline artifacts and activities. NIST provides the below table demonstrating the artifacts that need to be trusted in typical CI/CD environments, as well as the repository the artifacts generally reside in/depend on:
| Artifact | Repository |
| First-party code – source code or binary | SCM |
| Third-party code – open source or commercial | Artifact managers for language, container, etc. |
| Builds | Build Repository |
| Packages | Package repository |
Software supply chain security in CI/CD pipelines
Now that we’ve discussed some of the background, security goals and entities involved in trusted CI/CD pipelines, let’s take a look at some of the specific SSC security activities that NIST emphasizes in their guidance.
It should come as no surprise that NIST evangelizes zero-trust principles here as well, given their publication of 800-207 “Zero Trust Architecture”. The recommendations cited include defining roles for system operators, mapped to specific permissions and implementing least-privileged access aligned with the concept of role-based access control (RBAC). Activities like these mitigate the risk should a specific actor’s account or assets get compromised.
NIST also recommends automating the use of SAST and DAST, as well as declaratively defining the development and deployment of application code and CI/CD activities through techniques such as infrastructure-as-code (IaC) and policy/configuration-as-code, which can specify runtime settings for security and compliance purposes. The workflows of CI/CD pipelines must also be secure, including build, push/pull of artifacts from repositories and software updates or code commits.
NIST recommendations for builds
On the build front, recommendations include key activities such as specifying build policies and the use of isolated build platforms as well as permissions for those performing build activities. Organizations should also make use of policy enforcement engines and ensure that during the software build process evidence and attestations of secure build processes is produced.
These may include attestations for the environment, process, materials, and artifacts involved. NIST recommends the use of hashing to include the final build artifact, files, libraries, and events that produce the final artifacts.
There is then a recommendation to sign the attestation and securely store it where it can be used to demonstrate policy compliance. Doing so can help demonstrate that software was built by authorized entities, tools and with alignment to defined policies and compliance requirements.
In addition to the need for secure build activities NIST also recommends securing pull-push operations on SCM repositories. This includes the pull of code from repositories by developers, its modification and then the push of code back to the repository, each of which presents an opportunity for tampering. Recommendations include automated security checks on artifacts, ensuring confidence in the source code origin, and requiring explicit approval for all outside collaborators looking to push and pull from a repository.
Bad actors slip malicious code into repositories
The below image from Francois Proulx demonstrates how a malicious actor can take various actions to gain unauthorized access to a GitHub repository and submit malicious code to a repository.
NIST demonstrates how a malicious actor can take various actions to gain unauthorized access to a GitHub repository.
Among its other key recommendations, NIST advises maintaining the integrity of evidence generation during software updates, securing code commits, and securing workflows in CD pipelines. Attackers may look to erase or tamper with software update trails to mitigate investigation and detective controls.
In addition, to ensure code commits don’t introduce malicious code or vulnerable code, NIST recommends the use of SAST/DAST tooling in CI/CD pipelines with broad language coverage, and the use of SCA tooling to verify the security of OSS components and dependencies.
Since CD pipelines revolve around workflows and many modern environments are making use of technologies such as containerization, NIST recommends ensuring that containers being deployed were actually generated by the defined build process and that they have been scanned for vulnerabilities in alignment with an organization’s vulnerability management requirements.
Lastly, given the myriad of high-profile secret exposures the industry has seen lately, NIST recommends organizations scan for the presence of secrets in code, such as keys or access tokens, which can be abused by malicious actors for nefarious purposes.