DevSecOpsの基本

この章では、DevSecOpsの基本的な考え方と、代表的なセキュリティ検知手法であるSAST・SCA・DASTについて学びます。これにより、Shift Leftの考え方と各検知手法の位置づけが理解できます。

1. 本章の概要

1.1 本章の目的

セキュリティをリリース直前にまとめて確認する運用では、問題が見つかった時点で大きな手戻りが発生し、そのままリリース遅延や「先送り」につながります。DevSecOpsは、セキュリティを開発プロセスの中に組み込んで常時動かし続ける考え方で、以降のハンズオンで扱う各種セキュリティ検知の前提知識になります。

1.2 本章で学ぶ内容

DevSecOpsの目的とShift Leftの考え方を扱います。あわせて、代表的なセキュリティ検知手法であるSAST・SCA・DASTがそれぞれ何を検知する手法で、どんな攻撃・リスクから守ってくれるのかを整理します。

2. DevSecOpsとは

DevSecOpsは、DevOpsの開発・運用プロセスにセキュリティを組み込み、開発スピードを落とさずに安全なシステムを継続的に届ける考え方です。「Dev（開発）」「Sec（セキュリティ）」「Ops（運用）」を融合させたところから命名されています。

従来、セキュリティはリリース直前にまとめてチェックする「最終関門」として扱われがちでした。しかしこの方法では、問題が見つかった時点で大幅な手戻りが発生し、結果的にリリースが遅れたり、致命的な問題でなければ「次のバージョンで直そう」と先送りされたりしがちです。DevSecOpsはこの状況を変え、セキュリティを開発プロセスの一部として常時動かし続けることで、安全性とスピードを両立させます。

2.1 Shift Leftの考え方

DevSecOpsの中核となるのが Shift Left（シフトレフト）という考え方です。これは、セキュリティ検証を開発プロセスのできるだけ早い段階に持ってくるという方針です。開発フローを左から右に並べたときに、セキュリティチェックの位置を左側、つまりコーディング段階に近づけていくイメージから「Shift Left」と呼ばれます。

早い段階で問題を検知すればするほど、修正コストは小さく済みます。実装中であれば数分で直せる問題が、リリース直前に見つかればリリースが遅延し、本番運用後に発覚すればインシデント対応・顧客対応・サービス停止を含む大きなコストになります。問題は早ければ早いほど安く直せる——これがShift Leftが重視される理由です。

2.2 CI/CDパイプラインへの組み込み

Shift Leftを実現する最も自然な場所が、CI/CDパイプラインです。CI/CDはコードの変更があるたびに自動で動く仕組みなので、ここにセキュリティ検知を組み込めば、毎回同じ基準でチェックが走り、人手によるチェック漏れや基準のブレを防げます。

DevSecOpsではこのCI/CDパイプラインに、これから紹介するSAST・SCA・DASTを中心とした検知の仕組みを組み込み、コードの変更からデプロイ後の運用までを多層的にカバーします。3つの手法は、それぞれ「コードを読む」「依存関係を読む」「実際に攻撃してみる」という違ったアプローチで脆弱性を見つけ出すため、互いに補完し合う関係にあります。

対象と方式の違いを整理すると、以下のような関係になります。

flowchart LR
    A[ソースコード] -->|コードパターンを静的解析| SAST
    B[依存パッケージ] -->|既知脆弱性DBと照合| SCA
    C[動作中のアプリケーション] -->|攻撃ペイロードを送信| DAST
    SAST --> P[CI/CDパイプライン]
    SCA --> P
    DAST --> P

3. SASTの概要

SAST（Static Application Security Testing、静的アプリケーションセキュリティテスト）は、アプリケーションのソースコードを実行せずに静的に解析し、コードに含まれるセキュリティ上の問題を検出する手法です。

Pythonで静的解析をしようで扱った flake8 や mypy も静的解析の一種ですが、これらはコードの品質や型の正しさを見るのが主な目的です。SASTはそれと並ぶ位置づけで、セキュリティ観点に特化した静的解析を指します。

3.1 何を検知するのか

SASTツールはソースコードをスキャンし、脆弱性につながるコードパターンを見つけ出します。たとえばPythonの場合、ユーザ入力を文字列結合でSQL文に組み込んでいるコード、eval() や exec() のように任意のコードを実行できる関数の利用、ハードコードされたAPIキーなどがあれば、それらをすべて検出して警告します。

これらは実際にアプリケーションを動かさなくても、コードを読むだけで判断できる問題です。SASTはこの「コードを読めば分かる脆弱性」を、機械的かつ網羅的に拾い上げる役割を担います。

3.2 守れる攻撃・リスク

SASTで検出・防止できる攻撃やリスクは多岐にわたります。代表的な例として以下のようなものが挙げられますが、実際のSASTツールにはこれら以外にも数百〜数千のルールが組み込まれており、ここに挙げたのはあくまで一例です。

3.3 代表的なツール

実務でよく使われるSASTツールには以下があります。

汎用性の高い Semgrep や CodeQL をGitHub Actionsから動作させることで、プルリクエストごとにSASTを実行する運用が可能です。

