NIST SP 800-204D 日本語訳

Ramaswamy Chandramouli

Frederick Kautz Santiago Torres-Arias

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-204D

Ramaswamy Chandramouli Computer Security Division Information Technology Laboratory

Frederick Kautz TestifySec

Santiago Torres-Arias

Electrical and Computer Engineering Department

Purdue University

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-204D

February 2024

U.S. Department of Commerce Gina M. Raimondo, Secretary

National Institute of Standards and Technology

Laurie E. Locascio, NIST Director and Under Secretary of Commerce for Standards and Technology

Certain commercial equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

NIST Technical Series Policies Copyright, Use, and Licensing Statements NIST Technical Series Publication Identifier Syntax

Publication History Approved by the NIST Editorial Review Board on 2024-01-31

How to Cite this NIST Technical Series Publication: Chandramouli R, Kautz F, Torres-Arias S (2024) Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-204D. https://doi.org/10.6028/NIST.SP.800-204D

Author ORCID iDs Ramaswamy Chandramouli: 0000-0002-7387-5858

Contact Information sp800-204d-comments@nist.gov

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

Additional Information Additional information about this publication is available at https://csrc.nist.gov/pubs/sp/800/204/d/final, including related content, potential updates, and document history.

All comments are subject to release under the Freedom of Information Act (FOIA).

The predominant application architecture for cloud-native applications consists of multiple microservices, accompanied in some instances by a centralized application infrastructure, such as a service mesh, that provides all application services. This class of applications is generally developed using a flexible and agile software development paradigm called DevSecOps. A salient feature of this paradigm is the use of flow processes called continuous integration and continuous deployment (CI/CD) pipelines, which initially take the software through various stages (e.g., build, test, package, and deploy) in the form of source code through operations that constitute the software supply chain (SSC) in order to deliver a new version of software. This document outlines strategies for integrating SSC security measures into CI/CD pipelines.

actor; artifact; attestation; CI/CD pipeline; package; provenance; repository; SBOM; SDLC; SLSA; software supply chain.

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

The authors would like to express their thanks to Isabel Van Wyk of NIST for her detailed editorial review, both for the public comment version as well as for the final publication.

Cloud-native applications are made up of multiple loosely coupled components called microservices. This class of applications is generally developed through an agile software development life cycle (SDLC) paradigm called DevSecOps, which uses flow processes called Continuous Integration/Continuous Delivery (CI/CD) pipelines.

Analyses of recent software attacks and vulnerabilities have led both government and private-sector organizations involved in software development, deployment, and integration to focus on the activities involved in the entire SDLC. This collection of activities constitutes the software supply chain (SSC), and the integrity of the individual activities contributes to the overall security of an SSC. Threats can arise from attack vectors unleashed by malicious actors during SSC activities as well as defects introduced when due diligence practices are not followed by legitimate actors during the SDLC.

Executive Order (EO) 14028, NIST’s Secure Software Development Framework (SSDF) [2], other government initiatives, and industry forums have discussed the security of SSC and provided a roadmap to enhance the security of all deployed software. This document uses this roadmap as the basis for developing actionable measures to integrate the various building blocks of SSC security assurance into CI/CD pipelines to enhance the preparedness of organizations to address SSC security in the development and deployment of cloud-native applications. To demonstrate that the SSC security integration strategies for CI/CD pipelines meet the objectives of SSDF, a mapping of these strategies to the high-level practices in the SSDF has also been provided.

原本PDFの抜粋画像

Building a robust SSC security edifice requires various artifacts, such as a software bill of materials (SBOM) and frameworks for the attestation of software components. Since the specification of these artifacts, their mandatory constituents, and the requirements that processes using them must satisfy are continually evolving through projects in government organizations and various industry forums, they are beyond the scope of this document.

Cloud-native applications typically consist of multiple loosely coupled services or microservices and are sometimes accompanied by an integrated application service infrastructure, such as a service mesh. The applications are developed through an agile software development life cycle (SDLC) paradigm called DevSecOps, which uses flow processes called Continuous Integration/ Continuous Delivery (CI/CD) pipelines. The security of applications during runtime is ensured through various security measures, such as assigning unique service identities for microservices and subjects that invoke those services and policy enforcement through proxies. However, sophisticated attacks on software have been carried out through the stealthy introduction of attack vectors during various activities in the SDLC, which collectively constitute the software supply chain (SSC). Thus, in the context of cloud-native applications, SSC security assurance measures must be integrated into CI/CD pipelines.

