ソフトウェアコンポジション解析ガイド：SCAの5つの主な課題

ソフトウェアコンポジション解析を理解する：SCAの仕組み

今日の多くの、いや、ほとんどのアプリケーションを支えるコードには、オープンソースコンポーネントが含まれています。しかし、オープンソースコードには、最近発見されたLog4Shellエクスプロイトのような深刻な脆弱性が含まれている可能性があります。

ソフトウェアコンポジション解析は、オープンソースパッケージの脆弱性を発見し、その修正方法を把握するための最適な手段です。これにより、コードとアプリケーションの健全性を守ることができます。このガイドで、SCAツールを活用するためのベストプラクティスをご紹介します。

SCAは新しいものではありませんが、ここ数年でオープンソースの採用が拡大したことで、アプリケーションセキュリティプログラムの重要な柱となりました。その結果、SCAツールも数多く登場しています。しかし、すべてのSCAソリューションが同等というわけではありません。DevSecOpsの考え方をはじめとする最新のソフトウェア開発手法では、開発者を第一に考えたSCAが求められます。開発チームには使いやすいツールを提供し、セキュリティチームには、SDLC全体を通じて開発者がセキュリティを取り入れられるよう支援する機能を提供する必要があります。

ソフトウェアコンポジション解析（SCA）の5つの課題

前述のとおり、SCAは、アプリケーション（SASTなど）を通常は開発中にスキャンし、アプリケーションで使用されているオープンソースコンポーネントを特定するとともに、それらがもたらすセキュリティ脆弱性やソフトウェアライセンスに関する問題を検出する、アプリケーションセキュリティの手法とツールの総称です。こうしたオープンソースコンポーネントのリスクを適切に管理・軽減するために、SCAの手法やツールを導入する組織は、最新のアプリケーション構築におけるオープンソースの活用方法に関わるさまざまな課題に直面します。

SASTとSCAの違いと、安全なソフトウェアのリリースに向けた活用方法について、詳しくご覧ください。

1. 見えにくい可視性

オープンソースコードがアプリケーションのコードベースに組み込まれる過程は、可視性に関する大きな課題をもたらします。開発者が複数のオープンソースパッケージをコードに直接取り込むことがあります。しかし、それらのパッケージ自体が、開発者の把握していない別のオープンソースパッケージに依存している場合もあります。こうした間接的な依存関係や推移的依存関係は何層にも及ぶことがあり、アプリケーションで実際に使われているオープンソースをエンドツーエンドで把握するのは非常に困難です。

この課題をさらに深刻にしているのが、セキュリティ脆弱性の大半がこうした推移的依存関係に見つかることです。Snyk State of Open Source Securityレポートによると、node.jsの脆弱性の実に86%が推移的依存関係で発見されています。JavaやRubyでも同様の数値が報告されています。つまり、アプリケーションのセキュリティ脆弱性の大半は、開発者がそもそも使用していることすら把握していないオープンソースコードに潜んでいるのです。

クラウドネイティブアプリケーションでは、コンテナを構成する1つ以上のレイヤーとしてオープンソースが活用されており、これも組織の可視性に関する課題となり得ます。コンテナイメージはさまざまなオープンソースコンポーネントで構成されるため、それらを特定し、脆弱性をテストする必要があります。開発の観点では利点となる、コンテナが開発者に提供する抽象化レイヤーは、セキュリティの観点では弱点にもなります。

2. 依存関係の仕組みを理解する

アプリケーションが使用する依存関係と、それらがもたらす脆弱性を正確に特定するには、各エコシステムにおける依存関係の扱いを深く理解する必要があります。インストール時のパッケージ解決、ロックファイル、開発用依存関係などは、オープンソースパッケージの脆弱性の特定方法に影響し、その後の修正手順を左右する要素です。誤検知によるノイズを増やさないために、SCAソリューションはこうした細かな違いを理解する必要があります。

