AIでつくる人のセキュリティ 第1章を読む →
トップ›世界水準編›第22章
世界水準編第22章

NIST SSDFとSecure by Design：国家水準の開発基準

読む目安：約45分米国政府の開発基準PO／PS／PW／RVを、個人の規模に読み替える

ASVSが「できあがったアプリ」の基準だとすると、この章で扱うNIST SSDFは「アプリを作る過程」の基準です。米国政府が調達するソフトウェアに求める水準で、4つの実践群に19の実践が並びます。あわせて、CISAが提唱する「製品の安全は作り手の責任」というSecure by Designの原則を読みます。個人開発には大げさに見えますが、経理の内部統制と同じで、枠組みは大きくても規模に応じて適用できます。

この章の学習目標

  • NIST SP 800-218（SSDF v1.1）の4つの実践群PO／PS／PW／RVと、代表的な実践の番号を人に説明できるようになる
  • SP 800-218A（生成AI向けプロファイル）とSSDF 1.2草案、CISAのSecure by Design 3原則の位置づけを説明できるようになる
  • 各実践群から個人規模でできることを1つずつ選び、自分の開発の進め方を「国家水準の基準」に対応づけて点検できるようになる

SSDFとは：作る「過程」の基準

NIST（米国国立標準技術研究所）が2022年2月に公開したSP 800-218「Secure Software Development Framework (SSDF) Version 1.1」は、安全なソフトウェア開発の実践を体系化した文書です。NISTは、BSA、OWASP、SAFECodeといった既存の指針から実践を集めたと説明し、「成果に基づく（outcome-based）」もので「チェックリストではなく、リスクに基づく計画の出発点」だと位置づけています。

背景には、2021年5月の米国大統領令14028「国家のサイバーセキュリティの改善」があります。この大統領令は、政府が購入するソフトウェアの開発過程に安全性を求め、SSDFはその具体的な中身になりました。SP 800-218には、大統領令の各条項がSSDFのどの実践に対応するかの表が付いています。

経理の言葉で言えば、ASVSが「決算書の正しさを検証する監査手続」なら、SSDFは「正しい決算書ができあがる業務プロセスの整備基準」です。プロセスが整っていてはじめて、翌期も正しい結果が出ます。

4つの実践群と、その中身

SSDF v1.1は4つの実践群（practice groups）に分かれ、それぞれに番号付きの実践（practices）があります。次の表は、SP 800-218の原典（nvlpubs.nist.gov）から実践の原題を転記し、筆者が日本語の要約を添えたものです。なお、PW.3は改訂の過程でPW.4に統合され、v1.1では欠番になっています。

群番号原題要旨（筆者による要約）
PO
組織の準備		PO.1Define Security Requirements for Software Development開発のセキュリティ要件を定める
PO.2Implement Roles and Responsibilities役割と責任を決める
PO.3Implement Supporting Toolchains支援ツール群を整える
PO.4Define and Use Criteria for Software Security Checksセキュリティ検査の基準を定めて使う
PO.5Implement and Maintain Secure Environments for Software Development開発環境を安全に保つ
PS
ソフトウェアの保護		PS.1Protect All Forms of Code from Unauthorized Access and Tamperingあらゆる形のコードを不正アクセスと改ざんから守る
PS.2Provide a Mechanism for Verifying Software Release Integrityリリースが改ざんされていないことを確かめる手段を提供する
PS.3Archive and Protect Each Software Release各リリースを保管し保護する
PW
安全なソフトウェアの作成		PW.1Design Software to Meet Security Requirements and Mitigate Security Risks要件を満たしリスクを減らすように設計する
PW.2Review the Software Design to Verify Compliance with Security Requirements and Risk Information設計をレビューする
PW.4Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality自作せず、実績ある安全な部品を再利用する
PW.5Create Source Code by Adhering to Secure Coding Practices安全なコーディング慣行に従って書く
PW.6Configure the Compilation, Interpreter, and Build Processes to Improve Executable Securityビルドの設定で実行物の安全性を高める
PW.7Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirementsコードをレビュー・解析して脆弱性を見つける
PW.8Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements動くものをテストして脆弱性を見つける
PW.9Configure Software to Have Secure Settings by Default既定で安全な設定にする
RV
脆弱性への対応		RV.1Identify and Confirm Vulnerabilities on an Ongoing Basis脆弱性を継続的に見つけて確認する
RV.2Assess, Prioritize, and Remediate Vulnerabilities評価し、優先順位を付けて修正する
RV.3Analyze Vulnerabilities to Identify Their Root Causes根本原因を分析する

