LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

DevSecOpsとは：CI/CDへの継続的セキュリティ組み込み

DevSecOpsとは、開発（Development）・セキュリティ（Security）・運用（Operations）を一体化し、CI/CDパイプライン上でセキュリティ検査を継続的に自動実行するアプローチを指します。OWASP DevSecOpsガイドラインは、開発プロセスに「シフトレフトのセキュリティ文化」を根づかせ、設計上・アプリケーション上のセキュリティ問題をできる限り早期に検出することを目標として掲げています^*1。

従来のウォーターフォール型開発では、セキュリティ検査はリリース直前の最終工程に集約されていました。DevSecOpsはこの検査フェーズを開発の各ステージに分散させ、問題を早期に検出・修正する「シフトレフト」を実現します。

OWASP DevSecOpsガイドラインは、パイプラインのセキュリティを大きくコミット前（Pre-commit）・脆弱性スキャン・コンプライアンス監査に整理し、インフラ検査やコンテナ検査を脆弱性スキャンのなかに位置づけています^*1。本記事ではこれらを実装する具体的な設計パターンと、専門体制が社内にない場合の外注アプローチを解説します。

事後対応の限界：脆弱性発見が遅れるほど修正コストが膨らむ

リリース後に脆弱性が発覚した場合、修正には設計・実装・テスト・再デプロイのすべての工程が再発生します。NIST SP 800-218（SSDF：Secure Software Development Framework、2022年2月公表）は、脆弱性の根本原因に対処し、リリース後の脆弱性対応コストを削減するための実践群を体系化しています^*2。

修正コストが積み上がる要因は主に3点あります。第一に、コードが他のモジュールに組み込まれた後では影響範囲の特定に時間を要します。第二に、本番稼働中のシステムに対するパッチ適用は、サービス停止リスクと並行して計画する必要があります。第三に、外部の脆弱性診断業者に毎回依頼する場合、スポット診断の費用が繰り返し発生します。

本記事の主題はCI/CDパイプラインへの継続的なセキュリティ自動化（DevSecOpsの仕組み化）です。単発の脆弱性診断サービスの費用相場や種類については、別記事「脆弱性診断を外注する費用相場と種類・選び方」が詳しく解説しています。

DevSecOpsが解決しようとする課題は、開発の最後に一度だけ行う「点検型セキュリティ」から、各コミット・各ビルドごとに自動検査を走らせる「継続型セキュリティ」への転換です。この転換を実現するには、パイプライン上に複数のセキュリティスキャナーを正しい順序で配置する設計が必要です。

パイプライン設計：SAST・DAST・SCA・シークレットスキャン・IaCの役割分担

OWASP DevSecOpsガイドラインは、パイプラインに組み込むべきセキュリティ検査として、シークレットスキャン・SAST・SCA・DAST・IaCスキャンの5種類を挙げています^*1。それぞれの役割・実行タイミング・代表的なツールを以下に整理します。

シークレットスキャン：コミット前が最後の防衛ライン

OWASP DevSecOpsガイドラインは、シークレット管理において「開発者がメッセージを受け取り、機密情報がコードベースに入る前に遮断される」Pre-commit段階での検出を推奨しています^*1。APIキーやパスワードがGitリポジトリに一度でもコミットされると、履歴から完全に消去するには相当の手間がかかります。

truffleHogはGitリポジトリの履歴を遡り、高エントロピー文字列（ランダム性が高い文字列）を検出します。git-secretsはコミット時にフック処理で機密パターンを検出し、プッシュを拒否します。これらをPre-commitフレームワーク（例：pre-commit）に組み込むことで、開発者が手動チェックを意識せずとも自動的にスクリーニングが働きます。

SAST：コードを「実行せずに」静的に解析する

SAST（静的アプリケーションセキュリティテスト）は、ソースコードをプログラムとして実行することなく、コードを構文・データフロー・制御フローの観点で解析します^*1。SQLインジェクション・クロスサイトスクリプティング（XSS）・バッファオーバーフローなどの脆弱性パターンをビルド前段階で検出できます。

SemgrepはYAML形式のルールセットを使い、複数言語に対応した軽量なパターンマッチを提供します。SonarQubeは20以上の言語をサポートし、Web UIで指摘をチーム全体が確認できます。プルリクエスト作成時に自動実行するよう設定することで、レビューア負担を減らしながら指摘の見落としを防げます。

SCA：OSSライブラリのサプライチェーンリスクを管理する

現代のアプリケーションはOSSライブラリへの依存が深く、そのライブラリに既知の脆弱性（CVE）が含まれていることがあります。SCA（ソフトウェア構成分析）はコードベースの依存関係を自動分析し、既知CVEやライセンス違反を検出するプロセスです^*1。サプライチェーン攻撃のリスク軽減には、開発ライフサイクルの早期段階での実装が推奨されています。