3. 脆弱性の洪水に埋もれる

検出される脆弱性の数が膨大になると、脆弱性そのものや組織に及ぼすリスクが見えにくくなります。Snyk Intel脆弱性データベースには1万件を超える脆弱性が追加されており、脆弱性が増え続けていることを示しています。

これは組織にとって何を意味するのでしょうか。こうした増加傾向は最終的に、対応が必要な脆弱性を一覧にした脆弱性バックログに反映され、数千件もの問題が積み上がることも珍しくありません。開発チームやセキュリティチームが使えるリソースは限られているため、適切なセキュリティスキルや高度なセキュリティ知識を備えたツールなしに、対応の優先順位を決めるのは非常に困難です。CVSSに基づく深刻度は、リスク評価と対応の優先順位付けに一般的に用いられる方法ですが、利用するうえでいくつか本質的な弱点があります。

4. 脆弱性データベースはどこにある？

既知の脆弱性に関する情報は、さまざまなデータソースに分散しています。脆弱性情報の更新には、National Vulnerability Database（NVD）が一般的に利用されています。しかし、課題管理システム、オンラインフォーラム、セキュリティニュースレターなど、ほかの情報源にも重要なセキュリティインテリジェンスが存在します。また、NVDの脆弱性情報の登録が十分に迅速でない場合もあります。たとえば、NVDに登録されたJavaScriptの脆弱性の92%は、それ以前にSnykが登録していました。この遅れは、脆弱性にさらされる期間をできるだけ短くする必要があることを考えると、重大な問題になり得ます。脆弱性をいち早く把握できるかどうかが、大きな違いを生みます。

5. スピードへの対応

開発者が目まぐるしい速さで開発を進めるなか、セキュリティチームはそのペースに追いつくのに苦労しています。より速く、より頻繁にコードをリリースする必要に迫られ、開発者によるオープンソースの採用はますます進んでいます。一方、人的リソースや予算が限られるセキュリティチームは、従来、ソフトウェア開発ライフサイクルのさまざまな段階にセキュリティチェックを導入してきましたが、結果的に開発の速度を落としていました。また、組織全体のアプリケーションセキュリティプログラムにとってさらに深刻なケースでは、チェックが回避されたり無視されたりすることもあります。

こうした背景から、セキュリティモデルにおいてDevSecOpsやシフトレフトという考え方が生まれました。セキュリティの責任を開発チームに移し、開発ワークフローへの影響を最小限に抑えながら、安全性を確保するという考え方です。この原則に基づいて設計された新しい世代のSCAソリューションにより、開発プロセスの早い段階からオープンソースのセキュリティテストを実施できるようになりました。Snykが採用するような開発者第一のアプローチは、開発者の利用を促進し、シフトレフトを実現します。

ソフトウェアコンポジション解析（SCA）が重要な理由

Gartnerによると、アプリケーションの70%以上に、オープンソースの使用に起因する欠陥が含まれています。Equifaxの事例が示すように、こうした欠陥が悪用されれば、組織に甚大な被害をもたらす可能性があります。

最新のアプリケーションでは、オープンソースコードの割合がますます高まっています。アプリケーションのコードの最大90%をオープンソースコードが占めるともいわれています。もちろん、アプリケーションはオープンソースだけで構成されているわけではありません。コードベースの安全確保に取り組む組織が直面する課題の1つは、アプリケーションがさまざまな構成要素を組み合わせて作られており、リスクを効果的に管理・軽減するには、そのすべてを保護する必要があることです。

ソフトウェアコンポジション解析ツールを使う理由

オープンソースコンポーネントは、あらゆる業界のソフトウェアで主要な構成要素になりつつあります。SCAツールは、アプリケーションで使用されているオープンソースコンポーネントを追跡するのに役立ち、生産性とセキュリティの両面で重要な役割を果たします。

ソフトウェアコンポジション解析ツールの選び方