4つの群は時間の流れに沿っています。作る前の準備（PO）、作っている最中のコードの保護（PS）と作り方（PW）、公開した後の対応（RV）です。第1章の論文が示した失敗モードの多くは、PW.5（安全なコーディング慣行）とPW.7（コードレビュー）の欠落として説明できます。論文の「暗黙のセキュリティ規則の欠落」（658件、55.5%）は、SSDFで言えばPO.1（要件を定める）が無いまま作り始めた結果です。

生成AI向けの拡張と、1.2への改訂

SSDFは、AIの時代に合わせて2段階で広がっています。

  • SP 800-218A（2024年7月26日）「Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile」。生成AIと、軍民両用になりうる基盤モデルの開発に向けて、SSDF v1.1に実践や作業を追加した「コミュニティプロファイル」です。NISTはこれを、AIモデルを作る側、モデルを組み込んだシステムを作る側、そしてそれを調達する側の3者向けだと説明しています。2023年のAIに関する大統領令14110が、SSDFの「付属資料」を作るよう求めたことに応えたものです。
  • SSDF 1.2草案（SP 800-218 Rev. 1、初回公開草案）2025年12月17日公開、意見募集は2026年1月30日まで。大統領令14306に基づく改訂です。本稿執筆時点（2026年10月）で、NISTのページは意見募集を終了済みと表示しており、確定版の公開は確認できていません。番号や内容は確定版で変わる可能性があるため、この教材ではv1.1の番号を使います。

CISA「Secure by Design」：安全は作り手の責任

SSDFが「どう作るか」の手順なら、CISA（米国サイバーセキュリティ・インフラセキュリティ庁）のSecure by Designは「誰が責任を負うか」の原則です。CISAは2023年4月にこの取り組みを始め、同年10月16日には米国のNSA・FBIに加え、日本のNISCとJPCERT/CCを含む各国機関と共同で、指針「Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software」の改訂版を公開しました。

原則は3つです。CISAの発表文の原文をそのまま挙げます。

  1. Take ownership of customer security outcomes.（顧客のセキュリティの結果に、作り手が責任を持つ）
  2. Embrace radical transparency and accountability.（徹底した透明性と説明責任を受け入れる）
  3. Lead from the top.（経営層が先頭に立つ）

CISAは、製品が「出荷時点で、設定をほとんど変えずに安全に使える」状態をSecure by Default（既定で安全）と呼び、多要素認証やアクセス制御を追加費用なしで提供することを例に挙げています。

2024年5月8日には、企業が自発的に署名する「Secure by Design Pledge（誓約）」が始まり、当初68社が署名しました。誓約の目標は7つで、多要素認証の普及、初期パスワードの廃止、脆弱性の種類ごとの根絶（SQLインジェクション、XSS、メモリ安全性）、パッチの適用しやすさ、脆弱性開示方針の公表、CVE（共通脆弱性識別子）の正確さと迅速さ、侵入の証拠となるログの提供です。CISAのページは現在「数百社が署名した」と記しています。法的拘束力はなく、CISAが遵守を検証することもありません。

第1章の論文で見た「利用者任せ」（72件、6.1%）は、まさにSecure by Designが否定する姿です。AIが「本番ではここを変えてください」とコメントを残して去る。それは作り手の責任を利用者に転嫁したことになります。あなたが作り手なら、その責任はあなたにあります。

個人開発にSSDFは大げさか

答えは「枠組みは大げさでも、中身は小さく使える」です。経理のCOSO内部統制フレームワークを思い出してください。統制環境からモニタリングまでの構成要素は、上場企業のために書かれています。しかし、従業員数名の会社でも「現金の管理者と記帳者を分ける」「月次で残高を照合する」という形で、同じ考え方を縮小して適用します。SSDFも同じです。各実践群から1つずつ、個人の規模でできることを抜き出すと、次のようになります。

群実践個人開発での具体策この教材での対応章
POPO.1 要件を定めるAIへの指示に「本番運用に耐えるものを」と目的を書き、第13章の「持ち主への質問」への回答を業務ルール一覧として残す第4章・第13章
PSPS.1 コードを守るGitHubで二要素認証を有効にし、秘密情報をリポジトリに入れず、Secret scanningを有効にする第9章・第12章
PWPW.4 自作せず再利用する認証を自作せずSupabase Authなどに任せる。暗号も定評ある部品を使う第10章・第25章
PWPW.7 コードをレビューする作ったのとは別のセッションで、OWASP Top 10やASVSを観点に渡してAIにレビューさせる第13章・第20章
PWPW.9 既定で安全にRLSを全テーブルで有効にし、環境変数をSensitiveにし、プレビューURLを保護する第10章・第12章
RVRV.1 継続的に見つけるDependabotを有効にし、通知を放置しない。クラウド各社のセキュリティ告知を購読する第12章・第27章
RVRV.3 根本原因を分析する見つかった穴を、論文の8つの失敗モード（記憶・目的・知識の欠陥）のどれかに分類し、次の頼み方を変える第4章