OWASP Dependency-Checkはライブラリのバージョン情報をNVD（米国家脆弱性データベース）と突合し、CVEスコアと影響バージョンの一覧を出力します。Pythonプロジェクトではsafetyコマンドが、Rubyではbundler-auditが同様の役割を担います。

DAST：稼働中のアプリを外部から動的にテストする

DAST（動的アプリケーションセキュリティテスト）は、実際に稼働しているアプリケーションに対してリクエストを送信し、レスポンスを分析して脆弱性を発見します。SASTがソースコードを見るのに対し、DASTはブラックボックス的に外部から攻撃者の視点でテストする点が異なります。

OWASP ZAPはパイプライン上でスキャンを自動実行できるOSSのプロキシツールです。ステージング環境がデプロイされた後のジョブとして組み込み、認証後の画面や動的に生成されたエンドポイントも含めてスキャンします。実行時間がSASTより長い傾向があるため、毎コミットではなくステージングデプロイ後のタイミングに限定するのが現実的です。

IaCスキャン：インフラのコード化が招く設定ミスを事前検知

クラウドインフラをTerraformやHelm Chartでコード管理するIaC（Infrastructure as Code）が普及しています。設定ファイルに誤りがあると、S3バケットの公開設定ミスやセキュリティグループの過剰な開放が本番環境に反映されるリスクがあります。

IaCスキャンはインフラコードの変更をデプロイ前に検査し、設定不備を検出します。OWASP DevSecOpsガイドラインはTerraformやHelmChartの検査をパイプラインに含めることを推奨しています^*1。CheckovやtfsecなどのOSSツールが、GitHubやGitLab CIと統合しやすい形でこの検査を提供しています。

セキュリティゲート設計と誤検知トリアージ：開発速度を止めないための両立策

各スキャンツールをパイプラインに組み込んだだけでは、誤検知（False Positive）が大量発生し、開発者がアラートを無視するようになります。DevSecOpsを機能させるには、ゲートの閾値設計と誤検知トリアージのプロセスが不可欠です。

セキュリティゲートの設計：ブロックするものとしないものを分ける

セキュリティゲートとは、スキャン結果が基準を超えた場合にパイプラインを停止させる仕組みです。すべての指摘でパイプラインを止めると開発が停滞します。NIST SSDF（SP 800-218）は、組織がリスク許容度に応じた実践を採択することを前提に構築されており^*2、重大度に基づくゲート設定はその考え方に沿った実装です。

実務上は以下の基準が参考になります。

• ブロック対象（Critical/High）：CVSSスコア7.0以上のCVE、シークレットの検出、認証バイパスに直結するSAST指摘
• 警告扱い（Medium）：ビルドを通過させ、チケットを自動起票してバックログに積む
• 情報扱い（Low/Info）：レポートには記録するが即時対応を要求しない

この3段階運用により、開発者は毎回のコミットで大量のアラートに圧倒されることなく、優先度の高い問題だけを即時対処できます。

誤検知トリアージ：定期的な見直しサイクルを作る

SASTは「ソースコードを実行せずに解析する」性質上、実際には到達不可能なコードパスを脆弱性として報告することがあります。誤検知を放置すると、本物の指摘が埋もれます。

有効なアプローチは、初回スキャン後に全指摘を精査し、誤検知と判定したものをホワイトリストに登録するベースライン作成です。以降のスキャンではベースライン外の新規指摘のみを開発者に通知します。この作業は一度行えばメンテナンスコストが大幅に下がります。定期的（例：四半期ごと）にホワイトリストを再評価し、古い誤検知判定を見直すサイクルを維持することが大切です。

開発者体験との両立：フィードバックをIDEに近づける

セキュリティ指摘をCI上でのみ通知すると、開発者はコミット後に初めて問題を知ります。フィードバックサイクルを短縮するには、IDE拡張（SemgrepのVS Code拡張など）を利用して、コード記述中にリアルタイムで指摘を表示する方法が有効です。

また、指摘の通知先をSlackやJiraと連携させ、担当者に自動割り当てする設計も開発者体験の向上に寄与します。開発者が「なぜこれが問題か」を理解せずにアラートを消化するだけの状態は、DevSecOpsの文化浸透を妨げます。指摘ごとにドキュメントへのリンクや修正例を添付する設定が、学習効果と対応速度を高めます。

内製でのDevSecOps構築に必要なスキルセット

社内チームだけでDevSecOpsパイプラインを設計・運用するには、以下のスキルが必要です。

• CI/CDツール（GitHub Actions・GitLab CI・Jenkins等）のパイプライン設計経験
• セキュリティスキャンツールの設定・チューニング知識（SAST/DAST/SCA各ツール）
• 脆弱性の重大度評価（CVSSスコアの読み方・誤検知判定）
• IaCセキュリティ（Terraform・コンテナのセキュリティ設定）
• セキュリティ文化の浸透施策（開発チームへのトレーニング・ドキュメント整備）

