ゼロから12か月で DevSecOps を

何が問題だったのか

劇的なことは何もありませんでした。それが要点です。セキュリティは各リリースの最後に手作業で確認されていました。指摘はコードが完成してから届くので、リリースは待たされ、同じ手戻りがスプリントごとに繰り返されました。遅れは目に見える部分にすぎません。その下では、監査指摘が積み上がり、古いコードは誰も時間を割けない負債を抱え、サードパーティの部品は確認されないまま本番に入り、小さなセキュリティチームはいつも後手に回っていました。全員が自分の仕事をしていました。仕事が、間違った場所にあったのです。

何をしたのか

道具ではなく、人から始めました。ある役員が変化のスポンサーになることに同意し、DevSecOps フォーラムが集まり始め、各開発チームがセキュリティチャンピオン、つまり問いを双方向に運ぶ人を一人ずつ決めました。そのあとでようやくロードマップを描きました。ガイドライン、標準、パイプラインに差し込む道具を、OWASP DevSecOps Maturity Model で測ります。目標は単純でした。12か月以内にすべてでレベル2、最も重要な2つの領域、ビルドとデプロイ、テストと検証でレベル3。

1年を4つの段階に切り、それぞれに通過しなければ出られない関門を置きました。最初の3か月は基盤。評価、ポリシー、1〜2本のパイロットアプリでのコードと依存関係の検査。それ以上はしません。3〜6か月は自動化。ポリシーゲート、シークレット検査、動的テスト。6〜12か月は拡大。新しいチームが最初から安全に始められるパイプラインのテンプレート、インフラとコンテナの検査。12か月を過ぎると最適化が来ます。これは終わりません。実行時の監視と、四半期ごとに数字を見ること。

ライフサイクルのすべての工程に対策がつきました。計画で脅威モデリング。コーディングでシークレット検査。ビルドでコード、依存関係、部品表の検査。テストで動的テスト。リリースで署名付き成果物とポリシーゲート。デプロイでシークレット保管庫を伴うインフラとコンテナの検査。運用で監視。そして持ち主のいない道具は朽ちるので、ポリシー、パイプライン運用、修正、トリアージの責任の決まりを RACI として書き直し、NIST SSDF、OWASP SAMM、ISO/IEC 27001:2022 に対応づけました。監査人が求める証拠が、自然に積み上がるように。

何が変わったのか

セキュリティは出来事であることをやめ、習慣になりました。習慣が続いているかは4つの数字が語ります。それぞれ最初の段階で基準値を取りました。重大な欠陥をどれだけ早く直すか、本番前に見つかる指摘の割合、安全なパイプラインを通るアプリの数、リリースにかかる時間。どの対策もまず試行し、次に自動化し、チームが信頼してからようやくリリースの関門にしました。この順番が、こうしたプログラムを沈める二つのリスク、開発者の抵抗とアラート疲れが、根を張るのを防ぎました。