This document outlines strategies for integrating SSC security assurance measures into CI/CD pipelines to protect the integrity of the underlying activities. The overall goal is to ensure that the CI/CD pipeline activities that take source code through the build, test, package, and deployment stages are not compromised.

SSC security assurance measures use various artifacts, such as a software bill of materials (SBOM) and frameworks for the attestation of software components. The specification of these artifacts, their mandatory constituents, and the requirements that processes using them must satisfy are continually evolving through projects in government organizations and various industry forums and are, therefore, beyond the scope of this document. Rather, this document focuses on actionable measures to integrate various building blocks for SSC security assurance into CI/CD pipelines to enhance the preparedness of organizations to address SSC security in the development and deployment of their cloud-native applications.

This document is intended for a broad group of practitioners in the software industry, including site reliability engineers, software engineers, project and product managers, and security architects and engineers.

This document is part of the NIST Special Publication (SP) 800-204 series of publications, which offer guidance on providing security assurance for cloud-native applications that are developed and deployed using the DevSecOps SDLC paradigm that uses CI/CD pipelines. SP 800-204C [1] discusses DevSecOps, which is an agile software development paradigm for cloud-native applications that focuses on the various types of code involved in microservices-based applications that are supported by a service mesh infrastructure. SP 800-218 [2] provides a comprehensive list of high-level practices and tasks for ensuring SSC security under the Secure Software Development Framework (SSDF) based on the directives in Executive Order (EO) 14028 [3]. Other documents in the SP 800-204 series outline the mechanisms for enforcing various types of access controls for inter-service calls in the microservices environment during runtime.

This document presents strategies for integrating SSC security into CI/CD pipelines through the identification of workflow tasks that can meet the goals of the various high-level practices outlined in the SSDF. Not all practices and tasks outlined in the SSDF may be applicable to the environment under discussion in this document – i.e., cloud-native applications developed using the DevSecOPs SDLC paradigm with CI/CD pipelines, representing a specific application architecture and SDLC, respectively. The SSDF is agnostic to both application architecture and the SDLC paradigm. However, to demonstrate that the SSC security integration strategies for CI/CD pipelines meet the objectives of SSDF, Appendix A provides a mapping of these strategies to the high-level practices in the SSDF. However, tasks relating to secure software design and the enterprise-level vulnerability management strategies are beyond the scope of this document and these are indicated in Appendix B.

This document is organized as follows:

Most activities in the SSC strongly affect the resulting software product. As such, the security of each individual activity is paramount for the security of the end result. This includes both the integrity of the activities themselves as well as the assurance that all activities were carried out and — conversely — that no unauthorized activities were injected into the chain.

While software composition (e.g., dependency management) is under the purview of software supply chain activities, other often overlooked activities are central to the software supply chain. This includes writing source code; building, packaging, and delivering an application; and repackaging and containerization.

An SSC attack can take on several forms, such as:

SSC attacks can have a wide range of consequences that affect the correctness, integrity, or availability of a software product (e.g., making upstream dependencies unavailable). In practice, attackers often target the activities mentioned above to implant backdoors and subsequently compromise a target (i.e., end product) or exfiltrate sensitive information once the application is delivered.

SSC security should also account for discovering and tracking software security defects rather than simply mitigating attacks. To facilitate this, the software bill of materials (SBOM) must be shared with end users so that they can build inventories of software components. However, while SBOMs enable the identification of components and provenance, they do not provide enough information to address vulnerabilities nor content to address software defects. Hence, SBOMs alone cannot be used for vulnerability management. They simply provide the list of components to focus on when addressing vulnerabilities or defects in software.

SSC attacks have two fundamental properties that make them appealing to attackers. First, they allow attackers to infiltrate highly-regulated environments through less secure but legitimate channels. Second, due to the highly-interconnected nature of supply chains, they allow for widespread damage in a short period of time.

