組織がオープンソースセキュリティの課題解決にSnykを信頼する理由

オープンソースエコシステムの脆弱性を調査・分析し、オープンソースのセキュリティを確保する専任の自社セキュリティチームの役割を定義し、説明するのは簡単ではありません。「Snykのセキュリティチームは何をしているの？」という比較的シンプルな質問に、簡潔に答えるのも難しいものです。私たちが具体的に何をしていて、どのような専門性を持っているのかを説明する短い答えはありません。

その理由は、「Researcher」や「Analyst」、特に「Security Analyst」や「Security Researcher」という肩書きが、「Consultant」以来、最も乱用され、使い古された肩書きの一つだからだと思います。文字どおり何でも意味し得るうえ、各社でSecurity Research Teamの役割の定義がまったく異なります（そもそもチームを置いている会社ばかりではありません）。

仕事以外で会う人に自分の仕事を十分に説明するという課題を、私が完全に解決することはできないでしょう。それでもこのブログは、Snykの素晴らしいSecurity Research Teamが何をしているのかを明確に説明し、この問題を少しでも解消するための試みです。

この記事では、次の内容を取り上げます。

• 私たちのミッション

• 私たちの手法

  • 構造化されたコミュニティエコシステムのデータベース

  • 非構造化データベースとアドバイザリ

  • 未公開の脆弱性を発見する

  • コミュニティや学術機関からの開示

  • 独自調査と脆弱性の傾向分析

• まとめ

私たちのミッション

Snykのミッションは、オープンソースの世界をより安全にし、開発者が自らのコードベースのセキュリティ確保に積極的に取り組めるよう支援することです。その主な方法の一つが、ユーザーが管理するオープンソースライブラリやコンテナイメージをスキャンして脆弱性を検出し、発見した脆弱性について可能な限り正確で実用的な情報を提供するとともに、問題を修正する手段を用意することです。

社内におけるSecurity Research Teamの役割は、スキャンを支え、ユーザーが脆弱性をセキュリティ上の脅威になる前に修正できるよう情報を提供するSnyk Intel Vulnerability Databaseを構築・管理することです。

最高水準のセキュリティデータベースを構築し、維持するには多大な労力が必要です。データの正確性だけでなく、データベースの網羅性と深さにも注力しなければなりません。脆弱性をどのように情報源から収集し、検証し、データベースへの登録を判断するのかを説明すると、私たちの取り組みを理解していただきやすいでしょう。

私たちの手法

オープンソースのセキュリティ問題を継続的に把握するため、いくつかの方法を採用しています。

1. 構造化されたコミュニティエコシステムのデータベース

オープンソースエコシステムにおける脆弱性の最も分かりやすい情報源は、rubysec、friends of php、rustsecなど、コミュニティが運営するデータベースです。これらのデータベースは、エコシステム内で活動するオープンソース開発者が管理し、そのエコシステムに存在するセキュリティ問題をできる限り可視化しようとしています。

Snyk Security Research Teamは、脆弱性に関するコミュニティからの開示を常に把握できるよう、こうしたコミュニティ運営のデータベースを継続的に追跡しています。コミュニティがエコシステムのユーザーに脆弱性を知らせるために素晴らしい取り組みをしている一方で、追加の対応が必要になることも少なくありません。

開示された脆弱性はすべて、Security Research Teamがさらに検証・分析し、次の点を確認します。

1. 実際に脆弱性であることを検証する—開示された脆弱性を調査し、必要に応じて概念実証（PoC）を作成して、実際に悪用可能かどうかを確認します。

2. 深刻度とCVSSスコアを含む、完全で正確な脆弱性の説明を作成する—脆弱性を詳しく調査して、その想定される影響と攻撃経路、エコシステム内での脆弱なパッケージの用途をより深く理解します。こうして得た知見をもとに、開発者が脆弱性とコードベースへの潜在的な影響を適切に理解できるよう、説明と深刻度に関するアドバイザリを作成します。

3. 修正版や影響を受けるパッケージなど、重要なメタデータが完全かつ正確であることを確認する—パッケージのコードベースを調査し、脆弱性を発生させたコード変更と修正した変更を正確に特定します。その後、パッケージ名とバージョンを照合し、脆弱なパッケージとバージョンだけを漏れなく指定します。

4. パッケージ内の脆弱な関数やクラスを特定する—脆弱性のトリアージでは、パッケージ内の脆弱な関数（または複数の関数）を正確に特定します。このメタデータにより、開発者は自分のパッケージの使い方が脆弱性の影響を受けるかどうかを把握できます。

