Moshiru
会社情報記事一覧無料スキャン

会社のセキュリティ教科書　第12部 12-1

セキュアな開発とは｜脅威モデリングとセキュアSDLC、外注時の要件

公開：2026年10月15日／最終更新：同／Moshiru 岡﨑 悠太

こんなときに役立ちます

  • 自社でシステムやアプリを開発・外注するとき
  • 開発会社に出す依頼書や見積もりに、セキュリティの条件をどう書けばよいか迷うとき
  • 支援士・Security+・CISSPの勉強で、脅威モデリングやSDLCを実務の言葉でつかみたいとき

読み終えたあと、社内でこう言えます

「外注するシステムのセキュリティ要件と受け入れ条件を書きました」

結論：セキュアな開発とは、企画から運用までの全工程にセキュリティの作業を組み込む進め方です。完成後の診断だけに頼ると、設計の穴は直すのに大きな手戻りが出ます。作る前に「何が起こりうるか」を洗い出す脅威モデリングと、工程ごとの確認（セキュアSDLC）が柱です。外注する場合も、要件と受け入れの条件を発注側が書くことで、守りの水準を決められます。

企画・設計・実装・テスト・運用の各工程にセキュリティの確認を入れるセキュアSDLCの流れ

セキュアSDLCとは？工程ごとに何をするか

SDLC（Software Development Life Cycle）は、ソフトウェアを企画してから使い終えるまでの流れのことです。セキュアSDLCは、この各工程にセキュリティの作業を入れる考え方です。日本ではデジタル庁が「セキュリティ・バイ・デザイン」と呼び、2022年6月にガイドライン（DS-200）を出しています。

工程セキュリティの作業
企画扱う情報と利用者を書き出し、脅威を洗い出す（脅威モデリング）
要件定義ログイン方式、権限、記録、暗号化などをセキュリティ要件として書く
設計攻撃される入口を減らす。権限を最小にする。設計をレビューする
実装安全な書き方（セキュアコーディング）を守る。使う部品の脆弱性を確かめる
テストセキュリティ機能の試験と脆弱性診断を行う
運用更新、ログ監視、脆弱性の情報収集、事故への対応

デジタル庁のガイドラインは政府のシステム向けですが、工程の考え方は民間の開発にもそのまま使えます。大事なのは「最後に診断して終わり」にしないことです。

脅威モデリングとは？4つの問いで考える

脅威モデリングとは、システムの図を見ながら、セキュリティやプライバシーの心配な点を洗い出す作業です。専門家の有志がまとめた「Threat Modeling Manifesto」は、次の4つの問いを軸にしています。

  1. 何を作っているのか：画面、サーバー、データベース、外部サービスとのつながりを1枚の図にする。
  2. 何がまずいことになりうるか：図の線や箱ごとに、なりすましや改ざんなどの起こりうることを書き出す。
  3. それにどう対処するか：対策を決める。対策しないなら、その理由と判断した人を残す。
  4. 十分にできたか：対策が設計と実装に入ったか、テストで確かめる。

洗い出しの型：STRIDE

2つ目の問いで漏れを減らすには、マイクロソフトが広めたSTRIDEという分類が便利です。6つの頭文字で、それぞれ守るべき性質と対になっています。

脅威意味崩れる性質
Spoofing（なりすまし）他人や別のシステムのふりをする認証
Tampering（改ざん）許可なくデータを書き換える完全性
Repudiation（否認）やったことを「やっていない」と言える否認防止
Information disclosure（情報漏えい）見てはいけない情報が見える機密性
Denial of service（サービス妨害）システムを使えなくする可用性
Elevation of privilege（権限昇格）持つべきでない権限を得る認可

機密性・完全性・可用性の3つは1-1 機密性・完全性・可用性、否認防止は1-2 真正性と責任追跡性で扱っています。

国際的な型：NISTのSSDFとOWASP Top 10

米国国立標準技術研究所（NIST）は、安全な開発の実践項目をSSDF（Secure Software Development Framework）としてまとめています。現行はNIST SP 800-218 Version 1.1（2022年2月）です。2025年12月には改訂版（Version 1.2）の草案が公開されました。SSDFは4つのグループに分かれます。

