DevSecOps入門: 信頼の連鎖で守る供給網
DevOps 基本編の最終回では、セキュリティを「開発の最後に検査するもの」ではなく、CI/CD の流れに組み込む DevSecOps を扱います。
近年のソフトウェアサプライチェーン攻撃は、アプリケーションコードそのものだけでなく、依存ライブラリ、CI/CD、ビルド環境、コンテナイメージ、配布物の差し替えまで広がっています。つまり「自分たちのコードに脆弱性がないか」だけでは不十分で、「何を材料に、どこでビルドし、どの成果物を、誰が信頼して実行するのか」まで説明できる状態が求められています。
本記事では、推進担当・リーダー層が DevSecOps の第一歩として CI に組み込むべき施策を、サプライチェーンセキュリティの観点から整理します。
shift-left: セキュリティを最後の関門から最初へ
DevSecOps の基本思想は shift-left です。リリース直前や本番投入前にまとめて検査するのではなく、設計、実装、レビュー、CI の早い段階でリスクを見つけます。
実務への影響は明確です。後工程で見つかった脆弱性は、修正範囲が広く、リリース計画にも影響します。一方、Pull Request や CI で検出できれば、開発者の文脈が残っているうちに修正できます。これは開発速度を守るためのセキュリティでもあります。
ただし、筆者の評価としては、shift-left だけを合言葉にする段階は終わりつつあります。2024 年以降、CISA なども SBOM の「作成」だけでなく「消費」、つまり脆弱性情報や VEX と突き合わせて判断する運用を重視しています。今後は、早く検出することに加えて、成果物の署名、来歴、検証ポリシーによって「信頼できる証跡」を残す方向へ進むでしょう。
サプライチェーンの攻撃面を地図にする
DevSecOps をツール導入から始めると、施策が点になりがちです。先に見るべきなのは攻撃面です。
サプライチェーン上の主な攻撃面を、CI/CD の流れに沿って整理すると次のようになります。
この図で重要なのは、守る対象がコードだけではない点です。依存、CI/CD、ビルド、成果物、イメージの各地点で信頼が途切れると、後続の工程全体が汚染されます。
たとえば GitHub Actions では、外部 Action をタグで参照している場合、タグの扱いによってビルドが意図しないコードを取り込むリスクがあります。GitHub は 2025 年に Actions のブロックや SHA ピンをポリシーとして扱う機能を拡充しています。背景には、CI/CD が単なる自動化基盤ではなく、ソフトウェア供給網の中核になったという変化があります。
推進担当としては、「どのツールを入れるか」より先に、どこで信頼を作り、どこで検証するかを合意することが重要です。
SCA: 依存関係を可視化し、更新を回す
SCA（Software Composition Analysis）は、依存ライブラリを可視化し、既知脆弱性やライセンスリスクを把握する取り組みです。Dependabot、Renovate、Trivy などが代表的な選択肢です。
実務での価値は「脆弱性を見つけること」だけではありません。むしろ重要なのは、更新 PR を自動で作り、CI で互換性を確認し、チームが判断してマージする回路を作ることです。検出だけ増やして更新が進まない状態は、アラート疲れを生みます。
筆者の評価では、SCA は DevSecOps の初期投資として ROI が高い施策です。Dependabot は GitHub 利用組織で導入しやすく、Renovate は大規模・多言語環境でルールを柔軟に作れます。Trivy はコンテナや SBOM 周辺まで扱える一方、SBOM 生成と脆弱性スキャンのジョブ設計を分けて考えるなど、CI 上の責務分離が必要です。
今後は「High は何日以内に対応する」「修正不能なものは例外期限を持つ」といった、依存更新の SLO に近い運用がより重視されるでしょう。
SBOM: ソフトウェア部品表を作り、使う
SBOM（Software Bill of Materials）は、ソフトウェアを構成する部品表です。代表的な形式に CycloneDX と SPDX があります。CycloneDX はセキュリティ文脈での表現力を強め、SPDX 3.0 はソフトウェアだけでなくシステム全体の管理へ適用範囲を広げています。
実務への影響として、SBOM は顧客説明、監査、脆弱性対応の共通言語になります。たとえば重大な脆弱性が公開された際、「自社製品のどこに該当ライブラリが含まれるか」を短時間で確認できる状態は、対応速度に直結します。
一方で、SBOM は出力しただけでは防御になりません。筆者は、SBOM を「成果物に添付する JSON」ではなく、「脆弱性情報、VEX、例外判断、顧客回答につなげるデータ」として扱うべきだと考えています。品質も課題です。依存解決の揺れや欠落があると、判断を誤ります。
比較としては、外部提出や契約要件がある場合は相手指定の形式に合わせ、内部運用ではツールとの相性で選ぶのが現実的です。syft のようなツールで主要成果物から SBOM を生成し、保管場所と利用プロセスを決めるところから始めるのがよいでしょう。
署名と来歴: 本物であることを保証する
SCA と SBOM が「何が含まれるか」を扱うのに対し、署名と来歴は「それが本物か」「どの手順で作られたか」を扱います。
Sigstore/cosign は、コンテナイメージなどの成果物に署名する代表的な仕組みです。特に keyless 署名では、OIDC により CI の実行主体と署名を結び付けられます。鍵配布の負担を減らせる点が利点です。
SLSA は、ビルドの来歴を段階的に高めるためのフレームワークです。SLSA v1.0 では provenance、つまり「どのソースから、どのビルダーで、どの手順により作られたか」を説明する考え方が整理されています。
実務上のポイントは、署名や来歴を作るだけで終えないことです。検証をどこで強制するかまで設計して価値が出ます。
この流れでは、CI が成果物を作成し、署名と来歴を付与し、デプロイ時に検証します。未署名のイメージや、想定外のワークフローから作られた成果物を止めることで、信頼の連鎖が運用に落ちます。
筆者の評価では、署名と来歴はサプライチェーン対策の中核です。一方で、初期導入時は概念が難しく見えやすいため、全社一斉よりも重要なコンテナイメージや配布 CLI から段階的に進める方が成功しやすいです。
シークレット混入防止: 漏れる前に止める
API キー、トークン、秘密鍵が Git に混入すると、検知後のローテーション、影響調査、顧客説明に大きなコストが発生します。シークレットスキャンは、DevSecOps の中でも即効性の高い施策です。
GitHub の push protection は、秘密情報を push 時点で止める機能として改善が続いています。2025 年には対象パターンの調整が進み、2026 年にも API や検出機能の改善が発表されています。背景には、検出するだけでなく、開発者体験を損なわずにブロックする運用が求められていることがあります。
筆者の意見として、シークレット対策は CI よりさらに左、つまり開発者がリポジトリへ送る前に止めるのが効果的です。ただし、スキャンだけでは十分ではありません。長期固定キーを減らし、OIDC や短命クレデンシャルへ移行する設計と組み合わせることで、事故時の影響を小さくできます。
推進担当としての導入優先順位
リーダー層が最初に判断すべきなのは、完璧なツール選定ではなく、効果と導入負荷のバランスです。筆者なら、次の順序を推奨します。
シークレット混入防止
push protection やプリコミット検査で、漏えいを入口で止めます。効果が見えやすく、組織展開しやすい施策です。依存更新の自動化と SCA
Dependabot や Renovate で更新 PR を回し、Trivy などで可視化します。検出よりも、マージまでの流れを整えることが重要です。CI/CD 依存の固定化
GitHub Actions などの外部依存を SHA ピンや許可リストで管理します。ビルド環境を信頼できなければ、後段の成果物も信頼しにくくなります。SBOM 生成と保管
主要成果物から始め、CycloneDX または SPDX で部品表を出力します。提出先、保管先、脆弱性対応との接続を決めます。署名・来歴・検証の強制
cosign と SLSA provenance を使い、成果物の本物性と作成過程を説明できるようにします。最後はデプロイ時の検証ポリシーへ接続します。
この順序は、現場の負荷を抑えながら信頼の連鎖を太くする考え方です。
基本編6回の総括と次の一歩
DevOps 基本編では、文化、効果測定、CI/CD、IaC・コンテナ、可観測性、そして DevSecOps を扱ってきました。共通するテーマは、属人的な努力ではなく、チームが継続的に改善できる仕組みを作ることです。
DevSecOps も同じです。セキュリティ担当が最後に止めるのではなく、開発者が自然に安全な選択をできる CI/CD を設計します。SCA、SBOM、署名、来歴、シークレットスキャンは個別ツールではなく、信頼の連鎖を構成する部品です。
次の一歩としては、Kubernetes Admission で署名検証を強制する、SBOM と VEX を使って脆弱性対応の判断を改善する、SBOM 品質をメトリクス化する、といったテーマが候補になります。
DevSecOps の目的は、開発を遅くすることではありません。安全性を自動化し、証跡を残し、判断を速くすることです。サプライチェーン全体を「信頼の連鎖」として捉えることが、DevOps 推進担当に求められる次の視点です。