Insufficient care in operating highly regulated environments throughout the SDLC often allows motivated attackers to identify weak spots in the chain. In the case of SOLORIGATE [4], for example, attackers identified a single point of compromise that delivered software to multiple government agencies. Such attacks are also stealthy because they typically propagate through legitimate channels, such as software updates, which allows for widespread damage to users of the target software. These attacks are successful because of the significant amount of implicit trust present in these legitimate channels, and a first defensive measure calls for the removal of this implicit trust. Since attackers typically seek this avenue to obtain short-term benefits, widespread attacks of this nature often rely on the use of private crypto miners and cryptojackers. This is evidenced in the prevalence of these vectors existing in breadth-first approaches, such as typo and combosquatting attacks. Regardless of the motivations of the attackers, both vectors highlight the possibility of devastating impacts when attacks are successful.

Due to the distributed nature of an SSC, multiple practices, developer cultures, security and quality expectations, and legislative frameworks exist. As a consequence, there is no unified governance model, and these distinct models often overlap.

At a high level, an SSC is a collection of steps that create, transform, and assess the quality and policy conformance of software artifacts. These steps are often carried out by different actors who use and consume artifacts to produce new artifacts. For example, a build step uses a series of artifacts as tools (e.g., a compiler and a linker) and consumes artifacts (i.e., source code) to produce a new artifact (i.e., the compiled binary).

Without a loss of generality, this same definition can be applied to other actions, such as writing code, packaging an application inside of a container, and performing quality assurance. This definition also encompasses more activities than are colloquially considered. That is, it includes elements of secure software development, secure build systems, and dependency management. These elements collectively define the SSC model.

While this simplified model can accommodate multiple activities, mitigations and attacks may surface in different, nuanced ways for each activity.

Fig. 1. Interaction between the different elements¹ of a software supply chain (SSC) step²

Much like software defects (i.e., bugs), defective artifacts can propagate throughout an SSC and affect its security posture. A noteworthy example of such a defect is Log4Shell [5], where a vulnerability in a highly-used software artifact allowed attackers to compromise a large number of targets with very little effort.

If software is used in a manner that it was not originally intended or configured for, it may result in an insecure state. However, while the line between a defect and an attack is often blurred in the context of SSC, the guiding principle is that of intent — that is, whether or not the upstream actor intended to exploit that defect. In the context of software engineering, not all defects are vulnerabilities, regardless of intent. Vulnerabilities may be present for other reasons, and that presence does not guarantee exploitation, which is what defines an attack. Malicious actors complete the defect-attack chain by intentionally introducing weaknesses that they can later exploit.

In contrast to defects, an SSC attack is when a malicious party tampers with the steps, artifacts, or actors within the chain to compromise the consumers of a software artifact down the line.

Explicitly, an SSC attack is a three-stage process:

This section considers the various risk factors that are applicable to the SDLC environment and the mitigation measures that can counter those risks.

The risk factors in an SSC typically include:

Developer workstations and their environments present a fundamental risk to the security of an SSC and should not be trusted as part of the build process since they are at risk of compromise. Mature SDLC processes accept code and assets into their software configuration management (SCM) mainline and versions branches only after code reviews and scanners are in place.

Threat actors are generally:

External attackers may include foreign adversaries, criminal organizations, and cyber-activists who target an SSC for various reasons, such as espionage or sabotage. Internal attackers pose a significant risk, as they may have insider access to sensitive information — often using legitimate access rights — that allow them to launch attacks or steal confidential information. Additionally, both categories of threat actors may use a variety of techniques to compromise the SDLC environment and steal or manipulate software, such as phishing, malware, social engineering, and physical access. Therefore, companies should be aware of these risks and take appropriate measures (see Sec. 3.2) to secure their SSC.

Non-malicious threat actors may also impact the security of supply chains, such as a software engineer who inadequately manages secrets through a lack of tooling or purposeful subterfuge for ease of use. Organizations should be aware of these situations and take suitable measures to avoid such practices.

Attack vectors in an SSC include:

