米国 オーストラリア 「安全なソフトウェア展開： ソフトウェア製造事業者はどのようにして顧客の信頼性を確保するのか？」 (2024.10.24)
こんにちは、丸山満彦です。
米国のCISA、FBI、オーストラリアのACSCが共同で、 「安全なソフトウェア展開： ソフトウェア製造事業者はどのようにして顧客の信頼性を確保するのか？」を公表していますね...
マーケットに提供するソフトウェアにマルウェアを仕込まれると、その社会的な影響は大きいので、安全なソフトウェアを提供することが重要ですよね...
マイクロソフト、クラウドストライク、グーグルが協力していますね...
さて、これから重要となってくるAIシステムの市場への展開においても同じようなことがありますよね...AIシステムの場合は、学習データもある意味コードのようなものなので、コードだけを見ていても安全とはいえないところが難しいですよね...さりとて、テストをするとしても網羅的にはできない...その部分はSP800-218Aで検討ということなのでしょうが...
● CISA
・2024.10.24 Safe Software Deployment: How Software Manufacturers Can Ensure Reliability for Customers
| Safe Software Deployment: How Software Manufacturers Can Ensure Reliability for Customers | 安全なソフトウェア展開： ソフトウェア製造事業者はどのようにして顧客の信頼性を確保するのか？ |
| This guidance aids software manufacturers in implementing a safe software deployment process with robust testing and measurement components. The process laid out by CISA, FBI, and Australian Cyber Security Centre (ACSC) helps both the security and quality of products and deployment environments. | このガイダンスは、ソフトウェア製造者が堅牢なテストと測定コンポーネントを備えた安全なソフトウェア展開プロセスを実施することを支援するものである。CISA、FBI、Australian Cyber Security Centre (ACSC)が示したプロセスは、製品と展開環境のセキュリティと品質の両方に役立つ。 |
| This guide provides an overview of six key phases in a safe software deployment process. The authoring agencies strongly encourage the use and regular maintenance of playbooks that provide clear guidelines, best practices and contingency plans meant to guide teams through each phase of software deployment. This guidance is of moderate technical complexity and assumes a basic understanding of cybersecurity. | 本ガイドは、安全なソフトウェア導入プロセスにおける6つの重要なフェーズの概要を提供する。認可プロバイダは、ソフトウェア配備の各フェーズを通じてチームをガイドすることを意図した、明確なガイドライン、ベストプラクティス、不測の事態への対応策を提供するプレイブックの使用と定期的な保守を強く推奨している。このガイダンスは、技術的に中程度の複雑さを持ち、サイバーセキュリティの基本的な理解を前提としている。 |
・[PDF]
目次...
| Introduction | 序文 |
| Objectives | 目的 |
| Key Phases of A Safe Software Deployment Process | 安全なソフトウェア展開プロセスの主要フェーズ |
| Planning | 計画 |
| Key Considerations | 主要な考慮事項 |
| Development and Testing | 開発とテスト |
| Internal Rollout (Dogfood) | 内部ロールアウト（ドッグフード） |
| Deployment and Canary Testing | 展開とカナリアテスト |
| Controlled Rollout | 管理ロールアウト |
| Feedback Into Planning | 計画へのフィードバック |
| Playbooks | プレイブック |
| Errors | エラー |
| Emergency Protocols | 緊急プロトコル |
| Incident Detection and Reporting | インシデント検知と報告 |
| Engineering and Management Escalation Processes | エンジニアリングとマネジメントのエスカレーションプロセス |
| Recovery and Rollback Procedures | 復旧とロールバックの手順 |
| Root Cause Analysis and Reporting | 根本原因の分析と報告 |
| Customer and Partner Notification Plan | 顧客とパートナーへの通知計画 |
| Customer Notification Plan | 顧客への通知計画 |
| Additional Consideration: N-1 Releases | 追加の考慮事項： N-1リリース |
| Conclusion | 結論 |
| Disclaimer | 免責事項 |
| Acknowledgements | 謝辞 |
| Additional Resources | 追加リソース |
| Introduction | 序文 |
| Many software manufacturers and service providers deploy software and configuration updates as part of their service offerings. These updates may enhance features and/or address security vulnerabilities to provide benefits and security to customers. However, software and the systems that deploy software are highly complex and continually evolving, making it challenging to deploy secure updates. | 多くのソフトウェア製造事業者やサービスプロバイダーは、サービス提供の一環として、ソフト ウェアや設定のアップデートを展開している。これらのアップデートは、機能を強化したり、セキュリティの脆弱性に対処したりして、顧客にメリットとセキュリティを提供する。しかし、ソフトウェアとソフトウェアを展開するシステムは非常に複雑で、絶えず進化しているため、安全なアップデートを展開することは困難である。 |
| It is critical for all software manufacturers to implement a safe software deployment program supported by verified processes, including robust testing and measurements. The program should support and enhance both the security and quality of the product and deployment environment. This guide, authored by the Cybersecurity and Infrastructure Security Agency (CISA) and the following partners (hereafter referred to as the authoring agencies), encourages software manufacturers to establish a safe software deployment program as part of their software development lifecycle (SDLC). | すべてのソフトウェア製造事業者にとって、強固なテストと測定を含む検証済みのプロセスに支えられた安全なソフトウェア展開プログラムを実施することが極めて重要である。このプログラムは、製品と展開環境のセキュリティと品質の両方をサポートし、強化するものでなければならない。本ガイドは、サイバーセキュリティ・インフラセキュリティ庁（CISA）と以下のパートナー（以下、作成機関）が作成したものであり、ソフトウェア製造事業者に対し、ソフトウェア開発ライフサイクル（SDLC）の一環として、安全なソフトウェア展開プログラムを確立することを推奨する。 |
| • U.S. Federal Bureau of Investigation | - 米国連邦捜査局 |
| • Australian Signals Directorate’s (ASD’s) Australian Cyber Security Centre (ACSC) | - オーストラリア信号総局のオーストラリアサイバーセキュリティセンター |
| Software manufacturers should incorporate safe deployment practices early in the SDLC. Safe deployment processes do not begin with the first push of code; they start much earlier. To maintain product quality and reliability, technology leaders should ensure that all code and configuration changes pass through a series of well-defined phases that are supported by a robust testing strategy. These phases are designed to catch any new issues and regressions, reducing the risk of flawed software from impacting customers. | ソフトウェア製造事業者は、SDLC の早い段階で安全な展開方法を取り入れるべきである。安全な展開プロセスは、コードの最初のプッシュから始まるのではない。製品の品質と信頼性を維持するために、技術リーダーは、すべてのコードと設定の変更が、堅牢なテスト戦略によってサポートされる、明確に定義された一連のフェーズを通過することを確実にすべきである。これらのフェーズは、新たな問題や回帰をキャッチし、欠陥のあるソフトウェアが顧客に影響を与えるリスクを低減するように設計されている。 |
| This guidance is part of CISA’s Secure by Design campaign. The guide is primarily intended for software or service manufacturers deploying software to many types of customer systems, including mobile devices and laptops, as well as for cloud-based services (which may consist of thousands of physical and virtual systems organized into clusters). While the guide is not specifically focused on internal IT teams deploying to internal systems, many of the same phases will apply—albeit in a modified form. Other domains may require phases that are balanced differently. For example, organizations will have to contemplate complexities in some deployment scenarios, such as OSS software deployments, and the tradeoffs between automatic versus manual updates. This guide will not cover all scenarios but can be a useful tool for organizations looking to mature their deployment processes. | 本ガイダンスは、CISAのSecure by Designキャンペーンの一環である。本ガイダンスは、主に、モバイル・デバイスやノートPCを含む多くの種類の顧客システムにソフトウェアを展開するソフトウェアまたはサービス製造事業者、およびクラウドベースのサービス（クラスターに編成された数千の物理システムおよび仮想システムで構成される場合がある）を対象としている。本ガイドは、社内システムに展開する社内ITチームに特化しているわけではないが、同じフェーズの多くは、修正された形ではあるものの、適用できるだろう。他の領域では、異なるバランスのフェーズが必要になるかもしれない。たとえば、OSSソフトウエアの展開のような展開シナリオの複雑さや、自動更新と手動更新のトレードオフを考慮する必要がある。本ガイドは、すべてのシナリオをカバーするものではないが、展開プロセ スの成熟を目指す組織にとって有用なツールとなる。 |
| Objectives | 目的 |
| A safe software deployment process aims to achieve several key objectives, contributing to the success of secure software deployment efforts. These objectives help ensure that software is not only reliable, safe, and secure for customers, but is deployed in a controlled, efficient manner. By incorporating mechanisms for timely issue detection, continuous improvement, and support for agile development, the safe software deployment process empowers teams to deliver high-quality software while adapting to changing requirements and technologies. | 安全なソフトウェア展開プロセスは、いくつかの重要な目的を達成すること を目的とし、安全なソフトウェア展開作業の成功に貢献する。これらの目的は、ソフトウ ェアが顧客にとって信頼性が高く、安全でセキュアであるだけでなく、管理され た効率的な方法で展開されることを保証するのに役立つ。タイムリーな問題検知、継続的改善、アジャイル開発のサポートなどのメカニズムを組み込むことで、安全なソフトウェア展開プロセスは、変化する要件や技術に適応しながら、チームが高品質のソフトウェアを提供できるようにする。 |
| 1. Quality processes. Robust quality assurance processes help ensure that software products function consistently and meet customer expectations without causing disruptions. This focus on reliability enhances customer safety by reducing the risk of failures that could compromise critical systems or data, resulting in increased customer trust. | 1. 品質プロセス。堅牢な品質保証プロセスは、ソフトウェア製品が一貫して機能し、混乱を引き起こすことなく顧客の期待に応えることを保証するのに役立つ。このように信頼性を重視することで、重要なシステムやデータを危険にさらす可能性のある障害のリスクを低減し、顧客の安全性を高め、その結果、顧客の信頼を高めることができる。 |
| 2. Cost and impact management. For software manufacturers, technical and process defects cost less to remediate when such defects are caught early in the process and cause less damage to customer systems. Customers impacted by these defects can suffer downtime and data loss, adversely affecting both their financial and reputational positions. | 2. コストと影響の管理。ソフトウェア製造事業者にとって、技術的な欠陥やプロセス上の欠陥は、 プロセスの早い段階で発見されれば、修復にかかるコストが少なくなり、 顧客システムへのダメージも少なくなる。このような欠陥の影響を受けた顧客は、ダウンタイムやデータ喪失に見舞われ、財務面でも評判面でも悪影響を受ける可能性がある。 |
| 3. Controlled and measured deployments. A well-defined deployment strategy includes phased rollouts, such as canary releases, allowing manufacturers to monitor performance in realworld environments without impacting all customers at once. This reduces the risk of widespread failures and provides valuable data to refine subsequent deployments. | 3. 管理され、測定された展開。明確に定義された展開戦略には、カナリア・リリースなどの段階的な展開が含まれ、製造事業者は、すべての顧客に一度に影響を与えることなく、実環境でのパフォーマンスを監視することができる。これにより、広範な障害のリスクが軽減され、その後の展開を改良するための貴重なデータが得られる。 |
| 4. Comprehensive testing. Early detection through comprehensive testing strategies, including automated testing and monitoring tools, allows teams to identify and address defects before they escalate into larger problems. Proactively catching issues early improves the quality of a product and reduces the likelihood of expensive fixes later. | 4. 包括的テスト。自動テストや監視ツールを含む包括的なテスト戦略による早期検知により、チームは欠陥がより大きな問題に拡大する前に特定し、対処することができる。プロアクティブに問題を早期に発見することで、製品の品質が向上し、後で高額な修正を余儀なくされる可能性が低くなる。 |
| 5. Continuous improvement. Feedback loops integrated into the development and deployment processes enable teams to learn from each iteration and apply those lessons to future releases. Using feedback loops helps evolve the safe software deployment process and improves maintenance practices of security standards, as well as improves performance, and better meets the needs of users. It is important to include “near misses” in the feedback loop. “Near misses” provide an opportunity to enhance the program without the software manufacturer or their customers experiencing the full negative impact of an actual incident. | 5. 継続的改善。開発および展開プロセスに統合されたフィードバック・ループにより、チームは各反復から学び、その教訓を将来のリリースに適用することができる。フィードバックループの活用は、安全なソフトウエアの展開プロセスを進化させ、セキュ リティ標準の保守慣行を改善し、パフォーマンスを向上させ、ユーザーのニーズをよ りよく満たすのに役立つ。フィードバックループに「ニアミス」を含めることが重要である。「ニアミス」は、ソフトウエア製造事業者やその顧客が実際のインシデントによる悪影響を完全に経験することなく、プログラムを強化する機会を提供する。 |
| 6. Optimize for agility. Teams should be able to adapt quickly to changes in requirements, emerging technologies, and security threats. Shorter development cycles, collaboration, and iterative improvements help deliver high-quality software that meets evolving customer expectations. | 6. 俊敏性を最適化する。チームは、要件の変化、新たな技術、セキュリティ上の脅威に迅速に適応でき るべきである。開発サイクルの短縮、コラボレーション、反復的な改善は、進化する顧客の期待に応える高品質のソフトウエアを提供するのに役立つ。 |
| 7. Secure development ecosystem. A secure development ecosystem is designed to support developers while reducing the likelihood of defects entering the code base. Software manufacturers have a greater chance of detecting and blocking issues earlier by implementing automated technical controls throughout the development ecosystem. | 7. セキュア開発のエコシステム。セキュア開発のエコシステムは、コードベースに欠陥が入り込む可能性を低減しながら、開発者をサポートするように設計されている。ソフトウェア製造事業者は、開発エコシステム全体に自動化された技術的コントロールを導入することで、問題を早期に検知しブロックできる可能性が高まる。 |
| Key Phases of a Safe Software Deployment Process | 安全なソフトウェア展開プロセスの鍵フェーズ |
| Successful safe software deployments are based on an established secure software framework such as NIST Secure Software Development Framework (SSDF). Moreover, safe deployments hinge on a structured, well thought out process incorporated into the SDLC that minimizes risk and promotes reliability. Each phase of a safe software deployment process plays a critical role in guiding software from initial planning to release. Strongly recommended practices for safely deploying software are rigorous testing during the planning phase, controlled deployments, and continuous feedback. By following these key phases, software manufacturers can enhance product quality, reduce deployment risks, and provide a better experience for their customers. | 安全なソフトウェア展開は、NIST セキュア開発フレームワーク（SSDF）のような確立された安全なソフトウェアフレームワークに基づいている。さらに、安全な展開は、リスクを最小化し、信頼性を促進する SDLC に組み込まれた、構造化され、よく考えられたプロセスにかかっている。安全なソフトウェア展開プロセスの各フェーズは、初期計画からリリースまでソフトウェアを導く上で重要な役割を果たす。ソフトウェアを安全に展開するために強く推奨されるプラクティスは、計画段階での厳密なテスト、管理された展開、継続的なフィードバックである。これらの重要なフェーズに従うことで、ソフトウェア製造事業者は製品の品質を高め、展開リスクを低減し、顧客により良い体験を提供することができる。 |
| The subsections below include common phases found in successful safe software deployment programs: | 以下のサブセクションでは、安全なソフトウェア展開プログラムの成功に見られる一般的なフェーズを紹介する： |
| Planning | 計画立案 |
| Before writing any code, a clear plan should be established to define goals and build requirements, understand customer needs, scope potential threats, and specify success criteria. The planning phase sets the foundation for the entire deployment process, helping ensure teams are aware of the scope, potential risks, and costs before moving into development. | コードを記述する前に、目標定義と要件構築、顧客ニーズの理解、潜在的な脅威のスコープ、成功規準の特定を行うための明確な計画を策定する必要がある。計画フェーズでは、展開プロセス全体の基礎を設定し、開発に移行する前に、チームがスコープ、潜在的なリスク、コストを確実に認識できるようにする。 |
| Key Considerations | 主な考慮事項 |
| Operational Risk Assessment | 運用リスクアセスメント |
| Implementing a comprehensive, ongoing assessment of the risks and consequences of deploying software in an environment reduces risk. An operational risk assessment includes understanding system relationships and interdependencies, potential threats, safety, security, reliability, performance requirements, and risks associated with common defects. For example, if a service relies on another product’s service account (SA), and the permissions of that SA change, parts of the system may fail in seemingly unexpected ways. It is essential to include the processes and technologies of a safe software deployment program in the overall written product threat model. | ソフトウェアを環境に展開する際のリスクと結果について、包括的かつ継続的なアセスメントを実施することで、リスクを低減することができる。運用リスクアセスメントには、システムの関係や相互依存関係、潜在的な脅威、 安全性、セキュリティ、信頼性、性能要件、一般的な欠陥に関連するリスクなどを 理解することが含まれる。例えば、あるサービスが他の製品のサービスアカウント（SA）に依存しており、そのSAの権限が変更された場合、システムの一部が一見予期しない方法で故障する可能性がある。安全なソフトウエア展開プログラムのプロセスと技術を、文書化された製品脅威モデル全体に含めることが不可欠である。 |
| Conduct a Failure Anticipation Review | 障害予見レビューの実施 |
| Sometimes referred to as a “pre-mortem,” this review helps teams identify potential failures, drawing on insights from previous retrospectives (or post-mortems). | 「プレモルテム（pre-mortem）」と呼ばれることもあるこのレビューは、チームが以前のレトロスペクティブ（またはポストモルテム）から得た洞察をもとに、潜在的な障害を特定するのに役立つ。 |
| Platform Scale and Diversity | プラットフォームの規模と多様性 |
| Deployment teams should extensively document the multiple potential roll-out scenarios associated with their products. Teams should plan for increasing platform and device diversity in cases where the software operates across multiple environments. Consider more than just device count when contemplating device diversity. Diversity can include different types of operating systems, hardware brands, firmware versions, firmware settings, bandwidth speeds and reliability, environmental settings, and geography. Teams should verify sufficient testing coverage before increasing their internal deployment rate. | 展開チームは、製品に関連する複数の潜在的な展開シナリオを広範に文書化する必要がある。チームは、ソフトウェアが複数の環境で動作する場合、プラットフォームとデバイスの多様性を高める計画を立てるべきである。デバイスの多様性を考慮する際には、デバイス数以上のことを考慮する。多様性には、さまざまなタイプのオペレーティングシステム、ハードウェアブランド、ファームウェアのバージョン、ファームウェアの設定、帯域幅の速度と信頼性、環境設定、地理的なものなどが含まれる。チームは、社内展開率を高める前に、十分なテストカバレッジを検証すべきである。 |
| Online Service Diversity | オンラインサービスの多様性 |
| Online service diversity may include data center regions and network configurations and include failover and backup solutions as necessary. | オンラインサービスの多様性には、データセンターの地域やネットワーク構成が含まれ、 必要に応じてフェイルオーバーやバックアップソリューションが含まれる。 |
| Planning Deployment Cadence | 計画展開のケイデンス |
| Whether the organization sets a monthly “Patch Tuesday” or delivers multiple configuration updates per day, the team should formalize this plan and communicate it clearly to internal stakeholders and external customers. | 毎月の「パッチの火曜日」を設定する場合でも、1 日に複数の構成アップデートを配信する場合でも、チームはこの計画を正式なものとし、社内の利害関係者や社外の顧客に明確に伝えるべきである。 |
| Monitoring and Reporting Strategy | 監視および報告戦略 |
| Manufacturers should identify the signals that provide the clearest view of system health and report identified issues to feed back into the continuous improvement process. | 製造事業者は、システムの健全性を最も明確に把握できるシグナルを特定し、特定 された問題を報告して継続的改善プロセスにフィードバックする。 |
| Staffing | 人員配置 |
| Complex deployments require a team capable of monitoring both deployments and the refinement of the safe software deployment process. A shortage of either operations staff or software/process developers increases the risk of unexpected incidents. | 複雑な展開には、展開と安全なソフトウェア展開プロセスの改良の両方を監視できるチームが必要である。運用スタッフまたはソフトウェア／プロセス開発者のいずれかが不足すると、予期せぬインシデントのリスクが高まる。 |
| Fault Tolerance | フォールトトレランス（耐障害性） |
| Systems can be designed to be resilient and/or fail safely even when presented with bad or malicious code or configuration changes. Each organization should consider ways to build resilience into the planning process. | システムは、悪いコードや悪意のあるコード、あるいは構成の変更があった場合でも、レジリエンス（耐障害性） が高く、安全に機能するように設計することができる。各組織は、計画プロセスにレジリエンスを組み込む方法を検討すべきである。 |
| Deprecation and End of Life | 非推奨と耐用年数の終了 |
| Software manufacturers should plan for feature deprecation and product end of life. Early warning will reduce the impact to customers and reduce the likelihood of them facing adverse effects. | ソフトウェア製造事業者は、機能の廃止と製品寿命の終了を計画すべきである。早期に警告を発することで、顧客への影響を軽減し、顧客が悪影響に直面する可能性を減らすことができる。 |
| Patching | パッチ適用 |
| Software manufacturers should plan for patching the products and services they develop. They should make the process of applying patches as seamless as possible. Security patches may require subsequent updates to fix identified vulnerabilities that could be exploited by malicious actors. Malicious actors may reverse engineer patches to identify vulnerabilities that may not yet be publicly disclosed. By leveraging information from newly released patch advisories, malicious actors can exploit customer systems that lack the most recent security patches. (see the N-1 Releases section below). | ソフトウェア製造事業者は、開発した製品やサービスにパッチを適用する計画を立てるべきである。また、パッチの適用プロセスを可能な限りシームレスにする必要がある。セキュリティパッチは、悪意のある行為者に悪用される可能性のある識別された脆弱性を修正するために、その後のアップデートを必要とする場合がある。悪意のある行為者は、パッチをリバースエンジニアリングして、まだ一般に公開されていない脆弱性を特定する可能性がある。新しくリリースされたパッチ勧告の情報を活用することで、悪意のある行為者は、最新のセキュリティパッチが適用されていない顧客システムを悪用することができる。(後述の「N-1 リリース」のセクションを参照）。 |
| Development and Testing | 開発とテスト |
| This phase involves coding and continuous testing. Testing at this phase typically includes unit, integration, and automated (including static and dynamic) tests to catch issues early. Code should be tested in an environment that closely mirrors typical customer environments to help ensure accuracy and reliability. Organizations should consider devoting resources to actively trying to cause the deployment process to fail under controlled circumstances to preempt a failure in the field. | このフェーズでは、コーディングと継続的なテストが行われる。このフェーズのテストには、問題を早期に発見するための単体テスト、統合テスト、自動テスト （静的テストと動的テストを含む）が含まれるのが一般的である。コードは、正確性と信頼性を確保するために、顧客の典型的な環境に近い環境でテストされるべきである。組織は、現場での失敗を未然に防ぐために、制御された状況下で積極的に展開プロセスを失敗させようとするリソースを割くことを検討すべきである。 |
| Internal Rollout (Dogfood) | 内部ロールアウト（ドッグフード） |
| When appropriate, based on the type of software and internal enterprise needs, internal teams should be the first to use new software versions. This “dogfooding” phase allows organizations to catch issues before the software reaches external users. By testing the product in real-world scenarios, internal users provide valuable feedback that helps improve the product’s stability and performance. The number of devices and amount of time needed to obtain sufficient coverage will vary; organizations should establish standards and adjust them with input from previous release cycles. Additionally, organizations should establish a culture of encouraging staff to report potential problems, even when the problems seem negligible. | 適切な場合は、ソフトウェアの種類とエンタープライズ内部のニーズ に基づいて、内部チームが新しいソフトウェアバージョンを最初に使用す る。この 「ドッグフード 」フェーズによって、組織は、ソフトウエアが外部ユーザーに届く前に問題を発見することができる。実際のシナリオで製品をテストすることで、社内ユーザーは、製品の安定性とパフォーマンスの改善に役立つ貴重なフィードバックを提供する。十分なカバレッジを得るために必要なデバイスの数と時間は様々である。組織は、標準を確立し、以前のリリースサイクルからのインプットをもとに調整すべきである。さらに、組織は、たとえ問題が無視できると思われる場合でも、スタッフが潜在的な問題を報告することを奨励する文化を確立すべきである。 |
| Deployment and Canary Testing | 展開とカナリアテスト |
| The deployment to customers should be completed in a controlled way. Deployment options can include canary deployments (small-scale deployments to a limited number of customers or systems), allowing teams to monitor performance and resolve issues before a wider rollout. For software-as-aservice (SaaS) products, this may involve deploying the update to a small portion of servers or directing limited traffic at updated components. For on-premises products, the update may first be released to only a subset of customers. Organizations may wish to consider variations, such as “blue/green” deployment models or splitting customers into “Stable” and “Early Access” groups, allowing them to match access to new features with their risk tolerance. | 顧客への展開は、管理された方法で完了すべきである。展開のオプションには、カナリア展開（限られた数の顧客またはシステムへの小規模展開）を含めることができ、これによってチームは、広範囲に展開する前にパフォーマンスを監視し、問題を解決することができる。SaaS（Software-as-As-Service）製品の場合、一部のサーバーにアップデートを展開したり、アップデートされたコンポーネントに限定されたトラフィックを誘導したりする。オンプレミス製品の場合、アップデートはまず一部の顧客のみにリリースされる。組織は、「ブルー／グリーン」展開モデルや、顧客を「安定版（Stable）」と「アーリーアクセス（Early Access）」グループに分けるなどのバリエーションを検討するとよい。 |
| Controlled Rollout | 管理されたロールアウト |
| After verifying successful canary deployments, the deployment team can release the new version to more users. As confidence in the new version grows, the deployment can gradually expand to more devices or systems. This controlled rollout prevents sudden, widespread failures. Organizations will want to consider the appropriate velocity of a deployment for urgent security fixes compared to more routine content deployments. Organizations will need to factor in both their risk tolerance with expectations and the risk appetites of customers. During a rollout, teams may need an automatic breaker or the equivalent of an emergency stop button to halt the rollout, especially during an incident. | カナリア展開の成功を確認した後、展開チームは新バージョンをより多くのユー ザーにリリースすることができる。新バージョンの信頼性が高まるにつれて、展開を徐々にデバイスやシステムを増やしていくことができる。このように管理された展開により、突然の広範囲な障害を防ぐことができる。企業は、緊急のセキュリティ修正と、より日常的なコンテンツの展開とで、適切な展開速度を検討する必要がある。企業は、期待されるリスク許容度と顧客のリスク許容度の両方を考慮する必要がある。ロールアウト中、特にインシデントが発生した場合、チームはロールアウトを停止するための自動ブレーカーまたは緊急停止ボタンに相当するものを必要とすることがある。 |
| Feedback Into Planning | 計画へのフィードバック |
| Continuous feedback is critical throughout the entire process, but particularly after release. Insights from customers, development and quality teams, system logs, examples of unexpected or abnormal system behavior, and performance metrics should feed directly back into the planning phase of the next development cycle. This feedback will enable continuous improvement and a faster response to issues. | 継続的なフィードバックは、全プロセスを通じて重要であるが、特にリリース後に重要である。顧客、開発チーム、品質チームからの洞察、システムログ、予期せぬ、あるいは異常なシステム動作の例、パフォーマンス指標は、次の開発サイクルの計画段階に直接フィードバックされるべきである。このフィードバックにより、継続的な改善と問題への迅速な対応が可能になる。 |
| Figure 1 shows these phases over time. Each software and service provider will tune the slope of the curve to their risk tolerance and other business considerations. Providers should also factor in their customer risk tolerances. | 図1は、これらのフェーズを時系列で示したものである。各ソフトウェアプロバイダーやサービスプロバイダーは、自社のリスク許容度やその他のビジネス上の考慮事項に合わせて、曲線の傾きを調整する。プロバイダは、顧客のリスク許容度も考慮に入れるべきである。 |
 |
|
| Figure 1: Deployment Timeline | 図 1: 展開のタイムライン |
| Playbooks | プレイブック |
| Playbooks serve as essential tools for ensuring that safe software deployment processes are welldocumented, repeatable, and resilient. They provide clear guidelines, best practices, and contingency plans to help teams navigate each phase of deployment. Playbooks also help software manufacturers reduce risks and respond effectively to any issues that arise, ultimately safeguarding both the software and the customers who rely on it. Automation, where possible, can help align the above factors to the deployment objectives. | プレイブックは、安全なソフトウェア展開プロセスを文書化し、再現可能で、レジリエ ンスに優れたものにするために不可欠なツールである。プレイブックは、明確なガイドライン、ベストプラクティス、コンティンジェンシープランを提供し、チームが展開の各フェーズをナビゲートするのに役立つ。また、プレイブックは、ソフトウェア事業者がリスクを低減し、発生した問題に効果的に対応するのに役立ち、最終的にソフトウェアとそれに依存する顧客の両方を保護する。可能であれば自動化することで、上記の要素を展開の目的に合わせることができる。 |
| Like all playbooks, deployment teams should have regular training and simulated incident testing. The time to learn how to react is not when the system is failing and potentially causing customer issues. It is essential to determine how people, processes, and technologies work together before an incident. | すべてのプレイブックと同様に、展開チームは定期的なトレーニングとインシデントテストのシミュレーションを行うべきである。対応方法を学ぶべき時は、システムに障害が発生し、顧客の問題を引き起こす可能性がある時ではない。インシデントが発生する前に、人、プロセス、およびテクノロジがどのように連携するかを見極めることが不可欠である。 |
| It is important to recognize that deploying software to customer systems involves business considerations, not just technical considerations. Senior business leaders should ensure teams curate the playbook over time, request changes, and formally approve playbooks at least annually. The joint guide, Shifting the Balance of Cybersecurity Risk emphasizes the principle of “leading from the top.” Having a business leader take ownership of the process will help ensure the organization allocates the necessary resources to achieve successful outcomes. | 顧客のシステムにソフトウェアを展開するには、技術的な検討だけでなく、ビジネス上の検討が必要であることを認識することが重要である。シニア・ビジネス・リーダーは、チームがプレイブックを長期にわたって管理し、変更を要求し、少なくとも年に1回はプレイブックを正式に承認するようにすべきである。共同ガイド「サイバーセキュリティ・リスクのバランスをシフトする」では、「トップが主導する」という原則が強調されている。ビジネスリーダーにプロセスのオーナーシップを持たせることは、組織が成功の結果を達成するために必要なリソースを割り当てることを確実にするのに役立つ。 |
| Like all other elements of an SDLC, playbooks require regular maintenance to monitor and improve their level of maturity and ability to achieve the organization’s mission. | SDLC の他のすべての要素と同様に、プレイブックは、その成熟度と組織のミッションを達成する能力を監視し、改善するために定期的な保守が必要である。 |
| Errors | エラー |
| At any phase of the deployment process, the product or support system may encounter errors. These errors may be the result of latent coding errors in the software or deployment system that escaped testing measures. They can include performance issues, compatibility issues, or even security issues. | 展開プロセスのどの段階でも、製品やサポートシステムがエラーに遭遇することがある。これらのエラーは、ソフトウェアまたは展開システ ムに潜在するコーディングエラーの結果である可能性があり、テストによる対策 を逃れることがある。このようなエラーには、パフォーマ ンスの問題、互換性の問題、あるいはセキュリティの問題が含まれることもある。 |
| It is important that the technology leadership team establish written playbooks to guide staff when they encounter these types of errors. These playbooks should include thresholds for acceptable error rates, staff response, and command chain escalation. | テクノロジーリーダーシップチームは、スタッフがこの種のエラーに遭遇したときのガイドとなるプレイブックを文書化することが重要である。これらのプレイブックには、許容可能なエラー率のしきい値、スタッフの対応、およびコマンドチェーンのエスカレーションを含めるべきである。 |
| Organizations that deploy real-time monitoring systems and automated alerting and escalation systems can react more quickly to anomalies and errors than those that rely solely on human operators. Earlier detection of issues and automated remediation reduce the time between identification and resolution, leading to fewer impacted customers and minimized downtime. | リアルタイムの監視システム、自動化されたアラートとエスカレーションシステムを展開する組織は、人間のオペレーターだけに頼っている組織よりも、異常やエラーに対してより迅速に対応することができる。問題の早期検知と自動化された修復により、検知から解決までの時間が短縮され、影響を受ける顧客の減少とダウンタイムの最小化につながる。 |
| Emergency Protocols | 緊急時の手順 |
| The playbook should include detailed steps for handling emergencies during or after software deployments, including detailed recovery tasks. At a minimum, the following topics should be covered. | プレイブックには、詳細な復旧作業を含め、ソフトウェア展開中または展開後の緊急事態に対処するための詳細な手順を含めるべきである。最低限、以下のトピックをカバーする必要がある。 |
| Incident Detection and Reporting | インシデントの検知と報告 |
| Clearly define how issues are identified, whether through automated monitoring systems, internal testing and/or customer reports. Social media may also be a source of important information that may be missing from other, more formal channels. | 自動監視システム、内部テスト、顧客からの報告など、問題の検知方法を明確に定義する。ソーシャルメディアは、他の正式なチャネルにない重要な情報源となる可能性もある。 |
| Engineering and Management Escalation Processes | エンジニアリングおよびマネジメントのエスカレーションプロセス |
| Outline a structured escalation path that indicates when and how incidents are escalated to senior engineers, management, or even external partners. | いつ、どのようにインシデントがシニアエンジニア、マネジメント、あるいは外部パートナーにエスカレーションされるかを示す、構造化されたエスカレーションパスの概要を示す。 |
| Recovery and Rollback Procedures | 復旧およびロールバックの手順 |
| Document a detailed recovery plan that can be executed quickly if a deployment causes significant failures. This should include the steps needed to revert systems to a previous stable state, validation checks to ensure the rollback is effective, and safeguards to prevent data loss. Understanding how to bring customers back to the last known “good” state will require careful planning, especially if the target systems are highly diverse. One common strategy is to enhance systems to degrade gracefully by, for example, disabling certain configurations, rather than stopping a deployment entirely. | 展開に重大な障害が発生した場合に、迅速に実行できる詳細な復旧計画を文書化する。これには、システムを以前の安定した状態に戻すために必要な手順、ロールバックが効果的であることを確認するための妥当性確認、データ損失を防ぐための保護措置などを含める。特に対象となるシステムが非常に多様である場合は、どのようにして顧客を最後に確認された「良好な」状態に戻すかを理解するには、慎重な計画が必要となる。一般的な戦略の1つは、展開を完全に停止するのではなく、特定の構成を無効にするなどして、システムが優雅に劣化するように強化することである。 |
| Note: Recovery planning scenarios where automated rollback cannot be implemented require additional care. | 注：自動ロールバックが実施できない復旧計画シナリオでは、さらに注意が必要である。 |
| Root Cause Analysis and Reporting | 根本原因の分析と報告 |
| After resolving the immediate issue, conduct a thorough root cause analysis (RCA) as part of a blameless retrospective to identify what went wrong and why. RCA should be followed by documentation of the findings and corrective actions that can prevent similar incidents from occurring in future deployments. “Near misses” can provide significant value in this step. | 当面の問題を解決した後、何が問題であったか、なぜ問題であったかを特定するために、 非の打ちどころのない回顧の一環として徹底的な根本原因分析（RCA）を実施する。RCAの後には、調査結果を文書化し、今後の展開において同様のインシデントが発生しないようにするための是正措置を講じるべきである。「ニアミス」は、このステップにおいて重要な価値を提供することができる。 |
| Customer and Partner Notification Plan | 顧客およびパートナーへの通知計画 |
| Ensure there is a plan in place for notifying customers and partners in the event of a critical issue. This includes determining the appropriate communication channels (email, social media, in-app notifications) and message timing and providing clear information on the issue, its impact, and expected resolution time. Revalidating customer and partner contact information can prevent costly delays in communication. See below for more detail. | 重大な問題が発生した場合に、顧客およびパートナーに通知するための計画があることを確認する。これには、適切なコミュニケーションチャネル（電子メール、ソーシャルメディア、アプリ内通知）とメッセージのタイミングを決定すること、問題、その影響、予想される解決時間に関する明確な情報を提供することが含まれる。顧客やパートナーの連絡先情報を再検証することで、コストのかかるコミュニケーションの遅れを防ぐことができる。詳細は以下を参照のこと。 |
| Note: The safe software deployment process should be referenced in the larger incident response plan (IRP). Integrating the deployment process into the incident response plan allows for a seamless transition from deployment management to incident handling. It also helps ensure that all relevant stakeholders—developers, operations teams, security personnel, external communications, and customer support—are aligned and equipped to minimize downtime, address security vulnerabilities, and maintain business continuity. | 注：安全なソフトウェア展開プロセスは、より大きなインシデント対応計画（IRP）の中で参照されるべきである。展開プロセスをインシデント対応計画に統合することで、展開管理からインシデントハンドリングへのシームレスな移行が可能になる。また、開発者、運用チーム、セキュリティ職員、社外コミュニケーション、顧 客サポートなど、関係するすべての利害関係者が、ダウンタイムを最小化し、セキュリ ティの脆弱性に対処し、事業継続性を維持するための足並みをそろえ、体制を整え ることができる。 |
| Customer Notification Plan | 顧客への通知計画 |
| Even with a safe software deployment process, incidents may still occur. To maintain transparency and trust, software manufacturers should have structured plans for notifying customers. The following elements should be considered in the notification plan: | 安全なソフトウエア展開プロセスであっても、インシデントが発生する可能性はある。透明性と信頼を維持するために、ソフトウエア製造事業者は、顧客に通知するための体系的な計画を持つべきである。通知計画では、以下の要素を考慮する必要がある： |
| 1. Pre-deployment notifications: Before any major update, notify customers about upcoming deployments, including the expected timeline, potential impact, and any planned downtime. | 1. 展開前の通知： 主要なアップデートの前に、予定されるスケジュール、潜在的な影響、予定されるダウンタイムを含め、今後の展開について顧客に通知する。 |
| Note: This element needs to be calibrated to avoid alert fatigue. | 注：この要素は、アラート疲労を避けるために調整する必要がある。 |
| 2. Support customer controlled deployment: Allow customers control over the deployment schedule and how they receive updates. | 2. 顧客がコントロールできる展開をサポートする： 顧客が展開スケジュールやアップデートの受信方法を制御できるようにする。 |
| 3. Rollout status update: During the deployment process, provide real-time or frequent updates on the rollout status via an appropriate channel, such as a well-known and continuously updated public web portal. | 3. 展開状況の更新：展開プロセス中、よく知られた継続的に更新される公開ウェブポータルな どの適切なチャネルを通じて、展開状況に関するリアルタイムまたは頻繁な更新を提供 する。 |
| 4. Incident and outage reporting: If an issue arises during deployment, quickly inform customers about the nature of the incident, its impact on their systems, and the steps being taken to resolve it. | 4. インシデントおよび障害報告： 展開中に問題が発生した場合は、インシデントの内容、システムに対する影響、および解決に向けた措置について、顧客に迅速に報告する。 |
| 5. Post-deployment notification: Once the deployment is complete, send a follow-up communication to confirm the successful rollout. Include details of any new features, bug fixes, or changes and provide a channel for customers to report any post-deployment issues they may encounter. | 5. 展開後の通知： 展開が完了したら、フォローアップコミュニケーションを送信し、展開の成功を確認する。新機能、バグ修正、変更点の詳細を記載し、顧客が展開後に発生した問題を報告するためのチャネルを提供する。 |
| Additional Consideration: N-1 Releases | 追加の考慮事項： N-1リリース |
| Some customers prefer to stay on older versions of software or configurations—often referred to as N-1 (the previous release) or N-2 (two releases back)—to avoid potential risks associated with new updates. These risks may include bugs, compatibility issues, or disruptions that could affect their systems or operations. | 顧客によっては、新しいアップデートに伴う潜在的なリスクを避けるために、古いバージョンのソフトウェアや構成（しばしばN-1（1つ前のリリース）またはN-2（2つ前のリリース）と呼ばれる）を使い続けることを好む。こうしたリスクには、バグや互換性の問題、システムや業務に影響を与えかねない混乱などがある。 |
| However, while staying on older versions may seem safer, delaying updates can introduce unmanaged risks, particularly when updates include critical security enhancements or vulnerability patches. Software manufacturers should focus on improving their deployment practices and demonstrating their reliability to customers. Rather than slowing down deployments, software manufacturing leaders should prioritize enhancing deployment processes to ensure both security and stability. | しかし、旧バージョンを使い続けることは安全なように思えるかもしれないが、アップデートを遅らせることは、特にアップデートに重要なセキュリティ強化や脆弱性パッチが含まれている場合、管理しきれないリスクをもたらす可能性がある。ソフトウェア事業者は、展開方法を改善し、顧客に信頼性を示すことに注力すべきである。ソフトウェア製造事業者のリーダーは、展開を遅らせるのではなく、セキュリティと安定性の両方を確保するために展開プロセスを強化することを優先すべきである。 |
| Conclusion | 結論 |
| Safety and security incidents often result from multiple contributing factors, including people, processes, and technology elements working together in a system that may become misaligned (sometimes in unexpected and unlikely ways). A safe software deployment process should be integrated with the organization’s SDLC, quality program, risk tolerance, and understanding of the customer’s environment and operations. By adopting a systems-thinking approach, teams may reduce the likelihood of their deployment process operating outside the safety boundary. | 安全性とセキュリティのインシデントは、多くの場合、人、プロセ ス、技術要素がシステム内で連携し、（時には予期しない、ありそうもな い方法で）不整合になるなど、複数の要因から発生する。安全なソフトウェア展開プロセスは、組織の SDLC、品質プログラム、リスク許容度、顧客の環境と運用の理解と統合されるべきである。システム思考のアプローチを採用することで、チームは、展開プロセスが安全性の境界の外で動作する可能性を減らすことができる。 |
| Two approaches can help teams maintain this safety boundary. First, foster a blameless retrospective (also called “postmortem”) culture, where teams analyze both positive and negative outcomes by focusing on the processes that contributed to the result, rather than assigning blame to any individual. Individual actions should not lead to an incident if the environment and processes are resilient. | チームがこの安全境界を維持するには、2 つのアプローチが有効である。第一に、非を認めない回顧的な（「事後分析」とも呼ばれる）文化を醸成する。この文化では、チームは、個人に責任を負わせるのではなく、結果に貢献したプロセスに焦点を当てて、肯定的な結果も否定的な結果も分析する。環境とプロセスがレジリエンシーであれば、個人の行動がインシデントにつながることはないはずである。 |
| Second, treat “near misses” as real incidents. “Near misses” provide significant information to improve processes. They offer an opportunity to evolve programs without suffering the consequences of an actual incident. Analyzing “near misses” allows teams to uncover weak points in the system and address them proactively, reducing the likelihood of future failures. By studying these events, organizations can build a culture of continuous improvement that strengthens security and operational resilience. | 第二に、「ニアミス」を実際のインシデントとして扱うことである。「ニアミス」は、プロセスを改善するための重要な情報を提供する。ニアミスは、実際のインシデントの結果を被ることなく、プログラムを進化させる機会を提供する。ニアミス」を分析することで、チームはシステムの弱点を発見し、プロアクティブに対処することができる。このような事象を研究することによって、組織は、セキュリティと運用のレジリエンスを強 化する継続的な改善の文化を構築することができる。 |
| Organizations should formally evaluate their software deployment processes based on the points outlined herein and develop a plan to address them through a continuous improvement program. A well-designed software deployment process can ensure that customers receive new features, security, and reliability in a timely manner, while minimizing unplanned outages. | 組織は、ここで概説したポイントに基づいて自社のソフトウェア展開プロセスを正式に評価 し、継続的改善プログラムを通じてそれらに対処する計画を策定すべきである。適切に設計されたソフトウェア展開プロセスによって、顧客に新機能、セキュリ ティ、信頼性をタイムリーに提供することが可能になるとともに、計画外の停止を最小限に抑えることができる。 |
| Disclaimer | 免責事項 |
| The information in this report is being provided “as is” for informational purposes only. CISA, the FBI, and ASD’s ACSC do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA and co-sealers. | 本レポートの情報は、情報提供のみを目的として「現状のまま」提供されている。CISA、FBI、ASDのACSCは、本文書内でリンクされている事業体、製品、サービスを含め、いかなる営利団体、製品、企業、サービスも保証しない。サービスマーク、商標、製造事業者、その他による特定の事業体、製品、プロセス、サービスへの言及は、CISA及び共同シーラーによる推奨、推薦、支持を意味するものではない。 |
| Acknowledgements | 謝辞 |
| This information includes input from the following Joint Cyber Defense Collaborative (JCDC) participants: Microsoft, CrowdStrike, and Google contributed to this guidance. | 本情報には、以下のJoint Cyber Defense Collaborative（JCDC）参加者の意見が含まれている： Microsoft、CrowdStrike、Google が本ガイダンスに貢献した。 |
| Additional Resources | 追加リソース |
| • National Institute of Standards and Technology (NIST) Special Publication (SP) 800-218: Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. | - 国立標準技術研究所（NIST）特別刊行物（SP）800-218： セキュアソフトウェア開発フレームワーク（SSDF）バージョン 1.1： ソフトウェアの脆弱性リスクを低減するための推奨事項。 |
| • Australian Signals Directorate – Australian Cyber Security Centre’s Secure-by-Design Foundations | - オーストラリア信号総局 - オーストラリアン・サイバー・セキュリティ・センターのセキュア・バイ・デザインの基礎 |
● まるちゃんの情報セキュリティ気まぐれ日記
・2024.07.31 米国 NIST SP 800-218A 生成的AIとデュアルユース基盤モデルのための安全なソフトウェア開発プラクティス： SSDFコミュニティプロファイル
・2023.10.18 Five Eyes、ドイツ、オランダ、ノルウェー、韓国、イスラエル、日本、シンガポール、チェコ他 セキュア・バイ・デザイン原則の改訂
・2023.04.15 CISA他 サイバーセキュリティリスクのバランスを変える：セキュリティ・バイ・デザインとセキュリティ・バイ・デフォルトの原則とアプローチ
・2023.02.05 ソフトウェアサプライチェーンリスクの軽減策について...
・2022.02.06 NIST SP 800-218 セキュアソフトウェア開発フレームワーク (SSDF) Version 1.1: ソフトウェアの脆弱性のリスクを軽減するための推奨事項
・2021.10.02 NIST SP 800-218 （ドラフト）セキュアソフトウェア開発フレームワーク (SSDF) Version 1.1: ソフトウェアの脆弱性のリスクを軽減するための推奨事項
Comments