DevSecOpsとは？SAST・DAST・SCAとCI/CDの安全な運用【2026年版】

DevSecOpsは、開発・セキュリティ・運用が連携し、設計から公開後の対応までセキュリティを組み込む取り組みです。CI/CDへスキャナーを追加することは、その一部です。検出結果を誰が確認し、何を直し、どの状態で公開するかまで決めて、初めて日常の開発工程として機能します。

この記事では2026年10月時点のNIST・OWASPと各ツールの公式資料をもとに、検査手法の役割、パイプライン自体の保護、公開判断、修正を続ける運用を整理します。全社共通の導入順や合格率を置くのではなく、自社の製品・業務・開発体制に合わせて設計します。

DevSecOpsとシフトレフト：設計から公開後の対応までつなぐ

シフトレフトは、開発の早い段階でセキュリティを考え、問題を発見・修正する取り組みです。設計時にデータの機密性や権限を検討し、実装中にコードを確認し、変更を取り込む前に検査することで、後から大きく作り直す手戻りを抑えることを目指します。これは、公開直前の検査を単に前倒しするだけではありません。要求の整理、レビュー、検査、判断、修正の受け渡しを開発の流れに組み込む考え方です。設計段階で問題を見つけても、責任者や修正方法が決まらなければ、結果が積み残されます。

参考になる枠組みに、NISTのSecure Software Development Framework（SSDF）があります。NISTの公表一覧では、確認時点で1.1が最終版、1.2がドラフトとして掲載されています。新しい番号を、そのまま確定した要件として扱わないことが必要です。SSDF 1.1は、組織の準備、ソフトウェアの保護、安全性を考慮したソフトウェアの作成、脆弱性への対応という四つの領域を扱います。

具体化するときは、対象のアプリケーション、リポジトリ、依存部品、ビルド環境、公開先、保守責任者を対応させます。たとえば顧客情報を扱う管理画面では、他の担当者の情報へアクセスできないこと、管理者だけが実行できる処理、記録すべき操作などを要件にします。その要件をレビュー項目とテストへつなげると、単にツールの警告を減らす活動から、守るべき業務を確認する活動へ変えられます。一般的なCI/CDの仕組みと導入手順も、この要求と責任の整理を前提に考えます。

公開後も、新たな脆弱性の公表、設定変更、依存部品の更新、利用方法の変化が起こります。早期の検査を増やしても、運用時の監視や問い合わせへの対応を終えることはできません。また、修正費用が発見段階に応じて必ず何倍になる、導入すれば開発速度が必ず上がる、といった一律の数値は置きません。検査の待ち時間と確認工数も含め、自社で起きている手戻りや修正の滞留を測って改善します。

SAST・DAST・SCAの違いと、ツール選定の確認点

検査手法は同じ対象を違う名前で調べるものではありません。SASTはソースコードや解析可能なコードから問題の候補を探し、DASTは動いているアプリケーションへのリクエスト等から挙動を調べます。SCAは依存部品の構成と既知の脆弱性等を扱います。これに、シークレットの検出、コンテナの部品検査、IaCの設定検査などを組み合わせます。名称だけで検査済みとせず、入力、対応言語、ルール、対象となる環境と、検査できていない範囲を確認します。

手法	確認する対象	見落とさない条件
SAST	コード内の問題候補	対応言語・フレームワーク、解析範囲、ビルド等の前提
DAST	稼働するアプリの応答や挙動	ログイン・権限・画面遷移・APIの到達範囲、実施の許可と環境
SCA・部品検査	直接・間接の依存部品と既知の脆弱性	確定した版、取得できる構成、情報源と更新時点
シークレット検出	キー等の漏えい候補	コード以外のログ・成果物、検出後の失効・再発行等の対応
IaC・設定検査	構成ファイル等の設定	対応形式とルール、実際に稼働する設定との差異

OWASPのSASTの解説は、得意な問題と、認証・アクセス制御等で自動化が難しい部分を分けています。静的解析で警告がないことを、業務上の権限設計まで正しいという証明にはできません。Semgrepの公式の対応言語・解析説明でも、Community EditionとSemgrep Codeでは解析範囲や支援が異なります。同じ名称を含む製品群の機能を、無料版で全て使えると説明しないようにします。

Trivyの脆弱性検査の説明では、検出した部品と情報源、版の特定方法が結果に関わります。対応するOS・言語の一覧だけでなく、実際の入力で必要な部品が見つかるかを試します。ZAPのアクティブスキャンは対象へ攻撃を試みる検査です。合意した対象と検証環境で実施し、自動検査だけで業務ロジックや権限の問題を網羅したとしません。価格や実行時間だけで比較せず、検出結果を確認して修正へつなげられるかで評価します。

CI/CDに組み込む検査と、パイプライン自体の保護

検査を配置する場所は、変更の種類と必要な実行時間から決めます。実装中や変更の取り込み前には、開発者がすぐ戻れる検査を置き、ビルド後には生成された成果物を確認します。検証環境ではログイン後の処理やAPIも対象にし、公開前には必要な確認の結果が、公開する成果物と対応しているかを確かめます。一つの検査を毎回すべての段階で繰り返す設計にせず、変更時に行う確認と定期的な再検査を使い分けます。対象外になったファイルや、失敗して実行されていない検査も見えるようにします。

同時に、検査を動かすCI/CD自体が攻撃対象になる点を考えます。OWASPのCI/CD Security Cheat Sheetは、コード管理、実行環境、権限、秘密情報、依存関係、成果物の完全性、ログ等を扱っています。検査ツールを増やしても、誰でも検査設定を削除して公開できたり、未確認の変更へ本番の資格情報を渡したりする構成では、工程の信頼性が保てません。コードの変更と同様に、パイプラインの設定変更も確認対象にします。

