NIST ホワイトペーパー【プロジェクト概要】ソフトウェアサプライチェーンとDevOpsのセキュリティ実践：リスクベースアプローチによるDevSecOpsの実践: まるちゃんの情報セキュリティ気まぐれ日記

April 2025
Sun	Mon	Tue	Wed	Thu	Fri	Sat
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30

2022.11.12

NIST ホワイトペーパー【プロジェクト概要】ソフトウェアサプライチェーンとDevOpsのセキュリティ実践：リスクベースアプローチによるDevSecOpsの実践

こんにちは、丸山満彦です。

ソフトウェアのサプライチェーン・リスクは政府機関を含む、多くの組織にとって重要な影響を及ぼすにもかかわらず、その管理が社会全体で見ると十分にできていないために、社会的な取り組みが必要となるのかもしれませんね。SBOMとかもね。。。（ただ、本当にSBOMが最適解なのか、という話もあるかもですが...）

いずれにしてもサプライチェーン・リスクについては、政府機関等、影響を受ける組織が、率先して取り組みを進めることが重要かもしれません。。。

このホワイトペーパーでは、オープンソフト開発、クローズドソフト開発、それぞれのシナリオを用意していますね。。。

● NIST - ITL

・2022.11.09 White Paper [Project Description] Software Supply Chain and DevOps Security Practices: Implementing a Risk-Based Approach to DevSecOps

White Paper [Project Description] Software Supply Chain and DevOps Security Practices: Implementing a Risk-Based Approach to DevSecOps	ホワイトペーパー【プロジェクト概要】ソフトウェアサプライチェーンとDevOpsのセキュリティ実践：リスクベースアプローチによるDevSecOpsの実践
Abstract	概要
DevOps brings together software development and operations to shorten development cycles, allow organizations to be agile, and maintain the pace of innovation while taking advantage of cloud-native technology and practices. Industry and government have fully embraced and are rapidly implementing these practices to develop and deploy software in operational environments, often without a full understanding and consideration of security. Also, most software today relies on one or more third-party components, yet organizations often have little or no visibility into and understanding of how these components are developed, integrated, deployed, and maintained, as well as the practices used to ensure the components’ security. To help improve the security of DevOps practices, the NCCoE is planning a DevSecOps project that will focus initially on developing and documenting an applied risk-based approach and recommendations for secure DevOps and software supply chain practices consistent with the Secure Software Development Framework (SSDF), Cybersecurity Supply Chain Risk Management (C-SCRM), and other NIST, government, and industry guidance. This project will apply these DevSecOps practices in proof-of-concept use case scenarios that will each be specific to a technology, programming language, and industry sector. Both closed source (proprietary) and open source technology will be used to demonstrate the use cases. This project will result in a freely available NIST Cybersecurity Practice Guide.	DevOpsは、ソフトウェア開発と運用を統合し、開発サイクルの短縮、組織のアジャイル化、クラウドネイティブな技術と実践を活用しながらイノベーションのペースを維持することを可能にする。産業界と政府機関は、運用環境におけるソフトウェアの開発とデプロイのために、これらのプラクティスを完全に受け入れ、急速に導入しているが、多くの場合、セキュリティについて十分に理解し、考慮することなく行っている。また、今日のほとんどのソフトウェアは、1つ以上のサードパーティコンポーネントに依存しているが、組織はこれらのコンポーネントがどのように開発、統合、配備、保守されているか、また、コンポーネントのセキュリティを確保するためのプラクティスについてほとんど可視化できず、理解できないことがよくある。NCCoEは、DevOpsのセキュリティ向上を支援するため、DevSecOpsプロジェクトを計画している。このプロジェクトでは、まず、セキュアソフトウェア開発フレームワーク（SSDF）、サイバーセキュリティサプライチェーンリスク管理（C-SCRM）、その他のNIST、政府、業界の指針に沿った、安全なDevOpsとソフトウェアのサプライチェーンの実践のためのリスクベースのアプローチと推奨事項を適用し、文書化することに焦点を合わせます。このプロジェクトでは、これらのDevSecOpsの実践を、技術、プログラミング言語、産業分野に特化した概念実証のユースケースシナリオに適用する予定である。ユースケースの実証には、クローズドソース（プロプライエタリ）とオープンソースの両方の技術が使用される予定である。このプロジェクトは、自由に利用できるNISTサイバーセキュリティ実践ガイドを作成する予定である。

