Withdrawn Draft
Warning Notice
The attached draft document has been withdrawn and is provided solely for historical purposes.
It has been followed by the document identified below.
Withdrawal Date February 12, 2024
Original Release Date August 30, 2023

The attached draft document is followed by:
Status Final
Series/Number NIST SP 800-204D
Title Strategies for the Integration of Software Supply Chain Security in
DevSecOps CI/CD Pipelines
Publication Date February 2024
DOI https://doi.org/10.6028/NIST.SP.800-204D
CSRC URL https://csrc.nist.gov/pubs/sp/800/204/d/final
Additional Information

NIST Special Publication
NIST SP 800-204D ipd

Strategies for the Integration ofSoftware Supply Chain Security in
DevSecOps CI/CD Pipelines
Initial Public Draft

Ramaswamy ChandramouliFrederick Kautz
Santiago Torres Arias

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

NIST Special Publication
NIST SP 800-204D ipd

Strategies for the Integration ofSoftware Supply Chain Security in
DevSecOps CI/CD Pipelines
Initial Public Draft
Ramaswamy ChandramouliComputer 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.ipd

August 2023

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

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

1
2
3
4

Certain commercial equipment, instruments, software, or materials, commercial or non-commercial, are identified inthis 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.

5
6
7
8
9
10

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 andmethodologies, 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 ofthese new publications by NIST.

11
12
13

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 athttps://csrc.nist.gov/publications.

14
15
16
17
18
19
20

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.

21
22
23
24
25

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 beinterpreted 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 andis not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

26
27
28

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

29
30

Publication History
Approved by the NIST Editorial Review Board on YYYY-MM-DD [Will be added on final publication]

31
32
33
34

How to Cite this NIST Technical Series Publication:
Chandramouli R, Kautz F, Arias S T (2023) 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 ipd. https://doi.org/10.6028/NIST.SP.800-204D.ipd

35
36

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

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

37
38

Public Comment Period
August 30, 2023 – October 13, 2023

39
40
41
42
43
44

Submit Comments
sp800-204d-comments@nist.gov

45

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

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

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

46

Abstract

47
48
49
50
51
52
53
54

The predominant application architecture for cloud-native applications consists of multiple
microservices with a centralized application infrastructure, such as a service mesh, that provides
all application services. This class of applications is generally developed using a flexible andagile software development paradigm called DevSecOps. A salient feature of this paradigm is theuse of flow processes called 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). This document outlines strategies for integrating
SSC security measures into CI/CD pipelines.

55

Keywords

56
57

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

58

Reports on Computer Systems Technology

59
60
61
62
63
64
65
66
67
68

The Information Technology Laboratory (ITL) at the National Institute of Standards andTechnology (NIST) promotes the U.S. economy and public welfare by providing technicalleadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test
methods, reference data, proof of concept implementations, and technical analyses to advancethe development and productive use of information technology. ITL’s responsibilities include thedevelopment of management, administrative, technical, and physical standards and guidelines forthe cost-effective security and privacy of other than national security-related information infederal 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.

iNIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

69

Call for Patent Claims

70
71
72
73
74
75

This public review includes a call for information on essential patent claims (claims whose use
would be required for compliance with the guidance or requirements in this Information
Technology Laboratory (ITL) draft publication). Such guidance and/or requirements may bedirectly stated in this ITL Publication or by reference to another publication. This call also
includes disclosure, where known, of the existence of pending U.S. or foreign patent applications
relating to this ITL draft publication and of any relevant unexpired U.S. or foreign patents.

76
77

ITL may require from the patent holder, or a party authorized to make assurances on its behalf,in written or electronic form, either:

78
79a) assurance in the form of a general disclaimer to the effect that such party does not holdand does not currently intend holding any essential patent claim(s); or

80
81
82

b) assurance that a license to such essential patent claim(s) will be made available toapplicants desiring to utilize the license for the purpose of complying with the guidanceor requirements in this ITL draft publication either:

83
84

i.

under reasonable terms and conditions that are demonstrably free of any unfair
discrimination; or

85
86

ii.

without compensation and under reasonable terms and conditions that aredemonstrably free of any unfair discrimination.

87
88
89
90
91

Such assurance shall indicate that the patent holder (or third party authorized to make assuranceson its behalf) will include in any documents transferring ownership of patents subject to theassurance, provisions sufficient to ensure that the commitments in the assurance are binding on
the transferee, and that the transferee will similarly include appropriate provisions in the event of
future transfers with the goal of binding each successor-in-interest.

92
93

The assurance shall also indicate that it is intended to be binding on successors-in-interest
regardless of whether such provisions are included in the relevant transfer documents.

94

Such statements should be addressed to: sp800-204d-comments@nist.gov

ii

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

95

Table of Contents

96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129

Executive Summary ................................................................................................................. 1
Introduction ...................................................................................................................... 2
Purpose ...................................................................................................................... 2
Scope ......................................................................................................................... 2
Target Audience ......................................................................................................... 2
Relationship to Other NIST Documents ...................................................................... 2
Document Structure .................................................................................................... 3
Software Supply Chain (SSC) — Definition and Model .................................................. 4
Definition .................................................................................................................... 4
Economics of Security ................................................................................................ 4
Governance Model ..................................................................................................... 4
SSC Model ................................................................................................................. 5
2.4.1.

Software Supply Chain Defects ................................................................................ 5

2.4.2.

Software Supply Chain Attacks ................................................................................ 5

SSC Security — Risk Factors and Mitigation Measures ................................................ 7
Risk Factors in an SSC............................................................................................... 7
3.1.1.

Developer Environment ............................................................................................ 7

3.1.2.

Threat Actors ............................................................................................................ 7

3.1.3.

Attack Vectors .......................................................................................................... 8

3.1.4.

Attack Targets (Assets) ............................................................................................ 8

3.1.5.

Types of Exploits ...................................................................................................... 8
Mitigation Measures.................................................................................................... 9

3.2.1.

Baseline Security.....................................................................................................10

3.2.2.

Controls for Interacting With SCMs..........................................................................10

