IT用語集 2024/05/08

DevSecOpsとは？わかりやすく10分で解説

コラム

DevSecOpsとは

DevSecOpsとは、開発（Development）、セキュリティ（Security）、運用（Operations）を分離せず、ソフトウェア開発ライフサイクルとCI/CDの中にセキュリティ確認を組み込む実践です。要件定義、設計、実装、テスト、ビルド、デプロイ、運用の各段階で、脆弱性、設定ミス、依存関係、秘密情報、ログ、インシデント対応を扱える状態にします。最後にまとめて診断する方式だけに依存せず、変更のたびに確認し、リスクを早い段階で修正できる体制を作る考え方です。

DevSecOpsの定義と目的

DevSecOpsは、DevOpsの速度と自動化を維持しながら、セキュリティを開発・運用の通常業務に組み込む取り組みです。NIST SP 800-204Cでは、ソースコードをビルド、テスト、パッケージング、デプロイ、運用へ進めるパイプラインを、フィードバック機構を備えた自動化ツールで支えるものとして整理しています。

主な目的は次のとおりです。

リリースの速度を落とさず、重大な脆弱性や設定ミスを早期に検出する
開発者、運用担当者、セキュリティ担当者が同じ基準でリスクを判断する
検出結果、修正履歴、例外判断、監査ログを残し、後から説明できる状態にする
セキュリティ確認を属人的なレビューだけに依存させず、CI/CDやチケット管理へ組み込む

DevSecOpsは「セキュリティ担当者の作業を開発者に丸投げする」ことではありません。チームごとの責任範囲を明確にし、機械的に判定できる項目は自動化し、業務判断を伴う項目は承認・例外・再評価の手順を決めます。

DevOpsとの違い

DevOpsとDevSecOpsはいずれも、開発と運用の分断を減らし、小さな変更を継続的に提供する点で共通しています。違いは、セキュリティを外部の確認工程として扱うか、開発・運用の流れに組み込むかにあります。

DevOps	開発と運用の連携、自動化、継続的な改善を重視します。ビルド、テスト、デプロイを高速化し、サービス提供までの時間を短縮します。
DevSecOps	DevOpsの流れに、脅威分析、セキュアコーディング、依存関係管理、脆弱性検査、設定検査、ログ監視、インシデント対応を組み込みます。

DevOpsだけを進めると、デプロイは速くなっても、セキュリティ確認がリリース直前や外部診断に偏る場合があります。DevSecOpsでは、Pull Request、ビルド、コンテナイメージ作成、デプロイ、運用監視の各段階で、止める条件、警告にとどめる条件、例外承認の条件を決めます。

DevSecOpsが求められる背景

クラウドネイティブ、マイクロサービス、API連携、コンテナ、Infrastructure as Codeの利用により、システム変更は小さく高頻度になりました。アプリケーションコードだけでなく、OSSライブラリ、コンテナイメージ、クラウド設定、パイプライン権限、シークレット、実行時ログまで管理対象が広がっています。

この環境で、年1回の診断やリリース直前のレビューだけに頼ると、修正の手戻りが増えます。変更が入る段階で、依存関係の脆弱性、設定ミス、認証情報の混入、危険なコードパターンを検出し、担当者へ返す仕組みが必要になります。

対象範囲

DevSecOpsの対象は、ソースコードだけではありません。代表的な対象は次のとおりです。

アプリケーションコード、API、認証・認可処理
OSSライブラリ、パッケージ、ライセンス、依存関係
IaC、クラウド設定、ネットワーク設定、権限設定
コンテナイメージ、ベースイメージ、レジストリ、実行環境
CI/CDパイプライン、ビルド環境、デプロイ権限、署名・改ざん検知
ログ、監視、アラート、セキュリティインシデント対応

DevSecOps導入の考え方

導入前に決めること

DevSecOpsは、ツールを追加するだけでは成立しません。最初に、守る対象、許容できないリスク、止める条件、例外の扱いを決めます。特に、外部公開システム、個人情報を扱う機能、認証・決済・管理者権限に関わる機能は、確認水準を高く設定します。

対象資産：アプリ、API、クラウド設定、コンテナ、CI/CD、依存関係を棚卸しする
リスク基準：重大度、外部公開有無、悪用可能性、業務影響を使って優先順位を決める
セキュリティゲート：どの検出結果でビルドやリリースを止めるかを定義する
例外管理：一時的に受容するリスクには期限、理由、再評価日、承認者を残す

