ソフトウェア依存関係：大規模な依存関係管理の方法

ソフトウェア依存関係を活用すれば、開発者はこれまでの成果を基盤として、より迅速にソフトウェアを提供できます。ソフトウェア依存関係はここ数十年でアプリケーション開発に革命をもたらしましたが、見過ごされがちなリスクも伴います。

依存関係にはどのような種類がありますか？

ソフトウェア依存関係には、次の2種類があります。

• 直接依存関係：コードから直接呼び出すライブラリやパッケージ。

• 推移的依存関係：依存しているライブラリやパッケージが呼び出すライブラリやパッケージ。つまり、依存関係の依存関係です。

どちらの種類の依存関係も、リスクを抑えるために慎重に管理する必要があります。推移的または間接的な依存関係は、アプリケーションで使われていることがすぐにはわからないため、特に注意が必要です。依存関係はほかの依存関係の中に入れ子になり、複雑な依存関係ツリーを形成します。そのため、脆弱性のあるライブラリがアプリケーションで使われていても、見落としやすくなります。

依存関係の管理が不可欠な理由

ソフトウェア依存関係が登場した初期には、必要なライブラリをダウンロードしてインストールするのは手間のかかる作業でした。そのため、小規模なパッケージを再利用するのは現実的ではありませんでした。しかし、この20年で、Node.js向けのNode Package Manager（NPM）やJava向けのMavenなどの依存関係管理ツールが登場し、数行のコードで構成されるものも含め、小規模なパッケージを利用できるようになりました。それ以来、開発者が利用できるパッケージの数は急増し、ソフトウェア依存関係は現代のアプリケーションに欠かせない要素となっています。

開発者は、あらかじめ構築されたソフトウェア依存関係を活用することで、より短いリリースサイクルでソフトウェアを迅速に提供できます。一方で、依存関係には見過ごされがちなリスクもあります。外部ソフトウェアを依存関係として組み込むことは、そのコードを適切に作成、テスト、保守することを開発者に委ねることを意味します。

プログラムの依存関係にセキュリティ脆弱性が含まれている可能性があるだけでなく、古くなって、依存するソフトウェアの品質を損なったり、動作しなくなったりすることもあります。依存関係に含まれるバグやセキュリティ上の問題は、アプリケーションのパフォーマンスやリスクに影響を与える可能性があります。また、ライセンスが適用されている場合は、法的責任や賠償責任が生じることもあります。

このように、依存関係に伴うリスクを最小限に抑える管理は不可欠です。それにもかかわらず、多くの組織は依存関係の管理にほとんど注意を払っていません。ソフトウェアが問題なく動いていると、壊れていないものを直す必要はないと考えがちです。さらに、依存関係の管理は容易ではありません。推移的依存関係には複数のリンクや、循環依存関係が含まれる場合もあります。ある依存関係を更新すると連鎖全体が壊れ、依存関係地獄に陥ることもあります。

オープンソース依存関係を管理すべき理由

ソフトウェア依存関係の初期には、企業は信頼できる評判の高いベンダーからコードパッケージを購入していました。現在では、依存関係の大半をオープンソースのサードパーティ製ライブラリが占めており、依存関係の管理はより複雑になっています。本番ソフトウェアで使用されるコードを作成、保守するオープンソースのコントリビューターは、自社の組織外の人々である可能性が高いのです。

オープンソースライブラリが登場した当初、開発者はコードを直接コピーして貼り付けることがよくありました。そのため、コンポーネントの追跡やアップグレードが不可能でした。現在では、パッケージマネージャーを使ってオープンソースコンポーネントを管理したり、オープンソースライブラリを社内モジュールでラップしたりする手法が一般的です。こうした新しいアプローチにより、アプリケーションでオープンソースコードをより簡単に利用できます。しかし、オープンソースコンポーネントが急増する一方で、開発者はそれらがもたらす可能性のある脆弱性を十分に把握できていないことがよくあります。

作成されるコードの量が爆発的に増加したこともあり、セキュリティの専門家はオープンソースコンポーネントの脆弱性を絶えず発見しています。悪意ある攻撃者がこうした脆弱性を見つけると、攻撃に悪用する可能性があります（Equifaxの情報漏えい）。特に、広く使われているパッケージは狙われやすくなります（Log4Shell）。さらに、オープンソースライセンスには利用条件が定められており、違反すると多額の罰金や評判の失墜につながる可能性があります。

こうした理由から、ライフサイクル全体を通じてオープンソース依存関係を管理する仕組みを構築することが重要です。これには、開発者によるオープンソースコンポーネントの取り扱い方針を策定し、徹底することが含まれます。

依存関係管理における5つの課題

これまで見てきたように、オープンソース依存関係を活用すれば、開発者はアプリケーションをより迅速に提供できますが、組織はセキュリティ上および法的なリスクにもさらされます。特に、入れ子状の依存関係を形成する可能性がある推移的依存関係は、慎重に管理する必要があります。オープンソース依存関係のリスクを管理、軽減する方法の1つが、ソフトウェア構成分析です。

ソフトウェア構成分析（SCA）は、ソフトウェアコンポーネントを追跡、分析するアプリケーションセキュリティテストの手法です。SCAには、依存関係として使用されているコンポーネントを追跡するためにソフトウェアを監視するアプリケーションセキュリティの手法やツールが含まれます。SCAの対象はオープンソースコンポーネントに限りませんが、オープンソース依存関係の増加を背景に、近年SCAツールが急増しています。

