オープンソースの脆弱性がEquifaxを襲った。どうすれば身を守れるのか？

大手信用情報会社のEquifaxは先週、1億4,300万人の極めて個人的なデータが流出する侵害を受けたと公表し、原因は広く使われているJavaライブラリ、Apache Strutsの脆弱性だったと明らかにしました。同社は攻撃への対応を誤り、データの安全を守る責任はEquifaxにあります。しかし、Strutsやその他のオープンソースライブラリの脆弱性にさらされているのは、同社だけでは決してありません。

Equifaxへの侵入には、悪用が非常に容易な昨年3月に公表されたリモートコード実行（RCE）の脆弱性か、ほぼ同じくらい深刻な先週公表された新たなRCEの脆弱性が利用された可能性があります。これらの問題は比較的大きく報じられたにもかかわらず、該当パッケージを利用する側の対応は非常に遅れています。

GitHub上でStrutsを直接必要とするオープンソースプロジェクトを約1,000件調査したところ、その64%が3月に公表された深刻な脆弱性を依然として抱えていました。先週公表された脆弱性については、ほぼすべてのプロジェクトが影響を受けます。また、Snykがテストした数千件のJavaプロジェクトを個別に調べると、初回スキャン時に78%が3月のRCEの影響を受け、100%が先週の問題の影響を受けていました（その後、ユーザーにこれらの問題を通知し、修正を支援しました）。

これらの脆弱性によるリスクは机上の空論ではありません。現実に、差し迫った脅威となっています。Strutsの3月のRCEが公表されて以降、既知で悪用も容易なこのセキュリティホールを利用した攻撃が、実環境で多数確認され、増加しています。同様に、先週公表された脆弱性も大規模な攻撃の波を引き起こしています。

責任は誰にあるのでしょうか？

侵害が起きると、関係者が互いに責任を押し付け合うことがよくあります。残念ながら、オープンソースのセキュリティに関する責任の所在は複雑な問題です……

今回の場合、Apache Strutsを非難するのは簡単です。

過去10年間に、Apache Strutsでは40件を超える脆弱性が公表されました。その中には、先ほど触れたRCEのような深刻なものも含まれています。これを見て、Strutsは安全でないライブラリだと思うかもしれませんが、実際はまったく違います。開発チームは発見された問題に迅速かつ責任を持って対応し、多くのオープンソースプロジェクトとは異なり、古く、保守も十分でないバージョンにも重要な修正を適用してきました。ApacheはEquifaxのインシデントについてもよく書かれた声明を公開しています。

次に責任を問われるのは、侵害されたポータルを開発したEquifaxの開発者です。

開発者は、既知の脆弱性がないか確認せず、継続的な監視も行わないまま、サードパーティのオープンソースライブラリを採用し、その結果、深刻な事態を招きました。確かに、セキュアなソフトウェアを構築することは開発者の責務の一部であり、開発者にも責任があります。しかし、開発者はセキュリティの専門家ではなく、オープンソースライブラリを使うリスクを認識していない人も多いことを忘れてはいけません。さらに、Equifaxのような大企業では、開発者が「枠にとらわれずに考え」、明示的に依頼された範囲を超えて責任を持つことが認められていない場合もよくあります。

形式上の責任を考えれば、非はEquifaxのセキュリティチームにあるということになります。

システムを安全に保つ役割を正式に担っているのはセキュリティチームであり、それに失敗したのは明らかです。セキュリティチームに落ち度があったことは間違いありませんが、私がこれまで見てきた他の企業と同様、Equifaxのセキュリティチームも、会社のアプリケーションを安全に保つための体制が整っていなかった可能性があります。セキュリティチームは開発者の100分の1の人数しかいないことも多く、オープンソースライブラリの活用によってさらに加速する、現代のソフトウェア開発のペースには到底追いつけません。セキュリティ運用の責任をセキュリティチームだけに負わせれば、大規模な侵害はほぼ避けられません。

そして、最後に責任を負うべきなのが、この事態を招いたEquifaxの経営陣です。

経営陣は、私たちの個人データを道義的にも法的にも預かる立場にあり、利益や成長を犠牲にしてでも、データ保護にどれだけ投資するかを決めます。また、セキュリティを一部のチームだけの課題にせず、会社全体で重視するようにする責任もあります。さらに、オープンソースライブラリのような現代的な開発手法を使えば新たなリスクも伴い、そのリスクを適切に管理しなければならないと理解することも、経営陣の役目です。経営陣の責任について、私から付け加えることはありません。ただし、どんな組織も絶対に安全とは言えず、失敗したからといって必ずしも過失や無能さを意味するわけではありません。

次のEquifaxにならないために

責任の所在を追及するのではなく、セキュリティ侵害の殿堂入りを避けるために、会社をどう守るか考えてみましょう。今すぐ、そして継続的に自社を守るためにできることをいくつか紹介します。

1. テストを実施する。Apache StrutsのRCEを含む、脆弱なオープンソースライブラリを検出するオープンソースセキュリティツールでアプリケーションをスキャンし、すべてのアプリをテストしましょう。

2. 見つかった問題を修正する。目隠しを外して脆弱なライブラリを把握することは、必要な第一歩です。しかし、見つかった問題を修正しなければ、依然として脆弱なままです。脆弱性を問題として記録するだけで終わらせず、修正しましょう。

3. 使用しているライブラリの脆弱性を監視する。今、脆弱なライブラリをテストするのは大切ですが、Strutsでつい先日起きたように、新たな脆弱性は明日にも発見される可能性があります。新たに公表された脆弱性の通知を受け取り、攻撃者に悪用される前に修正できる体制を整えましょう。

4. 開発者が使えるセキュリティツールを見つける。セキュリティチームの人員には限りがあり、開発者がツールに求めるものはセキュリティ担当者とは異なります。開発者が使いたくなるセキュリティツールを見つけ、開発チームに使ってもらいましょう。DevOpsで実現したように、より多くの人がセキュリティの責任を担う必要があります（これはDevSecOpsと呼ばれることもあります）。

どこから始めればよいかわからない場合は、SnykのCLIまたはGitHub連携を使ってスキャンしてみましょう。Snykを勧めるのは当然ながら偏りがあるかもしれませんが、少なくともSnykの無料プランなら、アプリ内の問題を検出し、修正への一歩を踏み出せます。Snykを使いたくない場合は、別のツールを見つけてください。いずれにせよ、問題が手に負えなくなる前に対処しましょう。

これはStrutsだけの問題ではない

Lastly, it’s worth noting this is not a problem limited to Struts, nor the Java Maven system. In the last month alone, an Arbitrary Code Execution vulnerability in the popular Node.js npm package pg was disclosed, as well as a Cross-Site Scripting vulnerability in the Python framework django.

その前の月には、人気のJavaベースのビッグデータプラットフォームSpark CoreのXSSが公表され、npmレジストリでは数十件の悪意あるパッケージが見つかりました。今年初めに実施された調査によると、ウェブサイトの77%がホームページで脆弱なJSライブラリを使用しています。

統計はほかにも次々と出てきます。要するに、オープンソースライブラリの脆弱性を追跡して修正することは、今やどの組織にも欠かせません。真に対処する唯一の方法は、開発プロセスに組み込むことです。取り組み方についてアドバイスが必要なら、メールでお問い合わせください。始めるお手伝いをします。何をするにしても、Equifaxの過ちから学び、問題を放置しないでください。