脆弱性ゲートは実在した。ただし七つのうち一つのリポジトリしか守っていなかった

背景

スキャン定義は共有パイプラインテンプレートにあり、そのヘッダー自身に「全リポジトリがこれを取り込む」と書かれていた。七つのうち六つは一度も取り込んでおらず、テンプレートの一覧にはこのファイルの記載すらなかった——つまり書かれた記録のどこにも、イメージが走査されているという思い込みを否定するものがなかった。有効化してその重大さが判明する。九つのアプリケーションイメージすべてが、上流に修正版の存在する CRITICAL 脆弱性を抱えていた。いずれもアプリケーションの依存関係が原因ではない。ベースイメージに同梱され実行時には使われないパッケージマネージャ、小さなエージェントのビルドに使ったコンパイラのバージョン、開発ツールに同梱された事前ビルド済みバイナリ——出所はそこだった。

経路

症状

文書化された標準は「全リポジトリがイメージを走査する」と述べていた

仮説

標準が実態を記述していると想定

計測

標準と各パイプラインの実際の取り込み内容を突き合わせた

判断

先に原因を除去し、その後でゲートを有効化した

対応

ゲートを先に有効化することは意図的に避けた。全イメージに対する試験実行を、どのパイプラインも変更する前に計測した。すぐ有効化していれば五本のパイプラインが同一コミットで同時に赤くなり、「このゲートは回避すべき雑音だ」と学習させてしまうからである。まず原因を除いた——実行時に不要なパッケージマネージャを削除し、コンパイラを上げ、開発ツールを更新し、それぞれ再スキャンでゼロを確認した。そのうえで初めてゲートを組み込み、そこで初めて意味を持った。二件はどうしても修正できない。商用アプリケーションサーバーにベンダーが同梱するライブラリの内部にあるためだ。これらは閾値を緩めるのではなく、再確認の義務を伴う明示的な例外として記録した。文句を言うたびに緩められるゲートは、もはやゲートではない。

運用スキルの更新