5. 今後、この脆弱性の実環境でのエクスプロイト開示を監視し、トリアージする—脆弱性の公開後も、新たな情報、特に実用性の高いエクスプロイトが公開されていないかを追跡する必要があります。さまざまな情報源を監視して公開されたエクスプロイトを特定し、その成熟度に関するデータを提供できるようトリアージします。これにより、開発者は脆弱性の修正に優先順位を付けられます。

2. 非構造化データベースとアドバイザリ

エコシステム内に構造化データベースがあるのは有用ですが、新たな脆弱性に関する情報は、非構造化データベースや公開アドバイザリにも数多く存在します。こうした情報源も追跡し、トリアージすることが重要です。

最も分かりやすい例はCVEとNVDのデータベースです。ここには多くの脆弱性が、非構造化で機械可読ではない形式で記録されています。CVEやNVDに加えて、Apache Mailing List、Node.JS update blogs、Jenkins’ Security Advisoriesなど、個別の製品アドバイザリやメーリングリストも数えきれないほどあり、すべてに注意を払う必要があります。

もちろん、前のセクションで述べた作業はすべてここでも必要ですが、データを機械と人の双方が読み取れる形式に整えることも欠かせません。たとえば、NVDやApache Mailing Listで脆弱性が「Apache Tomcat」に影響すると報告されていても、開発者が知りたいのは、現在Mavenで利用できる「Apache Tomcat」関連の958種類のパッケージのうち、自分が使っている特定のパッケージが脆弱かどうかです。

脆弱なコードベースを詳細に調査することで、チームは脆弱なコードのパラメーターを特定できます。その後、社内ツールを使って、この脆弱性に関連する可能性の高いパッケージをスキャンし、脆弱なコードが含まれているかどうかを確認します。脆弱なコードが実際に存在し、関連性があると検証できた場合にのみ、脆弱性を特定のパッケージに割り当てます。この作業によって、データベース内の誤検知を大幅に減らし、Snykを利用する開発者がノイズへの対応ではなく、脆弱性の修正に集中できるようにしています。

3. 未公開の脆弱性を発見する

ここまでは、既知の脆弱性をトリアージし、開発者が対処しやすい形にするチームの役割を主に説明してきました。これはそれ自体が非常に重要です。しかし、チームには、まだ開示されていない脆弱性を特定し、オープンソースエコシステム全体のセキュリティをさらに高める役割もあります。

Data Teamと協力して、私たちが「半日脆弱性」と呼ぶものの発見に役立つ、複数の機械学習アルゴリズムを開発しました。これは、さまざまな公開フォーラムで議論されている可能性があるものの、まだ正式には開示されていない脆弱性です。

こうした脆弱性が極めて危険なことはよく知られています。脆弱性について議論されてから、それが認識され、一般の人々が修正に取り組めるようになるまでの間は、悪意ある攻撃者が早期に得た情報を悪用できる時間となるためです。

私たちは、ソース管理システムのPRやIssue、JIRAチケット、RedditやStackOverflowのようなサイトなど、コード修正やバグ報告、脆弱性の可能性が初期段階で話題になる場所から情報を収集しています。こうしてこのギャップを埋め、ライフサイクルのごく早い段階で新たに発見された脆弱性を検出し、ユーザーに警告できます。

脆弱なコードのスニペット、バグ報告、脆弱性の説明を集めた既存のデータベースを、手作業で丁寧に整備してきたおかげで、機械学習のロジックの基盤となる幅広い情報を確保しています。そのため、システムはサポート対象のすべてのエコシステムに属するパッケージについて、何千ものイベントを処理し、潜在的な脆弱性をチームに知らせることができます。総合すると、現在利用できるアラートフィードの中でも、おそらく最も広範なものを構築できたと考えています。

これらのアラートはチームの早期警告システムに送られ、チームによってトリアージされます。アナリストがアラートの情報を精査し、必要であればPoCを作成して脆弱性を検証したうえで、パッケージのメンテナーに連絡し、潜在的な脆弱性について見解を聞きます。

メンテナーとの協議と脆弱性の検証を経て、私たちのデータベースに脆弱性を公開し、エコシステム全体にセキュリティ問題を知らせて対処できるようにします。過去1年間だけでも、この方法で約200件の脆弱性の開示を支援しました。その中には、Vizionのコマンドインジェクションや、広く使われているEscadaおよびEllipticパッケージに影響するタイミング攻撃が含まれます。

4. コミュニティや学術機関からの開示