シフトレフトの位置づけ

シフトレフトは、セキュリティ確認を開発の早い段階へ移す考え方です。設計時の脅威分析、実装時の静的解析、Pull Requestでの依存関係チェック、CIでのシークレット検知を組み合わせると、修正コストを抑えやすくなります。

ただし、シフトレフトだけで十分ではありません。実行中のアプリケーションでしか見つからない問題、運用ログから把握する不審な挙動、侵害後の封じ込めは、運用段階の監視と対応で扱います。DevSecOpsでは、開発前半の検出と運用後の検知を分けず、継続的に改善します。

組織文化と役割分担

DevSecOpsでは、全員が同じ作業をするわけではありません。役割ごとに責任を分け、共通の判断基準を持ちます。

開発者	安全な実装、コードレビュー、依存関係の更新、シークレット混入防止、検出結果の修正を担当します。
運用担当者	デプロイ、設定管理、ログ監視、障害対応、権限管理、復旧手順を担当します。
セキュリティ担当者	基準策定、検出ルール設計、例外承認、教育、監査対応、インシデント対応支援を担当します。

失敗を個人の責任に寄せる文化では、検出結果やミスの報告が遅れます。ポストモーテムでは、誰が悪かったかではなく、検出できなかった条件、判断が遅れた理由、再発防止の変更点を記録します。

コミュニケーションと証跡

DevSecOpsでは、検出結果を出すだけでなく、誰が確認し、どの理由で修正・延期・例外承認したかを残します。口頭判断だけで進めると、監査、顧客説明、インシデント時の調査で確認に時間がかかります。

検出結果はチケット、Pull Request、ダッシュボードに連携する
重大度、修正期限、担当者、影響範囲を記録する
例外は期限付きで登録し、期限到来時に再評価する
リリース判断に使った検査結果と承認履歴を保存する

DevSecOpsツールと技術

DevSecOpsで使うツールは、工程ごとに役割が異なります。製品名を増やすより、検出結果を誰が処理し、どの条件でリリース可否を判断するかまで決めることが先です。

代表的なツール領域

SAST	ソースコードやバイトコードを解析し、危険な実装パターン、入力検証不足、認証・認可処理の不備などを検出します。
DAST	実行中のアプリケーションに対して外部から検査を行い、入力処理、セッション管理、公開画面の脆弱性を確認します。
SCA	OSSライブラリやパッケージの脆弱性、ライセンス、推奨バージョンを確認します。依存関係の棚卸しにも使います。
シークレット検知	APIキー、トークン、秘密鍵、パスワードがリポジトリやログに混入していないかを確認します。
IaCスキャン	TerraformやKubernetesマニフェストなどの構成コードを検査し、過剰権限、公開設定、暗号化漏れを確認します。
コンテナ検査	コンテナセキュリティの観点から、ベースイメージ、不要パッケージ、既知脆弱性、権限設定、署名を確認します。
SBOM管理	SBOMを整備し、ソフトウェアを構成する部品、バージョン、依存関係を把握します。
監視・ログ分析	運用時の不審なアクセス、権限変更、異常な通信、アプリケーションエラーを確認し、インシデント対応へつなげます。

CI/CDへの組み込み方

セキュリティ検査は、開発者の作業を止めすぎない位置に組み込みます。Pull Requestでは高速な検査を実行し、夜間やリリース前には時間のかかる検査を実行するなど、工程ごとに検査の粒度を分けます。

Pull Request時：シークレット検知、SCA、軽量なSASTを実行する
ビルド時：ユニットテスト、SAST、依存関係チェック、署名を実行する
パッケージ作成時：コンテナイメージ検査、SBOM生成、署名を実行する
ステージング時：DAST、API検査、設定検査を実行する
本番運用時：ログ監視、脆弱性情報の追跡、インシデント対応訓練を継続する

CI/CD環境そのものの保護

CI/CD環境は、ソースコード、認証情報、成果物、デプロイ権限を扱います。侵害されると、不正コードの混入、秘密情報の窃取、成果物の改ざん、本番環境への不正デプロイにつながります。

そのため、CI/CD環境では、多要素認証、最小権限、秘密情報の集中管理、ビルド実行環境の分離、依存関係の固定、成果物の署名、監査ログの保存を実施します。特に、管理者権限、リリース承認、デプロイ用トークンは、通常の開発権限と分けて管理します。