グループ中身の例
PO 組織の準備セキュリティ要件を決める。役割を決める。開発環境を守る
PS ソフトウェアの保護ソースコードを不正な変更から守る。リリースを保管する
PW 安全なソフトウェアの作成脅威モデリングを含む設計、レビュー、テスト、安全な初期設定
RV 脆弱性への対応脆弱性を見つけ、優先順位をつけて直し、根本原因を分析する

Webアプリでは、OWASP（Webアプリの安全性に取り組む国際的な団体）の「Top 10」が目安になります。2025年11月に公開された2025年版では、1位がアクセス制御の不備でした。3位には、外部の部品や開発の流れに起因する「ソフトウェアサプライチェーンの失敗」が入っています。

日本語の教材では、IPAの「安全なウェブサイトの作り方」（改訂第7版）が、SQLインジェクションなど11種類の脆弱性と対策をまとめています。「IPAセキュア・プログラミング講座」は2016年時点の内容でアーカイブ扱いですが、原則を学ぶには今も役立ちます。主な攻撃の仕組みは2-11 Webサイトへの攻撃（XSS・CSRF）で解説しています。

外注するとき、発注側は何を書けばいい？

中小企業では、開発そのものは外部の会社に頼むことがほとんどです。それでも、何を守ってほしいかを決めるのは発注側です。依頼書に書かれていないことは、見積もりにも作業にも入りません。

たとえば社員25人の住宅リフォーム会社では（架空の例）

見積もり依頼と顧客の住所を受け付けるWebフォームと、社内の案件管理画面を外注するとします。担当は総務の1人が兼務です。この会社が依頼書に足すとよい項目は、次のとおりです。

  1. 扱う情報：顧客の氏名・住所・電話番号を保存する。見られる社員を限りたい。
  2. ログイン：管理画面は多要素認証にする。社員ごとにアカウントを分ける。
  3. 記録：誰がいつ顧客情報を見て、変更したかのログを1年残す。
  4. テスト：納品前に脆弱性診断を行い、結果と直した内容を報告してもらう。
  5. 部品の管理：使ったライブラリの一覧を受け取り、更新の担当を契約で決める。
  6. 運用：脆弱性が見つかったときの連絡方法と、修正の費用の扱いを決める。

5つ目の「使った部品の一覧」は、SBOM（ソフトウェア部品構成表）と呼ばれます。経済産業省は2023年7月に導入の手引を公表しています。契約の結び方は8-2 委託契約とNDA、部品を通じて被害が広がる仕組みは8-5 サプライチェーンリスクで扱います。

テストと運用：診断は「最後の確認」として使う

脆弱性診断は大切ですが、設計の穴を見つけるのは得意ではありません。たとえば「一般社員が他人の案件も見られる」という設計は、仕様どおりに動いているので見逃されることがあります。だから企画の段階で脅威を洗い出し、診断はその確認に使います。

確認の方法見つけやすいもの
設計レビュー・脅威モデリング権限の設計ミス、守る範囲の抜け
ソースコードの解析（SAST）危ない書き方、入力チェックの抜け
動かしての診断（DAST）外から見える脆弱性、設定の不備
部品の解析（SCA）古いライブラリ、既知の脆弱性

公開した後も、部品の脆弱性は毎月のように見つかります。更新の段取りは7-5 パッチ適用の運用を参考にしてください。診断の費用感は脆弱性診断の費用の手引きにまとめています。

チェックシートではこう聞かれる

よくある設問答え方の例
システム開発の際、セキュリティ要件を定義していますか。はい。外注時の依頼書に、認証・権限・ログ・脆弱性診断の要件を記載しています。
リリース前に脆弱性診断を実施していますか。はい。公開前に第三者の診断を受け、指摘はすべて修正してから公開しています。
使用しているソフトウェア部品の脆弱性を管理していますか。いいえ。現在は未整備で、〇月までに開発会社から部品の一覧を受け取り、更新の担当を決める予定です。

「いいえ」でも、予定と担当を書けば誠実な回答になります。書き方はチェックシートの回答の書き方を参考にしてください。

試験ではここが問われる

支援士・Security+ 4・CISSP 8

  • STRIDEの6分類：なりすまし・改ざん・否認・情報漏えい・サービス妨害・権限昇格。対になる性質（認証・完全性・否認防止・機密性・可用性・認可）とセットで覚えます。
  • シフトレフト：セキュリティの作業を工程の早い段階（左側）へ移すほど、直す費用が小さくなるという考え方です。
  • SAST・DAST・SCA・IAST：SASTはソースコードを動かさずに解析、DASTは動かして外から診断、SCAは使っている部品の解析、IASTは動作中に内部から観測します。
  • SSDFの4グループ：PO（組織の準備）・PS（ソフトウェアの保護）・PW（安全なソフトウェアの作成）・RV（脆弱性への対応）。
  • DevSecOps：開発と運用を一体で回すDevOpsに、セキュリティの確認を自動で組み込む進め方です。

