中間調査メモ: 要件・設計・実装破綻リスク対策
主要根拠
- NIST SSDF は、セキュア開発を Prepare / Protect / Produce / Respond の4群に整理し、要件、リスク、設計判断の追跡、脆弱性対応、再発防止を重視している。チェックリストそのものではなく、リスクベースでカスタマイズして継続改善する基盤として使うべきと明記されている。
- OWASP SAMM は、ソフトウェアライフサイクル全体を対象に、技術・プロセス非依存で、リスク駆動かつ測定可能にセキュア開発を改善するモデルである。
- OWASP ASVS は、Webアプリケーションの技術的セキュリティコントロールを検証する基準であり、開発者向けのセキュア開発要件リストにもなる。
- Google SRE は、悪い入力・設定変更に対して「旧状態で動き続ける」「アラートする」など Fail Sanely を推奨し、非緊急リリースは段階的ロールアウトと監視、異常時は先にロールバックして後で診断することを推奨している。
- Google SRE のリリースエンジニアリングは、再現可能ビルド、自動ビルド、自動テスト、自動デプロイ、小さい変更、コードレビュー、監査証跡を重要原則としている。
- Google SRE の信頼性テストは、単体・統合・システム・スモーク・性能・回帰・本番テストを区別し、テストは信頼性を証明しきるものではないが、失敗するテストは信頼性欠如を示すと説明している。
- Google SRE のカナリアリリースは、テスト環境と本番環境が完全一致せず欠陥が本番に到達し得る前提で、小さい本番トラフィックに先に出して影響を限定しながら検知する設計である。
対策設計への示唆
- 素人向けには「完璧な文書を一発で作る」よりも、「壊れても戻せる」「小さく作る」「自動で検査する」「レビューを二重化する」「証跡を残す」仕組みを要件定義プロンプト自体に組み込むべきである。
- 成果物は Requirements / Specification / Architecture / SDD / Test Plan / Test Harness の個別品質だけでなく、相互トレーサビリティ、Exit Criteria、Rollback Criteria、Blocker分類で検証すべきである。
- AI生成文書は「仮説」として扱い、一次ソース・実ファイル・MVP実験・テストハーネスで検証してから実装に移すべきである。
参照候補
- NIST SSDF: https://csrc.nist.gov/Projects/ssdf
- OWASP SAMM: https://owasp.org/www-project-samm/
- OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
- Google SRE Service Best Practices: https://sre.google/sre-book/service-best-practices/
- Google SRE Release Engineering: https://sre.google/sre-book/release-engineering/
- Google SRE Testing for Reliability: https://sre.google/sre-book/testing-reliability/
- Google SRE Canarying Releases: https://sre.google/workbook/canarying-releases/