Grandream

公開: 2026.11.129 min read

安全なソフトウェア開発の進め方｜設計からリリース後までの情報漏えい対策【NIST SSDFで整理】

ソフトウェアからの情報漏えいは、リリース前の脆弱性（ぜいじゃくせい：システムの弱点）検査だけでは防げません。

弱点は実装だけでなく設計の段階でも生まれ、使っている部品やビルドの仕組みからも入り込みます。リリース後に新しく見つかる弱点もあります。

そのため、設計・実装・部品の管理・ビルド・テスト・運用までを一続きで回す必要があります。その整理に使えるのが、米国NIST（国立標準技術研究所）のSSDF（セキュアソフトウェア開発フレームワーク）です。

この記事では、SSDFとOWASP、IPAの資料をもとに、開発の段階ごとにやるべき対策を整理します。開発チームの責任者と、開発を発注する担当者の両方に向けた内容です。

SSDFの4つのグループ

SSDFの現行の確定版は、2022年2月に公開されたNIST SP 800-218（バージョン1.1）です。対策を次の4つのグループに分けています。

グループ	意味	主な中身
PO：組織を準備する	人・手順・道具を組織として整える	セキュリティ要件の定義、役割と教育、開発環境の保護
PS：ソフトウェアを守る	コードや成果物を改ざん・不正アクセスから守る	リポジトリの権限管理、成果物の完全性の確認、リリースの保管
PW：安全に作る	リリースに残る弱点を最小にする	設計レビュー、安全な部品の再利用、コードの検査、テスト、安全な初期設定
RV：弱点に対応する	残った弱点を見つけて直し、再発を防ぐ	弱点の受付と監視、優先度を付けた修正、根本原因の分析

改訂版のバージョン1.2（SP 800-218 Rev.1）は、2025年12月に意見募集用の案が公開されました。案には、継続的な改善や、更新を安全に配る仕組み（段階的な配布や元に戻す機構）の項目が加わっています。本記事の執筆時点で、確定版は確認できていません。

開発の段階ごとにやること

段階	やること	残すもの
要件・設計	扱うデータ・権限・外部連携を決め、起こりうる攻撃を洗い出す	セキュリティ要件、脅威の洗い出し、設計レビューの記録
実装	規約に沿って書き、入力の検証と出力の無害化を徹底する	コーディング規約、レビューの記録
部品の管理	使っているライブラリと版を把握し、既知の弱点を追う	SBOM（部品表）、依存関係の一覧
ビルド・配布	秘密情報を守り、成果物が改ざんされていないことを確かめる	署名やハッシュ、ビルドの記録
テスト	目的の違う検査を組み合わせる	検査結果、修正チケット
リリース	本番の設定・権限・ログ・監視を出す前に確かめる	リリース前チェックリスト
運用	監視し、新しい弱点に対応し、修正を配る	対応手順、弱点への対応記録

以下、段階ごとに要点を見ていきます。

設計で決めること

ログインの仕組み

管理者や社内ユーザー、お金や権限に関わる操作には、多要素認証を必須にします。偽のログイン画面にコードを入力させる手口があるため、可能ならパスキーなど偽サイトに強い方式を選びます。

パスワードを保存する場合は、専用のハッシュ関数で保存し、元に戻せる形では持ちません。OWASPの現行の推奨は、Argon2idが第一、使えない場合はscryptです。bcryptは既存システム向けの位置付けになっています。

ログイン状態には有効期限を設け、ログアウトや権限の取り消しのときはサーバー側で無効にします。振込先の変更や管理者の追加などの重要な操作では、もう一度本人を確かめます。

誰が何をできるかの判定

権限の判定は、必ずサーバー側で毎回行います。画面でメニューを隠すだけでは、裏の窓口（API）を直接呼ばれると防げません。

特に注意したいのが、URLや通信の中のIDを書き換えるだけで他人のデータが見えてしまう不備です。データ1件ごとに「この人のものか」「この人の会社のものか」を確かめます。Webアプリの危険の順位表「OWASP Top 10」の2025年版でも、アクセス制御の不備が1位です。