Attack vectors can originate from various sources, including malware attacks on developer workstations, social engineering attacks on developers, network-based attacks on the development environment, and physical attacks on the hardware or networks used by developers. These different attack vectors require distinct countermeasures, including endpoint protection software, network security controls, access control policies, and physical security measures. Companies should identify potential risks and vulnerabilities, assess their security posture, and implement appropriate defensive measures to mitigate threats to their SDLC environment.

In the case of ingested code, it is essential to verify the provenance information of the component being used to ensure that it is what it says it is and is coming from an expected source. Mitigations for this involve caching or curating packages and components for preferred use.

The assets targeted under an SSC may include:

A software developer’s workstation typically contains various assets, including source code, credentials, and access to sensitive information, such as personally identifiable information (PII), protected health information (PHI), intellectual property (IP), cryptographic materials (e.g., software artifact signing keys), and proprietary information. Companies should identify critical assets and implement controls to protect them from unauthorized access, such as access controls, multi-factor authentication, encryption of data at rest and in transit, and data loss prevention (DLP) measures.

Exploits in the context of attack vectors and targeted assets in an SSC typically include:

Threat actors may seek to compromise various components of the SDLC process, including source code, testing environments, development tools, and build pipelines. They may introduce vulnerabilities, malware, or stolen credentials to gain access to other systems or compromise sensitive data. Such threats can result in financial losses, reputational damage, physical damage and legal consequences.

To inject malicious code into repositories, attackers may perform an operation called “forking,” which allows the attacker to copy some repository and freely make modifications outside of the original project. The attacker then initiates a pull request to merge the forked project with the original project. If the project maintainer accepts the request without properly and adequately reviewing the changes and determining them to be suitable, they will merge them into the original project, thus introducing malicious code into the repository.

When open-source code is used, an artifact or package is often pulled from a repository based on the reputation of the developer or the repository. However, there is no guarantee that pulled code is the same software that the developer authored and checked into their source- code repository. The following actions could have potentially occurred, resulting in a lack of assurance or an inability to trust the code:

原本PDFの抜粋画像

A secure SDLC environment can reduce the likelihood of security incidents and ensure the confidentiality, integrity, and availability of software assets and systems. It is crucial to assess security risks and implement appropriate defensive measures to protect software supply chains against compromise.

The following generic mitigation measures are applicable to the entire SDLC but are particularly relevant to an SSC:

Organizations can implement various controls to mitigate risks to their SDLC environment, including regular patch management, robust authentication, granular authorization, malware protection, secure SDLC practices, data protection measures, physical security controls, and auditing and monitoring tools. They should regularly assess their security posture, identify potential weaknesses and vulnerabilities, and implement appropriate defensive measures to address them. Organizational network policies that account for and actively block maliciously known content-serving domains can reduce the use of software from non-curated or undesired locations. Another integral part of SSC security involves capturing the dependencies (e.g., package name, version) of the artifacts in a central repository. Organizations should also ensure that their SDLC environment remains compliant with various security and other relevant standards, such as the Open Worldwide Application Security Project (OWASP) Top Ten, SP 800-53, Health Insurance Portability and Accountability Act (HIPAA), and Payment Card Industry Data Security Standard (PCI DSS).

The choice of a mitigation approach will depend on the organization’s customized threat model. However, all developer systems should meet a predefined minimum baseline for security to ensure that the operating system and applications are kept up to date with the latest security patches, individual and unshared user accounts are adequately protected, and proper access controls are enforced when interacting with SCM.

Independent and open-source developers will need to follow best practices to protect their own systems. Government and enterprise environments should establish and adhere to a well-defined security policy that meets regulatory requirements and industry best practices. Since the development of such a policy is out of scope for this document, readers should refer to SP 800-53r5 (Revision 5) [6] for a more complete treatment of this topic.

The following are some baseline security measures that should be adopted when integrating open-source software (OSS) components into any enterprise project:

Developers use their workstations to create, edit, and test source code. This process requires developers to pull source code from the SCM, modify the source code, and submit changes (i.e., patches) back to the SCM. The proposed changes should adhere to the SDLC processes defined by the organization. Pull access to the software depends on the policies of the software project in question (e.g., open-source projects typically allow anyone to pull, replicate, modify, and share the source code with minimal or copyleft restrictions). Proprietary software vendors often enforce strict rules that describe who is allowed to access the source code and under what conditions. In all cases, write access to the SCM should be considered a high risk and tightly controlled. A mature SDLC process allows developers to propose patches to the SCM, but another developer should perform a code review before the patch is merged. Code analysis tools should be implemented to catch common mistakes, but care should be taken to not inundate the developers with too many false positives to prevent alert fatigue.

