トリアージは不要になるのか

セキュリティ全体を改善できる点が一つあるとすれば、組織の足かせになるというイメージです。

このイメージの大きな原因の一つが「トリアージ」です。これは、セキュリティアラートが実際に組織に影響を及ぼしているかを検証し、想定される影響の大きさを見積もり、解決方法を考えるプロセスです。

この記事では、トリアージが組織のボトルネックにたちまち変わる理由を検討し、トリアージを省いて脆弱性の修正に注力することを目指すべき理由を説明します。

理想的なトリアージのワークフロー

新たなセキュリティ脆弱性のアラートを受け取ったとき、トリアージのワークフローがどのようなものになるか、想像してみましょう。

例として、最終的にEquifaxの事件で悪用された、Apache Strutsの最近のRCE（リモートコード実行）脆弱性を取り上げます。それほど大規模な企業がこの脆弱性にどう対処するか、想像してみてください。

• まず、セキュリティ担当者が脆弱性の存在を知らせるアラートを受け取ります。関連するメーリングリストに登録している、またはこの脆弱性を知らせるツールを使っている（そして、そのアラートにも目を通している）ことが前提です。

• 次に、セキュリティ担当者はエンジニアの一人に、社内の全アプリケーションのうちApache Strutsを使用しているものを一覧にしたレポートの作成を依頼します。これだけでも簡単ではありません。資産や構成の管理は非常に難しく、特に長年事業を続けている企業では大きな課題です。長年にわたり合併や買収を繰り返し、複数の技術スタックを使用するチームをいくつも抱えている企業では、さらに困難になります。それでも、Apache Strutsを使用するプロジェクトを100件特定できたとしましょう。

• 続いてセキュリティ担当者は、重要度を「クリティカル」としたJiraチケットを100件起票し、問題にすぐ対処するために全社総動員の方針を発動します。

• 組織のさまざまな部署にいる100人のエンジニアを特定し、この脆弱性の修正を割り当てる必要があります。

今度は、開発者の視点から考えてみましょう。おそらく開発者は、重要な機能の開発に取り組んでおり、事業上の大きな目標や期限に間に合わせるため、できるだけ早く仕上げたいと思っています。それでも、これは重要なセキュリティアラートなので、対処しなければなりません。必要な作業は次のとおりです。

• 該当する脆弱性について調べる。

• リモートコード実行や、脆弱性の種類そのものについて調べ、理解を深める。

• その脆弱性が自分のアプリケーションに影響するかを確認する。実際のエクスプロイトを探し、適用されるかどうかを確かめることもあります。

• この脆弱性を修正する方法を調べる。

• 修正を適用する。

• 脆弱性が取り除かれたことを確認する。

これは大変な作業で、その一部には高度なセキュリティの専門知識が必要です。社内のワークフローがどれほど複雑かによっては、トリアージ全体に数日、数週間、あるいは数か月かかることもあります。これは望ましいことではありません。

トリアージを支援するソフトウェアは作れるでしょうか？

おそらく可能です。コードの計測と機械学習を活用すれば、脆弱性を含むライブラリ内の脆弱なメソッドを使用するコードパスがあるかどうかを知らせるシステムを構築できます。正確に動作すれば（つまり、誤検知と見逃しが少なければ）、開発者が行うトリアージの作業をいくつか減らせるでしょう。しかし、たとえ脆弱性が現在の環境で悪用可能だと証明できたとしても、修正方法を考えるのは依然として開発者の仕事です。

さらに危険なのは、現在の状況では悪用につながるデータフローが存在しない可能性がある、とツールが示すケースです。このような場合、多くの組織はアラートを抑制したり無視したりします。そこに危険が潜んでいます。

今は脆弱なデータフローがないからといって、明日もそうだとは限りません。今日呼び出されていないメソッドが、次の開発者のコミット後に呼び出されるかもしれません。次の開発者には、使用しているライブラリに脆弱なメソッドが潜んでいることも、そのメソッドがこれまで呼び出されていなかったためにアラートが抑制されたことも、知るすべがないでしょう。今日そのメソッドが呼び出されていないという前提にセキュリティ体制を委ねるのは、無謀に近いと言えます。

全体を見渡せば、トリアージは脆弱性を修正するための前段階にすぎません。脆弱性の修正は難しく、大変な作業だと考えられているため、トリアージが行われます。しかし、トリアージを支援するソフトウェアを使うのではなく、そのプロセスを省略して、ソフトウェアで修正を自動化する方法はどうでしょうか？

Snykのアラートからプルリクエストを作成！

プロジェクトをSnykに追加すると、すべての依存関係を正確かつ継続的に把握できます。そのため、Apache StrutsのRCEのような重大な脆弱性が公表された際には、その存在をリアルタイムでお知らせできます。さらに重要なのは、どのアプリケーションがその脆弱性を含んでいるかを正確に特定できることです。Snykをソースコード管理ツール（Github、Gitlab、BitBucketなど）に接続すると、さらに一歩進んで、影響を受けるリポジトリに修正を含むプルリクエストを直接送信できます。

コードから脆弱性を取り除くために必要なのは、プルリクエストを承認することだけです。現在、データフローによってそのコードが実行されているかどうかにかかわらず、脆弱性を修正するのが正しい対応です。

トリアージのプロセス全体を、プルリクエストの「承認」ボタン一つで置き換えられるだけでなく、修正を実行するために組織内で必要なセキュリティの専門知識も減らせます。セキュリティをシンプルに、スピーディーに。それはとても魅力的です。