CI/CD Pipelines — Background, Security Goals, and Entities to be Trusted ..............11
Broad Security Goals for CI/CD Pipelines ..................................................................11
Entities That Need Trust in CI/CD Pipelines — Artifacts and Repositories .................11
Integrating SSC Security Into CI/CD Pipelines ..............................................................13
Securing Workflows in CI Pipelines ...........................................................................135.1.1.

Secure Build ............................................................................................................13

5.1.2.

Secure Pull-Push Operations on Repositories .........................................................15

5.1.3.

Integrity of Evidence Generation During Software Updates .....................................15

5.1.4.

Secure Code Commits ............................................................................................16
Securing Workflows in CD Pipelines ..........................................................................17iii

NIST SP 800-204D ipd
August 2023

130
131
132
133
134
135
136
137

5.2.1.

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

Secure CD Pipeline — Case Study (GitOps) ...........................................................18
SSC Security for CI/CD Pipelines — Implementation Strategy ..................................18

Summary and Conclusions ............................................................................................20
References ..............................................................................................................................21
Appendix A. Mapping of Recommended Security Tasks in CI/CD Pipelines to
Recommended High-Level Practices in SSDF ......................................................................23
Appendix B. Justification for the Omission of Certain Measures Related to SSDF
Practices in This Document ...................................................................................................28

138
139

iv

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

140

Acknowledgments

141
142

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.

v

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

143

Executive Summary

144
145
146
147

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

148
149
150
151

Analyses of recent software attacks and vulnerabilities have led both government and privatesector organizations involved in software development, deployment, and integration to focus on
the activities involved in the entire SDLC. These collected activities are called the software
supply chain (SSC).

152
153
154

The integrity of these individual operations contributes to the overall security of an SSC, andthreats can arise from attack vectors unleashed by malicious actors as well as defects introduced
when due diligence practices are not followed during SDLC.

155
156
157
158
159
160

Executive Order (EO) 14028, NIST’s Secure Software Development Framework (SSDF)[2],other government initiatives, and industry forums have discussed the security of SSC to enhance
the security of all deployed software. This document focuses on actionable measures to integrate
the various building blocks of SSC security assurance into CI/CD pipelines to prepareorganizations to address SSC security in the development and deployment of their cloud-native
applications.

161
162
163
164
165

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

166

1

NIST SP 800-204D ipd
August 2023

167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

Introduction
Cloud-native applications consist of multiple loosely coupled services or microservices and are
deployed and run using an integrated application service infrastructure called 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 service mesh provides numerous runtime security
measures through mechanisms for assigning unique service identities for microservices andpolicy 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 ofcloud-native applications, SSC security assurance measures must be integrated into CI/CD
pipelines.
PurposeThis document outlines strategies for integrating SSC security assurance measures into CI/CD
pipelines. 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.
Scope
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 mustsatisfy 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 thedevelopment and deployment of their cloud-native applications.
Target Audience
This document is intended for a broad group of practitioners in the software industry, includingsite reliability engineers, software engineers, project and product managers, and security
architects and engineers.
Relationship to Other NIST Documents
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 aredeveloped and deployed using the DevSecOps SDLC paradigm with CI/CD pipelines. SP 800204C [1] discussed DevSecOps, which is an agile software development paradigm for cloudnative 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] provided a2

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

203
204
205
206
207

comprehensive list of high-level practices and tasks for providing SSC security under the Secure
Software Development Framework (SSDF) based on the directives Executive Order (EO) 14028[3]. Other documents in the SP 800-204 series have outlined the mechanisms for enforcing
various types of access controls for inter-service calls in the microservices environment duringruntime.

208
209
210
211
212
213
214

This document presents strategies for integrating SSC security into CI/CD pipelines through theidentification of workflow tasks that can meet the goals of the various high-level practices
outlined in the SSDF. Since the SSDF is application architecture and the SDLC paradigm isagnostic, not all practices and tasks outlined in the SSDF may be applicable in the context ofcloud-native applications developed using the DevSecOPs SDLC paradigm. Hence, thisdocument maps the SSC security integration strategies for CI/CD pipelines to the high-level
practices in the SSDF.

215

Document Structure216

This document is organized as follows:

217
218

•

Section 2 presents a series of definitions for modelling and understanding software
supply chains and their compromises.

219
220

•

Section 3 provides a broad understanding of common risk factors and potential mitigation
measures with a particular focus on the software developer environment.

221
222

•

Section 4 provides the background for CI/CD pipelines, the broad security goals of theprocesses involved, and the entities that need to be trusted.

223
224

•

Section 5 outlines strategies for integrating SSC security assurance measures into CI/CD
pipelines.

225•

Section 6 provides a summary and conclusions.

226
227

•

Appendix A provides a mapping of the SSC security integration strategies for CI/CD
pipelines to the SSDF’s high-level practices.

228
229

•

Appendix B provides a justification for the omission of certain measures related to SSDF
practices in this document.

3

NIST SP 800-204D ipd
August 2023

230
231

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

Software Supply Chain (SSC) — Definition and Model
Definition

232
233
234
235

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

236
237
238
239

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; andrepackaging and containerization.

240
241
242
243

In order to carry out an SSC attack, an attacker needs to subvert, remove, or introduce a step
within the SSC to maliciously modify the resulting software product. In practice, attackers often
target the activities mentioned above to implant backdoors and subsequently compromise a target
or exfiltrate sensitive information once the application is delivered.

244
245
246
247

SSC security should also account for discovering and tracking software defects rather thansimply mitigating attackers. This can be achieved by sharing a software bill of materials (SBOM)
with end users who can build inventories of software components to identify and address any
vulnerabilities or defects in the software.

248

Economics of Security

249
250
251
252

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.

253
254
255
256
257
258
259
260
261
262

Attacks that target highly regulated environments often allow motivated attackers to identify
weak spots in the chain. In the case of SOLORIGATE [4], for example, attackers identified asingle point of compromise that delivered software to multiple government agencies. Suchattacks are also stealthy because they typically propagate through legitimate channels, such assoftware updates, which allows for widespread damage to users of the target software. Since
attackers typically seek this avenue to obtain short-term benefits, widespread attacks of thisnature often rely on the use of private crypto miners and crypto jackers. This is evidenced in theprevalence of these vectors existing in breadth-first approaches, such as typo andcombosquatting attacks. Regardless of the motivations of the attackers, both vectors highlight thepossibility of incredible impact when carried out successfully.