専門家に「SSDFに沿って開発していますか」と聞かれたら、この表を見せて「個人の規模で、PO.1、PS.1、PW.4、PW.7、PW.9、RV.1、RV.3に相当することをやっています」と答えられます。全部をやっていると言う必要はありません。やっていることと、やっていないことを、同じ番号で言えることが大切です。

日本の指針

日本にも、同じ方向の公的資料があります。確認できたものだけを挙げます。

  • IPA（情報処理推進機構）「セキュリティ・バイ・デザイン導入指南書」（2022年）。セキュリティに不慣れな読者向けに、脅威分析、セキュリティ要件、安全な設計と開発を図入りで解説しています。第21章の脅威モデリングの日本語資料として読めます。
  • IPA「安全なウェブサイトの作り方」改訂第7版。届出のあった脆弱性をもとに、SQLインジェクションやクロスサイト・スクリプティングなど11種類の脆弱性と根本的解決策、失敗例を示しています。
  • 経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0」（2024年8月）。第24章で扱うSBOMの日本語の公式資料です。
  • CISAのSecure by Design指針（2023年10月改訂版）には、日本からNISC（内閣サイバーセキュリティセンター）とJPCERT/CCが共同署名しています。日本政府もこの原則を共有していると言えます。

演習：自分の開発の進め方をSSDFに対応づける

所要時間：約30分
  1. 上の「個人開発での具体策」の表を、点検ノートに写します。列を1つ足し、「やっている／やっていない」を書きます。
  2. 「やっている」ものには、根拠となる実践編の点検ノートの番号（第9章から第13章の結果）を書き添えます。
  3. 「やっていない」もののうち、今日中にできるものを1つ選んで実行します。多くの場合、PS.1（GitHubの二要素認証とSecret scanning）かRV.1（Dependabotの有効化）が最短です。
  4. SP 800-218の原典（PDF）を開き、自分が「やっている」とした実践の節を1つだけ読みます。英語ですが、各実践は「Practice／Tasks／Notional Implementation Examples／References」の定型で書かれており、実装例（Examples）の欄を読むだけで雰囲気がつかめます。
  5. CISAのSecure by Designの3原則を、自分のアプリに当てはめて1行ずつ書きます。「利用者に設定を任せている箇所はないか」（原則1）、「何を守り、何を守っていないかを利用者に示しているか」（原則2）、「安全性を後回しにする判断を自分がしていないか」（原則3）。
  6. 結果を点検ノートに日付入りで残します。
注意：基準は自分の開発に当てるもの この章の演習は、自分の開発の進め方を基準に照らす机上の作業です。他人のサービスや他社の製品が「SSDFに沿っているか」を、実際の操作で確かめようとしないでください。設定画面の目視やテスト用アカウントでの確認は、自分が作り、自分が管理するアプリに限ります。
補足：基準の「番号」を覚える意味 PO.1やPW.7といった番号を覚えること自体に価値はありません。価値があるのは、ベンダーの提案書や監査の指摘に「SSDF PW.8に基づくテスト」と書かれていたとき、それが「動くものをテストして脆弱性を見つける実践」だと読めることです。専門家の文書を読める人は、専門家に正しい質問ができます。

まとめ

  • NIST SP 800-218（SSDF v1.1、2022年2月）は、作る「過程」の基準。4つの実践群PO（組織の準備）／PS（ソフトウェアの保護）／PW（安全なソフトウェアの作成）／RV（脆弱性への対応）に、PO.1からRV.3までの実践が並ぶ。SP 800-218A（2024年7月）は生成AI向けの拡張、SSDF 1.2草案（2025年12月）は大統領令14306に基づく改訂。
  • CISAのSecure by Designは「製品の安全は作り手の責任」という原則。3原則は「顧客の安全の結果に責任を持つ」「徹底した透明性と説明責任」「経営層が先頭に立つ」。2024年5月の誓約には当初68社が署名した。日本のNISCとJPCERT/CCも指針に共同署名している。
  • 個人開発でも、COSOを小規模企業に適用するのと同じ要領で、各実践群から1つずつ実行できる。PO.1（目的を伝え、業務ルールを残す）、PS.1（二要素認証とSecret scanning）、PW.4（認証や暗号を自作しない）、PW.7（別セッションでのAIレビュー）、PW.9（RLSとSensitive）、RV.1（Dependabot）、RV.3（失敗モードで原因分類）。

出典