データの扱い

IPAは「不要な情報は持たない」を漏えい対策の基本原則としています。設計の段階で、そもそも持つ必要があるかを問い、持つなら保存期間と消し方を決めます。

個人情報や本人確認書類の画像は、保存時も通信時も暗号化します。パスワードは前述のハッシュで保存し、カード番号は自社で持たず決済代行会社に任せます。バックアップも同じ扱いにします。

見落とされやすいのがログです。パスワード、トークン、カード番号、本人確認書類の情報がログに残らないよう、伏せ字にする処理を共通の部品にしておきます。

外部との連携

APIへの入力は、すべてサーバー側で検証します。型、長さ、文字の種類、件数の上限を決め、想定外の入力を受け付けません。

APIキーやトークンは、ソースコードや設定ファイルに書かず、秘密情報の管理サービスに置きます。連携先ごとに必要な権限だけを与え、有効期間を短くし、漏れたときにすぐ無効にして作り直せる手順を用意します。

実装で防ぐ代表的な弱点

弱点	起きること	主な対策
SQLインジェクション	入力を細工されてデータベースを操作される	文字列の連結でSQLを作らず、プレースホルダを使う
XSS（クロスサイトスクリプティング）	画面に不正なスクリプトを埋め込まれる	出力する場所に応じて無害化し、CSP（読み込めるスクリプトを制限する設定）を設定する
CSRF	利用者の意図しない操作を送らされる	SameSite属性のCookieと、CSRFトークンを使う
SSRF	サーバーに内部のURLへアクセスさせられる	アクセス先を許可リストで限り、接続先が内部アドレスでないかを名前解決の後に確かめる
パストラバーサル	想定外の場所のファイルを読まれる	入力をファイル名に使わずIDで対応付ける。使う場合は正規化し、許可した場所の外を拒否する
アクセス制御の不備	他人のデータや管理機能を使われる	機能ごと・データごとの権限判定をサーバー側で行う
秘密情報の混入	コードからAPIキーなどが漏れる	秘密情報の検出を自動化し、混入したら鍵を無効にする
エラー情報の露出	内部の構造を知られる	スタックトレースやSQL文、内部のパスを画面に返さない

確認の基準には、OWASPのASVS（アプリケーションセキュリティ検証標準）が使えます。2025年5月に公開されたバージョン5.0では、出力の無害化、入力の検証、エラー処理とログなどを章ごとに確かめられます。日本語の資料では、IPAの「安全なウェブサイトの作り方」も実装の手引きになります。

部品とサプライチェーンを管理する

オープンソースの部品は開発を速くしますが、既知の弱点や、悪意のある更新を持ち込む経路にもなります。OWASP Top 10の2025年版では、「ソフトウェアサプライチェーンの不備」が3位に入りました。

まず、SBOM（ソフトウェアの部品表）で、どの部品のどの版を使っているかを把握します。新しい弱点が公表されたときに、自社のどのシステムが影響を受けるかをすぐ調べられます。経済産業省は2024年8月に「ソフトウェア管理に向けたSBOMの導入に関する手引 ver2.0」を公開し、発注時に契約で決めておく事項の例も示しています。

部品の版はロックファイル（package-lock.json や yarn.lock など）で固定し、更新は定期的に、検査を通してから取り込みます。取得元は信頼できる場所に限ります。

既知の弱点の検出（SCA）は、CI（変更のたびに自動でビルドと検査を行う仕組み）に組み込んで毎回自動で回します。見つかった弱点は、深刻度と、自社のコードから実際に使われているかで優先順位を付けます。

ビルドの仕組みと開発環境を守る

開発環境は、本番と同じく攻撃の対象です。SSDFも、開発環境やリポジトリ、ビルドの仕組みを不正アクセスや改ざんから守ることを求めています。

リポジトリには多要素認証を必須にし、アクセスできる人を最小限にします。本番に出るブランチへの直接の書き込みを禁止し、レビューと自動テスト、セキュリティ検査を通ったものだけを取り込みます。