263
264
265
266

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

NIST SP 800-204D ipd
August 2023

267

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

SSC Model

268
269
270
271
272

At a high-level, an SSC is a collection of steps that create, transform, and assess the quality ofsoftware 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).

273
274
275
276

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. Thisdefinition also encompasses more activities than are colloquially considered. That is, it includes
elements of secure software development, secure build systems, and dependency management.

277
278

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

279

280
281

Fig. 1. Interaction between the different elements of a software supply chain step282

2.4.1. Software Supply Chain Defects

283
284
285
286
287
288

Much like software defects (i.e., bugs), defective artifacts can propagate throughout an SSC andaffect its security posture. A noteworthy example of such a defect is that of Log4Shell [5], wherea vulnerability in a highly used software artifact allowed attackers to compromise a large numberof targets with very little effort. While the line between a defect and an attack is often blurred in
the SSC context, the guiding principle is that of intent — that is, whether or not the upstream
actor intended for that defect to be exploited.

289

2.4.2. Software Supply Chain Attacks

290
291

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

292

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

293
294

1. Artifact, step, or actor compromise: An attacker compromises an element of the SSC
to modify an artifact or information of such.
5

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines295

2. Propagation: The attack propagates throughout the chain.

296
297

3. Exploitation: The attacker exploits the target to achieve their goals (e.g., exfiltration ofdata, cryptojacking).

6

NIST SP 800-204D ipd
August 2023

298
299
300

SSC Security — Risk Factors and Mitigation Measures
This section considers the various risk factors that are applicable to the software development
environment and the mitigation measures that can counter those risks.
Risk Factors in an SSC

301
302

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

The risk factors in an SSC are discussed under the following topics:

303•

Developer Environment

304•

Threat Actors

305•

Attack Vectors

306•

Attack Targets (Assets)

307•

Types of Exploits308

3.1.1. Developer Environment

309
310
311
312
313
314
315

Developer workstations and their environments are at risk of compromise and present a
fundamental risk to the security of an SSC. The first and best line of defense is to not implicitly
trust the developer workstation. Mature SDLC processes accept code and assets into theirsoftware configuration management (SCM) mainline and versions branches only after code
reviews and scanners are in place. Furthermore, if the developer is working on proprietary
software with sensitive IP, additional measures must be put in place to protect the confidentialityof the source code and related material (e.g., architecture diagrams, documentation).

316

3.1.2. Threat Actors

317

Threat actors generally come in two types:

318•

External attackers who seek privileged access to an SSC

319•

Disgruntled employees or contractors who perpetuate insider threats

320
321
322
323
324
325
326
327

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 asignificant 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 thesoftware development environment and steal or manipulate software, such as phishing, malware,social engineering, and physical access. Therefore, companies should be aware of these risks andtake appropriate measures to secure their SSC.

7

NIST SP 800-204D ipd
August 2023

328

3.1.3. Attack Vectors

329

Attack vectors in an SSC include:330•

Malware331•

Social engineering

332•

Network-based attacks

333•

Physical attacks

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

334
335
336
337
338
339
340
341

Attack vectors can originate from various sources, including malware attacks on developer
workstations, social engineering attacks that target developers, network-based attacks that target
the development environment, and physical attacks on the hardware or networks used bydevelopers. 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 softwaredevelopment environment.

342

3.1.4. Attack Targets (Assets)

343

The assets targeted under an SSC include:344•

Source code

345•

Credentials

346•

Sensitive data

347
348
349
350
351
352
353

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), and proprietary information. Theseassets should be protected, as they are valuable to attackers who may attempt to steal orcompromise them. Companies should identify critical assets and implement controls to protect
them from unauthorized access, such as access controls, multi-factor authentication, encryption,and data loss prevention (DLP) measures.

354

3.1.5. Types of Exploits

355
356

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

Injection of vulnerabilities or malware into an SSC

358•

Stolen credentials that grant access to other systems

359•

Sensitive data leaked

360•

Injection of malicious code into repositories

361•

Lack of code integrity in public repositories
8

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

362
363
364
365
366

Threat actors may seek to compromise various components of the software development 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 orcompromise sensitive data. Such threats can result in financial losses, reputational damage, andlegal consequences.

367
368
369
370
371
372

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

373
374
375
376
377

Not all code is written from scratch. When open-source code is used, an artifact or package isoften 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 authoredand checked into their source code repository. The following actions could have potentiallyoccurred, resulting in a lack of assurance or an inability to trust the code:378•

The source code could have been modified.

379•

Vulnerabilities could have been introduced due to an insecure build system.

380
381

•

Checks, such as scanning and various types of tests (e.g., static, dynamic, or interactive),
may have been bypassed in the CI/CD process.
Mitigation Measures

382
383
384

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

385•

Patch management

386•

Access control

387•

Malware protection

388•

Secure SDLC

389•

Data protection390•

Physical security

391•

Audit and monitoring

392•

Adherence to applicable security standards (e.g., regulatory requirements)

393
394
395
396
397
398