オープンソース依存関係のリスクを適切に管理するには、SCAツールが次のような重要な課題を克服する必要があります。

1. 推移的依存関係は、複数の階層の中にオープンソースパッケージを隠してしまうため、アプリケーションが呼び出すすべてのオープンソースパッケージを把握するのが困難です。Snykの調査によると、脆弱性の大半はこうした見えにくい依存関係に潜んでいます。そのため、開発者はセキュリティ脆弱性を含むオープンソースパッケージを使っていることに気付かない場合があります。

2. 各エコシステムが依存関係をどのように処理するかを理解することが重要です。ロックファイルやインストール時のパッケージ解決などの要素は、脆弱性の検出方法に影響します。SCAツールは、関連する脆弱性を正確に特定するため、こうした違いを考慮する必要があります。たとえば、これにより依存関係の取り違え攻撃の検出と防止に役立ちます。これは、Yelp、Tesla、Apple、Microsoftなどからデータにアクセスし、持ち出すために実際に使われた手法です。

3. ソフトウェア依存関係で発見される脆弱性は、数千件に及ぶことがあります。SCAツールには、脆弱性の特定と解決に向けた取り組みの優先順位を決める仕組みが不可欠です。

4. SCAツールには、脆弱性を適時に特定し、安全を確保するための信頼できる情報源が必要です。

5. SCAツールは、開発者のスピードに対応できるだけの迅速さが必要です。対応が遅れると、開発者がセキュリティチェックを無視したり、回避したりするおそれがあります。

Snykの依存関係管理ツールがリスクを軽減する方法

従来のセキュリティ対策は、DevOpsのワークフローにセキュリティを組み込むのではなく、開発プロセスの終盤に重点を置いています。Snyk Open Sourceは、既存のワークフローやツールにすぐに統合できるため、開発者を組織のセキュリティを担う重要な存在として位置付けます。セキュリティチームと運用チームがプロセスを管理、監督する一方で、開発者はCI/CDツール内からSnykのツールを使い、開発パイプラインを継続的に保護できます。本番環境にコードが到達する前の開発段階でセキュリティ問題を修正することが、最も安全で費用対効果の高い方法です。

Snykはアプリケーションセキュリティのあらゆる側面をカバーします。依存関係ツリービューで依存関係とその脆弱性を特定し、依存関係の進化に合わせて自動的に更新します（JavaとPythonでの仕組みをご覧ください）。SnykはIDE内のスキャンを自動化するため、開発者は開発中に問題を見つけ、優先順位を付け、修正し、更新をマージできます。実行時に脆弱な関数が呼び出されると、アラートが自動的に発行されます。GitHubやGitLabなどのSCMとのインテグレーションにより、新規および既存のコードプロジェクト全体にツールを展開でき、修正用のPRも自動生成できます。これにより、貴重な開発時間への影響を抑えられます。

開発者を第一に考えたこのセキュリティアプローチにより、開発者はコードや依存関係にあるバグをリアルタイムで発見し、修正できます。脆弱性を早期に検出することで、開発ライフサイクルへの影響を軽減できます。包括的な脆弱性データベースには、専門家が精査した脆弱性の説明が掲載されています。データベース内のすべての項目は、正確性を確認するために分析、テストされ、各脆弱性にCVSSスコアとベクターが割り当てられています。脆弱性の説明では、検出されたライブラリの悪用可能性、ライセンス、セキュリティ履歴、保守状況を確認できます。

世界最大の教育企業であるPearsonは、リスクへの露出を最小限に抑えるため、Snykの依存関係スキャンの自動化を導入しました。開発者がプラットフォームを利用できるようになった後、DevSecOpsチームは問題を迅速に解決する方法も確実に把握できるようにしたいと考えました。

Snykの自動修正機能は脆弱性に優先順位を付け、開発者が修正のために行う作業を最小限に抑えます。これにより、古い依存関係、新たに発見されたセキュリティ脆弱性、ライセンスの問題に起因するPearsonのリスクを軽減できます。

「チームがSnykにログインして何百もの脆弱性を目にすると、少し気が遠くなることがあります」……「そこで、個々の問題ではなく、修正内容を見るように勧めています。依存関係を1つアップグレードするだけで、20～30件の脆弱性を修正できることもあります。チームにとって、こちらのほうが対応しやすいのです。」

ソフトウェア依存関係を保護する方法

ソフトウェア依存関係は、現代のソフトウェア開発で重要な役割を果たします。他者が作成したコードを再利用できるため、開発者はソフトウェアをより迅速に提供し、開発サイクルを短縮できます。その結果、利用が急増しましたが、組織が過小評価しがちなリスクや脆弱性ももたらします。

オープンソース依存関係は、特に注意が必要な領域です。現代の開発者が利用する依存関係の大半はオープンソースであり、本番ソフトウェアは、依存関係の作成、更新、保守を担う外部のコントリビューターに依存しています。

そのため、依存関係を包括的に監視することが不可欠です。しかし、アプリケーションが使用するすべての依存関係、特に推移的依存関係を監視するのは困難です。

Snyk Open Sourceは、開発ライフサイクル全体を通じて依存関係を自動的に検出、監視するSCAツールです。他のソリューションとは異なり、開発者を第一に考えたアプローチを採用し、開発者がアプリケーションセキュリティに積極的に参加できるようにします。

依存関係とアプリケーションセキュリティへの影響について詳しくは、レポート「The State of Open Source Security」をご覧ください。

お読みいただきありがとうございます。安全な開発を。