確認問題

問1 STRIDEの「Repudiation（否認）」への対策として、最も適切なものはどれですか。

  1. ア 通信を暗号化する
  2. イ 誰がいつ何をしたかを改ざんできない形で記録する
  3. ウ サーバーを2台に増やす
  4. エ 入力値の長さを制限する
答えと解説
正解：イ　否認は「やったことをやっていないと言える」脅威で、対になる性質は否認防止です。操作の記録を改ざんできない形で残すことが対策になります。アは情報漏えい、ウはサービス妨害への対策です。

問2 ソースコードを実行せずに解析し、危ない書き方を見つける手法はどれですか。

  1. ア DAST
  2. イ SCA
  3. ウ SAST
  4. エ ペネトレーションテスト
答えと解説
正解：ウ　SAST（静的解析）はコードを動かさずに調べます。DASTは動いているシステムを外から診断し、SCAは使っている部品の脆弱性を調べます。ペネトレーションテストは、侵入できるかを実際に試す診断です。

問3 社員30人の卸売業（架空）が、取引先向けの受発注サイトを外注します。公開の2週間前になって、取引先ごとの閲覧範囲をどう分けるか決まっていないと分かりました。今後の開発で同じことを防ぐ方法として、最も適切なものはどれですか。

  1. ア 公開前の脆弱性診断の項目を増やす
  2. イ 企画の段階で脅威モデリングを行い、権限の要件を依頼書に書く
  3. ウ 公開後にWAFを入れて攻撃を防ぐ
  4. エ 開発会社にすべて任せ、納品物だけ確認する
答えと解説
正解：イ　権限の分け方は設計の問題で、早い工程で決めるほど手戻りが小さくなります。アとウは実装後の確認や防御で、設計の抜けは補いにくいです。エでは要件が決まらないまま進みます。

よくある質問

小さな会社でも脅威モデリングは必要ですか？
はい、規模に合わせた簡単な形で十分です。システムの図を1枚描き、STRIDEの6つを当てはめて表にするだけでも、権限や記録の抜けが見つかります。1〜2時間の作業から始められます。
開発会社に任せていれば、セキュリティも大丈夫ですか？
いいえ、何を守るかは発注側が決める必要があります。依頼書に書かれていない要件は、見積もりにも作業にも入らないのが普通です。扱う情報、ログイン方式、記録、診断の有無を、依頼の時点で文書にしてください。
脆弱性診断とセキュアな開発は、どう違いますか？
脆弱性診断は「できあがったものを確かめる」作業で、セキュアな開発は「最初から穴を作らない」進め方です。診断は開発の最後の確認として位置づけます。両方を組み合わせると、手戻りと見逃しの両方を減らせます。

この記事のまとめ

公開したサイトの確認は任せて、結果を報告に使う

Moshiruは、打合せなしでテキストだけでお受けします。外注して公開したWebサイトについて、外から見える状態に危ない所がないかを確かめます。対象のURLと、確かめてよいという許可をいただければ始められます。

無料スキャンを申し込む対象のURLと許可だけメニューにないことを頼む文面で合意するまで料金はかかりません

参考にした資料

  1. デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」（DS-200、2022年6月）
  2. NIST「SP 800-218 Secure Software Development Framework (SSDF) Version 1.1」（2022年2月）
  3. NIST「SP 800-218 Rev. 1 (Initial Public Draft) SSDF Version 1.2」（2025年12月）
  4. Threat Modeling Manifesto（脅威モデリング宣言）
  5. Microsoft Learn「Threat modeling framework（STRIDE）」
  6. OWASP「OWASP Top 10:2025」（2025年11月）
  7. IPA「安全なウェブサイトの作り方」改訂第7版（2015年3月）
  8. IPA「IPAセキュア・プログラミング講座」（アーカイブ、2016年10月時点の内容）
  9. 経済産業省「SBOMを活用してソフトウェアの脆弱性を管理する具体的手法についての改訂手引（案）」（2024年4月）