セキュア開発ライフサイクル

Secure SDLC（Software Development Lifecycle）は、設計・実装・テスト・リリースの各フェーズにセキュリティ活動を組み込み、「脆弱性を作り込まない」開発プロセスを実現するアプローチである。「後付けセキュリティ」から「Shift Left（早期シフト）」への転換が核心であり、発見が遅くなるほど修正コストが指数的に増加する。情報カットオフ ~2025-08 のため、各ツールの最新バージョンや採用状況は 2026-05 時点で要確認。

Secure SDLC と Shift Left

Shift Left とは、セキュリティテストや脅威モデリングを開発プロセスの「左側（早期）」に移動させることを指す。NIST の調査（ IBM Systems Sciences Institute 引用）では、設計フェーズで発見した脆弱性の修正コストは本番環境で発見した場合の 1/100 以下とされる。

従来の「テスト後期にペネトレーションテスト」モデルに対し、Secure SDLC は次の 4 フェーズ全体に活動を分散させる。

フェーズ	主要アクティビティ
設計	脅威モデリング・セキュリティ要件定義・アーキテクチャレビュー
実装	セキュアコーディング・SAST・依存関係スキャン（ SCA）
テスト	DAST / IAST・ペネトレーションテスト・ファジング
リリース	コード署名・SBOM 生成・リリースノート・ロールバック計画

脅威モデリング

脅威モデリングは「何を守るか・誰が攻撃するか・どう攻撃されるか・対策は何か」を体系的に分析するセキュリティ設計活動であり、設計フェーズで実施することで後工程の手戻りを最小化する。

主要な手法:

STRIDE: Microsoft が提唱。Spoofing / Tampering / Repudiation / Information Disclosure / Denial of Service / Elevation of Privilege の 6 カテゴリで脅威を列挙する。データフロー図（ DFD）を基に信頼境界を特定し、各コンポーネントに STRIDE を適用する。
PASTA（Process for Attack Simulation and Threat Analysis）: ビジネスリスクを起点にした 7 段階の脅威分析フレームワーク。攻撃シミュレーションを通じてリスクの優先順位を付ける。
Attack Tree: 攻撃ゴールを根に、それを達成する手段を木構造で分解する表現方法。複雑な攻撃シナリオの可視化に有効。

実践上の鍵は「資産・信頼境界・データフロー・攻撃者の能力」の 4 要素を明確にすることと、機能変更のたびに更新することである。一度作成して放置された脅威モデルは急速に陳腐化する。

セキュアコーディング

セキュアコーディングは、実装フェーズで脆弱性を作り込まないための実践原則の集合である。

主要領域と対策:

入力バリデーション: 全外部入力（ HTTP パラメータ・ファイル・環境変数）を信頼しない。許可リスト方式でバリデーション。SQL インジェクション・ XSS・パストラバーサルの根本対策。
認証・認可: 認証（ Authentication）と認可（ Authorization）を分離して実装。OWASP ASVS L2 以上を参照基準にする。デフォルト拒否（ deny by default）の徹底。
エラー処理: スタックトレース・内部パスなどの機密情報をクライアントに露出しない。ログには詳細、レスポンスには汎用エラーメッセージを返す。
秘密情報管理: API キー・パスワードをソースコードにハードコードしない。シークレットマネージャー（ Vault / AWS Secrets Manager など）を使用する。
セッション管理: セッション ID の推測不能化・有効期限設定・ログアウト時の明示的無効化・ Cookie の Secure / HttpOnly / SameSite 属性。

OWASP Cheat Sheet Series（ auth / session / input-validation 等）が実装レベルの参照として有用。

セキュリティテスト（SAST / DAST / IAST / SCA）

セキュリティテストツールは検出対象と実行タイミングで 4 種類に分類される。

種類	略称の意味	動作	実行タイミング	代表ツール
SAST	Static Application Security Testing	ソースコード・バイトコードの静的解析	コミット / PR 時	Semgrep・CodeQL・SonarQube
DAST	Dynamic Application Security Testing	実行中アプリへのブラックボックス攻撃	CI 後・ステージング	OWASP ZAP・Burp Suite
IAST	Interactive Application Security Testing	実行中アプリへエージェントを埋め込み内部観測	機能テスト実行中	Contrast Security
SCA	Software Composition Analysis	依存関係の既知脆弱性・ライセンス検出	CI / 定期スキャン	Dependabot・Snyk・OWASP Dependency-Check

SAST の注意点: 偽陽性率が高く、チームが「ノイズ」として無視し始めると機能しなくなる。初期設定でルールセットを絞り、段階的に拡張する運用が重要。

SCA の重要性: 現代の Web アプリは依存ライブラリが本体コード量を上回ることが多く、 SCA なしでは表面積の大半がスキャン外になる。 SBOM 生成と組み合わせる（ tech-140 参照）。

ファジング（ fuzzing）は想定外の入力でアプリケーションをクラッシュ・異常動作させる手法で、パーサー・プロトコル実装・ファイル処理など入力が多様な箇所に有効。OSS-Fuzz が継続的ファジングの基盤として活用されている。

リリース・配布のセキュリティ

リリースフェーズで実施すべき主要活動:

コード署名: リリースアーティファクト（バイナリ・コンテナ・パッケージ）に署名し、改ざん検出を可能にする。Sigstore / Cosign が鍵管理を簡素化（ tech-138 参照）。
SBOM 同梱: 依存関係の一覧（ SPDX / CycloneDX 形式）をリリースに同梱し、下流ユーザの脆弱性影響調査を支援（ tech-140 参照）。
リリースノート: CVE 修正・既知の問題・影響を受ける設定を明示する。
ロールバック計画: 本番リリース後に重大な脆弱性が発見された場合の手順を事前に定義する。デプロイ時間・影響範囲・通知先をロールバック判断基準として文書化。

アンチパターン

アンチパターン	問題
セキュリティテストを本番リリース直前の「ゲート」としてのみ実施する	発見が遅く修正コストが高い。PR / コミット時の SAST・SCA を先行させる
SAST の偽陽性を「後で対応」として積み上げる	ノイズが増えると真陽性を見落とす。初期に閾値と優先ルールを決定する
脅威モデルを設計時に一度だけ作成し更新しない	機能追加・アーキテクチャ変更のたびに信頼境界が変わる
ペネトレーションテストを「コンプライアンスのための年次行事」にする	継続的な自動テストと組み合わせて初めて実効性が生まれる

Secure Development Lifecycle（セキュア開発ライフサイクル）