実践的AppSecシリーズの第1回では、開発者がAppSecを信頼しない理由、そしてその不信が、現実に検証可能な悪用可能性のある脆弱性ではなく理論上の脆弱性に焦点を当てるツールに根差していることについて話しました。
セキュリティアラートがエンジニアリングチームやセキュリティチームを苛立たせるときでさえ、彼らはCVEで埋め尽くされたダッシュボードに向き合い続け、すべてを緑にしようとしています。なぜでしょう？ ええ……もちろん、シフトレフトのせいです。
私たちは皆、アプリケーションセキュリティにおいてそれが正しいやり方だと知っています。なぜならコストを節約できるからです。セキュリティブログを読んでいれば、同じ数字を何度も目にしているはずです。ほぼすべてのセキュリティベンダーが「開発ライフサイクルの早い段階で脆弱性を修正すれば、後で修正するより最大100倍の節約になる」と言っています。ですが……本当にそうでしょうか？
「シフトレフト」は不確かな土台の上に成り立っている
OWASP創設者のMark Curpheyは今年初め、もてはやされてきた「100倍」統計が単なる「都市伝説」にすぎないことを示す説得力のある証拠を提示しました。出典はIBMの社内トレーニングマニュアルで、そこに使われたデータは、遅くとも1981年に収集されたものに基づいていました。その間にソフトウェア開発は大きく変わりました（いくつか思い当たることは確かにあります）が、この統計はしぶとく残り続けています。おそらく、シフトレフト製品を売る多くのベンダーにとって、ROI計算機に使うのに都合がよかったからでしょう。
最近の研究によれば、シフトレフトは実際にはお金も労力もまったく節約できない可能性があります。2016年の論文で、3人の研究者が「遅延問題効果（delayed issue effect）」――開発サイクルの後半で見つかった問題ほど解決により多くの労力が必要になる――の証拠を探しました。
チームは「遅延問題効果の証拠は見つからなかった」とし、それは「特定の種類のプロジェクトで断続的に起こるにすぎない歴史的遺物」だと結論づけました。
常識や都市伝説に頼らず、アプリケーションセキュリティを考え直してみたらどうでしょう？ 今日の組織が直面している問題や状況に対して、実際に何が最も有効かを考えてみたらどうでしょう？
ここで少し、開発の領域を離れて――キッチンへと向かう思考実験をしてみましょう。
ピーナッツバターの瓶：思考実験
あなたは友人のために料理をしています。そして彼がピーナッツアレルギーだと知っています。あなたは気の利く友人です（そして夜の終わりをアナフィラキシーで締めくくりたくもない）から、料理にピーナッツは一切使いません。念のため、使うものはすべてラベルも確認します。
友人がやって来ると、彼は新しいものを持っていると言います――あなたが作った食事を食べても安全かどうか判定できる検知器です。彼が検知器の電源を入れると、赤く点滅します。「大丈夫」と彼は言います。「帰り道で何か買っていくよ」
「ちょっと待って」とあなたは言います。「私は食事のどこにもピーナッツが入らないように本当に気をつけたの。キッチン中を探してもいいよ」
そこで二人で本当に探し回り、1時間後に見つけます。棚の奥にある、小さくて未開封のピーナッツバターの瓶です。「これは使ってない！ まだ封が切られてない！」とあなたは言います。
友人は言います。「これは、使われているかどうかではなく、建物内にピーナッツを含む製品が存在するかどうかを検知するように作られてるんだ。ピーナッツバターを家の外に出すまで点滅は止まらないよ」
瓶を外で処分して戻ってくると、あなたは苛立ちをほとんど隠せません。友人は、そのスキャナーにあまり自信がないと打ち明けます。「実は、これまで『安全に食べられる』って判定された家をまだ見つけたことがないんだ」と彼は惨めそうに言います。「それにアパートなんて、もう無理だよ」
さらに悪いことに、彼はどこへ行っても、戸棚を探して回ったり、本当に食べるのを避けるべきタイミングと大丈夫なタイミングを見極めようとしたりするのに時間を費やしています。温かい食事を食べる余裕はまったくありませんし、友人の中には、毎回大変だからという理由で彼の訪問自体を避けている人もいるようだと言います。
ピーナッツスキャナーの何が筋が通っていないのかは明らかですよね？
本当に重要なのは、実際に皿に盛られて口に入るものです。建物全体をスキャンする必要はありません。提供する準備ができた皿だけを分析し、理論上のリスクではなく実際のリスクにスキャンを限定したほうがよいでしょう。
キッチンからスクラムへ移っても、この教訓は当てはまります。マニフェストファイルから想定しうる脆弱性をすべてスキャンし――脆弱なライブラリが実際にロードされているか、動作しているか、あるいは脆弱な関数が呼び出されているかをほとんど考慮しないまま――進めれば、多くの無駄な時間とフラストレーションを生むことになります。
真のリスクは実行中のアプリケーションから生まれる
結局のところ、マニフェストファイルに基づくスキャンは、最初からピーナッツスキャナーのようなものだったのです。ですが、「シフトレフト」が金銭的にも労力的にも節約になっておらず、過度に広範なスキャンツールがチーム間の不信を生んでいるのだとしたら、代替案は何でしょう？
キッチンで重要なのは、提供されるものです。ソフトウェアで重要なのは、アプリケーション実行時にロードされ、動作し、アクセスされるものです。
アプリケーションセキュリティベンダーは何十年もの間、「100倍」統計を用いて「シフトレフト」を売ってきました。その間にオープンソース利用（そしてCVE件数）は爆発的に増え、ほぼすべての組織が開発プロセスの早い段階で脆弱性を検出するための何らかのツールを導入しました。
しかし、TVミニシリーズ『チェルノブイリ』でValery Legasovが言ったように、「私たちがつく嘘はすべて、真実に対する負債を生む。遅かれ早かれ、その負債は支払われる」
.avif)
嘘について真であることは、業界の基盤となる神話についても同じだ。
SDLCのより早い段階にセキュリティを押し込むことの利点について、誰も意図的に嘘をついたわけではないとしても、今日のAppSecプログラムにおける苛立ち、無駄な労力、無駄な時間はすべて、「シフトレフト」という基盤神話に対して支払われている負債なのです。
しかし新しい時代がやって来ています。組織が無駄のない実践的なAppSecソリューションを求める中で、本当に悪用可能なものを見極める唯一の方法は、アプリケーションが動いている最中に確認することだと学びつつあります。
実行中のアプリケーションをスキャンするほうが、マニフェストファイルの内容をスキャンするよりも焦点が絞れて効率的だとしたら、なぜ誰もがすでにそれをやっていないのでしょうか？ そして、そのような可視性を持つソリューションは、AppSecプログラムのために他に何ができるのでしょうか？
続きは次回：このブログシリーズ最終回――実践的AppSec（後編その2）「Oligoが実際のリスクにフォーカスし続ける方法」で、これらの問いへの答えをお話しします。
