IT 技書の森

シフトレフトセキュリティ

セキュリティ対策を開発ライフサイクルの早い段階 (左側) に組み込むアプローチ

セキュリティDevOps

シフトレフトセキュリティとは

シフトレフトセキュリティは、セキュリティ対策を開発ライフサイクルの後工程 (デプロイ後の脆弱性スキャン) ではなく、早い段階 (設計、コーディング、CI) に組み込むアプローチである。「左」は開発タイムラインの早い段階を指す。

IBM の Systems Sciences Institute の調査によると、本番環境で発見されたバグの修正コストは、設計段階で発見した場合の 6 倍、要件定義段階の 100 倍になる。セキュリティの脆弱性も同様で、早期発見が修正コストを劇的に下げる。

従来:  設計 → 実装 → テスト → デプロイ → [セキュリティ監査]
                                            ↑ 発見が遅い、修正コスト大

シフトレフト: [脅威モデリング] → [SAST] → [SCA] → テスト → デプロイ
              ↑ 早期発見、修正コスト小

各段階でのセキュリティ施策

段階 施策 内容 ツール例
設計 脅威モデリング 攻撃者の視点でシステムの脅威を洗い出す STRIDE
コーディング IDE プラグイン コード記述中にリアルタイムで脆弱性を検出 ESLint security rules
プリコミット シークレットスキャン コミット前に API キーやパスワードの混入を検出 git-secrets
CI SAST (静的解析) ソースコードの脆弱性パターンを検出 Semgrep, CodeQL
CI SCA (依存関係) npm パッケージの既知の脆弱性を検出 npm audit, Snyk
CI IaC スキャン CloudFormation テンプレートの設定ミスを検出 cfn-lint, Checkov
デプロイ コンテナスキャン コンテナイメージの脆弱性を検出 Trivy, ECR スキャン

SAST と SCA の違い

混同されやすいが、検査対象が異なる。

種類 検査対象 検出する問題 例
SAST 自分が書いたコード SQL インジェクション、XSS、ハードコードされた認証情報 query("SELECT * FROM users WHERE id = " + userId)
SCA 依存ライブラリ 既知の CVE (脆弱性) lodash 4.17.20 の Prototype Pollution

両方を CI に組み込むことで、自前のコードと依存ライブラリの両方をカバーする。

CI パイプラインへの組み込み

# GitHub Actions の例
- name: npm audit
  run: npm audit --audit-level=high  # High 以上でビルド失敗

- name: SAST
  uses: returntocorp/semgrep-action@v1
  with:
    config: p/owasp-top-ten

- name: IaC scan
  run: npx cfn-lint template.yaml

全ての警告をブロッカーにすると開発速度が低下する。実務では以下の段階的な運用が現実的だ。

重大度 CI での扱い 理由
Critical ビルド失敗 (ブロック) リモートコード実行など即座に悪用される
High ビルド失敗 (ブロック) データ漏洩のリスクが高い
Medium 警告 (ノンブロック) 悪用条件が限定的
Low レポートのみ 情報提供レベル

SAM / CloudFormation でのシフトレフト

IaC のセキュリティスキャンは、インフラの設定ミスを本番デプロイ前に検出する。

  • S3 バケットのパブリックアクセスが有効になっていないか
  • Lambda 関数に過剰な IAM 権限が付与されていないか
  • DynamoDB テーブルの暗号化が有効になっているか
  • API Gateway に認証が設定されているか
# cfn-lint でテンプレートの構文・ベストプラクティスをチェック
cfn-lint template.yaml

# Checkov で IaC のセキュリティポリシーをチェック
checkov -f template.yaml

よくある失敗パターン

ツールを入れただけで満足する

SAST ツールを CI に組み込んでも、検出結果を誰も確認しなければ意味がない。検出された脆弱性のトリアージと修正のプロセスを定義し、担当者を明確にする。

偽陽性の放置

SAST は偽陽性 (実際には脆弱性でない検出) が多い。偽陽性を放置すると、開発者が警告を無視する習慣がつき、本物の脆弱性も見逃す。偽陽性は明示的に抑制 (// nosemgrep) し、その理由をコメントに残す。

基礎から学ぶなら関連書籍が手がかりになる。

関連用語