As the neverending stream of publications implementing Executive Order (EO) 14028 continue to drop, the National Institute of Standards and Technology (NIST) continues to provide additional guidance. At the end of August 2023, NIST released its most recent draft Special Publication (SP) 800-204D “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD pipelines.” Although NIST will collect comments until October 13, 2023, this draft provides some insight into the agency’s future direction. In response to attacks targeting the software supply chain (SSC), NIST published SP 800-204D as a follow up to its Secure Software Development Framework (SSDF), integrating security assurance into CI/CD pipelines. 

Although developers don’t need to know all the details, you may want to have a high level understanding of the basic principles outlined in NIST’s “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD pipelines.”

Differentiating between software supply chain defects and software supply chain attacks

At the outset, NIST notes that SSDF as an application architecture may not map to the Software Development Lifecycle (SDLC) that cloud-native application developers use. To tie everything together, the agency identifies these following SSC activities:

• Dependency management
• Writing source code
• Building, packaging, and delivering an application
• Repacking and containerization

In doing this, NIST explains that the SSC model applies to elements of secure software development, secure build systems, and dependency management.

Additionally, NIST makes the following distinction:

• Software Supply Chain Defects: unintended defects that malicious actors can exploit, like Log4Shell
• Software Supply Chain Attacks: malicious tampering with steps, artifacts, or actors intended to compromise software artifact consumers

A SSC attack occurs in the following three stages:

• Artifact, step, or actor compromise that modifies an artifact or its information
• Propagation throughout the chain
• Exploitation by the attacker to achieve objectives

SSC Risk Factors

NIST categorizes the risk factors into five groups:

• Developer environment: workstations and environments 
• Threat actors: internal threats (disgruntled employees or contractors) and external threats (foreign adversaries, criminal organizations, and cyber activists)
• Attack vectors: malware, social engineering, network-based attacks, physical attacks
• Attack targets: at-risk assets like source code, credentials, and sensitive data
• Types of exploits: malicious actors seeking to compromise components by injecting vulnerabilities or malware into SSC, using stolen credentials, leaking sensitive data, injecting malicious code into repositories, leveraging code integrity issues in public repositories

Mitigation Measures

Noting that a secure software development environment reduces the likelihood that an organization will experience a security incident, NIST outlines the following generic mitigation measures relevant to an SSC:

• Patch management
• Access control
• Malware protection
• Secure SDLC
• Data protection
• Physical security
• Audit and monitoring
• Adherence to applicable security standards (e.g., regulatory requirements)

Additionally, NIST identify the importance of:

• Baseline security: open-source software repository review as part of security best practices to mitigate risks like malicious actors typosquatting, compromising repositories, or legally acquiring repositories
• Controls for interacting with software configuration management (SCM): tightly controlling high-risk write access to SCMs, segregating path proposal and code review duties, implementing code analysis tools

Identifying CI/CD Pipeline Security Goals and Trusted Entities

To protect CI/CD pipelines, SSC security means that workflows across the CI/CD pipeline should generate as much provenance data as possible. 

NIST identifies two broad security goals:

• Incorporating defensive measures so attackers can’t tamper with software production processes or introduce malicious software updates
• Ensuring CI/CD pipeline artifact integrity an activities through actor role definitions and authorizations

Further, when developers need to verify artifact and repository integrity to provide assurance over the CI/CD pipelines, listing the following entities that need to be reviewed:

• First party code and the associated repository
• Third-party code and the associated artifact managers
• Builds and their associated build repository
• Packages and their associated package repository

Integrating SSC Security into CI/CD Pipelines

NIST identifies different security activities for CI pipeline and CD pipeline workflows based on the activities associated with them. 

Securing Workflows in CI Pipelines

Security goals for running CI pipelines include:

• Supporting cloud-native and legacy software environments
• Standardizing compliant evidence structures
• Supporting various hardware and software platforms
• Supporting infrastructures that generate evidence

Secure Build

To obtain SSC security assuring during the build process, developers must:

• Specify policies that include using a secure isolated platform, the tools that perform the build, and the developers’ authentication/authorization requirements
• Enforcing build policies
• Ensuring build attestation with real-time-generated evidence

Build attestation consists of documentation across the following components:

• Environment: platform used to run build process must be hardened, isolated, and secure
• Process: computer programs transforming original source code or materials into an artifact and/or programs performing testing, like a code testing tool
• Materials: raw data, including configuration, source code, and other data 
• Artifacts: results of a CI process, like source code’s executable binary and scan results

Secure PULL-PUSH Operations on Repositories

When securing PULL-PUSH operations, security must look at both the authorization to perform operations and the code’s trustworthiness. 

User access reviews include:

• Implementing authentication that authorizes developers to perform operations
• Ensuring access aligns with developer’s role

When reviewing code trustworthiness, developers should use the following mechanisms:

• PULL-PUSH_REQ-1: use automated checks on all artifacts in the pull request
• PULL-PUSH_REQ-2: only use external tools, like Jenkins, after establishing confident in the source-code origin’s trustworthiness
• PULL-PUSH_REQ-3: configure repository or SCM system built-in protections that require maintainers with write access to approve CI workflow runs submitted by outside collaborators to the strictest level
• PULL-PUSH_REQ-4: use external security tools when SCM system lacks native built-in protections or to enhance existing protections

Integrity of Evidence Generation During Software Updates

Securing software update systems protects against threat actors trying to evade detection when they maliciously manipulate code. 

NIST outlines the following consensus goals for its evolving framework around securing software updates systems:

• Protecting against attacks on the tasks that software update systems perform
• Minimizing the impact of a key compromise
• Being flexible to apply to various software update systems
• Being easy to integrate with software update systems

Secure Code Commits

Before code commits, teams should engage in appropriate testing that meets the following requirements:

• Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) cover different language systems used in cloud-native applications 
• Software Composition Analysis (SCA) tools should be used to detect dependence and their security conditions

Additionally, when scanning to prevent secrets being committed to code, the push protection should:

• COMMIT-REQ-1: generate an alert identifying the secret type, location, and remediation method

• COMMIT-REQ-2: be enabled for all repositories assigned to an admin

Securing Workflows in CD Pipelines

Some typical due diligence measures that developers can implement for deployment include:

• DEPLOY-REQ-1: Specify that deployed artifact must be generated by the secure build environment before being cleared for deployment
• DEPLOY-REQ-2: Check for evidence that container image was scanned for vulnerabilities and attested vulnerability findings to allow or blog image deployment based on organization-defined policies
• DEPLOY-REQ-3: Invoke security scanning sub-feature to detect hard coded secrets, like keys and access tokens
• DEPLOY-REQ-4: review dependencies for details of any vulnerable versions 

Qwiet AI: Automation for Software Supply Chain Security in CI/CD Pipelines

By integrating Qwiet AI into your existing CI/CD pipelines, ticketing systems, and development tools, you can accelerate your SSC security practices without slowing down your processes. Further, Qwiet AI’s preZero platform gives you visibility into all third-party libraries and frameworks while focusing only on those vulnerabilities that pose an actual threat to your application. By focusing on reachability, our AI/ML considers the context of a vulnerability within your source code, giving you a way to prioritize your remediation activities. With preZero’s combination of known vulnerabilities, heuristic detections, and guided AI, developers spend less time hunting down false positives or upgrades that could be completed later for faster time to market. 

Take our preZero platform for a free spin to see how Qwiet AI can help you secure your SSC today.