4. SCAの概要

SCA（Software Composition Analysis、ソフトウェア構成分析）は、アプリケーションが利用している外部の依存パッケージ・ライブラリに既知の脆弱性が含まれていないかを検出する手法です。

現代のアプリケーションは、自分で書いたコードよりも外部ライブラリのコード量のほうが圧倒的に多いのが普通です。たとえば数千行規模のFastAPIアプリケーションでも、依存しているOSSライブラリの総行数は数百万行にのぼります。外部ライブラリに脆弱性があれば、自分のコードがどれだけ正しくてもアプリケーション全体が脆弱になってしまうため、SCAはこのリスクを継続的に検知するための仕組みです。

4.1 何を検知するのか

SCAツールは、requirements.txt や package.json などの依存定義ファイルから、アプリケーションが使っているパッケージとそのバージョンの一覧を取得し、既知の脆弱性データベースと突き合わせます。データベースには CVE（共通脆弱性識別子）、GitHub Advisory Database、PyPA Advisory Database などが使われ、該当するバージョンが見つかれば、脆弱性ID・深刻度・修正済みバージョンとともにレポートされます。

たとえば requests==2.25.0 というバージョンが脆弱性データベースに登録されていれば、SCAツールは「このバージョンには CVE-XXXX-YYYY という脆弱性がある。2.31.0 以降にアップデートを推奨」のように、具体的な対応策まで提示してくれます。

4.2 守れる攻撃・リスク

SCAで防げるのは、依存ライブラリ経由で受ける攻撃やリスク全般です。代表的な例として以下のようなものが挙げられますが、これら以外にも数多くの脆弱性パターンがCVEとして日々登録されており、ここに挙げたのはあくまで一例です。

4.3 代表的なツール

CIによるマージ前チェックとしての Trivy と、自動修正PRを作る Dependabot を組み合わせることで、二層での脆弱性管理が実現できます。

5. DASTの概要

DAST（Dynamic Application Security Testing、動的アプリケーションセキュリティテスト）は、動作中のアプリケーションに対して実際にリクエストを送り、攻撃を試みることで脆弱性を検出する手法です。

SASTとSCAが「コードや依存関係を読んで」脆弱性を見つけるのに対し、DASTは「動いているアプリケーションを外から実際に攻撃してみる」アプローチです。攻撃者と同じ視点で、稼働中のシステムが実行時にどう振る舞うかを確かめます。

5.1 何を検知するのか

DASTツールは、対象アプリケーションのURLにアクセスし、画面遷移やAPIエンドポイントを自動で巡回しながら、各エンドポイントに対して脆弱性を狙った攻撃ペイロードを順番に送り込みます。たとえばログインフォームに ' OR '1'='1 のような文字列を送ってSQLインジェクションが成立しないか、検索パラメータに <script>alert(1)</script> を送ってXSSが反応しないか、といった具合です。

返ってきたレスポンスを解析し、攻撃が通った気配があれば「このURLのこのパラメータに脆弱性がある」というレポートを出します。実際の攻撃を再現するため、コードを読むだけでは分からない問題まで検出できるのが特徴です。

5.2 守れる攻撃・リスク

DASTで検出できるのは、実行時にしか現れない脆弱性全般です。代表的な例として以下のようなものが挙げられますが、ツールごとにさらに多くのルールが用意されており、ここに挙げたのはあくまで一例です。

5.3 代表的なツール

OWASP ZAP をGitHub Actionsから動作させることで、ステージング相当の環境に対して動的な検知を実行できます。なお、DASTは実際に攻撃ペイロードを送り込むため、本番環境で実行するとデータ破壊やサービス障害の原因になります。必ずステージング環境や検証用環境で実施することが前提となる手法です。

6. その他の施策例

DevSecOpsを支える手法は、SAST・SCA・DASTの3つだけではありません。コードリポジトリ・インフラ定義・コンテナイメージ・運用中のリソースといった、それぞれの領域に特化した仕組みを組み合わせることで、開発から運用までの全工程で脆弱性を検知できる体制になります。本節では、本講座の後続講座で扱う代表的な施策を概要レベルで紹介します。

6.1 Secret Scanning

Secret Scanning は、ソースコードリポジトリの中に APIキー・パスワード・接続文字列などの機密情報 が含まれていないかを検出する仕組みです。AKIA で始まるAWS Access Key ID、ghp_ で始まるGitHub Personal Access Token のように、各クラウド・SaaSプロバイダが発行する認証情報には固有のフォーマットがあるため、それらを正規表現で検出します。

防げるのは、機密情報のリポジトリ流出による不正アクセスです。とくにパブリックリポジトリでは、Pushした瞬間に世界中のクローラに拾われる可能性があり、被害が一瞬で広がります。

GitHub特有の機能 として、GitHub Secret Scanning（GitHubがリポジトリ全体を継続的にスキャンしてアラートを出す機能）と Push Protection（GitHubが機密情報を含むコミットのPush自体をブロックする機能）の2つを組み合わせることで、GITHUB_TOKENの権限最小化や使用Actionの制限といった他のセキュリティ設定とあわせて、CI/CDパイプラインを堅牢化できます。GitHub以外のリポジトリホスティングを使う場合は、汎用ツールである gitleaks や TruffleHog をCIに組み込むのが代替手段になります。

