ビルドが通れば即リリース、という運用が引き起こす障害コストは、セキュリティスキャンの導入コストをはるかに上回る。参考記事が示す「コンパイルして祈る」というアンチパターンは、SRE視点では「SLO違反の温床をパイプラインに放置している」状態と読み替えられます。
SAST・DASTのフェーズ分離がオブザーバビリティを高める
SAST（Static Application Security Testing）はコードを実行せずにソースを解析し、SQL Injectionのハードコード、平文パスワード、非安全な暗号関数の使用などを検出します。SonarQube・Semgrep・CodeQLが代表的なツールです。一方、DAST（Dynamic Application Security Testing）はアプリケーションを実際に動かした状態でHTTPリクエストを投げ、XSS・CSRF・認証不備を発見します。OWASP ZAPやBurp Suiteが広く使われます。
SREの観点で重要なのは、この2種類のツールが「いつ・どの環境で動くか」という設計です。参考記事が提示するパイプライン構造は次のようになっています。
フェーズ1: Commit/PR → SAST + シークレットスキャン
フェーズ2: Build → SCA（依存関係の脆弱性検査）
フェーズ3: Staging Deploy → DAST + E2Eテスト
フェーズ4: Quality Gate → ブロック判定
フェーズ5: 本番 → RASP / WAFDASTをステージング環境でのみ実行するという設計は、インフラ運用上の副次効果をもたらします。本番トラフィックを誤って攻撃スキャンの対象にしてしまうリスクが排除されるため、エラーレートのアラートが誤検知を含まなくなります。Prometheusなどでエラー率をSLIとして計測している場合、スキャン起因のノイズが混入するとエラーバジェットを不当に消費します。フェーズ分離はオブザーバビリティの精度を保護する設計でもあります。
IaCとの統合でセキュリティゲートをコード化する
CI/CDパイプラインをTerraformやPulumiで管理している場合、SASTとDASTのフェーズをインフラの定義と同じリポジトリで宣言できます。GitHub ActionsやGitLab CIのジョブ定義として書けば、パイプライン自体がバージョン管理されたドキュメントになります。
# GitHub Actions での SAST 組み込み例（概念）
jobs:
sast:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Semgrep
uses: semgrep/semgrep-action@v1
with:
config: p/owasp-top-ten
dast:
needs: staging-deploy
runs-on: ubuntu-latest
steps:
- name: OWASP ZAP Baseline Scan
uses: zaproxy/[email protected]
with:
target: 'https://staging.example.com'この構成では、Qualityゲートの判定基準もコードで管理できます。SonarQube CloudはQuality Gateを設定ファイルで定義でき、「Critical以上の脆弱性が1件でも存在すればブランチのマージをブロックする」といったルールを宣言的に書けます。
SCA（Software Composition Analysis）はSASTの一形態で、npm・PyPI・Mavenなどのパッケージが持つCVEを検出します。SnykやDependabotをビルドフェーズに組み込むと、ライブラリ更新のPRが自動生成され、既知脆弱性の滞留期間を短縮できます。この滞留期間はMTTR（平均修復時間）の構成要素であり、SRE的にはSLOの補助指標として追跡する対象です。
障害対応の仕組み化としてのセキュリティパイプライン
セキュリティスキャンをパイプラインに埋め込む最大の意義は、障害対応をリアクティブからプロアクティブへ転換することです。参考記事が描く「月30%成長のスタートアップ」のような環境では、リリース頻度が高いほど未検査のコードが本番に届くリスクも線形に増加します。
SREが設計するインシデントレスポンスの文脈では、セキュリティ脆弱性に起因するインシデントは通常のサービス障害より検出が遅れます。エラーレートやレイテンシのスパイクとして現れず、データ漏洩や認証バイパスは長期間潜伏することがあります。SASTがコミット時点で脆弱なパターンを検出する仕組みは、この「潜伏期間」を設計の段階で短縮する手段です。
また、パイプラインのスキャン結果はオブザーバビリティの一環として集約できます。SonarQubeのAPIから脆弱性件数をPrometheusのメトリクスとして取り込み、Grafanaダッシュボードで可視化するアーキテクチャは、セキュリティ状態をSLI/SLOと並べて議論できる土台を作ります。
SASTのインクリメンタルスキャンは差分コードのみを対象にするため、実行時間は数秒から数分程度に収まります。DASTの完全スキャンは数十分かかることもありますが、ステージングへのデプロイ後に非同期で走らせれば、開発者の待機時間には影響しません。スキャン結果はSlackやPagerDutyへの通知として組み込み、発見された脆弱性をインシデントチケットと同じワークフローで追跡することで、修正の抜け漏れを防げます。
セキュリティとSLOが同じダッシュボードに並ぶとき、信頼性の議論は初めて完結する形を持ちます。