SCAツールはそれぞれ異なり、さまざまな形態があります。多くのベンダーがひしめく市場では、選択に迷うこともあるでしょう。ここまで説明した課題を踏まえ、SCAツールを選ぶ際に検討すべき10項目をまとめました。

ソフトウェア開発ライフサイクルのどの段階でSCAツールを使うのか？

SCAツールは、ソフトウェア開発ライフサイクル（SDLC）の複数の段階に組み込まれ、オープンソースの依存関係に伴うリスクの特定と軽減に役立ちます。開発段階では、コードリポジトリや依存関係マニフェストをスキャンし、脆弱性を早期に検出します。ビルドやテストの段階では、安全性とコンプライアンスを確保したオープンソースコンポーネントだけがデプロイされるようにします。さらに、デプロイ後も、新たに発見された脆弱性に関するセキュリティ情報やアラートを継続的に提供します。

SCAとDAST、SAST、IASTなどのテストツールの違いは？

SCAがオープンソースコンポーネントとその依存関係に含まれる脆弱性の特定に焦点を当てるのに対し、ほかのセキュリティテストツールはアプリケーションセキュリティの異なる側面を対象とします。静的アプリケーションセキュリティテスト（SAST）は、実行前に独自のソースコードを解析して脆弱性を検出します。一方、動的アプリケーションセキュリティテスト（DAST）は、模擬攻撃を通じて実行中のアプリケーションのセキュリティ上の欠陥を調べます。インタラクティブアプリケーションセキュリティテスト（IAST）は、アプリケーションの実行中に脆弱性をリアルタイムで検出します。SCAはオープンソースソフトウェアに関するリスクに特化し、ソフトウェアサプライチェーン全体のコンプライアンスとセキュリティを確保します。

ソフトウェアコンポジション解析が必要な理由

ソフトウェアが世界を席巻し、オープンソースがソフトウェアを席巻しています。デジタルトランスフォーメーションを推進するうえで、オープンソースが果たす役割は計り知れません。クラウドとDevOpsの普及に伴い、オープンソースは企業がサービスをデジタル化し、テクノロジーを活用して競争の激しい市場で優位に立つための重要な要素となっています。

オープンソースはどのように役立つのでしょうか。アプリケーションを一から構築するには、時間とリソースがかかります。同じ機能を提供するオープンソースパッケージを利用すれば、こうしたコストを削減できます。オープンソースは本質的に柔軟性が高く、必要に応じて簡単にカスタマイズできます。コミュニティに支えられ、より厳しい検証を受けていることから、安全性が高い場合も少なくありません。もちろん無料で、ベンダーロックインの回避にも役立ちます。

こうしたメリットは効率の向上につながり、市場投入までの時間を短縮したい組織でオープンソースの採用が進んでいる理由を説明しています。Tideliftによる別の調査では、回答者の68%が、組織がアプリケーション開発でオープンソースの使用を推奨する主な理由として、コストと開発時間の削減を挙げています。また、48%はアプリケーション開発と保守の効率向上を理由に挙げました。オープンソースの利用はCOVID-19以前から拡大していましたが、パンデミックによって採用がさらに加速しました。Gartnerは現在、90%の組織がアプリケーションでオープンソースを利用していると推定しています。

最新のソフトウェアサプライチェーン

オープンソースは、最新のクラウドネイティブアプリケーションを構成する要素の1つにすぎません。今日のアプリケーションは、一から構築されるというより、組み立てられています。オープンソースパッケージに加え、独自コード、コンテナ、Infrastructure as Codeなど、新たなソフトウェアサプライチェーンを構成するさまざまな要素が組み合わされています。そのすべてが、悪意ある攻撃者の侵入経路となる可能性があります。