実装時は、誰が変更を取り込めるか、実行時のIDは何へアクセスできるか、どの操作で公開されるかを図にして確認します。ビルドと配布の権限を必要な範囲に絞り、外部からの変更を処理する実行と、秘密情報を扱う実行の境界を明確にします。依存パッケージやプラグインの取得元・版・更新も管理対象です。署名やチェックサムは由来や改変の確認に役立ちますが、それ自体が中身の安全性を保証するものではありません。

秘密情報は、コードへ埋め込まないだけでなく、ログや生成物へ残さないことも確認します。検出した場合には、その文字列を削除して終わりにせず、利用状況の確認、失効・再発行、関係先への反映等を扱う手順へつなげます。検査用アカウントの権限や有効期間も管理し、不要になったアクセスを残さないようにします。人のログインを守る多要素認証の方式と運用、パスキーと復旧経路の設計は、自動実行IDの管理と分けて整理すると、対策の抜けを見つけやすくなります。

公開判断と修正の運用：検出件数だけを目標にしない

セキュリティゲートは、検査結果等を使って変更の取り込みや公開を判断する仕組みです。「まず警告だけ、次はCriticalだけ、最後はHighまで」といった順番を、どの製品にも共通の成熟モデルとして固定する必要はありません。現在攻撃され得る問題を、導入初期だからという理由だけで見過ごせません。一方で、深刻度のラベルだけを見て既存の全検出を無条件に同じ扱いにすると、必要な調査と修正の順序が分かりにくくなります。外部への接点、利用するデータ、必要権限、悪用情報、修正方法等を踏まえて基準を定めます。

運用の一例として、新しい変更で持ち込む問題と、既存の問題の解消計画を分けて管理します。検出結果には対象製品・版、確認担当、判断根拠、対応期限、修正後の確認を残します。誤検知と判断したもの、実害がないと確認したもの、未調査のもの、リスクを受容したものを、すべて「無視」にまとめないことが大切です。例外が必要な場合には、承認者、理由、代替策、期限、再評価する条件を記録します。検査の失敗や情報源を取得できない状態も、「問題ゼロ」と区別します。

指標は、何を分母にして何を完了とするかを明確にします。修正時間なら、検出からコード変更までか、稼働環境への適用と再確認までかで意味が変わります。平均値だけでは滞留が見えないため、重大な未対応項目、期限を過ぎた項目、再発した問題も確認します。検査対象率も、登録したリポジトリの割合と、公開する全成果物を確認できているかを分けます。ビルド停止率を一律に5〜15％へ合わせる、といった根拠のない適正値は置きません。

脆弱性情報は、コードを変更しなくても後から更新されます。部品構成と成果物を結び付け、定期的に照合し直せるようにします。SBOMの形式・適用要件と脆弱性管理を整えると、対象製品へたどる基礎ができます。ただしSBOMは部品一覧であり、影響判断や修正の代わりにはなりません。開発時の検査、公開後の情報収集、問題の受付、判断、修正、配布、再確認を一連の運用として扱います。

導入とAI活用：小さな対象で確認し、合意した範囲から広げる

導入時は、重要な製品とその公開経路を一つ選び、現状を確認します。扱うデータ、権限、依存部品、検査と修正の担当、外部委託先との責任分担を整理したうえで、取りこぼしているリスクに合う検査を選びます。シークレット検出が必要な対象もあれば、ログイン後の権限検証や古い依存部品の更新が先に必要な対象もあります。全社で同じツールを一斉に入れることより、選んだ対象で検出から修正・再確認までを回すことを最初の到達点にします。

試行では、既知の問題を確認できるか、通常の開発変更に必要な時間はどれほどか、確認担当へ情報が届くか、例外が期限切れになったときに再評価されるかを見ます。実行環境、設定とルール、対応言語、検査対象、出力の保存方法を記録すれば、ツールや版の更新で結果が変わった場合も調査しやすくなります。費用には利用料だけでなく、連携の設定、実行基盤、結果の確認、修正と検証、教育、保守を含めます。無料のツールがあることと、運用コストが発生しないことは別です。

AIによるコード分析や修正候補の作成を使うときも、任せる対象と判断権限を決めます。修正の説明、元の問題との対応、実行した検査、機能への影響を確認し、修正候補が出たことを公開可能という結論にしません。コードや検出結果を外部へ渡す場合の保管・学習利用・アクセス条件も確認します。単一ファイルの修正機能、依存部品の更新、複数の処理にまたがる設計変更では対象が異なります。製品名だけをもとに、すべての問題を自動検出・自動修正できると説明しないことが必要です。

自動検査で確認しにくい処理や権限の関係は、設計レビューや合意した検証を組み合わせます。脆弱性診断とペネトレーションテストは、検査の目的と範囲を整理する際の参考になります。OWASPのソフトウェアサプライチェーン対策も、ツールと人による確認、公開後の維持管理を合わせて考えています。

renueのAI脆弱性診断支援サービスでは、業務とシステム構成を確認し、合意した対象でコード分析や既知の脆弱性の確認、認証・権限・外部との接点の検証を進めます。結果は該当箇所、想定される影響、改善方法と優先順位へつなげます。診断後の改修・刷新も、範囲を合意して支援します。DevSecOpsの検査項目を増やす前に、現在の開発で何を守り、どこで判断が止まるかを整理するところからご相談いただけます。