本記事は2021年3月22日（米国時間）に公開した英語ブログHow to choose a Software Composition Analysis (SCA) toolを日本語化した内容です。
はじめに
開発者であれ、セキュリティエンジニアであれ、ソフトウェア構成分析（Software Composition Analysis、略してSCA）という言葉を耳にする機会が増えてきたと思います。まだ聞いたことがなければ、これから聞くことになるはずです。
その理由は簡単です。
あなたの会社では、アプリケーションの開発をオープンソースソフトウェアやコンテナに依存する傾向が強まっており、そうすることでセキュリティの脆弱性やライセンス違反という形でリスクを抱え込んでいるのです。ソフトウェア構成分析（SCA）として知られるアプリケーション・セキュリティ手法と、その実践を可能にする専用ツールは、あなたの組織がこのリスクを管理し、軽減するのに役立つのです。
しかし、リスクを理解し、SCAツールを使って適切な管理を行おうと思っても、最適なツールをどのように選べばよいのでしょうか。SCAツールは数多く存在しますが、どれも同じようなものでしょうか。それとも、製品ごとに重要な違いがあるのでしょうか。オープンソースがもたらすリスクをうまく軽減するために絶対に必要な主要機能とは何でしょうか。それともさほど重要でない機能もあるのでしょうか。意思決定プロセスにおいて、脆弱性データベースはどのような役割を果たすべきでしょうか。コンテナはどのような要因になりえるのでしょうか。
お客様の意思決定の一助となるよう、このような疑問に対する答えをまとめたチートシートを作成しました。SCAとは何か、なぜSCAが重要なのか、SCAツールに求められる主要な要件について、より深く理解するために、ぜひご一読ください。
ソフトウェア構成分析（SCA）ツールとは何か、なぜ必要か？
オープンソースの採用率は非常に高いです。オープンソースのトレンドは、COVID19が広がるかなり前からすでに勢いを増しており、現在も加速しています。Gartnerは、今日90％の組織がアプリケーションでオープンソースを利用していると推定していますが、これは過小評価かもしれません。
オープンソースは、企業がより速く開発し、競争力を維持することを可能にします。これは、開発者がゼロから機能を構築するのにかかる時間や費用を節約できます。オープンソースには、柔軟性、無料、ベンダーの囲い込みを避けることができるなど、他にも明らかなメリットがあります。
しかし、無料だからといって、コストがかからないわけではありません。実際、セキュリティやコンプライアンスの観点からは、オープンソースは非常に高くつく場合があります。それは、使用されているオープンソースパッケージによってもたらされるリスクが適切に管理されていない場合です。オープンソースのコンポーネントには、チェックが必要な既知のセキュリティ脆弱性が含まれています。また、オープンソースのライセンスには、利用を制限するような条項が含まれていることもあります。どのようなオープンソースが使用されているのかがわからず、それがもたらすリスクの範囲も理解できないままでは、悲惨でコストのかかる結果を招くことになりかねません。
今日のアプリケーションには、オープンソース以外のものも多く含まれています。開発者がアプリケーションをより迅速にビルド、テスト、デプロイできるように、アプリケーションはコンテナにパッケージ化され、Kubernetesなどのコンテナオーケストレーションツールでオーケストレーションされるようになっています。アプリケーションを構成し、セキュリティを確保する必要があるコンポーネントのリストは、より長く、より複雑になっています。
SCAは、開発チームとセキュリティチームが、使用されているさまざまなコンポーネントを追跡し、それらが含むセキュリティ脆弱性を検出するのに役立つアプリケーションセキュリティテスト方法論です。
SCA（Software Composition Analysis）ツールとは何ですか？
SCAツールは、アプリケーションを構成するさまざまなコンポーネントを効率的に管理することを容易にします。SCAツールを使用すると、開発チームは、オープンソースのコンポーネント、そのサポートライブラリ、直接および間接の依存パッケージ、コンテナなど、プロジェクトに持ち込まれたあらゆるコンポーネントを迅速に追跡および分析することができます。SCAツールは、ソフトウェアライセンス、サポートが終了したパッケージ、脆弱性、悪用の可能性なども検出することができます。スキャンプロセスにより部品表（BoM）が生成され、プロジェクトのソフトウェア資産の完全なインベントリーが提供されます。
SCAツール選定時の10大要件
SCAは決して新しいものではなく、少なくとも10年以上前から存在しています。しかし、オープンソースの人気の高まりと、アプリケーションが複数コンポーネントから組み立てられるようになり、多くの異なるタイプのソリューションからなる市場が形成されるようになったのです。オープンソースのスキャナーから、専門化した商用ツール、アプリケーションセキュリティのための統合ソリューションまで、さまざまな種類のソリューションがあります。また、ソフトウェア統合開発ソリューションの中には、基本的なSCA機能を提供するものもあります。
圧倒されましたか？大丈夫です。オープンソースがもたらすリスクをうまく管理し、軽減するために、以下の主要な要件に基づいてSCAツールを評価してください。
1. 開発者の利便性
2. エコシステムのサポートと統合
3. 依存関係分析
4. 脆弱性の検出
5. 優先順位付け
6. 修正
7. ガバナンスとコントロール
8. レポーティング
9. 自動化と拡張性
10. クラウドネイティブアプリケーションのセキュリティ
1. 開発者の利便性
セキュリティチームが、脆弱性のリストを渡して、開発者が修正する時代はとっくに終わっているのです。そのようなサイロ化されたアプローチは、もはや通用しないのです。DevSecOps は、開発者がセキュリティに対してより大きなオーナーシップを持つことを求めていますが、開発者の使用するツールが開発者に寄り添って動作することで達成することができます。
開発者がきちんとツールを使いこなすことが鍵になります。SCAツールがあまりにも使いにくかったり、開発の妨げになったりすると、開発者はそのツールを使用しなくなり、あまり意味がなくなります。したがって、SCAツールには次のようなものが必要です。
-
直感的でセットアップや使用が簡単であること。 開発者は、既存のツールと同じように動作するツールを高く評価します。
-
既存の開発ワークフローに容易に統合できること。 gitベースのワークフローに1～2クリックで統合できるツールや、IDEやCLIに簡単にプラグインできるツールは、開発者の採用を促進する上で大きな役割を果たすでしょう。
-
自動化された実用的なアドバイスを提供すること。 SCAツールは、問題を表面化させるだけでなく、自動化された実用的な修正アドバイスにより、開発者を修正への道筋に導くことで、開発者に行動を促します。Snykの自動修正プルリクエストは、この良い例です。
2. エコシステムのサポートと統合
アプリケーション構築に使用されている言語の対応や、開発環境に適合する機能がなければ、SCAツールはあまり役に立ちませんよね？これはかなり基本的な要件に聞こえますが、当然と考えるべきではありません。完全な言語カバレッジに対応するかわりにアプリケーションセキュリティテストをビルドプロセスに簡単に組み込む Jenkins プラグインは提供してくれないSCAソリューションもあります。また、IDE プラグインはソフトウェア開発ライフサイクル (SDLC) のはるか左側 (上流) にセキュリティをシフトしてくれますが、すべてのソリューションがプラグインを提供しているわけではありません。
言語サポートについては、アプリケーションを構築するために使用される主要なプログラミング言語とフレームワークに対して、SCAツールがセキュリティカバレッジを提供できることを検証してください。
ヒント! 技術スタックに含まれる言語には、当初は重要視しなくてよいものもあるかもしれません。使用中のコア言語に対するサポートに基づいてSCAツールを評価してみてください。
統合については、SDLCを横断して幅広く統合できることだけでなく、深さも重要です。SCA ツールが簡単に統合でき、実際に期待通りの結果をもたらすことを確認してください。API については後で説明しますが、堅牢な API が利用可能であることは、ここでは大きな利点となります。
3. 依存関係分析
Snyk 2020 State of Open Source Security reportで報告されているように、オープンソースパッケージの脆弱性の80%は、推移的（間接的）な依存パッケージにおいて検出されています!
つまり、コードベース内の脆弱性の大部分は、そもそも自分が使っていることを知らなかったパッケージによってもたらされるのです。ここでの推移的依存の深さは数階層に及ぶことがあり、アプリケーションで実際に使用されているオープンソースをエンドツーエンドで可視化することは非常に困難です。
それだけでなく、アプリケーションが依存しているパッケージや、それらがもたらす脆弱性を正確に特定するためには、各エコシステムによる依存関係の処理方法を深く理解することが必要です。インストール時のパッケージの解決、ロックファイル、開発時にのみ用いられるパッケージ (例: npm におけるdevDependencies)など、これらはすべてオープンソースパッケージの脆弱性を特定する方法に影響を与える要因であり、その後の改善策を決定するものです。
そのため、SCAツールを評価する際には、アプリケーションのすべての依存関係を正確に解釈し、実務担当者に完全な可視性を提供できるかどうかを検証することが重要です。
4. 脆弱性の検出
SCAツールは、オープンソースパッケージに含まれる脆弱性の有無を正確に判定できなければなりません。これは、上述したように、ツールが依存関係の論理を理解する能力に左右されます。加えて、ツールが参照するセキュリティ情報も同じく重要です。
ここで、SCAツール間の違いがより浮き彫りになります。SCAツールの中には、NVDのような公開データベースのみに依存するものがあります。また、一般に入手可能な脆弱性情報を追加して、公開データベースを補強するものもあります。SCAツールの中には、セキュリティチームが関わることで、複数のソースを1つの脆弱性データベースに統合し、継続的に更新し、さまざまな高度な分析プロセスを用いて強化するものもあります（Snykを含む）。このような場合でも、データベースの品質、正確性、および提供するインテリジェンスの包括性については、ソリューションごとに微妙な違いがあります。
一般的に言えば、SCAツールが提供する脆弱性データを評価する場合、以下の点を考慮することをお勧めします。
-
正確性 - 誤検知(フォールスポジティブ)は避けられませんが、誤検知の割合が高いと、リソースを浪費し、開発者による利用を妨げます。
-
包括性 - NVDだけに頼っていては十分ではありません。公開、非公開、および内部のセキュリティ・データ・ソースを組み合わせたSCAを選択するようにしてください。
-
適時性 - 新たに公開された重大な脆弱性がデータベースに追加されるスピードは非常に重要です。使用中のパッケージにゼロデイ脆弱性が含まれている場合、それを特定しないわけにはいかないでしょう。
-
実用性 - 脆弱性に関する豊富で、かつ関連した情報を提供する SCAツールを選択することで、開発者が行動を起こせるようにします。
5. 優先順位付け
オープンソースコンポーネントの脆弱性は常に増加傾向にあり、毎年数千の新しい脆弱性が公表されています。SCAツールは、数千件とは言わないまでも、数百件の脆弱性を特定することが多く、それらはすぐにバックログとして積み上がり、チームを簡単に圧迫することになります。
現実的には、リスト上のすべての脆弱性を修正することはできないため、どの脆弱性が投資した時間に対して最高のリターンをもたらすかを決定する必要があります。これらの判断は、リスクを管理し低減するための取り組みに大きな影響を与えます。優先順位付けが不適切だと、誤検出のために時間を浪費することになり、摩擦が生じ、開発者の信頼が失われます。すでに述べたように、DevSecOps の実践とセキュリティをスケールさせるために信頼関係は非常に重要です。
少なくとも、SCAツールは以下の方法で優先順位をうまく設定できることを確認してください。
-
リスク評価のためにCVSSスコアリングだけに頼らないこと。 CVSSは良い出発点ですが、その程度のものです。CVSSは出発点としては良いが、コンテキストに欠け、理解や利用が困難な場合が多いです。
-
脆弱性に関して、アプリケーションレベルおよびビジネスレベルの深いコンテキストを提供すること。 コンテキストはなにもりも重要です。SCA は、脆弱性が到達可能（訳注：脆弱性を含むコードが実際に呼び出されていること）かどうかを教えてくれるのでしょうか？その脆弱性が悪用可能かどうかを知ることができますか？SCAは、本番環境およびミッションクリティカルなアプリケーションで使用されているコンポーネントにその脆弱性が存在するかどうかを理解するのに役立ちますか？
-
優先順位付けを自動化できること。 規模が大きくなると、手動で優先順位付けを行うことは完全に不可能になります。プロジェクトやチームにまたがるプロセスをポリシーに基づいて自動化できるSCAツールは、そうでないツールよりも高く評価すべきです。
6. 修正
大半のSCAツールは、オープンソースパッケージのセキュリティ脆弱性を特定する機能を備えています。これに加えて、次の論理的ステップである脆弱性の修正をサポートするものもありますが、修正機能はツールによって異なります。
例として、修正に関するアドバイスを考えてみましょう。一つの方法として、その脆弱性を修正したバージョンへパッケージをアップグレードを提案することができます。機能を維持するため、必要最小限のアップグレードに留めることもあわせて検討すべきでしょう。まったく別の切り口として、適切な修正が存在する脆弱性が新たに検出された場合に、プルリクエストを自動作成することもできます。
評価する際には、SCAツールが提供する脆弱性の修正に関するアドバイスや、実行可能性を高めるためにサポートするワークフローについて深く掘り下げます。修正プログラムを適用する場所と方法を理解するために十分な情報があるか？自動化されたワークフローは利用可能か？といった内容です。
7. ガバナンスとコントロール
SCAツールは、アプリケーションにおけるオープンソースの使用を制御するために必要なコントロールを提供しますか？少なくともSCAツールが、セキュリティとコンプライアンスについて組織の定めるガイドラインを定義・自動適用するための、きめ細かいポリシーを提供していることを確認します。
8. レポーティング
組織全体で使用されている多様なオープンソースパッケージと、それに含まれる多様なオープンソースライセンスを含めて長期にわたって追跡できるようにすることは、様々な理由で、また、異なるビジネス利害関係者にとって重要です。たとえば、セキュリティリーダーは、どれだけの脆弱性が特定され、修正されたかを答えることによって、SCAプロセスの成功を長期的に測定したいと思うでしょう。
コンプライアンスおよび法務部門は、組織のコンプライアンス体制に影響を与えるオープンソースのパッケージとライセンスのすべてを含むインベントリに関する BoM レポートの作成に関心を持つでしょう。コンプライアンス状況の長期間に渡る把握、そして、オープンソースのインベントリについてBoM レポートの作成と共有、これらが SCA ツールにより実現できることを確かめてください。
9. 自動化と拡張性
規模が大きくなればなるほど、SCAプロセスに関わる人的プロセスをすべて実行することは困難になってきます。新しいテスト対象プロジェクトやユーザーを追加したり、CI/CDパイプラインの一部として新しいビルドをスキャンしたりといったタスクを自動化する機能は、効率を高めるだけでなく、既存の開発ワークフローとの摩擦を減らすことにも役立ちます。したがってこれは、DevSecOpsの成功のための重要な要素です。
考慮すべき重要な要件の1つは、堅牢で自動化可能なAPIが提供されていて、カスタマイズ、および既存のワークフローとシステムへSCAプロセスの統合ができることです。セキュリティ監視のシステムをすでに構築していますか？APIがあれば、これらのシステムに結果を統合することができるはずです。継続的デリバリプロセスの一環としてビルドツールを使用していますか？SCA ツールが、プロセスの一環としてセキュリティテスト自動化のプラグインを提供することを確かめてください。
10. クラウドネイティブアプリケーションのセキュリティ
現代のアプリケーションは複数のコンポーネントで構成されており、エンドツーエンドのセキュリティカバレッジを提供するために、すべてのコンポーネントをスキャンしてセキュアにする必要があります。オープンソースのパッケージに加え、コンテナ、Infrastructure as Code（IaC）、カスタムコードが、今日のアプリケーションを組み立てるために使用されるビルディングブロックです。
コンテナのセキュリティについて、SCAツールは、少なくとも、コンテナイメージのセキュリティ脆弱性をスキャンできることと、コンテナのビルド・テスト・実行に使用されるワークフローやツール、システムに統合できることが必要です。より高度なソリューションでは修正手順も提供されます。たとえばSnyk は、コンテナのベースイメージを識別し、脆弱性を低減するアップグレードを推奨、加えて、脆弱性を修正するコンテナのビルドコマンドと依存パッケージを提供することで、コンテナの修正作業を簡単で迅速なものにします。
必要最低限のこと
各組織は、技術スタック、ユースケース、そしてもちろん利用可能なセキュリティ予算や優先順位などの様々な要因に基づいた異なるニーズを持っています。万能のSCAツールは存在しないのです。
しかし、少なくとも、また、早急な判断が必要ならば、選択するSCAツールが、使用しているすべてのオープンソースコンポーネントと、それらに含まれる脆弱性やライセンスを正確に検出できることを確認する必要があります。
もちろん、主要なエンドユーザーである開発者が実際にツールを活用することを確実にするため、開発者にとって使いやすいことも同様に重要です。例えば、世界で最も優れた脆弱性データベースがあっても、それが搭載されたSCAツールが現実に使われなければ、無駄になってしまいます。開発者が理解し、使い方を知っている、そしてあえて言うなら、楽しんで使えるSCAツールを選びましょう。
安全な開発を、迅速に！