サプライチェーンの一部で悪用された脆弱性は、アプリケーション全体への感染に利用され、攻撃対象領域を拡大させる可能性があるため、保護が必要です。たとえば、Octopus Scannerマルウェアの事例では、GitHubがApacheのオープンソースNetBeans IDEを列挙し、バックドアを仕掛けるよう設計されたマルウェアを発見しました。ビルドプロセスを悪用してサプライチェーンに影響を与え、生成された成果物を拡散させるという攻撃手法は、影響を受けたプロジェクトがクローンやフォークされ、多数のシステムで使われる可能性があるため、興味深いものでした。しかし、残念ながらこれだけが特異な事例ではありません。今回の標的はプロプライエタリソフトウェアでしたが、最近のSolarWindsへの攻撃も、現代のソフトウェアサプライチェーンが組織にもたらすリスクの高まりを示しています。

オープンだからといって安全とは限らない

オープンソースプロジェクトは、より安全に利用できると考えられています。プロジェクトの維持や開発にコミュニティ全体が関わっていれば、問題がより速やかに発見され、修正されるからです。これにはもちろんバグだけでなく、セキュリティ上の脆弱性も含まれます。しかし、だからといってオープンソースにリスクがないわけではありません。実際、オープンソースコードがより安全だと考えられる理由そのものが、弱点にもなり得ると言えるでしょう。

定義上、オープンソースプロジェクトは公開されており、誰でも閲覧できます。悪意ある攻撃者も例外ではありません。発見され修正された脆弱性は、攻撃者にも見つけられる状態にあると言えます。オープンソースプロジェクトの人気が高いほど、攻撃の影響が広範囲に及ぶため、そのパッケージはより魅力的な標的になります。前述のEquifaxの情報漏えいを例に挙げると、攻撃に使われたオープンソースパッケージであるJavaのApache Strutsライブラリは非常に多くのアプリケーションで利用されており、その広範な被害範囲から、この攻撃は悪名を知られることになりました。

もちろん、オープンソースを利用する組織は「自己責任」で利用しています。欠陥を通知してくれるベンダーも、責任を免除する署名済み契約もありません。これらのコンポーネントのセキュリティを維持する責任は、全面的に利用者にあります。

Software Composition Analysis（SCA）の未来

オープンソースの利用拡大に加え、最近の情報漏えいやサイバー攻撃が広く報じられていることから、SCAへの関心は今後も高まるでしょう。デジタルトランスフォーメーションを推進するうえで、オープンソースが果たす役割はますます明らかになっており、こうした傾向が近いうちに変わると考える理由はほとんどありません。

組織は、それぞれの市場で競争力を高めるためにオープンソースを活用する一方で、それに伴うリスクを管理・軽減し、利用を適切に制御する必要があるとの認識も高まっています。上記の主要な要件を満たすSoftware Composition Analysisツールだけが、組織によるこの目標の達成を支援します。

Snyk Open Sourceによる包括的なSoftware Composition Analysisソリューション

Snykは、Forresterの2024年第4四半期Software Composition Analysis（SCA）Waveレポートでリーダーおよび顧客から高く評価される企業に選ばれ、ビジョン、イノベーション、カスタマーサービスなどの主要分野で最高評価を獲得しました。Forresterは、顧客の成功に対するSnykの取り組みと、開発プロセスにセキュリティを組み込む戦略を高く評価し、リスクインテリジェンス、修正、分析における高度な機能にも言及しました。

Snyk Open Sourceは、Salesforce、Google、Facebookなどの組織において、開発チームがSDLCの早い段階から全体を通じて、オープンソースの依存関係やコンテナに含まれるセキュリティ上の脆弱性やライセンス上の問題を自動で検出、優先順位付けし、修正できるようにすることで、アプリケーションセキュリティの強化を支援します。市場の他のセキュリティソリューションとは異なり、Snyk Open Sourceは開発者に使いやすく、開発ワークフローにシームレスに統合できます。自動修正と実行可能なセキュリティインサイトを提供し、組織がリスクを効率的に特定・軽減できるよう支援します。