DevSecOps is an agile paradigm used for the development and deployment of cloud-native applications. This paradigm consists of a series of stages that takes code from variously sourced repositories (e.g., first-party or in-house, third parties or open-source/commercial) to perform tasks or activities, such as building, packaging, testing, and deploying.

In this document, the term “artifacts” denotes source code as well as the things generated from it, such as builds and packages. Each of the artifacts is associated with an owner. The logical containers that hold these artifacts are called repositories. The build process is based on application logic-driven dependencies and generates builds using many individual source-code artifacts that are stored in build repositories. The build artifacts are tested and used to generate packages whose artifacts are then stored in designated repositories and scanned before being deployed in testing or production environments. These stages and the various tasks performed at each stage are collectively called CI/CD pipelines. In other words, CI/CD pipelines use processes called workflows to transform source artifacts to deployable packages in production environments.

A common approach to SSC security in all of these workflows is to generate as much provenance data as possible. Provenance data are associated with the chronology of the origin, development, ownership, location, and changes to a system or system component, including the personnel and processes that enabled those changes or modifications. The generation of these data should be accompanied by corresponding mechanisms to validate, authenticate, and leverage them in policy decisions.

原本PDFの抜粋画像

From the above description of CI/CD pipelines and associated activities, one can identify the set of security assurance measures that need to be added:

There are two security goals in the application of SSC security measures or practices in CI/CD pipelines:

The most common approach is to introduce security measures into the CI/CD platform, which allows developers to automate their build, test, and deployment pipelines. There are many open-source and commercial CI/CD platforms available on the market.

原本PDFの抜粋画像

Zero trust architectures focus on protecting resources such as hardware systems (e.g., servers), services and the application itself. The entities that access these assets (e.g., users, services, and other servers) are not inherently trusted, and the primary goal of zero trust architecture is to establish this trust. In the context of CI/CD pipelines, the scope of trust is much larger and requires, at a minimum, the following steps:

Table 1 gives examples of entities (i.e., artifacts and repositories) that need to be trusted in typical CI/CD pipelines [7].

Table 1. Top-level entities in the trust chain of typical CI/CD pipelines³

ᵃ Here, the artifacts include only those that go directly into the final software products. Other artifacts used for the security assurance of CI/CD processes (e.g., SBOMs, vulnerability reports, and model registries that use AI models) must also be trusted. ᵇ The addition of attestations like VSA does not necessarily imply that the artifact manager is trusted.

In order to outline the strategies for integrating SSC security into CI/CD pipelines, it is necessary to understand the workflows in each of the two pipelines (i.e., CI pipelines and CD pipelines) and their overall security goals.

The prerequisites to activating CI/CD pipelines include the following:

The workflows in the CI pipeline mainly consist of build operations, push/pull operations on repositories (both public and private), software updates, and code commits.

The overall security goals for the framework used for securely running CI pipelines include:

The following subsections consider the SSC security tasks for the various workflows in CI. Although providing support for artifact testing (that generates tamper-proof records of test runs and associated results) is an important security goal, it is beyond the scope of this document.

The following tasks are required to obtain SSC security assurance in the build process:

A common technique for facilitating the second task is to wrap commands from a CI tool with capabilities to gather evidence and ultimately create an evidence trail of the entire SDLC [8]. The first type of evidence is from the build system itself, which should be able to confirm that the tools or processes used are in an isolated environment. This provides internal operational assurance. The second type of evidence that should be gathered consists of the hash of the final build artifact, files, libraries, and other materials used in the artifacts and all events. This is then signed by a trusted component of the build framework that is not under the control of the developers using a digital certificate to create the attestation, which provides verifiable proof of the quality of the software to consumers and enables them to verify the quality of that artifact independently from the producer of the software, thus providing consumer assurance. In this context, the artifact is the build generated by a series of CI process steps.

