「シフトレフト・セキュリティ」はほぼすべてのDevSecOpsのピッチ資料に登場しますが、多くのチームでは実質的にたった一つのことしか意味していません——パイプラインにスキャナーを追加しただけで、誰もその結果を読んでいない、という状態です。本当のシフトレフト・セキュリティが変えるのは、ツールをどこで実行するかではなく、問題がいつ発見され、誰がそれを修正する責任を持つかです。
修正コストが最も低い場所にチェックを配置する
プルリクエストの段階で見つかった脆弱性なら、開発者が数分で対応できます。同じ脆弱性が本番環境で見つかれば、インシデント対応、パッチのサイクル、そして多くの場合、顧客との会話が必要になります。最も早く成果につながるパイプラインの段階は、すべてのコミットに対する依存関係とシークレットのスキャン、すべてのプルリクエストに対するSAST、そして`terraform apply`の前のIaC（Infrastructure as Code）スキャンです。これらが網羅的だからではなく、最もコストの低いポイントで最大量の問題を検出できるからです。
ポリシーゲートは「危険なもの」を止めるべきであり、「うるさいもの」を止めるべきではない
セキュリティゲートを無効化させる最も確実な方法は、それをうるさくすることです。悪用可能なクリティカルなCVEでビルドを失敗させるゲートは信頼を勝ち取ります。一方、推移的依存関係にある中程度の深刻度の指摘すべてでビルドを失敗させるゲートは、チームにセキュリティの警告を読まずにクリックして通過する習慣を教え込んでしまいます。私たちは深刻度のしきい値を意図的に調整し、ブロックラインを下回るものはビルド失敗ではなく、トリアージ用のダッシュボードに回します。
セキュリティは共有された責任であり、別チームのゲートではない
これをうまくやっているチームは、事後にコードをレビューするセキュリティチームを持っているわけではありません。そのチェックがなぜ存在するのかを理解しているエンジニアたちがいるのです。それは、そのチェックが彼らに課されたものではなく、彼らと一緒に設計されたものだからです。つまり、エンジニアリングをポリシーの実施だけでなく、その策定にも巻き込み、ツールの出力に単なるCVE番号ではなく、明確で実行可能な修正ガイダンスを含めるということです。
活動ではなく成果を測る
実行されたスキャンの回数は虚栄の指標（vanity metric）です。本当に重要なのは、クリティカルな指摘を修正するまでの平均時間、マージ前とデプロイ後のどちらで発見された指摘の割合か、そしてそのトレンドがリリースを重ねるごとに改善しているかどうかです。指標がスキャンの成功しか示していないなら、それはツールを測っているのであって、セキュリティ態勢を測っているわけではありません。
正しく実践されたシフトレフト・セキュリティは、チームを遅くするものではありません。むしろ、本番インシデントの火消しという、はるかにコストの高い遅延を取り除くものです。パイプラインのパターン自体はシンプルです。難しく、そして価値があるのは、エンジニアが実際にゲートを信頼できるだけのシグナル対ノイズ比を維持し続ける規律のほうです。