40 時間から 8 時間へ — AI 開発ライフサイクルにセキュリティを設計として組み込む
日本の自動車業界のお客様向け GenAI 開発プログラムで、デリバリー 1 サイクルあたりのセキュリティ工数を 約 40 時間から約 8 時間へ削減しました。数字は注目を集めるので、この記事はその出どころに費やします。 興味深いのは自動化の部分ではありません。
セキュリティを減らしたのではありません。より多く、より早く実施し、本当に高コストだったものへの 支払いをやめたのです。
先送りした判断のすべてがオプションではない
Gregor Hohpe の枠組みを私は繰り返し借用しています — アーキテクトはオプションを売る。 オプションとは「既知の価格で後から決める権利」であり、その権利には実際の価値があります。とくに 不確実性の高い局面では。
この枠組みは、デリバリーサイクルにおけるセキュリティの何が壊れているかを見るのにも最速です。
オプションが価値を保つのは、行使価格がほぼ固定されている場合だけです。価格が毎週上がる判断を先送り したなら、買ったのはオプションではありません。負債を背負ったのであり、返済はエンジニアの カレンダーで行われます。
サイクル末尾のセキュリティゲートがしているのはこれです。セキュリティ判断に対するオプションではありません。 初週にすでに、しかも粗く下されてしまった判断に対する、予定された利払いです。
32 時間はもともとセキュリティ作業ではなかった
デリバリーサイクルを計測して、セキュリティ工数がどこに消えているかを問う。答えが「セキュリティの分析」 であることはまずありません。
実際はこうです。レビュー枠を待つ時間。初めて見る人にアーキテクチャを再説明する時間。6 週間前の判断を、 理由が書き残されていないために再構成する時間。ビルドステップで検出できたはずの指摘を起票する時間。 深刻度の定義を事前に合意していないために深刻度を議論する時間。
このリストのすべてが、遅い発見に対する支払いです。分析は一つもありません。そしてすべてが、判断が 未決のまま置かれた期間に比例して増えます。
だから自動化は最初の手として間違っており、ほぼすべてのプログラムがその間違った手を打ちます。遅い発見の プロセスを自動化すれば、同じ手戻りに速く到達します。手戻りはボトルネックではありませんでした。 タイミングがボトルネックだったのです。
構築したもの
意図的に分離した 2 つの半分です。
プラットフォームに組み込まれたデフォルトのセキュリティ。 脅威モデリング、コードスキャン、脆弱性の 優先度付けを、最後のゲートではなく開発プロセスの一部として提供します。チームはプラットフォームを使う ことでこれらを得ます。依頼も日程調整も不要で、セキュリティエンジニアの名前を知る必要もありません。
これはお客様の既存のプラットフォームエンジニアリング施策の上に載せました。そして、それは私たちが設計した 何よりも重要でした。既にある道にセキュリティの車線を足したのです。その道がない場所ではこのやり方は失敗し、 正直な助言は「まず道を作りましょう」になります。
オンデマンドのセルフサービスセキュリティ。 カレンダーが空いたときではなく、チームが望んだときに 起動できるペネトレーションテスト。デフォルトより速く動きたいチームは、列に並ぶのではなく保証を 「買える」べきです。
分離は整理整頓のためではありません。デフォルトのセキュリティは全員のクリティカルパス上にあるので、 遅さとノイズで死にます。セルフサービスはオプトインなので、起動時の摩擦で死にます。これは所有者の異なる 別のエンジニアリング課題であり、両方に最適化した単一システムはどちらにも最適化されていません。
雰囲気ではなく決定論的なチェック
GenAI 固有の部分は、2 回実行しても同じ答えを返す信頼性チェックを作ることでした。
AI システムを AI システムで評価したくなる引力は強いものです — 別のモデルが出力の安全性を採点する。 探索段階では実際に有用です。統制ではありません。そして理由は精度ではありません。モデル採点のチェックは ルールより精度が高くても使えないことがあります。再現できず、差分が取れず、バージョン番号を打てないからです。
したがって、ブロックするものはすべて決定論的にしました。
- ツールのスコープは宣言されているか、そしてコードが到達できる範囲と一致しているか
- 認証情報は短命でタスクスコープか
- 認可したケーパビリティまで記録されたアクションログがあるか
- 取り消せないアクションに決定論的な承認経路があるか
どれも退屈で、検査可能な性質です。そして退屈さは妥協ではなく仕様です。退屈なものだけが、ビルド パイプライン、監査人、そしてチームの入れ替わりを生き延びます。
モデル採点による評価にも仕事はあります。助言し、探索し、人の注意を向ける候補を挙げる。ゲートは持ちません。
脅威モデリングはお客様の技術リードと
削減のもう半分は、お客様の技術リードと一緒に、その業界とプロジェクトに即したシナリオに対して実施した 脅威モデリング質問票から来ました。
分かりやすい効果は、脅威モデルの質が上がることです。システムを知っている人が列挙するからです。
実際に効いた効果はもっと静かでした。チームが自分たちのアーキテクチャを歩き、エージェントが到達できる 範囲を書き出したあと、セキュリティ要件は外部のものでなくなります。自分が特定した脅威への緩和策を 議論する人はいません。あの 32 時間の相当部分は議論であり、議論の多くは「指摘が外部からの判定として 届くこと」から生まれます。
一つだけ残せるなら残すのはここです。同時に、前払いコストが最も高く、しかも最も邪魔したくない人たちが 支払う部分でもあります。だから最初に削られます。
これで解決しないこと
自動チェックには必ず、発火したときに何が起きるかの担当者と、ゼロに到達する経路が必要です。
組織側で同じ教訓が、定常的な指摘対応ループを完全自動化する動機になりました。あのループは、判断を一切 含まない作業にシニアの時間を食っていました — まさに人のカレンダーに載るべきでない作業です。結果として 100 時間以上をお客様向けデリバリーに還元できましたが、それは残った判断に依然として名前が付いていたから です。
一般化された形と、壊れる条件
セキュリティ工数は、必要な分析量よりも「いつ判断が下されるか」の関数です。判断をまだ安い最も早い 時点へ動かし、ブロックするものは決定論的にし、システムを所有するチーム自身に脅威を列挙させる。
ただし成立には 3 つの条件が必要で、それなしにこの数字を約束することはしません。デフォルトを載せる プラットフォームが存在すること。デリバリーのリズムが「1 サイクル」という単位に意味を持つ程度に反復的 であること。そして経営層が、以降のサイクルを速くする対価として最初のサイクルの遅さを受け入れること — 私が最も頻繁に売り損なってきた取引です。
40 時間から 8 時間は本物の数字ですが、症状であって主題ではありません。原因は、セキュリティが独立した フェーズであることをやめ、その利息を請求しなくなったことです。