跳到主要内容

DevSecOpsと静的セキュリティスキャン

DevSecOpsの核心は、「シフトレフト」アプローチにあります。これは、開発ライフサイクルの早い段階でセキュリティ上の問題を検出し、修正することを意味します。本ドキュメントでは、モダンな静的解析ツール（特にIaCスキャン）と、それらをCI/CDパイプラインに効果的に統合するためのベストプラクティスについて解説します。

モダンな静的セキュリティスキャンツール​

静的解析には大きく分けて、アプリケーションコードを解析するSAST (Static Application Security Testing) と、インフラコードを解析する IaC Security Scanning があります。

1. Infrastructure as Code (IaC) セキュリティ​

クラウドインフラ定義（Terraform, Kubernetes manifest, ARM/Bicep, CloudFormationなど）の設定ミスを防ぐためのツールです。

  • Checkov:
    • 特徴: Palo Alto Networks (旧 Bridgecrew) が開発。Terraform, CloudFormation, Kubernetes, Dockerfile, Serverless Frameworkなど幅広いフォーマットに対応。
    • 強み: ポリシーが豊富で、グラフベースのスキャンにより複雑な依存関係も解析可能。Pythonベースで拡張しやすい。
  • Trivy:
    • 特徴: Aqua Securityが開発。コンテナイメージのスキャンから始まり、現在はIaC、ファイルシステム、AWSアカウント設定まで幅広く対応するオールインワンツール。
    • 強み: 高速で、導入が容易。CI/CDだけでなくローカルでの使い勝手も良い。
  • tfsec (現在はTrivyに統合):
    • 特徴: Terraform特化の軽量スキャナ。現在はTrivyの一部として機能しているが、スタンドアロンとしても引き続き利用されることが多い。
  • KICS (Keep Infrastructure as Code Secure):
    • 特徴: Checkmarxが開発。2000以上のクエリを持ち、対応プラットフォームが非常に広い。

2. Static Application Security Testing (SAST)​

ソースコード自体の脆弱性を検出するツールです。

  • SonarQube:
    • 特徴: コード品質とセキュリティの業界標準。静的解析だけでなく、コードカバレッジや複雑度の計測も可能。
  • CodeQL:
    • 特徴: GitHubが提供。コードをデータベース化し、クエリを実行して脆弱性を発見する。GitHub Advanced Securityの中核。
  • Semgrep:
    • 特徴: 構文（AST）を意識したgrepツール。カスタムルールの作成が非常に容易で、軽量かつ高速。

3. シークレットスキャン​

コード内にハードコードされたAPIキーやパスワードを検出します。

  • GitGuardian: 公開リポジトリの監視に強み。
  • TruffleHog: リポジトリのコミット履歴全体をスキャン可能。

CI/CDへの統合ベストプラクティス​

ツールを単に導入するだけでなく、開発フローに適切に組み込むことが重要です。

1. 多層的な防御 (Layered Defense)​

一つのポイントですべてを防ごうとせず、複数の段階でチェックを行います。

  1. IDE / ローカルフック (Pre-commit):

    • 目的: コミット前に開発者自身が気付くこと。
    • ツール: VS Code拡張機能 (Checkov, SonarLint)、pre-commit フレームワーク。
    • 効果: フィードバックループが最も短く、修正コストが低い。

  2. Pull Request (PR) チェック:

    • 目的: マージされるコードがポリシーに準拠しているか、レビューアが確認するため。
    • 動作: PR作成・更新時にスキャンを実行し、失敗した場合はPRへのコメント投稿やマージブロックを行う。
    • 重要: **SARIF (Static Analysis Results Interchange Format)**形式でレポートを出力し、GitHub Securityタブなどに統合すると視認性が高まる。

  3. 定期スキャン (Nightly Build):

    • 目的: 新たに発見された脆弱性（CVE）への対応や、長時間かかる詳細なスキャンの実行。

2. ブロッキングとノンブロッキングの使い分け​

  • Blocking (Soft Fail / Hard Fail):
    • 明らかに危険な設定（例: S3バケットのパブリック公開、ハードコードされたシークレット）はエラーとしてビルドを落とす。
    • Checkovでは --soft-fail オプションを使わず、特定の重大度（Severity）以上をエラーにする運用が一般的。
  • Non-Blocking (Warning):
    • ベストプラクティスからの逸脱や、修正の優先度が低いものは警告にとどめ、開発スピードを阻害しないようにする。

3. ポリシーのコード化 (Policy as Code)​

セキュリティルールをドキュメントではなく、コード（OPA/Regoなど）として管理します。CheckovはPythonやYAMLでカスタムポリシーを定義できます。これにより、組織固有のルール（例: 特定のタグ付け必須、特定リージョンのみ使用可）を強制できます。

実装例: GitHub Actions + Checkov​

TerraformコードをPR時にスキャンし、結果をPRコメントおよびSecurityタブに表示する例です。

name: Checkov IaC Scan

on:
  pull_request:
    branches: [ main ]

jobs:
  checkov-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Run Checkov action
        id: checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: ./terraform
          # HIGHとCRITICALのみで失敗させる
          soft_fail: false
          framework: terraform
          output_format: cli,sarif
          output_file_path: console,results.sarif

      # 結果をGitHub Securityタブにアップロード
      - name: Upload SARIF file
        if: success() || failure()
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: results.sarif

まとめ​

DevSecOpsの実践において、CheckovやTrivyのようなツールは強力な味方になります。しかし、ツールを入れることがゴールではありません。「開発者がストレスなくセキュリティチェックを行える環境」を作ることが、安全なソフトウェア開発の持続可能性につながります。まずはローカルやCIでの警告表示から始め、徐々にブロッキングルールを厳格化していく段階的な導入をお勧めします。