脆弱性は、露出していてもいなくても危険

イラスト：Lou Reade

裏庭に池があり、木製の桟橋が架かっていると想像してください。ある日、桟橋を歩いていると、板にひびが入っていることに気づきました。今にも割れそうです。修理するか、しばらくそのままにして後で対処するか、判断を迫られます。桟橋を使うのが自分だけなら、それほど大きな問題ではないかもしれません。板が壊れていることは分かっているので、気をつけて歩けます（覚えていればの話ですが）。でも、家族はどうでしょう？遊びに来る友人は？全員に伝えたとしても、みんなが覚えている保証はありません。いずれ誰かがその板を踏み、望まぬ水浴びをすることになります。たった一人、たった一歩で十分なのです。ライブラリに既知の脆弱性があっても、対象のサイトやアプリケーションで特定のメソッド呼び出しを使っていなければ、その脆弱性は露出していない場合があります。この場合、その脆弱性を無視しても仕方ないと思うかもしれません。現在のシステムには影響しないからです。しかし、重要なのは「現在」という言葉です。脆弱性は、たいてい分かりやすいものではありません。脆弱なメソッドに「安全ではありません。使用禁止」といった名前が付いているわけではないのです。脆弱性はたいてい巧妙に潜んでいます。設定を一つ変更するだけ、何気ないメソッドを一つ呼び出すだけで、安全な状態から脆弱な状態へと変わってしまいます。脆弱性が今日露出しているかどうかは重要ですが、考えられているほど大きな意味を持つわけではありません。優先順位を決める要素にはなり得ます。対処すべき脆弱性が二つあり、一方は露出していて、もう一方は露出していない場合は、露出しているほうを優先します。それでも、露出していない脆弱性にも速やかに対処することが不可欠です。対処するまでは、アプリケーションの弱点であり、鎧の隙間です。開発者がコードを一か所変更するだけで、悪用可能な状態になってしまいます。レジリエンスは重要です。露出していないものの未対処の脆弱性は、システムを不必要にもろくします。セキュリティ対策の多くは、攻撃者がシステムを攻撃するさまざまな手口に、防御側が追いつこうとする受け身の対応です。アプリケーション内でまだ露出していない既知の脆弱性を、放置してはいけません。むしろ、問題が起きる前に対策を講じ、システムを堅牢にするための貴重な機会です。サイトやアプリケーションを守るうえで数多くの課題に直面するなか、構築するもののセキュリティを先回りして確保できる機会は、逃さず活用すべきです。