開発とセキュリティ部門の責任分担
文書番号：2606.00007
要旨
開発部署が設計・コード・依存関係のリスクを説明し、セキュリティ専門部署が基準、検査、例外判断を支えるための役割分担案なのだ。役割を部署名や時代で優劣づけず、変更の頻度、対象の影響、保有する知識に合わせて分担するのだ。
開発工程へ組み込む根拠と本記事の範囲
NIST SSDFはセキュア開発のプラクティスをSDLCへ統合するための枠組みなのだ。OWASP SAMMはGovernance、Design、Implementation、Verification、Operationsの各機能を扱うのだ。以下の分担表はそれらを参照した著者の組織設計案であり、外部規格が特定の部署編成を要求するものではないのだ。12
開発側が用意する判断材料
| 判断対象 | 開発側が整理すること | 専門部署に求める支援 |
|---|---|---|
| 設計・入力境界 | 扱う情報、信頼できない入力、認証と認可、ログの設計 | 脅威の洗出し、設計レビューの観点 |
| 依存関係と設定 | 対象版、影響範囲、SCA・IaC等の検査結果 | 検査基準、判定の難しい事象の分析 |
| 修正とリリース | 修正結果、試験、残る制約 | 重大度と業務影響に応じた確認 |
| 例外 | 修正できない理由、暫定策、期限、残余リスク | 承認経路、独立した確認、経営への報告 |
開発側がすべての専門領域を単独で判断する必要はないのだ。何が分かり、どこが不明で、誰に判断を求めるかを説明できる状態を目指すのだ。
CI/CDと標準テンプレートで支える
SAST、SCA、SBOM、IaC検査は、検知結果の所有者と処理期限まで決めて工程へ組み込むのだ。自動検査が成功した場合も、重要な入力、権限、失敗経路を検査できているかは別に確認するのだ。
専門部署は、使える基準、安全な設定例、相談窓口、例外申請の様式を提供するのだ。判断が必要な案件に絞ってレビューし、同じ問題が繰り返される場合はテンプレートと検査を改善するのだ。
兼務と例外承認の限界
小規模組織では役割を兼務できるが、重大な例外は申請者の自己承認で完了させず、別の責任者の確認と期限を記録するのだ。緊急変更には事後確認の期限を定め、暫定状態が継続していないか追跡するのだ。
運用移管やBuild・Run・Improveの分担はセキュリティ組織設計を参照するのだ。本記事は、その前後で開発側と専門部署が交換する判断材料に焦点を当てるのだ。
結論
分担が機能しているかは部署数や検査数ではなく、影響の説明、修正、例外承認、再確認が担当と期限に結び付いているかで判断するのだ。導入後はレビュー待ち時間、期限切れ例外、再発する不備を観測し、分担案を見直すのだ。