6.2 IaC Scanning

IaC Scanning は、TerraformやCloudFormationなどのインフラコードを解析し、設定上の不備を検出する仕組みです。

防げるのは、インフラ設定の不備による情報漏洩・不正アクセスです。S3バケットがパブリック公開になっている、セキュリティグループが 0.0.0.0/0 からのSSHを許可している、IAMポリシーで * を許可しているといった問題は、人の目によるレビューでは見落としやすい領域ですが、Checkov や Trivy などのIaCスキャナを使えば機械的に漏れなく検知できます。

Checkov や tfsec をGitHub Actionsから動作させることで、TerraformコードのIaC ScanningをCI/CDパイプラインに組み込めます。

6.3 コンテナイメージスキャン

コンテナイメージスキャン は、Dockerコンテナイメージに含まれるOSパッケージや言語ランタイムの既知脆弱性を検出する仕組みです。

防げるのは、ベースイメージや同梱パッケージ経由の脆弱性悪用です。python:3.13-slim のようなベースイメージにはOSパッケージが多数含まれており、これらに既知の脆弱性があるとコンテナ全体が脆弱になります。Amazon ECRのEnhanced scanning（Amazon Inspector連携）や Trivy などを使い、ビルド直後とレジストリPush後の両方でスキャンするのが一般的な運用です。

CI側で Trivy による事前検知を行ったうえでECRにPushし、Push後は Amazon ECR Enhanced scanning が継続的にスキャンするという二層構成で、コンテナイメージの脆弱性を管理できます。

6.4 コンピュートリソースの脆弱性管理

CI/CDで防ぎきれない脆弱性、たとえば運用中に新たに公表されたCVEは、Amazon Inspector のような稼働中リソースの脆弱性管理サービスで継続的に監視します。Inspectorは EC2・Lambda・ECRイメージを定期的にスキャンし、新しい脆弱性が公表された時点で「現在使っているこのバージョンが該当する」と通知してくれるため、デプロイ後も含めた継続的な脆弱性管理が実現できます。

Amazon Inspector で EC2 / Lambda の脆弱性スキャンを有効化することで、検知から修正・再スキャンまでの継続的な運用フローが実現できます。

6.5 AIによる統合セキュリティレビュー

近年は AIエージェント を活用したセキュリティレビューが実用段階に入ってきました。SAST・SCA・DASTのような個別ツールがそれぞれの観点で機械的に検知するのに対し、AIエージェントは設計書・コード・稼働中のアプリケーションを横断した文脈を理解した上でレビューできるのが大きな特徴です。

主なメリットは以下のとおりです。

• 設計レビュー・コードレビュー・ペネトレーションテストといった、本来は別々のツール・別々の担当者で行っていた工程を、1つのコンテキストで連続実施できる
• 「なぜ問題なのか」「どう直すべきか」を、コードや設計の意図に沿った自然言語で提示してくれる
• 単独ツールでは見えにくい攻撃チェーン（設計上の不備＋コードの脆弱性＋設定ミスの組み合わせなど）を、設計からコード、稼働環境まで横断して複数情報源を統合し発見できる
• 検知に留まらず、修正コードのPRを自動作成してくれるツールもあり、対応まで含めて自動化できる

代表的なツールに、AWSが提供する AWS Security Agent があります。AWS環境向けに最適化されており、上記の3つのレビュー（設計・コード・ペネトレーションテスト）を1サービスで統合的に実施できます。

本講座のハンズオンAWS Security AgentでAIによる統合セキュリティレビューを体験しようでは、この AWS Security Agent を実際に使い、設計レビュー・コードレビュー・ペネトレーションテストの3つを同じアプリケーションに対して連続して実施する流れを体験します。

7. まとめ

この章では、DevSecOpsの基本的な考え方と、代表的なセキュリティ検知手法について学びました。

• DevSecOpsは、開発・運用プロセスにセキュリティを組み込み、Shift Leftの考え方で早期に脆弱性を検出・修正する考え方である
• SASTは、ソースコードを静的に解析し、SQLインジェクション・XSS・ハードコードされた認証情報など、コード自体に潜む脆弱性を検出する手法である
• SCAは、依存パッケージのバージョンを既知脆弱性データベースと突き合わせ、ライブラリ経由の攻撃やサプライチェーン攻撃を防ぐ手法である
• DASTは、動作中のアプリケーションに実際に攻撃を仕掛け、認証・認可不備や設定ミスなど実行時にしか現れない脆弱性を検出する手法である
• Secret Scanning・IaC Scanning・コンテナイメージスキャン・稼働中リソースの脆弱性管理・AI統合レビューなどを組み合わせることで、開発から運用までを多層的にカバーできる

次の章では、SASTツール Semgrep をGitHub Actionsに組み込む流れをハンズオン形式で体験します。