In the context of “concurrent generation of evidence,” the evidence generated should be enabled by a process with a higher level of trust or isolation than the build itself to protect against tampering. The generation of such evidence requires verification within the build as it occurs.

The attestation for a build consists of the following components [9]:

The requirements associated with signed evidence (i.e., attestation) and its storage must include the following:

The attestations can then be used to evaluate policy compliance. A policy is a signed document that encodes the requirements for an artifact to be validated. The policy may include checks as to whether each of the functionaries involved in the CI process has used the right keys to generate the attestations, the required attestations are found, and the methodology to evaluate the attestation against its associated metadata has also been specified. The policy enables the verifiers to trace the compliance status of the artifact at any point during its life cycle.

The above capabilities collectively provide the following assurances:

The first SSC security task is to secure source-code development practices. In the context of CI/CD pipelines, code resides in repositories, is extracted by authorized developers using a PULL operation, is modified, and is then put back into the repositories using a PUSH operation. To authorize these PULL-PUSH operations, two forms of checks are required:

The various mechanisms for ensuring the trustworthiness of the code in the repository are:

An example of such a tool is the popular open-source tool OpenSSF scorecard.⁴

The software update process is typically carried out by a special class of software development tool called software update systems. Ensuring the security of these software update systems plays a critical role in the overall security of an SSC. Threats to software update systems primarily target the evidence generation process so as to erase the trail of updates and prevent the ability to determine whether the updates were legitimate or not.

There are several types of software update systems [11]:

The primary task performed by a software update system is to identify the files that are needed for a given update ticket and download trusted files. At first glance, it may appear that the only checks needed to establish trust in downloaded files are the various integrity and authenticity checks performed by verifying the signatures on the metadata associated with individual files or the package. However, the very process of signature generation may be vulnerable to known attacks, so software update systems require many other security measures related to signature generation and verification.

The evolving framework for providing security for software update systems has incorporated many of these required security measures into its specification and prescribed some others for future specifications. A framework is a set of libraries, file formats, and utilities that can be used to secure new and existing software update systems. The framework should protect the signing operation by requiring the policy defined in Sec. 5.1.1 to be satisfied prior to performing the signing operation. The following are some of the consensus goals for the framework:

Appropriate forms of testing should be performed before code commits, and the following requirements must be met:

One SSC security measure required during code commits is the prevention of secrets getting into the committed code. This is enabled by a scanning operation for secrets and results in a feature called push protection [12], [20]. This feature should satisfy the following requirements:

Supply chain security measures also apply to controls during the CD process. The following are some due diligence measures that should be used during CD. These measures can be implemented by defining verification policies for allowing or disallowing an artifact for deployment.

A container image should be scanned for vulnerabilities as soon as it is built, even o before it is pushed to a registry. The early scanning feature can also be built into local workflows.

The tools used to interact with repositories that contain container images and o language packages should be capable of integration with CD tools, thus making all activities an integral part of automated CD pipelines.

All operations during and after a build in the CI/CD pipeline involve interacting with a central repository (e.g., Bitbucket, GitHub, and GitLab). The operations are collectively called GitOps, which is an automated deployment process facilitated by open-source tools, such as Argo CD and Flux. GitOps is carried out for both infrastructure code and application code and consist of commits, forking, and pull and push requests. The usage of GitOps covers the following [16]:

The following SSC security tasks should be applied with respect to creating configuration data prior to deployment, capturing all data pertaining to a particular release, modifying software during runtime, and performing monitoring operations:

Administrators can choose to automatically resync configurations to the defined o state.

Notifications should be sent regarding the differences, and manual remediation o should be performed.

The extensive set of steps needed for SSC security cannot be implemented all at once in the SDLC of all enterprises without a great deal of disruption to underlying business processes and operational costs. Rather, solutions that provide SSC security can be broadly classified into the following types [17]:

a. Verifying that the software is built correctly by ensuring tamper-proof build pipelines, such as by providing verified visibility into the dependencies and steps used in the build [18], since compromised dependencies or build tools are the greatest sources for poisoned workflows.

b. Including features for the specification of checklists for each step of the delivery pipeline to provide guidance for implementation and to check and enforce controls for complying with checklists.

