DevSecOps実践ガイド：CI/CDパイプラインにセキュリティを組み込む

COLUMN コラム

2026年02月19日
DevSecOps実践ガイド：CI/CDパイプラインにセキュリティを組み込む
- ＩＴ系

DevSecOpsとは何か

DevSecOpsは、DevOpsの実践にセキュリティを統合するアプローチです。従来、セキュリティテストはリリース直前に行われることが多く、脆弱性が発見されても修正のコストが高くなりがちでした。DevSecOpsでは「Shift Left」の原則に基づき、開発の初期段階からセキュリティを組み込みます。

重要なのは、セキュリティをゲートキーパー（門番）ではなく、開発者を支援するガードレールとして機能させることです。自動化されたセキュリティチェックを CI/CDパイプラインに統合し、開発速度を落とさずにセキュリティを確保します。

CI/CDパイプラインへの統合

GitHub Actionsを例に、セキュリティスキャンをパイプラインに組み込む方法を紹介します。

name: Security Pipeline
on: [push, pull_request]

jobs:
  sast:
    name: Static Analysis
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten

  dependency-check:
    name: Dependency Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Trivy
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          severity: CRITICAL,HIGH

  container-scan:
    name: Container Security
    runs-on: ubuntu-latest
    needs: [sast]
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:test .
      - name: Scan image
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:test
          severity: CRITICAL,HIGH

  secret-scan:
    name: Secret Detection
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2

このパイプラインでは、4つのセキュリティスキャンを実行しています。SAST（静的アプリケーションセキュリティテスト）にSemgrep、依存関係の脆弱性スキャンにTrivy、コンテナイメージのスキャンにもTrivy、シークレット検出にGitleaksを使用しています。

各スキャンの詳細と選定

SAST（静的解析）はソースコードを解析し、SQLインジェクション、XSS、パストラバーサルなどの脆弱性を検出します。Semgrepは軽量で高速であり、カスタムルールの作成も容易なため、近年人気が高まっています。

SCA（Software Composition Analysis）は、オープンソースの依存関係に含まれる既知の脆弱性を検出します。Log4j脆弱性（Log4Shell）のような事例が示すように、依存関係のセキュリティ管理は極めて重要です。

シークレット検出は、コードリポジトリにコミットされたAPIキー、パスワード、秘密鍵を検出します。一度コミットされた秘密情報はGitの履歴に残るため、事前の防止が最善の対策です。

運用上のポイント

全てのスキャン結果をブロッキング（パイプラインを停止する）にすると、開発チームのフラストレーションが溜まり、セキュリティチェック自体が回避されるリスクがあります。最初はCriticalとHighのみをブロッキングにし、MediumとLowはレポートのみにする段階的なアプローチが有効です。また、誤検知の管理も重要で、確認済みの誤検知は除外リストに登録してノイズを減らしましょう。