これらを一人のエンジニアが兼ねることは難しく、専任のセキュリティエンジニアが不在の組織では外注が現実的な選択肢となります。スキャンツールの初期設定を誤ると誤検知が乱発し、開発者がアラートを「無視するもの」として扱うようになります。この状態を後から修正するにはリセットのコストがかかります。

体制が整っていない場合の外注アプローチ：要件定義からパートナー選定まで

DevSecOpsの外注とは、CI/CDパイプラインへのセキュリティツール統合・ゲート設計・運用体制構築を専門パートナーに委ねる取り組みです。スポットの脆弱性診断とは異なり、継続的な自動化の仕組みを構築・維持するプロジェクトとして位置づける必要があります。

外注前に整理すべき3つの要件

外注を依頼する前に、以下の3点を社内で整理しておくことで、見積もりの精度と成果物の品質が高まります。

1. 対象リポジトリ・技術スタック：言語・フレームワーク・CI/CDツール・クラウドプロバイダーを明記する。SASTツールの言語対応状況がスコープに直結します。
2. 現状のパイプライン成熟度：CI/CD自体がない段階なのか、CIはあるがセキュリティスキャンがない状態なのかで、外注スコープが変わります。
3. ゴール指標：「クリティカル指摘をゼロに」「SASTをプルリクエストに組み込む」など、完了基準を数値・状態で定義します。曖昧な「セキュリティを強化する」では成果の検証ができません。

パートナー選定で確認すべきポイント

DevSecOps支援の実績を持つパートナーを選ぶ際は、以下の点を確認することを勧めます。

• 使用するスキャンツールとその理由：ツール選定に対して技術的根拠を説明できるか
• 誤検知トリアージの経験：ベースライン作成・ホワイトリスト管理の実務経験があるか
• 引き渡しドキュメントの範囲：構築後に社内チームが自走できるドキュメントを提供するか
• 継続的なチューニング支援：初期構築だけでなく、誤検知率の改善や新規ツール追加に対応するか
• NIST SSDF・OWASPなど標準フレームワークへの準拠：業界標準に基づいた設計をしているかどうかが、技術力の目安になります

段階的な導入で立ち上がりリスクを下げる

すべてのスキャンを一度に本番パイプラインに組み込むと、大量の指摘が発生して開発が停滞するリスクがあります。外注パートナーと連携しながら段階的に進める順序として、以下を参考にしてください。

1. フェーズ1：シークレットスキャン＋SAST（ビルド時間への影響が少ない・高い効果）
2. フェーズ2：SCA（依存ライブラリの既知CVEを継続監視する仕組みを追加）
3. フェーズ3：DAST（ステージング環境への組み込みで動的テストを自動化）
4. フェーズ4：IaCスキャン（クラウドインフラのコード管理が整った段階で追加）

フェーズ1の完了後に誤検知トリアージのベースラインを作成し、開発チームがアラートに慣れた段階で次フェーズを追加する進め方が、開発速度を極力落とさずに段階的にセキュリティ水準を高めることにつながります。

元請（プライムベンダー）としての役割と外注管理

DevSecOpsの外注では、複数のツールベンダー・セキュリティパートナー・開発チームが関わることがあります。元請として全体を統括する立場のパートナーを選ぶことで、ツール間の連携漏れや責任の所在の曖昧さを防げます。

外注先がパイプラインにアクセスする際のソースコードの取り扱い・機密情報の管理方針は、契約書に明記する必要があります。特にシークレットスキャンの設定作業では外注担当者が既存のリポジトリ構成を把握します。NDA締結・アクセス権限の最小化・作業完了後のクレデンシャル無効化を標準手順として定めておくことが大切です。

まとめ：DevSecOps外注を成功させる3つの判断軸

本稿では、DevSecOpsのCI/CDパイプラインへの組み込みについて、OWASP DevSecOpsガイドラインとNIST SP 800-218（SSDF）を軸に整理しました。要点を3点にまとめます。

第一に、DevSecOpsはシークレットスキャン・SAST・SCA・DAST・IaCスキャンの5種類の検査を、コミット前からデプロイ前の各フェーズに分散させて組み込む設計が基本です。検査をリリース直前の1点に集中させる従来型では、修正コストが大きくなります。

第二に、セキュリティゲートは重大度（Critical/High/Medium）に応じた3段階で設計し、誤検知はベースライン登録で管理する仕組みを作ることで、開発速度とセキュリティ水準の両立が図れます。すべての指摘でビルドを止めると開発者のアラート疲れが生じます。

第三に、外注を選ぶ場合は段階的なフェーズ設計・引き渡しドキュメント・継続チューニング支援の有無がパートナー選定の判断軸になります。初期構築だけで終わるのではなく、社内チームが自走できる状態に移行できるかどうかが成否を左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：OWASP「OWASP DevSecOps Guideline」（2021年〜継続更新）
2. *2　出典：NIST「Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, NIST Special Publication 800-218」（2022年2月）

Tweet