脆弱性の78%は間接依存関係で見つかり、修正が複雑に

著者

Liran Tal

2019年2月26日

8 分で読めます

Snykの年次レポート「2019年オープンソースセキュリティの現状」へようこそ。本レポートは複数の記事で構成されています。

この情報をはじめ、さらに多くの内容を1か所にまとめた、手作りの素敵なPDFレポートもダウンロードできます。

2019年オープンソースセキュリティの現状レポートをダウンロード

間接依存関係

オープンソースの依存関係なしでソフトウェアを書いていた時代を想像するのは難しいでしょう。プロジェクトの依存関係を管理することは重要な作業であり、依存するライブラリを正確に把握するための十分な注意が必要です。最終的に、デプロイするアプリケーションには、自分のコードだけでなく依存関係も含まれます。

npm、Maven、Rubyの依存関係の大半は間接依存関係であり、明示的に指定した少数のライブラリによって取り込まれます。全体の脆弱性の78%は、間接依存関係に起因しています。

Snykは100万件を超えるスナップショットプロジェクトをスキャンし、全体の脆弱性の78%が間接依存関係に起因することを明らかにしました。この結果は、依存関係ツリーを明確に把握し、脆弱性のある経路の詳細を正確に特定して、脆弱性に対処することの重要性をさらに示しています。

もちろん、依存関係にある脆弱性を見つけるのは、最初の一歩にすぎません。脆弱性のある依存関係に到達する依存関係ツリー内のすべての経路を正確に特定するのは、より複雑な課題です。

さらに、依存関係間の互換性を保ちながら脆弱性を解消するための手順を提案することは、より大きく、はるかに興味深い課題です。

PyPI、PHP Packagist、Maven Central、RubyGems、npmにおける直接依存関係と間接依存関係の割合を示す、100%積み上げ棒グラフ。

リスクと影響

深刻度が高い、または重大な脆弱性に1日以内で対処できる開発者は3人に1人にすぎません。

今年のGitHubによる「State of the Octoverse」レポートで、セキュリティが最も人気のあるプロジェクト統合アプリのカテゴリーであり、開発者向けの統合機能が複数あると報告されているのは、多くの人にとって驚きではないでしょう。ここでは、アプリケーションのライフサイクルのできるだけ早い段階でセキュリティテストを行う必要性を取り上げた、最近のアプリケーションセキュリティレポートから、業界アナリストGartnerの見解を紹介します。

回答者のほぼ半数（43%）が、直接依存関係を20件以上使用しています。これらのライブラリを通じて持ち込まれるオープンソースの脆弱性を監視する必要性が高まっています。

オープンソースソフトウェアの利用が増えるほど、リスクも高まります。他者のコードを取り込む機会が増え、そこに現在または将来、脆弱性が含まれている可能性があるためです。また、リスクはコードの安全性だけでなく、採用したコードのライセンス遵守状況や、ライセンス違反の有無にも関わります。

「企業は、ソフトウェア資産（バージョン管理システムや構成管理システムなど）を含むリポジトリを定期的に監査するためにSCAツールを使用し、自社で開発または使用するソフトウェアがセキュリティ基準や法的基準、規則、規制を満たしていることを確認する必要があります。アプリケーション開発者は、使用を予定しているコンポーネントを調査できるよう、SCAツールを利用できるようにすべきです。」

Mark Horvath

Hype Cycle For Application Security 2018, Gartner

今すぐできること

アプリケーションの構成は複雑です。OSのメンテナーや開発者として、自分が所有または貢献するプロジェクトのセキュリティを向上させるためにできることがあります。

オープンソースのメンテナー

オープンソースのメンテナーは、コードの安全なリリースを提供し、利用者とのコミュニケーション戦略を整えることで、他のプロジェクトやアプリケーションに良い影響を与えられます。その結果、自分のプロジェクトにもメリットがもたらされる可能性があります。

可能であれば、同僚と安全なコードレビューを実践し、セキュアコーディングのベストプラクティスに従いましょう。コードレビューのチェックリストにセキュリティ上の確認事項を加え、レビュアーが確認すべき点を把握できるように教育しましょう。
たとえば静的・動的コード解析を活用して、コードベースの脆弱性を定期的に監査しましょう。こうした解析は開発ワークフローに自動化して組み込むことができ、脆弱性が公開される前に発見しやすくなります。
独自のポリシーを定めるか、既存のプログラムに転送するなどして、責任ある脆弱性開示のためのシンプルなプロセスを明確にしましょう。セキュリティへの取り組みを伝えるには、SECURITY.MDポリシーと、プロジェクトのセキュリティ状況を示すバッジの導入を検討してください。
シフトレフトのセキュリティ戦略を導入し、開発中やCI、プルリクエストの作成時にもチームがセキュリティ上の問題を把握できるようにしましょう。脆弱なコードがプロジェクトに入り込む可能性をなくすことにつながります。

オープンソースの開発者

オープンソースコンポーネントを利用する側には、プロジェクトで使用する直接・間接の依存関係と、依存関係ツリーに存在する可能性のあるセキュリティ上の欠陥をすべて把握する責任があります。次のセキュリティガイドラインの導入を検討してください。

サードパーティーの依存関係にある脆弱性を自動検出し、チームに修正のアドバイスを提供するツールを使って、コードベースを定期的に監査しましょう。デプロイ後もプロジェクトの依存関係を監視できるツールを選びましょう。
セキュリティ脆弱性を報告する際は、ユーザーを危険にさらさないよう、責任ある開示ポリシーに従いましょう。方法がわからない場合は、Snykの責任ある開示プログラムのように、開示プロセスを一緒に進めてくれるセキュリティ企業への報告を検討してください。
オープンソースの依存関係にセキュリティ情報を配信するチャネルがあれば登録し、脆弱性が報告されたときに把握できるようにしましょう。

主なポイントをまとめた記事もぜひご覧ください。

CTFを始めよう

オンデマンドのバーチャル入門ワークショップを視聴して、CTFの課題の解き方を学びましょう。

今すぐ視聴