ツール選定で確認する条件

ツール選定では、検出性能だけでなく、現場で継続できるかを確認します。

既存のGit運用、レビュー、CI/CD、チケット管理へ連携できるか
検出結果に担当者、期限、重大度、修正方針を付けられるか
誤検知の抑制、ルール調整、例外の期限管理に対応しているか
監査ログ、権限管理、レポート出力が社内要件に合うか
開発者が修正方法を理解できる説明や修正例を提示できるか

DevSecOpsの課題と対策

検出結果が多すぎる

最初から多くの検査を有効化すると、検出結果が大量に発生し、担当者が処理できなくなります。導入初期は、重大度、外部公開有無、悪用可能性、到達可能性で優先順位を付け、止める条件を限定します。低リスクの検出結果は、通知、チケット化、期限付き対応に分けます。

ツール導入だけで終わる

ツールを導入しても、検出結果の処理担当、修正期限、例外承認、再評価手順がなければ、結果は放置されます。DevSecOpsでは、検出から修正完了までの流れをチケットやPull Requestに接続し、未対応の件数よりも、修正までの時間と再発率を追跡します。

スキル差が大きい

開発者全員に高度なセキュリティ専門性を求めると、導入が停滞します。役割ごとの到達目標を分け、セキュアコーディング基準、レビュー観点、テンプレート、教育資料、相談窓口を用意します。セキュリティ担当者は、指摘だけでなく、修正方法と判断基準を提示します。

例外が放置される

本番影響、互換性、顧客対応、ベンダー都合により、すぐに修正できない脆弱性や設定が残る場合があります。例外を認める場合は、期限、理由、影響範囲、補完策、再評価条件を登録します。期限を過ぎた例外は、リリース判定やリスクレビューで再確認します。

DevSecOpsだけでは足りないケース

DevSecOpsは開発・運用プロセスの改善策ですが、すべてのセキュリティ課題を代替するものではありません。外部委託先の管理、契約条件、法令対応、物理環境、端末管理、ID管理、ゼロトラスト設計、社内教育、経営判断は別途扱います。特に、サプライチェーン攻撃への備えでは、開発パイプラインだけでなく、調達、委託、署名、配布、脆弱性連絡の体制まで確認します。

成果指標と継続運用

成果の測り方

DevSecOpsの評価では、検出件数そのものより、改善の速度と再発防止を確認します。検出件数は、ツール追加直後に増えるため、単独では良否を判断しにくい指標です。

重大脆弱性の平均修正時間
リリース前に検出できた問題の割合
同種の脆弱性や設定ミスの再発率
期限切れ例外の件数
セキュリティゲートによるリリース停止件数と停止理由
インシデント発生時の検知から封じ込めまでの時間

ROIの考え方

DevSecOpsのROIは、ツール費用と人件費の単純な差額だけでは評価しにくい領域です。評価では、重大インシデントの低減、リリース直前の手戻り削減、監査対応工数の削減、顧客説明に必要な証跡整備、開発者の待ち時間削減を分けて確認します。

短期的には、検査追加により作業が増えたように見える場合があります。中長期では、修正の前倒し、標準化、再発防止により、緊急対応や属人的な確認を減らせるかを評価します。

今後のDevSecOps

今後のDevSecOpsでは、SBOM、署名、成果物の真正性確認、Policy as Code、ランタイム防御、ゼロトラストとの連携がさらに重視されます。生成AIを使った開発支援が普及するほど、生成されたコード、依存関係、秘密情報、ライセンス、レビュー責任をどう扱うかも課題になります。

技術要素が増えても、基本は変わりません。資産を把握し、変更点を検査し、リスクを記録し、修正と例外を管理し、運用ログから改善する。この一連の流れを継続できる組織設計が、DevSecOpsの実効性を左右します。

まとめ

DevSecOpsは、開発・運用・セキュリティを分けて扱うのではなく、ソフトウェア提供の工程全体にセキュリティ確認を組み込む実践です。SAST、DAST、SCA、IaCスキャン、コンテナ検査、SBOM、ログ監視などをCI/CDと運用に接続し、検出結果を担当者、期限、例外、証跡と結び付けます。導入時は、対象資産、止める条件、例外管理、責任分担を先に決め、効果が出やすい範囲から段階的に拡張します。