・[PDF] Project Description

目次...

1 Executive Summary	1 エグゼクティブサマリー
Purpose	目的
Scope	範囲
Assumptions/Challenges	前提条件／課題
Background	背景
2 Scenarios	2 シナリオ
Scenario 1: Free and Open Source Software (FOSS) Development	シナリオ1：フリー＆オープンソースソフトウェア（FOSS）開発
Scenario 2: Closed Source Software Development	シナリオ2：クローズドソースソフトウェアの開発
3 High-Level Architecture	3 ハイレベルなアーキテクチャ
Component List	コンポーネント一覧
Desired Security Capabilities	望ましいセキュリティ機能
4 Relevant Standards and Guidance	4 関連する標準とガイダンス
5 Security Control Map	5 セキュリティコントロールマップ
Appendix A References	附属書A 参考文献
Appendix B Acronyms and Abbreviations	附属書B 頭字語および略語

エグゼクティブサマリー...

1 EXECUTIVE SUMMARY	1 エグゼクティブサマリー
Purpose	目的
DevOps brings together software development and operations to shorten development cycles, allow organizations to be agile, and maintain the pace of innovation while taking advantage of cloud-native technology and practices. Industry and government have fully embraced and are rapidly implementing these practices to develop and deploy software in operational environments, often without a full understanding and consideration of security.	DevOps は、ソフトウェア開発と運用を統合し、開発サイクルを短縮し、組織がアジャイルになり、クラウドネイティブな技術とプラクティスを活用しながらイノベーションのペースを維持することを可能にする。産業界と政府機関は、運用環境におけるソフトウェアの開発とデプロイのために、これらのプラクティスを完全に受け入れ、急速に導入しているが、多くの場合、セキュリティを十分に理解し、考慮することなく行っている。
DevSecOps helps ensure that security is addressed as part of all DevOps practices by integrating security practices and automatically generating security and compliance artifacts throughout the processes and environments, including software development, builds, packaging, distribution, and deployment. This is important for several reasons, including:	DevSecOpsは、ソフトウェア開発、ビルド、パッケージング、配布、配備などのプロセスや環境全体を通じて、セキュリティの実践を統合し、セキュリティとコンプライアンスの成果物を自動的に生成することにより、すべてのDevOps実践の一部として、セキュリティへの対応を確保することを支援する。これは、以下のようないくつかの理由で重要である。
• reducing vulnerabilities, malicious code, and other security issues in released software without slowing down code production and releases;	・コードの生産とリリースを減速させることなく, リリース済みソフトウエアの脆弱性、悪意あるコード、その他のセキュリティ問題を低減する。
• mitigating the potential impact of vulnerability exploitation throughout the software lifecycle, including when the software is being developed, built, packaged, distributed, deployed, and executed on dynamic hosting platforms;	・ソフトウェアの開発、ビルド、パッケージング、配布、配備、および動的ホスティングプラットフォームでの実行を含むソフトウェアライフサイクル全体を通して脆弱性の悪用による潜在的な影響を軽減すること。
• addressing the root causes of vulnerabilities to prevent recurrences, such as strengthening test tools and methodologies in the toolchain, and improving practices for developing code and operating hosting platforms; and	・再発防止のための脆弱性の根本原因への対処（ツールチェーンにおけるテストツールや手法の強化、コード開発やホスティングプラットフォームの運用方法の改善など）；及び
• reducing friction between the members of the development, operation, and security teams in order to maintain the speed and agility needed to support the organization’s mission while taking advantage of modern and innovative technology.	・開発・運用・セキュリティの各担当者間の摩擦を減らし、組織のミッションをサポートするために必要なスピードと俊敏性を維持しながら最新かつ革新的な技術を活用すること。
There is increasing recognition that DevSecOps should also encompass software supply chain security. Most software today relies on one or more third-party components, yet organizations often have little or no visibility into and understanding of how these software components are developed, integrated, deployed, and maintained, as well as the practices used to ensure the components’ security. DevSecOps practices can help identify, assess, and mitigate cybersecurity risk for the software supply chain [1].	DevSecOpsは、ソフトウェアサプライチェーンセキュリティも包含すべきであるという認識が広まってきている。今日、ほとんどのソフトウェアは1つ以上のサードパーティコンポーネントに依存しているが、組織はこれらのソフトウェアコンポーネントがどのように開発、統合、配備、保守されているか、また、コンポーネントのセキュリティを確保するためのプラクティスについてほとんど可視化できず、理解できないことがよくある。DevSecOpsの実践は、ソフトウェアサプライチェーンのサイバーセキュリティリスクを特定、評価、軽減するのに役立つ[1]。
This document defines a National Cybersecurity Center of Excellence (NCCoE) project. This project focuses on developing and documenting an applied risk-based approach and recommendations for DevSecOps practices. For the purposes of this project, the term “DevSecOps” refers to integrating security practices developed by the security team into existing pipelines (e.g., continuous integration/continuous delivery [CI/CD]) and existing toolchains used by developers and managed by operations teams. NIST’s proposed approach for this project is similar to those used for the NIST Secure Software Development Framework (SSDF) [2] and the NIST Cybersecurity Framework [3]. This project is intended to help enable organizations to maintain the velocity and volume of software delivery in a cloud-native way and take advantage of automated tools. The project will also determine how the practices and tasks from the NIST SSDF can be implemented as part of a DevSecOps approach.	この文書は、国立サイバーセキュリティ・センター・オブ・エクセレンス（NCCoE）プロジェクトを定義している。このプロジェクトは、DevSecOps の実践のための応用リスクベースのアプローチと推奨事項を開発し、文書化することに重点を置いている。このプロジェクトでは、「DevSecOps」という用語は、セキュリティチームが開発したセキュリティ対策を、既存のパイプライン（例えば、継続的インテグレーション／継続的デリバリー［CI/CD］）と、開発者が使用し、運用チームが管理する既存のツールチェーンに統合することを指している。このプロジェクトでNISTが提案するアプローチは、NISTセキュアソフトウェア開発フレームワーク（SSDF）［2］やNISTサイバーセキュリティフレームワーク［3］に用いられているアプローチと類似している。このプロジェクトは、組織がクラウドネイティブの方法でソフトウェア提供の速度と量を維持し、自動化ツールを活用できるようにすることを目的としている。また、NIST SSDFのプラクティスやタスクが、DevSecOpsアプローチの一部としてどのように実装できるかを判断する。
The project’s objective is to produce practical and actionable guidelines that meaningfully integrate security practices into development methodologies. Industry, government, and other organizations could then apply the guidelines when choosing and implementing DevSecOps practices in order to improve the security of the software they develop and operate. That, in turn, would improve the security of the organizations using that software, and so on throughout the software supply chain. Additionally, the project intends to demonstrate how an organization can generate artifacts as a byproduct of its DevSecOps practices to support and inform the organization’s self-attestation and declaration to conformance to applicable NIST and industryrecommended practices for secure software development and cybersecurity supply chain risk management.	このプロジェクトの目的は、セキュリティの実践を開発手法に有意義に統合する、実用的で実行可能なガイドラインを作成することである。産業界、政府機関、その他の組織は、開発・運用するソフトウェアのセキュリティを向上させるために、DevSecOpsの手法を選択・導入する際に、このガイドラインを適用することができる。その結果、そのソフトウェアを使用する組織のセキュリティが向上し、ソフトウェアのサプライチェーン全体が改善される。さらに、このプロジェクトでは、組織がDevSecOpsの実践の副産物として成果物を生成し、安全なソフトウェア開発とサイバーセキュリティサプライチェーンリスク管理に関して適用可能なNISTと業界が推奨する実践への適合を自己証明し、宣言する方法を示すことを意図している。
The project will also strive to demonstrate the use of current and emerging secure development frameworks, practices, and tools to address cybersecurity challenges. Lessons learned during the project will be shared with the security and software development communities to inform improvements to secure development frameworks, practices, and tools. Lessons learned will also be shared with standards developing organizations to inform their DevSecOps-related work.	また、このプロジェクトでは、サイバーセキュリティの課題に対処するために、現在および将来の安全な開発フレームワーク、手法、ツールを使用することを実証するよう努める。このプロジェクトで得られた教訓は、セキュリティコミュニティやソフトウェア開発コミュニティと共有され、安全な開発フレームワーク、実践方法、ツールの改善に役立てられる。また、得られた教訓は、標準化団体と共有し、DevSecOps関連の作業に反映させる予定である。
We received community feedback on the initial draft of this project description through both public comments and the NCCoE DevSecOps Workshop. We revised the project description to address the feedback.	このプロジェクトの説明の最初のドラフトに対して、パブリックコメントとNCCoE DevSecOpsワークショップの両方を通じて、コミュニティからフィードバックがあった。そのフィードバックに対応するため、プロジェクトの説明を改訂した。
This project will result in a publicly available NIST Cybersecurity Practice Guide, a detailed implementation guide of the practical steps needed to implement a cybersecurity reference design that addresses this challenge.	このプロジェクトは、この課題に対処するサイバーセキュリティのリファレンスデザインを実装するために必要な実践的ステップの詳細な実装ガイドである、一般に利用可能なNISTサイバーセキュリティ実践ガイドを作成する予定である。
Scope	範囲
This project will apply DevSecOps practices in multiple proof-of-concept use case scenarios that each involve different technologies, programming languages, industry sectors, etc. The NCCoE project will use closed source and open source technology to demonstrate the use cases. The intention is to demonstrate DevSecOps practices, especially using automation, that would apply to organizations of all sizes and from all sectors, and to development for information technology (IT), operational technology (OT), Internet of Things (IoT), and other technology types. This project will not focus on the development of any particular technology type.	このプロジェクトでは、異なる技術、プログラミング言語、産業分野などを含む複数の概念実証のユースケースシナリオにDevSecOpsの実践を適用する。NCCoEプロジェクトでは、クローズドソースとオープンソースの技術を使用して、ユースケースを実証する。その意図は、あらゆる規模、あらゆる分野の組織、および情報技術（IT）、運用技術（OT）、モノのインターネット（IoT）、その他の技術タイプの開発に適用できる、特に自動化を用いたDevSecOpsの実践を実証することにある。このプロジェクトは、特定の技術タイプの開発に焦点を当てることはない。
As part of this project, NIST will bring together and normalize content on DevSecOps practices from existing guidance and practices publications. This content, to be published as part of the project’s NIST Cybersecurity Practice Guide, will be drafted and revised in parallel with the use case implementations. It will provide definitions of fundamental DevSecOps concepts so that developers, security professionals, and operations personnel can all have the same shared understanding of them. Also, it will document key elements that organizations would need to build successful DevSecOps practices, from changing the organization’s culture to automating security practices into existing development pipelines and toolchains to support the concept of continuous authorization to operate (ATO). The guide will also provide all organizations with a way to document their current DevSecOps practices and define their future target practices as part of their continuous improvement processes. The recommendations and practices in the guide will be crafted to provide organizations choosing to adopt them with flexibility and customizability in their implementation.	このプロジェクトの一環として、NISTは、既存のガイダンスやプラクティスの出版物からDevSecOpsのプラクティスに関するコンテンツを集め、標準化する予定である。このコンテンツは、このプロジェクトのNISTサイバーセキュリティ実践ガイドの一部として発行される予定で、ユースケースの実装と並行して起草・改訂される予定である。開発者、セキュリティ専門家、運用担当者が同じように理解できるように、DevSecOps の基本概念の定義を提供する。また、組織の文化を変えることから、既存の開発パイプラインやツールチェーンにセキュリティ対策を自動化し、継続的な操作権限（ATO）の概念をサポートするなど、組織がDevSecOpsを成功させるために必要な主要な要素を文書化する予定である。また、このガイドは、すべての組織が、継続的な改善プロセスの一環として、現在のDevSecOpsの実践を文書化し、将来目標とする実践を定義する方法を提供するものである。ガイドの勧告とプラクティスは、それらを採用することを選択した組織が、その実装において柔軟性とカスタマイズ性を得られるように作成される予定である。
Selected NIST guidance most closely related to DevOps and supply chain security, such as NIST Special Publication (SP) 800-218 [2], SP 800-190 [4], and SP 800-161 [1], will be leveraged for the use case implementations and may be updated during the course of the project based on lessons learned from the implementations. There are many existing security guidance and practices publications from NIST and others, but they have not yet been put into the context of DevOps or DevSecOps. Industry, standards developing organizations, government agencies, and others are already performing DevSecOps. Their efforts would be leveraged to provide a community-developed set of recommended practices. Updating affected NIST publications so they reflect DevSecOps principles would also help organizations to make better use of their recommendations.	NIST Special Publication (SP) 800-218 [2]、SP 800-190 [4]、SP 800-161 [1]など、DevOps とサプライチェーンのセキュリティに最も関係の深い NIST のガイダンスが使用事例の実装に利用され、実装から得られた教訓に基づいてプロジェクトの過程で更新されることがある。NIST などから多くの既存のセキュリティガイダンスと実践の出版物があるが、それらはまだ、DevOps または DevSecOps の文脈に当てはめたものではありません。業界、標準化団体、政府機関などは、すでにDevSecOpsを実施している。彼らの努力を活用し、コミュニティが開発した一連の推奨プラクティスを提供する。NIST の関連出版物を更新して、DevSecOps の原則を反映させれば、組織がその勧告をよりよく利用できるようにもなる。
Assumptions/Challenges	前提条件／課題
Readers are assumed to understand basic DevOps and secure software development concepts.	読者は、基本的なDevOpsと安全なソフトウェア開発の概念を理解していることが前提である。
Background	背景
A software development life cycle (SDLC)[1] is a formal or informal methodology for designing, creating, and maintaining software (including code built into hardware). There are many models for SDLCs, including waterfall, spiral, agile, and – in particular – agile combined with software development and IT operations (DevOps) practices. Few SDLC models explicitly address software security in detail, so secure software development practices usually need to be added to and integrated into each SDLC model. Regardless of which SDLC model is used, secure software development practices should be integrated throughout it for three reasons: to reduce the number of vulnerabilities in released software, to reduce the potential impact of the exploitation of undetected or unaddressed vulnerabilities by both external attackers and insider threats, and to address the root causes of vulnerabilities to prevent recurrences. Vulnerabilities include not just bugs caused by coding flaws, but also weaknesses caused by security configuration settings, incorrect trust assumptions, secrets or credentials stored within code, and outdated or incorrect risk analysis [5].	ソフトウェア開発ライフサイクル（SDLC）[1]は、ソフトウェア（ハードウェアに組み込まれたコードを含む）を設計、作成、および保守するための公式または非公式な方法論である。SDLC には、ウォーターフォール、スパイラル、アジャイル、そして特にアジャイルとソフトウェア開発および IT オペレーション（DevOps）プラクティスを組み合わせたものなど、多くのモデルが存在する。ソフトウェアセキュリティの詳細を明示的に扱うSDLCモデルはほとんどないため、安全なソフトウェア開発の実践は、通常、各SDLCモデルに追加、統合される必要がある。どの SDLC モデルを使用するかに関係なく、安全なソフトウェア開発の実践は、3つの理由から、SDLC モデル全体に統合されるべきである。脆弱性には、コーディングの欠陥によるバグだけでなく、セキュリティ構成の設定、誤った信頼の仮定、コード内に格納された秘密や認証情報、時代遅れまたは誤ったリスク分析に起因する弱点も含まれる[5]。
Most aspects of security can be addressed at multiple places within an SDLC, typically with some differences in cost, effectiveness, and ease of integration. However, in general, the earlier in the SDLC that security is addressed, the less effort and cost is ultimately required to achieve the same level of security. This principle, known as shifting left, is critically important regardless of the SDLC model. Shifting left minimizes any technical debt that would require remediating early security flaws late in development or after the software is in production, at a higher cost than if they’d been remediated earlier. Shifting left can also result in software with stronger security.	セキュリティのほとんどの側面は、SDLC 内の複数の場所で対処することができ、典型的には、コスト、有効性、および、統合の容易さにおいて、多少の違いがある。しかし、一般に、SDLC の早い段階でセキュリティに対処すればするほど、同じレベルのセキュリティを達成するために必要な労力とコストは最終的に少なくなる。この原則は、左遷として知られているが、SDLC モデルに関係なく、極めて重要である。左にシフトすることによって、初期のセキュリティ不具合を、開発の後期または、ソフトウェアが生産された後に、早期に是正した場合よりも高いコストで是正しなければならないような技術的負債を最小限にすることができる。また、レフトシフトすることで、より強固なセキュリティを備えたソフトウェアを実現することができる。
With today’s software, the responsibility for implementing security practices is often distributed among multiple organizations based on the delivery mechanism (e.g., infrastructure as a service, software as a service, platform as a service, container as a service, serverless). In these situations, it likely follows a shared responsibility model involving the platform/service providers and the tenant organization that is consuming those platforms/services. The parties will need to agree on what security practices need to be performed based on the organization’s defined policy, regulations, and mandates, which party is responsible for each practice, and how each party will attest to their conformance with the agreement.	今日のソフトウェアでは、セキュリティ対策を実施する責任が、提供メカニズム（例：サービスとしてのインフラ、サービスとしてのソフトウェア、サービスとしてのプラットフォーム、サービスとしてのコンテナ、サーバーレス）に応じて複数の組織に分散されることが多くなっている。このような状況では、プラットフォーム／サービスのプロバイダーと、それらのプラットフォーム／サービスを消費しているテナント組織が関与する責任共有モデルに従う可能性が高い。両当事者は、組織が定義したポリシー、規制、および義務に基づき、どのようなセキュリティ対策を実施する必要があるか、各対策にどの当事者が責任を負うか、そして各当事者が契約への準拠をどのように証明するかについて合意する必要がある。
Another aspect of today’s software is that it often uses one or more software components developed by other organizations, groups, or individuals. Some of those components may also use components from other organizations, and so on. Managing cybersecurity risk from thirdparty software components, as part of cybersecurity supply chain risk management (C-SCRM), involves identifying, assessing, selecting, and implementing processes and mitigating controls. This risk management can largely be integrated into DevSecOps through its automation capabilities—for example, constant automated testing of software and software components to identify vulnerabilities, breaches of integrity, and other security issues.	今日のソフトウェアのもう一つの側面は、他の組織、グループ、または個人によって開発された一つまたは複数のソフトウェアコンポーネントを使用することが多いということである。これらのコンポーネントの中には、他の組織のコンポーネントを使用しているものもあり、そのような場合は、他の組織のコンポーネントを使用することになる。サードパーティのソフトウェアコンポーネントがもたらすサイバーセキュリティリスクを管理するには、サイバーセキュリティサプライチェーンリスク管理（C-SCRM）の一環として、プロセスと緩和策を特定、評価、選択、実施する必要がある。このリスク管理は、自動化機能を通じて、DevSecOps に統合することができる。例えば、ソフトウェアとソフトウェアコンポーネントの自動テストを常に行い、脆弱性、整合性違反、およびその他のセキュリティ問題を特定することができる。
[1] Note that SDLC is also widely used for “system development life cycle.” All usage of “SDLC” in this document is referencing software, not systems.	[1] SDLC は、「システム開発ライフサイクル」としても広く使用されていることに留意してください。本書における「SDLC」のすべての用法は、システムではなく、ソフトウェアに言及している。