This document provided an overview of strategies for integrating SSC security assurance measures into the various workflows associated with CI/CD pipelines, which is a methodology in the DevSecOps paradigm that is widely used for the development and deployment of cloud-native applications. However, no recommendations were provided with respect to the specific artifacts and frameworks associated with SSC security, such as SBOMs, code signing, and attestation. This is due to the fact that specifications and the standards associated with them are still evolving as part of projects in government institutions and industry forums. Further, NIST is aware of the emergence of a DevSecOps platform that provides an integrated set of services covering both CI and CD pipelines. Since this platform is not yet mature and there is a lack of consensus regarding the set of baseline features pertaining to it, the requirements for the secure use of this platform to carry out the activities in the CI/CD workflows are not discussed in this document.

[1] Chandramouli R (2022) Implementation of DevSecOps for a Microservices-based Application with Service Mesh. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-204C.

https://doi.org/10.6028/NIST.SP.800-204C

[2] Souppaya M, Scarfone K, Dodson D (2022) Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-218. https://doi.org/10.6028/NIST.SP.800-218

[3] EO 14028 (2021) Improving the Nation’s Cybersecurity. Available at https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity [4] Goud N (2021) What is Solarigate. Available at https://www.cybersecurity-insiders.com/what-is-solorigate/ [5] Berger A (2023) What is Log4Shell? Available at https://www.dynatrace.com/news/blog/what-is-log4shell/#:~:text=Log4Shell%20is%20a%20software%20vulnerability,logging%20error%20messages%20in%20applications [6] Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 5. Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5 [7] Lorenc D (2021) Zero Trust Supply Chain Security. Available at https://dlorenc.medium.com/zero-trust-supply-chain-security-e3fb8b6973b8 [8] Testify/Witness (2023) Witness – Secure Your Supply Chain. Available at https://github.com/testifysec/witness/ [9] Kennedy C (2021) What is a Software Supply Chain Attestation – and Why do I need it? Available at https://www.testifysec.com/blog/what-is-a-supply-chain-attestation/ [10] Gelb Y (2023) Mass Scanning of Popular GitHub Repos for CI Misconfiguration. Available at https://medium.com/checkmarx-security/mass-scanning-of-popular-github-repos-for-ci-misconfiguration-cd36ad6be788 [11] TUF V1.0.31 (2022) The Update Framework Specification. Available at https://theupdateframework.github.io/specification/latest/ [12] Malik Z, Sulakian M (2023) Push Protection is generally available. Available at https://github.blog/2023-05-09-push-protection-is-generally-available-and-free-for-all-public-repositories/?utm_source=thenewstack&utm_medium=website&utm_content=inline-mention&utm_campaign=platform [13] GitHub Docs (2023) Enabling Security Features for Multiple Repositories. Available at https://docs.github.com/en/enterprise-cloud@latest/code-security/security-overview/enabling-security-features-for-multiple-repositories

原本PDFの抜粋画像

[14] Cloud Build (2023) Securing Image Deployments to Cloud Run and GKE. Available at https://cloud.google.com/build/docs/securing-builds/secure-deployments-to-run-gke [15] GitHub Docs (2023) About dependency review. Available at https://docs.github.com/en/enterprise-cloud@latest/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review [16] Williams A (2021) A Blueprint for Supply Chain Security. Published by Newstack [17] Crane D (2023) Five Stages for A Secure Software Supply Chain. Available at https://danacrane.medium.com/five-stages-for-a-secure-software-supply-chain-f8420841cc3a [18] CyRise (2023) Supply Chain Security with Ensignia. Available at https://medium.com/@cyrise/supply-chain-security-with-ensignia-483c1d872639 [19] GitLab Docs (2023) Dependency Scanning. Available at https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html [20] GitLab Docs (2023) Secret Detection. Available at https://docs.gitlab.com/ee/user/application_security/secret_detection/ [21] GitLab Docs (2023) Push Rules. Available at https://docs.gitlab.com/ee/user/project/repository/push_rules.html

原本PDFの抜粋画像

Table 2. Mapping of recommended CI/CD pipeline security tasks to SSDF practices

Table 3. Justification for the omission of certain SSDF practices