コンテナの脆弱性は「ビルド時」に殺せ：CI/CDゲート制御の極意
やあ。今日もプロダクション環境のログを眺めていたが、相変わらず攻撃者は「設定ミス」という名の低木に火をつけようと躍起になっているよ。
君たちがせっせと書いたアプリケーションコードがどれほど堅牢でも、その土台となるコンテナイメージが「中身スカスカの脆弱性だらけ」だったらどうなるか？ 答えは簡単だ。攻撃者はアプリの脆弱性を探す手間さえ省き、コンテナ内の古いライブラリ（OpenSSLやglibcの古いバージョンなど）を突いて、一瞬でコンテナを脱出し、ホストOSを掌握する。
今日は、そんな「穴だらけのコンテナ」をCI/CDのパイプラインで物理的に排除する、実戦的なゲート制御の話をしよう。
—
1. なぜ「スキャン」だけでは不十分なのか？
多くのエンジニアが犯すミスは、「脆弱性を検知して満足する」ことだ。JenkinsやGitHub Actionsのログにズラリと並んだCVEリストを見て、「ふーん、結構あるね」で終わらせていないか？
セキュリティの現場では、「脆弱なイメージはビルドはできても、デプロイはさせない」という強固なゲートが必要だ。これを実装しない限り、開発者は忙しさに紛れて「緊急対応」のパッチを後回しにする。現場の泥臭い現実として、人間は「強制力」がないと動かない。
—
2. Trivyを使ったCI/CD統合（GitHub Actionsの実装例）
ここでは、業界標準となりつつある「Trivy」をGitHub Actionsに組み込み、重大な脆弱性（Critical）が見つかったらビルドを即座に停止する設定を教える。
実践：GitHub Actionsのワークフローファイル
以下の設定を `.github/workflows/docker-build.yml` に配置してくれ。
name: Secure Build Pipeline
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: リポジトリをチェックアウト
uses: actions/checkout@v3
- name: コンテナイメージをビルド
run: docker build -t my-app:${{ github.sha }} .
# ここが肝だ。Trivyで脆弱性をスキャンする
- name: Trivyによる脆弱性スキャン
uses: aquasecurity/trivy-action@master
with:
image-ref: ‘my-app:${{ github.sha }}’
format: ‘table’
# 重要: ‘CRITICAL’な脆弱性のみを判定基準にする
severity: ‘CRITICAL’
# EXIT_CODE 1 を返すことで、パイプラインを強制停止させる
exit-code: ‘1’
ignore-unfixed: true # パッチが存在しないものは除外（ノイズ軽減）
- name: レジストリへプッシュ
if: success() # 上記スキャンが成功（exit 0）した場合のみ実行
run: |
docker tag my-app:${{ github.sha }} my-registry.com/my-app:latest
docker push my-registry.com/my-app:latest
この実装のポイント
- `exit-code: ‘1’`: これが防波堤だ。これがないと、どれだけ脆弱性が出てもパイプラインは「成功」してしまう。
- `ignore-unfixed: true`: 現場での開発効率を考慮した設定だ。修正パッチがOSベンダーから出ていない脆弱性にリソースを割いても仕方ない。まずは「修正可能な重大リスク」を潰すことに集中しろ。
—
3. 攻撃者の視点：なぜ彼らは古いイメージを狙うのか？
攻撃者は `docker pull` で取得したイメージの中身を `trivy` や `grype` で静的解析し、CVE情報を元にエクスプロイトコード（PoC）を当てる。
例えば、古いDebianベースのイメージを使っていると、`CVE-2023-xxxx` のような既知の脆弱性が含まれている可能性が高い。攻撃者はこれを利用して、コンテナ内の特権昇格を行い、`containerd` の設定ミスを突いてホストOSへ侵入する。
「動くからいいや」という妥協は、攻撃者への招待状だ。
—
4. 運用上のTips：脆弱性とどう向き合うか
最後に、セキュリティチーフとしてのアドバイスだ。
1. ベースイメージを厳選せよ: `alpine` や `distroless` を使え。OSのパッケージマネージャが入っていないイメージは、攻撃者が攻撃の足がかりにするツール（`curl`, `wget`, `sh` 等）を配置できず、攻撃の成功率を劇的に下げる。
2. 定期的な自動再ビルド: 脆弱性は日々発見される。昨日まで安全だったイメージが、今日から危険になる。CIパイプラインを毎日cronで回し、最新のパッチを自動適用するフローを組め。
3. 例外管理のドキュメント化: どうしても修正できない脆弱性がある場合は、その理由とリスク許容の判断をチケット管理システムに残せ。これが後の監査で君を守る。
セキュリティは「ツールを入れたら終わり」ではない。「脆弱な状態を許さない文化」をパイプラインという物理的な制約として実装することこそが、世界最高峰のエンジニアが取るべきアプローチだ。
さあ、今すぐ君のCIパイプラインを確認してくれ。もし `exit-code` の設定が漏れていたら、それは今すぐ直すべき「最大の弱点」だ。健闘を祈る。
コメント