レビュー・テスト・リスク対策・再リサーチループの根拠整理
作成者: Manus AI
1. 主要根拠の整理
| 根拠 | 要点 | テンプレート体系への反映 |
|---|---|---|
| NIST SSDF | SSDFは安全なソフトウェア開発実践を、Prepare、Protect、Produce、Respondの4群で整理し、脆弱性数と未対応脆弱性の影響低減、再発防止を目的とする。 | リスク台帳、セキュリティ要件、CIゲート、脆弱性対応ループに反映する。 |
| OWASP SAMM | SAMMはリスク駆動かつ反復的にソフトウェアセキュリティ保証を改善する成熟度モデルである。 | 一度作って終わりではなく、発見から再リサーチへ戻す改善ループの根拠とする。 |
| OWASP ASVS | ASVSはWebアプリケーションの技術的セキュリティ制御を検証する基準であり、開発者向けのセキュア開発要件としても使える。 | セキュリティ要件、テスト計画、受入基準にASVS型のID付き検証要件を入れる。 |
| ADR | ADRはアーキテクチャ上重要な判断と理由、トレードオフ、結果を記録する。 | 技術要件・アーキテクチャ設計に採否理由と見直し条件を必須化する。 |
| GitHub Actions | Workflowはイベントで起動し、build、test、deployなどのジョブを自動実行できる。 | CI品質ゲートをテンプレート化し、非エンジニアにも赤黄緑で表示する。 |
| Google SRE | 監視は症状と原因を区別し、低ノイズで明確な失敗を人間に伝える必要がある。 | 運用・監視・アラートは複雑化せず、素人が判断できる簡潔なゲートへ変換する。 |
| Anthropic Agent Patterns | 複雑なエージェントよりも単純で構成可能なワークフローを優先し、評価器・最適化ループは明確な評価基準がある場合に有効。 | Codex/Opusを評価者として分離し、発見から再提案へ回すEvaluator-Optimizer型にする。 |
| Atlassian Testing | 単体、統合、機能、E2E、受入、性能、Smokeなどのテスト種別を分け、自動テストと探索的テストを併用する。 | テスト計画を階層化し、Must要件にテストIDを必須接続する。 |
2. ループ制度化の結論
単にフォーマットを作るだけでは、非エンジニアはその品質を判断できない。したがって、各テンプレートは次の条件を満たす必要がある。第一に、各判断がEvidence Matrixに接続される。第二に、Must要件は受入基準とテストIDに接続される。第三に、外部API、規約、課金、投稿、削除、認証、DB、個人情報、権利関係などの破壊的リスクは、ハーネス設計とCIゲートを通る。第四に、CodexレビューとOpus再分析の結果は、実装修正だけでなく、リサーチ計画、要件、仕様、技術要件、リスク台帳へ戻す。
3. 参照URL
| No | URL | 用途 |
|---|---|---|
| 1 | https://csrc.nist.gov/Projects/ssdf | SSDFの安全開発・リスクベース改善 |
| 2 | https://owasp.org/www-project-samm/ | セキュリティ成熟度と反復改善 |
| 3 | https://owasp.org/www-project-application-security-verification-standard/ | セキュリティ検証要件 |
| 4 | https://adr.github.io/ | ADRによる設計判断記録 |
| 5 | https://docs.github.com/en/actions/writing-workflows/about-workflows | CI/CD Workflowの公式説明 |
| 6 | https://sre.google/sre-book/monitoring-distributed-systems/ | 監視・症状・原因・低ノイズアラート |
| 7 | https://www.anthropic.com/engineering/building-effective-agents | ワークフロー、評価器・最適化ループ、エージェント設計 |
| 8 | https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing | テスト種別と自動化 |