Organizations can implement various controls to mitigate risks to their software development
environment, including regular patch management, access control, malware protection, securedevelopment life cycle (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 toaddress them. Organizations should also ensure that their software development environment
9

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

399
400

remains compliant with various security standards, such as the OWASP Top Ten, SP 800-53,
HIPAA, and PCI DSS.

401
402
403
404
405
406
407
408

Overall, a secure software development environment can reduce the likelihood of security
incidents and ensure the confidentiality, integrity, and availability of software assets andsystems. It is crucial to assess security risks and implement appropriate defensive measures toensure a secure software development environment. The choice of a mitigation approach will
depend on the organization’s customized threat model. However, all developer systems shouldmeet a minimum baseline for security to ensure that the operating system and applications are
kept up to date with the latest security patches, that individual and unshared user accounts areadequately protected, and that proper access controls are enforced when interacting with SCM.

409

3.2.1. Baseline Security

410
411
412
413
414

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 thedevelopment of such a policy is out of scope for this document, readers should refer to SP 80053r5 (Revision 5) [6] for a more complete treatment of this topic.

415
416
417
418

An important responsibility of the developer is to download, evaluate, and integrate open-sourcecomponents into their projects. There has been a significant increase in malware deployedthrough software repositories with typo-squatting, compromised repositories, or – in somescenarios — malicious actors legally acquiring repositories.

419

3.2.2. Controls for Interacting With SCMs

420
421
422
423
424
425
426
427
428
429
430
431

Developers also 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(patches) back to the SCM. The proposed changes should adhere to the SDLC processes definedby the organization. Pull access to the software depends on the policies of the software project inquestion (e.g., open-source projects typically allow anyone to pull, replicate, modify, and sharethe 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, butanother 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 thedevelopers with too many false positives to prevent alert fatigue.

432

10

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

433

CI/CD Pipelines — Background, Security Goals, and Entities to be Trusted

434
435
436
437
438
439
440
441
442
443
444
445
446

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 performtasks or activities, such as building, packaging, testing, and deploying. The build process is basedon application logic-driven dependencies and generates builds using many individual sourcecode artifacts that are stored in build repositories. The build artifacts are tested and used togenerate packages. The generated package artifacts are then stored in designated repositories andscanned before being deployed in testing or production environments. These stages and thevarious tasks performed at each stage are collectively called CI/CD pipelines. In other words,
CI/CD pipelines use processes called workflows to transform source code to deployable
packages in production environments. There are several platforms that support these workflows(e.g., GitHub Actions workflows, GitLab Runners, Buildcloud, etc.). A common approach for
SSC security in all of these workflows is to generate as much provenance data as possible.

447
448

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

449
450

•

Internal SSC security practices that are applied during the development and deploymentof first party software

451
452

•

Security practices that are applied with respect to the procurement, integration, anddeployment of open-source and commercial software modules.

453
454
455

Not all artifacts involved are composed of entities developed in-house (i.e., first party). Some
components may involve third-party sources.
Broad Security Goals for CI/CD Pipelines

456
457

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

458
459
460

1. Incorporate a range of defensive measures to ensure that attackers cannot tamper with
software production processes or introduce malicious software updates (e.g., secure
platform for build process).

461
462

2. Ensure the integrity of the CI/CD pipeline artifacts (e.g., repositories) and activities
through role definitions and authorizations for actors.

463
464
465
466

The most common approach to security assurance measures for CI/CD pipelines is theintroduction of security measures into the CI/CD platform, which allows developers to automate
their build, test, and deployment pipelines. There are many open-source CI/CD platforms, such
as GitHub Actions.

467
468
469
470

Entities That Need Trust in CI/CD Pipelines — Artifacts and Repositories
Zero trust architectures focus on protecting assets and resources, such as services, the entire
application, and hardware systems (e.g., servers). The entities that access these assets — such asusers, services, and other servers — are not inherently trusted. Trust needs to be established11

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

471
472
473

through the verification of credentials that these entities present through a process called
authentication. Based on this authentication, appropriate permissions or access rights are
assigned to those entities based on enterprise business policies.

474
475
476

In contrast, an SSC focuses on ensuring the integrity of artifacts and the repositories where they
are stored because artifacts that travel through various repositories ultimately become the final
product. This integrity assurance results in trust.

477
478

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

479

Artifact
First-party code — source code or binary

SCM

Repository

Third-party code — open source or commercial

Artifact managers for language, container, etc.

BuildsBuild repository

Packages

Package repository

480

12

NIST SP 800-204D ipd
August 2023

481

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

Integrating SSC Security Into CI/CD Pipelines

482
483
484

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

485

The prerequisites to activating CI/CD pipelines are:

486
487

•

Define the roles for the various actors that operate the various CI/CD pipelines (e.g.,
application updaters, package managers, deployment specialists, etc.).

488
489
490

•

Identify the granular authorizations to perform various tasks, such as generating andcommitting code to SCMs, generating builds and packages, and checking various
artifacts (e.g., builds and packages) into and out of the repositories.

491
492
493
494

•

The entire CI/CD pipeline must be automated through the deployment of appropriate
tools. The driver tools for CI and CD pipelines are at a higher level, and they invoke asequence of function-specific tools, such as those for code checkouts from repositories,
edits and compilation, code commits, and testing (e.g., SAST, DAST and SAC testers).

495
496

•

CI/CD pipeline activities and associated security requirements are defined for thedevelopment and deployment of application code as well as:

497

o Infrastructure as code, which contains details about the deployment platform.

498
499

o Policy as code and configuration code, which specify runtime settings (e.g.,
YAML files)
Securing Workflows in CI Pipelines

500
501
502

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.

503

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

504
505

•

The capability to support both cloud-native and legacy software development
environments.

506•

Standard compliant evidence structures, such as metadata and digital signatures

507•

Support for multiple hardware and software platforms

508•

Support for infrastructures for generating the evidence.

509

The following subsections consider the SSC security tasks for the various workflows in CI.

510

5.1.1. Secure Build

511

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

512
513
514

•

Specify policies regarding the build, including (a) the use of a secure isolated platform
for performing the build, (b) the tools that will be used to perform the build, and (c) the
authentication/authorization required for the developers performing the build process.
13

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

515
516

•

Enforce those build policies using an agent or some other means and a policy
enforcement engine.

517
518

•

Ensure the concurrent generation of evidence for build attestation to demonstratecompliance with secure build processes during the time of software delivery.

519
520
521
522
523
524
525
526

A common technique for facilitating the second task is to wrap commands from a CI tool withcapabilities to gather evidence and ultimately create an evidence trail of the entire SDLC [8]. The
evidence gathered consists of the hash of the final build artifact, files, libraries, and othermaterials used in the artifacts and all events. This is then signed using a secure PKI distribution
system to become 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 producerof the software. In this context, the artifact is the build generated by a series of CI process steps.
The attestation for a build consists of the following components [9]:

527
528
529
530

1. Environment Attestation: Environment attestation pertains to the inventory of the systemat the time when the CI process happens. It generally refers to the platform on which thebuild process is run. The components of the platform (e.g., compiler, interpreter, etc.)
must be hardened, isolated, and secure.

531
532
533
534

2. Process Attestation: Process attestation pertains to the computer programs thattransformed the original source code or materials into an artifact (e.g., compilers,
packaging tools, etc.) and/or the programs that performed testing on that software (i.e.,code testing tool).

535
536

3. Materials Attestation: Materials attestation pertains to any raw data and can include
configuration, source code, and other data.

537
538
539
540
541
542
543

4. Artifacts Attestation: An artifact is the result or outcome of a CI process. For example, if
the CI process step involves running a compiler (e.g., GCC) on a source code written inC, the artifact that will result is an executable binary of that source code. If the step
involves running a static application security testing (SAST) tool on the same source
code, the artifact that will result will be the “Scan Result.” The step that generated it canbe a final or intermediate step. An attestation pertaining to this newly generated productfalls under the category of artifacts attestation.

544
545
546
547
548
549
550

The signed evidence (i.e., attestation) must be stored securely in a server and can then be used toevaluate 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 associatedmetadata has also been specified. The policy enables the verifiers to trace the compliance statusof the artifact at any point during its life cycle.

551

The above capabilities collectively provide the following assurances:

552
553

•

The software was built by authorized persons using the authorized tools (e.g., machines
for each step) in the correct sequence of steps.

554•

There is no evidence of potential tampering or malicious activity.

14

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines555

5.1.2. Secure Pull-Push Operations on Repositories

556
557
558
559

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:

560
561
562

1. The type of authentication required for developers authorized to perform the PULLPUSH operations. The request made by the developer must be consistent with their role(e.g., application updater, package manager, etc.).

563
564

2. The integrity of the code in the repository can be trusted such that it can be used forfurther updates.

565

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

566
567
568

•

PULL-PUSH_REQ-1: The project maintainer should run automated checks on all
artifacts covered in the pull request, such as unit tests, linters, integrity tests, security
checks, and more.

569
570
571

•

PULL-PUSH-REQ-2: Running CI pipelines using external tools (e.g., Jenkins) shouldbe performed only when confidence is established in the trustworthiness of the sourcecode origin.

572
573
574
575
576
577

•

PULL-PUSH-REQ-3: The repository or source-code management system (e.g., GitHub)
should have built-in protection that incorporates a delay in CI workflow runs until they
are approved by a maintainer with write access. This built-in protection should go into
effect when an outside contributor submits a pull request to a public repository. The
setting for this protection should be at the strictest level, such as “Require approval for alloutside collaborators” [10].

578
579
580

•

PULL-PUSH_REQ-4: If there are no native built-in protections available in the sourcecode management system, then external security tools with the following features are
required:

581
582
583

o Functionality to evaluate and enhance the security posture of the SCM systems withor without a policy (e.g., OPA) to assess the security settings of the SCM account andgenerate a status report with actionable recommendations

584
585
586

o Functionality to enhance the security of the source-code management system (e.g.,
GitHub, GitLab) by detecting and remediating misconfigurations, security
vulnerabilities, and compliance issues

587

5.1.3. Integrity of Evidence Generation During Software Updates

588
589
590
591
592
593

One important process in an SSC is the software update process, which is typically carried out by
a special class of software development tool called software update systems. Ensuring thesecurity of these software update systems plays a critical role in the overall security of an SSC.
Threats to software update systems mainly target the evidence generation process so as to erase
the trail of updates and prevent the ability to determine whether the updates were legitimate ornot.
15

NIST SP 800-204D ipd
August 2023

594

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

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

Package managers that are responsible for all of the software that is installed on a system

596•

Application updaters that are only responsible for individual installed applications

597
598

•

Software library managers that install software that adds functionality, such as plugins orprogramming language libraries

599
600
601
602
603
604
605

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

606
607
608
609
610

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 following are some of the consensus
goals for the framework:

611
612
613
614

•

The framework for software update systems should provide protection against all known
attacks on the tasks performed by the software update systems, such as metadata (hash)generation, the signing process, the management of signing keys, the integrity of theauthority performing the signing, key validation, and signature verification.

615
616
617
618
619
620

•

The framework for software update systems should provide a means to minimize theimpact of key compromise. To do so, it must support roles with multiple keys andthreshold or quorum trust (with the exception of minimally trusted roles designed to use asingle key). The compromise of roles that use highly vulnerable keys should haveminimal impact. Therefore, online keys (i.e., keys used in an automated fashion) must not
be used for any role that clients ultimately trust for files they may install [11].

621
622

•

The framework must be flexible enough to meet the needs of a wide variety of software
update systems.

623•

The framework must be easy to integrate with software update systems.

624

5.1.4. Secure Code Commits

625
626

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

627
628

•

Both SAST and DAST tools used in CI/CD pipelines must provide coverage for different
language systems used in cloud-native applications.

629
630
631

•

If open-source modules and libraries are used, dependencies must be detected using
appropriate SCA tools, and the security conditions they should meet for their inclusion mustalso be tested.
16

NIST SP 800-204D ipd
August 2023

632
633
634

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

An 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]. This feature should satisfy the following requirements:

635
636
637

•

COMMIT-REQ-1: If the committed code has an embedded secret, there should be afeature to generate an alert that contains information on the secret type (e.g., personal
access token) and location, as well as the methodology to remediate the exposure.

638
639

•

COMMIT-REQ-2: Push protection features should be enabled for all repositories
assigned to an administrator [13].
Securing Workflows in CD Pipelines

640
641
642
643
644
645
646
647
648

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

DEPLOY-REQ-1: A key deploy time control that can be used is based on build
information. If a secure build environment and associated process have been established,
it should be possible to specify that the artifact (i.e., container image) being deployedmust have been generated by that build process in order to be cleared for deployment.

649
650
651
652
653
654

DEPLOY_REQ-2: Another deploy time control is to check for evidence that thecontainer image was scanned for vulnerabilities and attested vulnerability findings. This
technique enables DevOps teams to implement a proactive container security posture by
ensuring that only verified containers are admitted into the environment and remain
trusted during runtime [14]. Specifically, it should be possible to allow or block image
deployment based on organization-defined policies.

655

The tasks to be performed include:

656
657
658

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

659
660
661
662

o There should be tools to manage container images and language packages. The
common repository over which both of these activities can be performed should
support native artifact protocols, and the tools used should be capable of integration
with CD tools, thus making all activities an integral part of automated CD pipelines.

663
664
665

•

DEPLOY-REQ-3: For code that is already in the repository and ready to be deployed, asecurity scanning sub-feature should be invoked to detect the presence of secrets in thecode, such as keys and access tokens.

666
667

•

DEPLOY-REQ-4: Before merging pull requests, it should be possible to view the detailsof any vulnerable versions through a form of dependency review [15].

17

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

668

5.2.1. Secure CD Pipeline — Case Study (GitOps)

669
670
671
672
673
674

All operations during and after a build in the CI/CD pipeline involve interacting with a central
repository (usually GIT). Bitbucket, GitHub, and GitLab are some examples of GIT
repositories. The operations are collectively called GitOps and consist of commits, forking, andpull and push requests. In other words, GitOps is an automated deployment process facilitated byopen-source tools, such as Argo CD and Flux. GitOps is carried out for both infrastructure code
and application code. The usage of GitOps covers the following [16]:675•Managing infrastructure as code

676•

Managing and applying cluster configurations

677
678

•

Automating the deployment of containerized applications and their configurations to
distributed systems.

679
680
681

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

682
683
684

•

GitOps-REQ-1: The process should rely on automation rather than manual operations.
For example, manually configuring hundreds of YAML files to roll back a deployment
on a cluster in a Git should be avoided.

685
686
687
688

•

GitOps-REQ-2: Package managers that facilitate GitOps should preserve all data on the
packages that were released, including version numbers of all modules, all associatedconfiguration files, and other metadata as appropriate for the software operational
environment.

689
690
691
692
693

•

GitOps-REQ-3: Another situation that should be avoided is manually applying changes
directly into the nodes with a kubectl edit during runtime. For example, security issues
discovered in running applications will need to be remediated in the build process rather
than an administrator making changes directly in the cluster. This is to ensure that Git
commits remain the single source of truth for what runs in the cluster.

694
695
696
697
698

•

GitOps-REQ-4: (Monitoring and Remediation for Drift) — Since the Git repository
contains the application definitions and configuration as code, it should be pulled
automatically and compared with the specified state of these configurations. For any
configurations that deviate from their specified state, the following actions may be
performed:

699
700
701
702
703
704

o Administrators can choose to automatically resync configurations to the defined state.
o Notifications should be sent regarding the differences, and manual remediation
should be performed.
SSC Security for CI/CD Pipelines — Implementation Strategy
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 and18

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

705
706

operational costs. Rather, solutions that provide SSC security can be broadly classified into two
types [17]:

707
708

1. Solutions that ensure SSC security through the following features associated with eachtask in the DevSecOps pipelines:

709
710
711

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]

