この記事は株式会社うるる（ULURU）Advent Calendar 2024の18日目の記事です。
DevSecOpsについて基礎知識的なところと、これまでの私自身の開発・運用経験を踏まえた見解を書いてみたいと思います。

DevSecOpsとは

DevOps開発手法に セキュリティに関する対応(Sec) をプラスした開発手法のこと。

ここでいう「セキュリティに関する対応」が指すものは、「脆弱性¹」への対応です。

DevOpsにおけるCI/CDパイプラインの一環にセキュリティ対策サービスやツールを組み込み、セキュリティ対策を自動的かつ継続的に実施することで、システムのセキュリティを安定的に確保する開発手法、ということになります。

参照元：DevSecOpsGuideline

なぜDecSecOpsが必要となるのか

開発の早い段階からセキュリティを組み込み、シフトレフト（開発の前段階でのセキュリティ対策）することで 手戻りリスク（コスト）を最小限に抑える ため、です。

セキュリティ対策が大事ということは多くのエンジニアが重々承知、ではあるものの現実的にはその対策は「後回し」にされることが多いではないでしょうか（※個人の見解です）。

ウォーターフォール開発
　- セキュリティ検査の工程がプログラム開発・試験終了後など後半の工程（総合試験的なポジション）で行われることが多い
　- 脆弱性が検知された場合、開発工程に戻して対応するため手戻り（かつスケジュール的な影響）も大きい
　
アジャイル開発
　- 機能単位の設計・実装・デプロイを繰り返すという性質上、セキュリティ検査の工程が入りづらい
　- スピード感重視のため「一旦リリースして後（≒運用）で対応しよう」となりがち

どちらの開発手法にも共通して言えることは、
開発工程においてセキュリティ対応が自動的、かつ継続的に実施出来ていない
点にあり、結果として対応が後手になり、その分リスクが大きくなってしまうわけです。

DevSecOpsと従来のセキュリティ対応の違い

項目	従来	DevSecOps
タイミング	最終工程でのみ実施	開発プロセス全体で実施
アプローチ	手動チェック中心	自動化ツールとシフトレフト
責任者	特定チームのみ	開発＋運用全員で対応

DevSecOpsでどんな試験（解析）ができる？

CI/CDパイプラインに組み込みできる試験（解析）はいろいろな種類がありますが、従来手動で行われていた脆弱性試験の代替となり得る試験方法を3つご紹介します。

動的解析(DAST)

Dynamic Application Security Testingの略。
アプリケーションを実行した状態で、それに対して擬似攻撃を行い脆弱性を検出する方法です。実際の悪意を持った攻撃者からのアタックに近いテストで、内部の仕組みを考慮しないブラックボックス状態のまま行われることが特徴です。

CI/CDパイプラインに組み込めるDASTツール

・OWASP ZAP
・Burp Suite

DASTで検出される代表的な脆弱性：
SQLインジェクション
XSS（クロスサイトスクリプティング）

DASTは使い方を誤ると大きな事故につながります
・他社のサービスやアプリに向けての利用は絶対にNG
・自社（自分）のものであっても、外部サービスと連携している場合は影響が及ばないようにクローズドな環境を準備するなどの対応を要検討

静的解析(SAST)

Static Application Security Testingの略。
ソースコードを解析してセキュリティ脆弱性を検出する方法です。アプリケーションを稼働させる前にテストが可能なため、開発の初期段階からセキュリティリスクを特定できることが特徴です。

CI/CDパイプラインに組み込めるSASTツール

・SonarQube
・Semgrep

SASTで検出される代表的な脆弱性：
ハードコーディングされた認証情報
入力値の検証不足
エラーハンドリングの不備

ソフトウェア構成分析（SCA）

Software Composition Analysisの略。
ソフトウェアに含まれるオープンソースコンポーネントやサードパーティライブラリを解析し、ライセンスリスクやセキュリティ脆弱性を特定する手法です。CI/CDパイプラインに専用のツールを組み込むことで依存関係を管理し、脆弱性やライセンス違反などのリスクを把握することができます。またソフトウェアの部品表（SBOM²）を作成し、依存関係やバージョンを可視化することもできます。

CI/CDパイプラインに組み込めるSCAツール

・Aqua Trivy
・Dependabot

SCAで検出可能な脆弱性：
npm・yarn・pip等で導入したパッケージの脆弱性情報（その脆弱性がFixされたバージョンも教えてくれる）

DevSecOps導入のガイドライン

DevSecOpsを導入してみよう！という方のためにガイドラインも整備されています。

OWASP³が提唱するDevSecOpsガイドライン（日本語訳）です。

DesSecOpsパイプラインごとに適用可能なツールも公開されています。
なお本記事であげた SCA や SAST はCIのパイプラインに、DAST はCDのパイプラインに組み込むことが想定されていることがわかります。

Introduction to the OWASP DevSecOps Guideline

導入において迷った時にはこのガイドラインを参考にするのが良さそうです。

DevSecOpsのメリット・デメリット

新しい仕組みを導入するときにはメリットだけではなく、デメリットにもしっかりと目を向ける必要があります。DevSecOpsという仕組みを導入することが目的ではありませんので、自身の組織・チーム状態に合わせた運用を考えつつ、導入後もPDCAを回して運用改善を続けていく必要があります。

メリット
　- 開発初期からセキュリティテストを実施することで脆弱性の早期発見が可能
　- 修正コストの削減と後工程での大幅な手戻りを防止
　- 都度発生していた手動のセキュリティテストにかかる時間を削減
　- 運用フェーズも継続することでシステムやコードに潜む脆弱性も検知可能
　
デメリット
　- 初期導入においてツールの選定・導入費用や、チームのトレーニングコストが必要
　- CI/CDパイプラインが複雑になってしまう
　- セキュリティと提供スピードのトレードオフ（継続的なバランス調整が必要）

終わりに

DevOps が DevSecOps になったということは、そう遠くない未来にさらに新しい言葉が加わるのでしょうか…？少し目を離すと置いて行かれてしまう世界ですが、頑張って追いついていきたいと思います🙋

明日は、許斐さん(@heromoon9218)の記事です！
最後までご覧いただき、ありがとうございました🙇

脆弱性とは（国民のためのサイバーセキュリティサイト）
コンピュータのOSやソフトウェアにおいて、プログラムの不具合や設計上のミスが原因となって発生するサイバーセキュリティ上の欠陥のこと ↩
SBOM（Software Bill of Materials）
ソフトウェアに含まれるすべてのコンポーネントや依存関係をリスト化した「ソフトウェアの部品表」のこと ↩
OWASP(Open Web Application Security Project）
ウェブアプリケーションのセキュリティに関するオープンソースのプロジェクト（コミュニティ） ↩