参考文献

APPENDIX A REFERENCES

Boyens et al., Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, National Institute of Standards and Technology (NIST) Special Publication (SP) 800-161 Revision 1, Gaithersburg, Md., May 2022, 326 pp. Available: https://doi.org/10.6028/NIST.SP.800-161r1 .
Souppaya et al., Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, National Institute of Standards and Technology (NIST) Special Publication (SP) 800-218, Gaithersburg, Md., February 2022, 36 pp. Available: https://doi.org/10.6028/NIST.SP.800-218 .
NIST, Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1, 2018. https://doi.org/10.6028/NIST.CSWP.04162018 .
Souppaya et al., Application Container Security Guide, National Institute of Standards and Technology (NIST) Special Publication (SP) 800-190, Gaithersburg, Md., September 2017, 63 pp. Available: https://doi.org/10.6028/NIST.SP.800-190 .
LeMay et al., The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities, National Institute of Standards and Technology (NIST) Internal Report (IR) 7864, Gaithersburg, Md., July 2012, 39 pp. Available: https://doi.org/10.6028/NIST.IR.7864 .
Executive Order on Improving the Nation’s Cybersecurity, Executive Order (EO) 14028, May 12, 2021. Available: https://www.whitehouse.gov/briefing-room/presidential actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/.
Joint Task Force, Security and Privacy Controls for Information Systems and Organizations, National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Revision 5, Gaithersburg, Md., September 2020, 492 pp. Available: https://doi.org/10.6028/NIST.SP.800-53r5 .