責任ある脆弱性開示は、サイバーセキュリティ分野で一般的に使われる開示モデルです。0-day脆弱性をまず非公開で開示することで、コードやアプリケーションのメンテナーが修正プログラムやパッチを提供するための時間を確保してから、脆弱性を公開します。そうしなければ、エンドユーザーのセキュリティを犠牲にすることになります。何事もバランスが重要です。脆弱性を非公開にする期間と、修正がないままアプリケーションが脆弱な状態に置かれる期間の両方を最小限に抑えることを目指します。

Snykは2019年に脆弱性開示プログラムを開始しました。研究者が脆弱性を簡単に報告できるようにすること、そしてもちろん、発見に尽力した研究者に適切な謝意を示すことを目的としています。

セキュリティチームは、すべての脆弱性報告を慎重にトリアージします。そのためには、対象となる言語、パッケージ、そしてその背景について、専門知識と理解が必要です。脆弱性の詳細を検証した後、チームはメンテナーと緊密に連携し、速やかな修正を目指します。

最後に、CVE採番機関（CNA）として、問題へのCVE IDの割り当てと詳細なアドバイザリの公開を支援しています。2019年には、130件を超える脆弱性の開示を支援しました。主な事例として、mongo-expressのRCEやyarnにおける任意ファイル書き込みがあります。

Snykは、脆弱性の開示にあたり、独立系研究者やセキュリティ担当者、学術コミュニティと連携しています。個人研究者は、当社の開示プログラムを利用して、パッケージに影響する単一または複数の脆弱性を開示します。一方、新たな脆弱性の種類を発見した学術研究者は、エコシステム全体にわたる複数の脆弱性を一括開示するため、Snykに連絡して当社の開示プログラムを利用します。2020年の初めには、ジョンズ・ホプキンス大学セキュリティラボのチームと大規模なパートナーシップを開始し、60件を超える脆弱性（現在も増加中）の開示を支援しました。注目すべき例として、undefsafeのCVE-2019-10795やaws-lambdaのCVE-2019-10777があります。

5. 独自調査と脆弱性の傾向分析

セキュリティ対策の最後の要素は、オープンソースエコシステムにおける新たな脆弱性を発見し、責任ある形で開示するための社内独自調査です。Snykは、新たな脆弱性の発見と責任ある開示が、エコシステムの安全を維持するうえで重要な役割を果たすと考えています。そのために、既存の脆弱性データベースを活用しています。特定のプログラミング言語や複数の言語にわたる脆弱性の傾向を調べることで、エコシステム内で広く見られる可能性が高い脆弱性の主な特徴を特定します。

つまり、類似した攻撃経路を持つ特定の脆弱性が、エコシステム内の複数のパッケージで見つかった場合、まだ発見されていない脆弱性がほかにも存在する可能性が高いと判断できます。さらに、悪意ある攻撃者もこの可能性を認識し、悪用しようとしている可能性が高いことも分かっています。

そのためSnykは、調査能力を慎重かつ効率的に活用し、zip-slipのような大規模な新種の脆弱性を発見したり、人気パッケージにおける、注目されている脆弱性の新たな事例を発見したりしています。この調査では、ビッグデータを詳細に分析して、脆弱性が潜むコードスニペットの種類やコードパターンなどの特徴を特定します。同時に、さまざまな攻撃手法も調査します。その後、社内ツールを使って、脆弱性が潜む可能性のあるパッケージに対して攻撃を実行し、実際に脆弱性が存在するかどうかを判断します。

脆弱性を発見すると、責任ある開示のタイムラインと手順に沿って、影響を受けるメンテナーに開示し、修正に向けた取り組みを支援します。その後、脆弱性をデータベースで一般公開し、CVEを割り当てます。

まとめ

こうした取り組みの結果、Snykのセキュリティ製品は、次の4つの重要な目標を実現しています。

1. 適時性—ユーザーが脆弱性やエクスプロイトに関する情報を、適切なタイミングで入手できるため、広く知られたり、悪意ある攻撃者に悪用されたりする前に対処できます。

2. 網羅性—ユーザーは、脆弱性の全体像を把握できるため、コードベースに悪用される可能性のある脆弱性がほかにも潜んでいるのではないかと心配せずに済みます。

3. 正確性—提供されるデータの精度が高いため、セキュリティスキャンで問題となるノイズや誤検知を排除できます。

4. 実用性—データを活用して、開発者は自分たちに影響する脆弱性をすばやくトリアージし、優先順位を付けて作業を進められます。

この4つの目標により、Snykユーザーは、オープンソースエコシステムに脆弱性が絶えず現れる状況でも、セキュリティの専門家からなる専任チームがすぐに対応できる体制で支援していることを確信できます。自分たちとオープンソース全体を安全に保つために必要な情報を、すべて提供します。

コード内の脆弱性を見つけましょう—Snykの無料アカウントを作成してください。