弊社では、オープンソースの脆弱性管理・コンプライアンス管理ツールであるMend SCA（旧WhiteSource）を販売しています。

今やOSSライセンスを使ったソフトウェア開発は90%以上とも言われている中で、これらの管理をスプレッドシートを使い手作業で確認をしている、あるいは他のツールを使用しているが壁に当たって考えている方々に是非こちらのブログをお読みいただき、Mend SCA(旧WhiteSource）に興味を持っていただけたらと思っています。

本ブログは2021年９月、WhiteSorce社（当時）に了承を得て翻訳をしたものになります。

今回は全6回のうち最終回、「アプリケーションセキュリティの"アラート疲れ"からの解放」というブログをご紹介します。

■さまざまな「アラート」共通するのは「被害を防ぐためにプロセスが自動化されていること」

医療機器、地下鉄の車両ドア、気象警報、重機、車の警報器、ソフトウェアのセキュリティアラート、これらはすべて、異常事態を通知してくれるので、被害を避けるために予防策を取ることができます。

病院のモニターは、投薬量の間違いや、心拍の乱れなど、さまざまな問題の検知に役立ち、命を救うことができます。
竜巻や台風が接近しているという気象警報も同じです。
ソフトウェアのセキュリティアラートは、命に直接かかわるわけではありませんが、リスクが存在する方向を示してくれます。

リスクはセキュリティアラート以外では検知されない程度のものかもしれませんが、侵害が発生すると組織に大きな影響を与えるかもしれません。
こうしたアラートに共通する点は、被害を防ぐためにプロセスが自動化されているということです。

自動化には、生活をより良く、より安全に、より簡単にしてくれる可能性があります。これが、自動アラートが作られた最初の理由です。

しかし、警告音があまりに頻繁に鳴ったらどうでしょうか。
何回も繰り返されたら、常に聞こえている雑音と同じように感じないでしょうか。

また、アラートの半数以上が誤報だったらどうでしょうか。
病院で敗血症の兆候を検知するために設置されているモニターを、いきなり消音にして無視すれば、患者を危険にさらすことになります。

アプリケーションのセキュリティアラートの場合は、膨大な量になるので本番稼働前にそのすべてを個別に対応することはほぼ不可能です。
とはいえ、そうしたアラートを無視すれば、被害のリスクを高めることになります。
多くの業界で、アラート疲れが深刻な問題と考えられているのは当然のことです。

■「アラート疲れ」の本当の意味

アラート疲れ（警告疲れ）とは、アラートの数があまりに膨大であるために、監視する人の感覚が麻痺した状態のことをいいます。
感覚が麻痺すると、アラートの見逃しや無視が起こり、結果的に対応が遅れる、あるいはまったく対応がないという事態が生じます。

アラート疲れはさまざまな業界に広がっていますが、アラート疲れが起きていると、自動アラートシステムは本来の役割を果たせなくなります。
自動アラートは、本来、潜在的な問題を、大きな被害をもたらす前に見つけ出して解決するものです。
生成されたアラートを管理し、修正を施すことが、重大な問題を防ぐための不可欠なステップです。

■「アラート疲れ」がアプリケーションセキュリティに与える影響

アプリケーションセキュリティの「アラート疲れ」とは、開発者やセキュリティ担当者が毎日受け取る大量のセキュリティアラートに圧倒されている状態のことをいいます。
アラートは、ソフトウェア開発ライフサイクル（SDLC）のあらゆる点で生成されます。
アプリケーションの事前構築されたコードベースのスキャンから、QA時、本番稼働時までさまざまです。

アラートの誤検知率が高いと、ノイズが大量になり、問題は悪化します。
アラートがあまりに大量で、誤検知が多く交じっていると、甚大な被害をもたらす可能性のある重大な脆弱性を特定することは極めて困難になります。

セキュリティアラートは、この5年間で倍以上に増えています。
こうした大量のアラートに優先度を付け、修正することが大きな課題となっています。

セキュリティチームの大半がアラート疲れを深刻な問題ととらえることは当然です。
アラート疲れは、組織のセキュリティ負債（未対応状態のセキュリティ脆弱性のことで、組織が悪質な攻撃に対して無防備になります）を膨らませています。

■検出に関する問題

長年、アプリケーションセキュリティテストは問題を検出することに力を入れてきました。
この問題検出から始めることは当然です。
結局、問題が存在していることがわからなければ、それを修正することはできません。

しかし、検出は、セキュリティ脆弱性への対処という点からいえば、最も重要なものではありません。
早期段階の検出は誤検知率が高く、大量のノイズを生成しますが、これでは、アラート疲れを助長します。

さらに、検出は単に問題を見つけるだけです。
問題の修正方法について具体的なデータを提供してはくれません。
セキュリティ脆弱性を解消する方法についてアドバイスがない状態で、アラートはさらにたまっていきます。
これも、アラート疲れを悪化させます。

アプリケーションセキュリティの技術が成熟するにつれて、誤検知の問題は当然解決されていくことでしょう。
実際、誤検知のアラートがないことを保証する技術も登場してきています。

しかし、誤検知ゼロを約束するソリューションでも、検出だけでは、やはり不十分です。
セキュリティ担当者は、毎日、膨大な量のアラートを扱っています。このアラートすべてについて修正を行うことは不可能です。

さらに、作成されるすべてのアラートが同じレベルというわけではありません。
すべてのアラートが、優先度が高い重大な脆弱性を示すわけではありません。

■アラートの優先順位付けと修正

検出すること自体が問題の一部であるなら、アプリケーションセキュリティに関する大量のアラートを扱うときに次のステップとして当然必要になるのが、アラートの優先度付けと修正です。
アラートは、対処しない限り、消えてはくれません。

セキュリティ担当者は、セキュリティ脆弱性の優先順位を決める方法を見つける必要があります。
リスクが最も大きい脆弱性、または影響が最も大きい脆弱性を特定し、そうした脆弱性の修正に最初に取り組みます。

このとき課題となるのが、脆弱性の優先順位付けについて絶対的といえるような基準がないことです。

アラートに付ける優先順位は組織によって異なります。
また、同じ組織でも、チームによって、優先順位を決めるまでの経路はさまざまです。

対処すべき重大なアラートを特定し、アラートの優先順位を決めたら、それに従ってセキュリティ脆弱性の修正作業を開始します。

どのセキュリティ脆弱性も修正することが最終目標ですが、修正までの道筋は常に明らかになっているわけではありません。
このため、何らかのソリューションを使って脆弱性を修正する方法を調べる必要があります。

また、アプリケーションを壊すことなく脆弱性に関する更新を行うことがどの程度可能かを知る必要もあります。

アプリケーションセキュリティのベストアプローチとしては、単なる検出機能ではなく、優先順位付けと修正の高度な機能に集中した成熟な機能を備えるソリューションです。

自動化を活用した脆弱性の修正を開始できれば、アラート疲れは解消されていくでしょう。

■アラート疲れを防ぐためにできること

アラート疲れの問題に対処するには、まず次のような点に取り組みます。

頻繁に発生して「ノイズ」となるアラートの量を減らすようにシステムを調整する。
誤検知ゼロを保証し、アラートの重大度や関連性がわかるようなコンテキストデータを提供できるセキュリティソリューションを探す。

■セキュリティアラートを「スヌーズ（無視）」しない

アプリケーションセキュリティでは「アラート疲れ」と呼ばれている問題ですが、「スヌーズ」ボタンを押して無視しても、問題は解消できません。

脆弱性の数が多過ぎて組織がすべてに対処できない状態になっていたとしても、自分の生活が振り回されないように、また自分のリスクが増えないように、アラート疲れに対処することができます。

仕事中にうたた寝してしまうことがないよう、手に入るテクノロジーを活用して、ノイズをフィルターで除去したり、セキュリティ脆弱性の優先順位付けや修正を楽にしたりする方法を検討してください。

本ブログは2021年9月2日に公開したものを2022年12月8日に再編集したものです。