AppScan: サードパーティ・コンポーネント・セキュリティ: 良いこともあれば、そうでないこともあるし、ひどいこともある。

2020/7/20 - 読み終える時間: 2 分

サードパーティーのコンポーネントが入っていないソフトウェアが今どきあるでしょうか。開発する側として、サードパーティーの安全性をどうやって担保すればよいのでしょうか。「サードパーティー製だったので気づきませんでした」は言い訳にならないでしょう。開発の利便性が高まる一方で、セキュリティー対策、特にサードパーティーコンポーネントに関することがますます重要になってきています。今回は Third-Party Component Security: The Good, The Not So Good and the Downright Ugly の翻訳版を掲載します。

サードパーティ・コンポーネント・セキュリティ。良いこともあれば、そうでないこともあるし、ひどいこともある。

2020年7月16日

著者: Shahar Sperling / Chief Architect at HCL AppScan

サードパーティのコンポーネント、特にオープンソースは、現代の開発努力として欠かせないものです。これらのコンポーネントは開発を加速させ、チームがコア技術のコード開発に集中できるようにしてくれます。

それはそれで良いことでしょう。

サードパーティ製コンポーネントを採用する際の課題は、コンポーネントの動作やセキュリティの問題も取り込まれることです。

挙動上の問題は通常、すぐに発見されます：コンポーネントの機能が使用されるにつれて、障害や予期せぬ結果が発見されます。挙動上の問題は、OO コミュニティによって回避したり、報告したり修正したりすることができます。

セキュリティの問題は発見しにくい

しかし、セキュリティ問題の場合はもう少し複雑です。なぜなら、セキュリティ問題を発見するのは予想外の使用方法であり、ほとんどの開発チームはセキュリティ上の欠陥を発見するために必要な固有のスキルを持っていないからです。脆弱性は、アプリケーションによって使用される機能に発生する可能性があります。しかし、多くの脆弱性は、コンポーネントによって公開されているが、アプリケーションによって使用されていない機能に悪用される可能性があります。このため、リモートの攻撃者によって悪用される可能性のあるコンポーネントが Web アプリケーションやモバイルアプリケーションで使用されている場合、脆弱性は特に危険なものとなります。

これはあまり良くないですね。マズいことです。

サードパーティ製のコンポーネントに脆弱性が確認されると、アップデートがリリースされます。これは完全に標準化されており、期待されていることです。しかし、あるコンポーネントがアップデートを提供したからといって、そのコンポーネントを使用するすべてのアプリケーションでアップデートが行われたとは限りません。

これは、物事が悪いだけではなく、醜いものになってしまうところです。サードパーティのコンポーネントのパッチが適用されていないことが原因で、ヘッドラインに載りたい人はいないでしょう。

チームは喜んでサードパーティ製の、ほとんどがオープンソースのコンポーネントを採用しますが、コンポーネントの迅速なアップデートには備えていません。私たちは自分のコードにコンポーネントを入れても、それを忘れてしまう傾向があります。結局のところ、自分のところで書いたコードには注意は払われるけれど、サードパーティ製のコンポーネントを採用している、ということで、サードパーティ製のコンポーネントについて関心が払われていないのが実際ではないでしょうか。

サードパーティ製のコンポーネントに対処しなかった場合の現実的な結果

数年前、世界は Equifax の大規模な侵害とその後の余波にさらされました。2017年5月から7月にかけてサードパーティ製のコンポーネントに悪用された脆弱性は、早くも2017年3月に報告されていますが、Equifax 内ではすぐに対処されていませんでした。

迅速なアップデートに備えることは重要ですが、迅速なアップデートは本質的に緊急性が高く未知の要素であるため、通常のプロトコルの一部として無視されがちです。ほとんどのチームにとって、深刻な脆弱性が原因で初めて更新を余儀なくされた場合、それはパニック状態の緊急事態になりますが、本来は日常的な準備訓練の一環であるはずです。

訓練の実行を恐れる必要はありません。訓練を実施する理由は準備を整えるためです。訓練を実施することで、緊急アップグレードが発生したときに、より良い対応をするためのスキルや考え方を身につけることができます。開発者が、自前のコードとサードパーティコードの間のすべてのインターフェイスと依存関係を理解していることを確認してください。これらの依存関係をチェックするためのテスト環境を準備しておけば、変更が必要になったときに、迅速かつ自信を持って変更を行うことができます。

アプリケーションが危険にさらされているかどうかは、どのようにして見分けることができるのでしょうか？

これで、サードパーティ製コンポーネントのセキュリティに関する一つの課題が解決されました。しかし、そもそもセキュリティ問題を特定することについてはどうでしょうか？アプリケーションが危険にさらされていることを知っていますか？そして、それらの兆候を可能な限り迅速に得るにはどうすればよいでしょうか？

動的解析には、長い間、公表されているサードパーティの脆弱性を特定するテストがありました。これらのテストは、ベンダによって公開された CVE を識別するテストエクスプロイトを実行するために、動的解析 (DAST) 技術を使用しています。しかし、脆弱性のためのエクスプロイトを作成するには長い時間がかかるかもしれません。しかし、ハッカーが先にエクスプロイトを作成するまで待ちたくはないでしょう。

HCL AppScan on Cloud (ASoC) では、ASoC Open Source Analyzer (OSA) を作成しました。OSAは、ASoCの静的解析ツールを活用して、プロジェクトが依存しているすべてのサードパーティ製コンポーネントのシグネチャを生成します。これらのシグネチャは ASoC サービスにアップロードされます。OSAはアプリケーション内の特定の暴露を示すのではなく、コンポーネントが脆弱性を持っており、何に対して脆弱であるかを示します。

それがどのように役立つのでしょうか。サードパーティのオープンソース・コンポーネントの新バージョンがリリースされると、ライブラリのシグネチャが作成され、保存されます。コンポーネントに対する脆弱性が報告されると、OSAは即座に認識し、その脆弱性はコンポーネントのシグネチャに関連付けられます。静的解析またはオープンソース解析がビルドパイプラインに統合され、スキャンが継続的に実行されている場合、コンポーネントとその特定のバージョンが脆弱であることを示すゼロデイ表示が表示されます。これは、エクスプロイトがまだ利用できない場合でも発生します。これにより、ハッカーを先回りしてアプリケーションが安全であることを確認することができます。

最近まで、OSA は静的解析スキャンの一部としてしか利用できませんでした。AppScan on Cloud では、OSA のみのスキャンを作成できるようになりました。これにより、オープンソースのスキャンを実行する際の応答時間がさらに向上します。アプリケーションが安全であることを確認しながら、開発を加速することができます。また、誤った理由でヘッドラインに載ることもありません。

これは良い状況です。

詳細

HCL AppScan on Cloudをご自身でテストドライブするには、今すぐ30日間の無料トライアルに登録してください。