CIの権限も最小限にします。たとえばGitHub Actionsの pull_request_target について、GitHubは、外部から送られたプルリクエストのコードをこの仕組みで実行すると、キャッシュの汚染や、書き込み権限・秘密情報への意図しないアクセスにつながりうると警告しています。

.env などの設定ファイル、本番のデータ、認証情報はリポジトリに置きません。誤って公開した場合は、ファイルを消すだけでは足りません。鍵やトークンを無効にして作り直します。

成果物には署名やハッシュを付け、配布や本番への反映のときに確かめます。

テストと検査を組み合わせる

1つの道具ですべての弱点は見つかりません。目的の違う検査を組み合わせます。

検査	見つけるもの	回すタイミング
SAST（静的解析）	ソースコードの危険な書き方	変更のたびに自動で
SCA（部品の検査）	部品の既知の弱点	変更のたびと、定期的に
秘密情報の検出	APIキーやトークンの混入	コミットの前と、変更のたびに
DAST（動的検査）	動いている状態での認証・権限・設定の不備	確認用の環境で定期的に
設定の検査	クラウドやコンテナの危険な設定	設定を変えるたびに
脅威の洗い出し	設計上の弱点	設計の早い段階と、大きな変更のとき
侵入テスト	組み合わせで成立する攻撃	ログイン・決済・管理画面など重要な機能の公開前

脅威の洗い出しについて、OWASPは設計の早い段階で行い、システムの変化に合わせて更新し続けることを勧めています。

検査結果は、重要度順の一覧で終わらせません。担当者、期限、修正の確認、同じ弱点を繰り返さないための対策まで追いかけます。

リリース後に続けること

本番では、ログインの記録、操作の記録、APIの記録を集め、ログイン失敗の急増、普段と違う接続元、権限の変更、身に覚えのない管理者の操作に気づける状態にします。

使っている部品の弱点情報を追い続け、公表されたらSBOMで影響を調べて修正を配ります。利用者が自分で更新できない製品では、修正の配り方そのものを設計しておく必要があります。

外部から弱点の報告を受け付ける窓口と、公開の方針も用意します。SSDFは脆弱性を開示する仕組みづくりを求めており、IPAも2026年3月公開の「製品開発者向けガイド」で、報告の受付窓口と開示方針、PSIRT（製品の弱点に対応する社内チーム）の整備を挙げています。なお、このガイドは不特定多数が使う製品の開発者向けで、受託開発は対象外とされています。

事故や弱点が見つかったら、なぜ起きたかを分析し、規約、テスト、レビュー、アラートに反映します。

小さなチームの導入順

少人数のチームなら、次の順で始めると無理がありません。

多要素認証、権限の最小化、秘密情報の管理を全員の標準にする
CIに静的解析・部品の検査・秘密情報の検出を組み込む
SBOMを作り、部品の更新を定期的に回す
主要な機能に、脅威の洗い出しと設計レビューを入れる
ログの監視、事故の対応手順、弱点の受付窓口を整える
委託先、外部API、オープンソースまで含めた管理を決まりにする

費用に対して効果が大きいのは、弱点を作り込まない設計と、早い段階で自動で見つける仕組みです。後の段階で見つかるほど、直す手間は大きくなります。

発注者が開発会社に聞きたいこと

開発を外に頼む場合も、ここまでの内容を全部理解する必要はありません。次の質問への答え方で、開発会社の取り組みの深さが分かります。

聞くこと	確かめたい中身
設計の段階で、セキュリティをどう決めますか	扱うデータ・権限・攻撃の想定を、設計の記録に残しているか
他人のデータが見えないことを、どう確かめていますか	データごとの権限判定と、そのテスト
使っている部品の弱点を、どう追っていますか	部品表の有無、自動の検査、更新の頻度
APIキーやパスワードを、どこで管理していますか	コードに書かず、管理サービスで扱っているか
どんな検査を、いつ回していますか	自動の検査と、重要な機能の公開前の検査
公開後に弱点が見つかったら、どう対応しますか	連絡の手順、修正までの目安、費用の扱い
契約が終わるとき、データと権限はどうなりますか	データの返却・削除と、アカウントの停止