712
713
714

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 checklists715

2. Solutions that ensure integrity and provenance through digital signatures and attestations

19

NIST SP 800-204D ipd
August 2023

716
717
718
719
720
721
722
723

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

Summary and Conclusions
This document provided an overview of strategies for integrating SSC security assurance
measures with 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 cloudnative applications. However, no recommendations were provided with respect to the specificartifacts and frameworks associated with SSC security, such as SBOMs, code signing, andattestation. This is due to the fact that specifications and the standards associated with them arestill evolving as part of projects in government institutions and industry forums.

724

20

NIST SP 800-204D ipd
August 2023

725

References

726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767

[1]

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

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] EO14028 (2021) Improving the Nation’s Cybersecurity. Available athttps://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-thenations-cybersecurity[4] Goud N (2021) What is Solarigate. Available at https://www.cybersecurityinsiders.com/what-is-solorigate/[5] Berger A (2023) What is Log4Shell ? Available athttps://www.dynatrace.com/news/blog/what-islog4shell/#:~:text=Log4Shell%20is%20a%20software%20vulnerability,logging%20error%
20messages%20in%20applications[6] Joint Task Force (2020) Security and Privacy Controls for Information Systems andOrganizations. (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 athttps://dlorenc.medium.com/zero-trust-supply-chain-security-e3fb8b6973b8[8] Testify/Witness (2023) Witness – Secure Your Supply Chain. Available athttps://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-githubrepos-for-ci-misconfiguration-cd36ad6be788[11] TUF V1.0.31 (2022) The Update Framework Specification. Available athttps://theupdateframework.github.io/specification/latest/[12] Malik Z, Sulakian M (2023) Push Protection is generally available. Available athttps://github.blog/2023-05-09-push-protection-is-generally-available-and-free-for-allpublicrepositories/?utm_source=thenewstack&utm_medium=website&utm_content=inlinemention&utm_campaign=platform[13] GitHub Docs (2023) Enabling Security Features for Multiple Repositories. Available athttps://docs.github.com/en/enterprise-cloud@latest/code-security/securityoverview/enabling-security-features-for-multiple-repositories[14] Cloud Build (2023) Securing Image Deployments to Cloud Run and GKE. Available athttps://cloud.google.com/build/docs/securing-builds/secure-deployments-to-run-gke

21

NIST SP 800-204D ipd
August 2023

768
769
770
771
772
773
774
775
776
777

Software Supply Chain Security
in DevSecOps CI/CD Pipelines[15] GitHub Docs (2023) About dependency review. Available athttps://docs.github.com/en/enterprise-cloud@latest/code-security/supply-chainsecurity/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 athttps://danacrane.medium.com/five-stages-for-a-secure-software-supply-chainf8420841cc3a[18] CyRise (2023) Supply Chain Security with Ensignia. Available athttps://medium.com/@cyrise/supply-chain-security-with-ensignia-483c1d872639

22

NIST SP 800-204D ipd
August 2023

778
779
780

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

Appendix A. Mapping of Recommended Security Tasks in CI/CD Pipelines to
Recommended High-Level Practices in SSDF
Table 2. Mapping of recommended CI/CD pipeline security tasks to SSDF practices
Section
5.1.1 Secure Build— Policies for Build
Process andMechanisms to
Enforce Policies

5.2 Securing
Workflows in CD
Pipelines

Recommended Security Tasks in CI/CD
Pipeline• Specify policies regarding the build. The
policies include (a) the use of secureisolated platform for performing the build,(b) the tools that will be used to perform thebuild, and (c) the
authentication/authorization required fordevelopers performing the build process.
• Enforce those build policies using an agent
or some other means and a policy
enforcement engine.
DEPLOY-REQ-1: A key deploy time control
that can be used is based on build information. If
a secure build environment and associatedprocess have been established, it should bepossible to specify that the artifact (i.e.,
container image) being deployed must have been
generated by that build process in order to beallowed to be cleared for deployment.
DEPLOY_REQ-2: Another deploy time
control is to check for evidence that thecontainer image was scanned for vulnerabilities
and attested vulnerability findings. This
technique enables DevOps teams to implement a
proactive container security posture by ensuringthat only verified containers are admitted into
the environment and remain trusted duringruntime [14]. Specifically, it should be possible
to allow or block image deployment based onorganization-defined policies.
The tasks to be performed include:
As soon as a container image is built, it should
be scanned for vulnerabilities even before it ispushed to a registry. The early scanning feature
can also be built in as part of the local
workflows.
There should be tools to manage container
images and language packages. The common
repository over which both of these activities
can be performed should support native artifact
protocols, and the tools used should be capableof integration with CD tools, thus making all
activities an integral part of automated CD
pipelines.

23

Recommended High-Level
Practice in SSDF
Define Security Requirements for
Software Development (PO.1):
Ensure that the security requirements
for software development are knownat all times so that they can be taken
into account throughout the SDLC
and duplication of effort can be
minimized. This includes
requirements from internal sources(e.g., the organization’s policies,
business objectives, and risk
management strategy) and externalsources (e.g., applicable laws andregulations).

NIST SP 800-204D ipd
August 2023
SectionSoftware Supply Chain Security
in DevSecOps CI/CD Pipelines
Recommended Security Tasks in CI/CD
Pipeline• DEPLOY-REQ-3: For code that is alreadyin the repository and ready to be deployed, asecurity scanning sub-feature should be
invoked to detect the presence of secrets inthe code, such as keys and access tokens.
•

Recommended High-Level
Practice in SSDF

DEPLOY-REQ-4: Before merging pull
requests, it should be possible to view thedetails of any vulnerable versions through aform of dependency review.

5 Integrating SSC
Security in CI/CD
Pipelines

The prerequisites for activating CI/CD pipelinesare:• Define roles for various actors operating thevarious CI/CD pipelines (e.g., application
updaters, package managers, deployment
specialists, etc.)• Identify the granular authorizations toperform various tasks, such as generating
and committing code to SCMs, generatingbuilds and packages, and checking various
artifacts (e.g., builds and packages) into andout of the repositories.

Implement Roles andResponsibilities (PO.2): Ensure thateveryone inside and outside of theorganization involved in the SDLC is
prepared to perform their SDLCrelated roles and responsibilities
throughout the SDLC.

5 Integrating SSC
Security in CI/CD
Pipelines

A prerequisite for activating CI/CD pipelines is:• The entire CI/CD pipeline must be
automated through the deployment ofappropriate tools. The driver tools for CI
and CD pipelines are at a higher level, andthey invoke a sequence of function-specifictools, such as those for code checkouts from
repositories, edits and compilation, codecommits, and testing (e.g., SAST, DASTand SAC testers).

Implement Supporting Toolchains(PO.3): Use automation to reduce
human effort and improve theaccuracy, reproducibility, usability,
and comprehensiveness of security
practices throughout the SDLC, aswell as provide a way to document
and demonstrate the use of thesepractices. Toolchains and tools may
be used at different levels of theorganization, such as organizationwide or project-specific, and may
address a particular part of theSDLC, like a build pipeline.

5.1.4 Secure CodeCommits

A prerequisite operation before code commits isappropriate forms of testing. The following
requirements must be met:

Define and Use Criteria for
Software Security Checks (PO.4):
Help ensure that the software
resulting from the SDLC meets theorganization’s expectations bydefining and using criteria forchecking the software’s security
during development.

•

Both SAST and DAST tools used in CI/CD
pipelines must provide coverage fordifferent language systems used in cloudnative applications.

•If open-source modules and libraries areused, dependencies must be detected using
appropriate SCA tools, and the security
conditions they should meet for their
inclusion must also be tested.

24

NIST SP 800-204D ipd
August 2023
Section
5.1.1 Secure Build
Policies for Build
Process andMechanisms for
Enforcement of
Policies

5.1.2 Secure PULLPUSH Operations
on Repositories

Software Supply Chain Security
in DevSecOps CI/CD Pipelines
Recommended Security Tasks in CI/CD
Pipeline
Already covered under meeting requirements
for PO.1. In addition:
1. Environment Attestation: Environment
attestation pertains to the inventory of thesystem when the CI process happens. It
generally refers to the platform on which
the build process is run. This platform mustbe hardened, isolated, and secure.

All forms of code used in SDLC reside inrepositories. Code is extracted from these
repositories by authorized developers using a
PULL operation, modified, and then put backinto the repositories using a PUSH operation. To
authorize these PULL-PUSH operations, twoforms of checks are required.
1.

2.
5.1.3 Integrity of
Evidence
Generation During
Software Updates(To provide theassurance to acquirers
that the software they
get is legitimate,steps are taken toprotect the integrityof evidence
generation tasks)

1.

2.

The type of authentication required fordevelopers authorized to perform the
PULL-PUSH operations. The request madeby the developer must be consistent with
their role (e.g., application updater, package
manager, etc.).
The integrity of the code in the repository
can be trusted such that it can be used forfurther updates.
The framework for software update systems
should provide protection against all known
attacks on the tasks performed by thesoftware update systems, such as metadata(hash) generation, the signing process, themanagement of signing keys, the integrityof the authority performing the signing, key
validation, and signature verification.
The framework for software update systems
should provide a means to minimize theimpact of key compromise. To do so, it
must support roles with multiple keys andthreshold or quorum trust (with the
exception of minimally trusted roles
designed to use a single key). The
compromise of roles that use highly
vulnerable keys should have minimal
impact. Therefore, online keys (i.e., keys
used in an automated fashion) must not be
used for any role that clients ultimately trust
for files they may install [11].

25

Recommended High-Level
Practice in SSDF
Implement and Maintain Secure
Environments for Software
Development (PO.5): Ensure that allcomponents of the environments forsoftware development are strongly
protected from internal and external
threats to prevent the environmentsor the software in them from being
compromised. Examples ofenvironments for softwaredevelopment include development,
build, test, and distribution
environments.
Protect All Forms of Code From
Unauthorized Access andTampering (PS.1): Help prevent
unauthorized changes to code, both
inadvertent and intentional, that
could circumvent or negate theintended security characteristics ofthe software. For code that is notintended to be publicly accessible,
this helps prevent theft and may
make it more difficult or timeconsuming for attackers to findvulnerabilities in the software.

Provide a Mechanism for
Verifying Software Release
Integrity (PS.2): Help software
acquirers ensure that the software
they acquire is legitimate and has notbeen tampered with.

NIST SP 800-204D ipd
August 2023
Section

5.2.1 Secure CD
Pipeline — Case
Study (GitOps)

5.1.2 Secure PULLPUSH Operations
on Repositories(Implements secure
coding and build
processes to improvesecurity throughvarious checks during
PULL-PUSH
operations)

Software Supply Chain Security
in DevSecOps CI/CD Pipelines
Recommended Security Tasks in CI/CD
Pipeline
3. The framework must be flexible enough tomeet the needs of a wide variety of software
update systems.
4. The framework must be easy to integratewith software update systems.
The following SSC security tasks are to 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:• GitOps-REQ-2: Package managers thatfacilitate GitOps should preserve all data on
the packages that were released, including
version numbers of all modules, allassociated configuration files, and othermetadata as appropriate for the software
operational environment.
• PULL-PUSH_REQ-1: The project
maintainer should run automated checks on
all artifacts covered in the pull request, suchas unit tests, linters, integrity tests, security
checks, and more.
• PULL-PUSH-REQ-2: Running CI
pipelines using external tools (e.g., Jenkins)should be performed only when confidence
is established in the trustworthiness of thesource-code origin.
• PULL-PUSH-REQ-3: The repository orsource-code management system (e.g.,
GitHub) should have built-in protection thatincorporates a delay in CI workflow runs
until they are approved by a maintainer withwrite access. This built-in protection should
go into effect when an outside contributor
submits a pull request to a public repository.
The setting for this protection should be at
the strictest level, such as “Require approval
for all outside collaborators” [10] .
• PULL-PUSH_REQ-4: If there are nonative built-in protections available in thesource-code management system, thenexternal security tools with the following
features are required:o Functionality to evaluate andenhance the security posture of the
SCM systems with or without apolicy (e.g., OPA) to assess the
security settings of the SCM
account and generate a status
report with actionable
recommendations.
26

Recommended High-Level
Practice in SSDF

Archive and Protect Each
Software Release (PS.3): Preserve
software releases in order to help
identify, analyze, and eliminate
vulnerabilities discovered in thesoftware after release.

Create Source Code by Adhering
to Secure Coding Practices(PW.5): Decrease the number of
security vulnerabilities in thesoftware and reduce costs byminimizing vulnerabilities
introduced during source code
creation that meet or exceedorganization-defined vulnerability
severity criteria.

NIST SP 800-204D ipd
August 2023
Section

5.1.1 Secure Build(Addresses therequirements for
PW.6 throughsecurity requirements
for the build
platform)

781

Software Supply Chain Security
in DevSecOps CI/CD Pipelines
Recommended Security Tasks in CI/CD
Pipelineo Functionality to enhance thesecurity of the source-code
management system (e.g., GitHub,
GitLab) by detecting andremediating misconfigurations,security vulnerabilities, andcompliance issues.
Environment Attestation: Environment
attestation pertains to the inventory of thesystem at the time when the CI process happens.
It generally refers to the platform on which thebuild process is run. This platform components(e.g., compiler, interpreter, etc.) must be
hardened, isolated, and secure.

5.1.4 Secure CodeCommits

A prerequisite operation before code commits isappropriate forms of testing. The following
requirements must be met:
• Both SAST and DAST tools used in CI/CD
pipelines must provide coverage for thedifferent language systems used in cloudnative applications.
• If open-source modules and libraries areused, dependencies must be detected using
appropriate SCA tools, and the security
conditions they should meet for their
inclusion must also be tested.

5 Integrating SSC
Security into CI/CD
Pipelines

CI/CD pipeline activities and associated security
requirements are defined for the development
and deployment of application code as well as:• Infrastructure as code, which contains
details about the deployment platform• Policy as code and configuration code,
which specify runtime settings (e.g.,
YAML files)

782

27

Recommended High-Level
Practice in SSDF

Configure the Compilation,
Interpreter, and Build Processes to
Improve Executable Security(PW.6): Decrease the number of
security vulnerabilities in thesoftware and reduce costs byeliminating vulnerabilities before
testing occurs.
Test Executable Code to Identify
Vulnerabilities and Verify
Compliance With Security
Requirements (PW.8): Identify
vulnerabilities so that they can becorrected before the software isreleased. Using automated methods
lowers the effort and resources
needed to detect vulnerabilities andimproves traceability andrepeatability. Executable code
includes binaries, directly executed
bytecode and source code, and anyother form of code that anorganization deems executable.
Configure Software to Have
Secure Settings by Default (PW.9):
Help improve the security of thesoftware at the time of installation to
reduce the likelihood of the software
being deployed with weak security
settings, thus putting it at greater riskof compromise.

NIST SP 800-204D ipd
August 2023

Software Supply Chain Security
in DevSecOps CI/CD Pipelines

783
784

Appendix B. Justification for the Omission of Certain Measures Related to SSDF
Practices in This Document

785

Table 3. Justification for the omission of certain SSDF practices
SSDF Practice

Justification for Omission

Produce Well-Secured Software (PW)PW1 through PW4, PW7

These practices pertain to secure software design,
review of the design, and software reuse. CI/CD
pipelines focus on setting up the environment for
secure development and deployment and not software
design per se.
Vulnerability management strategies are at theorganization policy level and are not specific to CI/CD
pipelines.

Respond to Vulnerabilities (RV)
RV1 through RV378628