このブログは アプリケーション・セキュリティ・テストツールの市場分類を紹介する、WhiteSoure社のブログ翻訳シリーズの第2回です。
前回の1回目では、市場分類 の概要を説明し、開発からリリース前の間に脆弱性を検出し修正するための「セキュリティ・スキャン」と リリース後のアプリケーション環境を攻撃から守るための「ランタイム・プロテクション」の大きく2つに分かれていることを説明しました。

今回からは、WhiteSourceを含む「セキュリティ・スキャン」分野を掘り下げてお伝えしていきます。
まずは、WhiteSourceのソフトウェア構成分析 (Software Composition Analysis : SCA) を紹介します。

SCAは、次回以降に説明するSAST・DAST・IAST と異なり、脆弱性を検査する対象がオープンソースコンポーネントであることが一番の特徴です。
この辺りを踏まえてお読みいただくとSCAの特徴や優位性がより理解できるかと思います。

オープンソースコードはどこにでもあり、セキュリティリスクを軽減するために管理する必要があります。

開発者は、魅力的で信頼性の高いアプリケーションをこれまで以上に早く作ることを求められています。
そのために、開発者はオープンソースコードに頼ることで、自社のプロプライエタリなソフトウェアに素早く機能を追加しています。
オープンソースコードは、プロプライエタリアプリケーションのコードベースの60〜80％を占めると言われており、組織のセキュリティリスクを軽減するためには、オープンソースコードの管理が重要になっています。

ソフトウェア構成分析ツールは、オープンソースの使用を管理することに役立ちます。

■ソフトウェア構成分析とは？

ソフトウェア構成分析 (Software Composition Analysis : SCA）は、アプリケーション・セキュリティ・テスト（AST）ツール市場の中で、オープンソース・コンポーネントの利用に関する管理を扱う分野になります。
SCAツールは、アプリケーションのコードベース（コンテナやレジストリなどの関連するアーティファクトを含む）を自動スキャンし、すべてのオープンソース・コンポーネントとそのライセンス・コンプライアンス・データ、およびセキュリティ脆弱性を特定します。
SCAツールの中には、オープンソースの使用状況を可視化するだけでなく、オープンソースの脆弱性の修正を支援するための優先順位付けや自動修復機能を持つ物もあります。

【インベントリ】

SCAツールは通常、プロダクトに含まれるすべてのオープンソース・コンポーネントのインベントリ・レポートを生成するためのスキャンから始まり、すべての直接的および間接的な依存関係を含みます。
すべてのオープンソース・コンポーネントの詳細なインベントリを持つことは、オープンソースの使用を管理することの基礎となります。
結局のところ、自分達が使っているコンポーネントのことを知っていなければセキュリティやコンプライアンスを確保することはできません。

【ライセンスの遵守】

すべてのオープンソース・コンポーネントが特定されると、SCAツールは各コンポーネントの情報を提供します。
これには、コンポーネントのオープンソースライセンスの詳細、帰属要件、およびそのライセンスが組織のポリシーに適合しているかどうかが含まれます。

【セキュリティの脆弱性】

ソフトウェア・コンポジション分析ツールの主な機能の1つは、既知の脆弱性を持つオープンソース・コンポーネントを特定することです。
優れたSCAソリューションは、既知の脆弱性を持つオープンソース・ライブラリを教えてくれるだけでなく、コードが脆弱性を持つライブラリを呼び出しているかどうかを教え、該当する場合には修正を提案してくれます。
また、更新やパッチが必要なオープンソース・ライブラリも特定します。

【高度なSCA機能】

高度なSCA機能には、自動化された承認ワークフローの開始からビルドの失敗までのような様々なレスポンスをトリガーにして、コードに含まれるすべてのオープンソース・コンポーネントを組織のポリシーと照合させる、自動ポリシー実行があります。

主要なSCAソリューションは、オープンソースの選択、承認、追跡の全プロセスを自動化します。
中にはプルリクエストによってコンポーネントに脆弱性が入り込む前に、開発者に警告することができるものもあります。
これにより、開発者の貴重な時間を節約し、精度を高めることができます。

■ソフトウェア構成分析の進化

2002年の初めに、最初のオープンソースの手動スキャナがリリースされました。
組織のコードベースの可視性は向上したものの、この初期の技術では偽陽性の割合が高く、解決するためには手動による干渉が必要であり、アジャイル開発環境のニーズを満たしていませんでした。

2011年には技術が向上し、数年後には脆弱性やライセンスの問題をリアルタイムで自動検出できるようになっていました。
これにより、ソフトウェアチームやセキュリティチームは、オープンソース管理のシフトレフトが可能になりました。同時に、SCAソリューションは、リポジトリ、ビルドツール、パッケージマネージャ、CIサーバなどのソフトウェア開発ツールとの統合も進み、オープンソース管理とセキュリティの力を開発者の手に委ねることができるようになった。
このような進歩にもかかわらず、SCAは依然として検出に重点を置いていました。

【検知だけでは不十分】

オープンソースの普及に伴い、オープンソースに存在する既知の脆弱性の数も増加しています。
開発者やセキュリティ担当者が日々扱うアラートの量を考慮すると、すべてがノイズになってしまいます。

検知だけに焦点を当てても、それは最初の一歩に過ぎません。
それだけでは、組織のリスクを減らすことはできません。
対策のない検知は、不完全なアプリケーション・セキュリティ・モデルです。

では、どうすればよいのでしょうか。
Gartner社のアナリストであるNeil MacDonald氏は、"10 Things to Get Right for Successful DevSecOps (DevSecOpsを成功させるために必要な10のこと)" の中で、「完璧なセキュリティは不可能である。リスクをゼロにすることは不可能である。継続的なリスクと信頼に基づくアプリケーションの脆弱性の評価と優先順位付けをDevSecOpsに導入しなければならない。」 と述べています。

今日の脅威の状況に対処するためには、完璧を目指す必要はありませんが、前に進み続ける必要があります。
そのためには、組織は、開発者とセキュリティ専門家が本当に重要なことに集中できるように、検出に加えて優先順位付けと修復を含む成熟したSCAセキュリティモデルを採用する必要があります。

【優先順位付けと修復】

SCAソリューションは現在、検知と修復の間のギャップを埋めています。

優先順位付け(Prioritization)：成熟したソフトウェア構成分析ツールには、オープンソースの脆弱性に優先順位をつける技術が含まれているはずです。
重大なリスクをもたらすセキュリティ脆弱性を自動的に特定することで、組織はこれらの優先度の高い物を最初に対処することができます。
開発者やセキュリティの専門家は、どの脆弱性が最も重要かを判断するために何ページにもわたって警告を読み解いて時間とリソースを無駄にすることが無くなり、悪用可能な重要な脆弱性を本番システムに放置することもありません。

修復(Remediation)：優先順位付けの後には修正があります。
脆弱性を自動的に修正することで、単に脆弱性がどこにあるかを開発者に示すだけでなく、実際に修正を提案し、その修正がビルドにどの程度の影響を与えるかについてのデータを提供します。
自動修復ワークフローは、脆弱性の検出、脆弱性の深刻度、CVSSスコア、または新しいバージョンがリリースされたときに起動するセキュリティ脆弱性ポリシーに基づいて開始することができます。
最も確実なリスク軽減策の一つは、オープンソースのコンポーネントに継続的にパッチを当て、既知の脆弱性にさらされないようにすることです。
優れたSCAソリューションは、この実現に役立ちます。

先進的なSCAツール（リポジトリ、ブラウザ、IDEなどとの統合）は、ソフトウェア開発ライフサイクル（SDLC）にシームレスに統合され、脆弱性の修正が容易で安価な時期に早期解決することができます。

■ソフトウェア構成分析要求

Forrester社の 2019 Software Composition Analysis Waveでは、SCAツールを探している組織に、適切なベンダーを選ぶためのヒントを提供しています。
私たちはこのリストに含めたいことを幾つか紹介します。

【包括的なデータベース】

データベースは、あらゆるSCAソリューションの心臓部です。
複数のソースからデータを集約した包括的なデータベースであればあるほど、オープンソース・コンポーネントとセキュリティの脆弱性を特定するのに適しています。
包括的で継続的に更新されるデータベースがなければ、オープンソース・コンポーネントの適切なバージョンを検出してライセンスを更新したり、セキュリティ脆弱性を修正したり、アップデートやパッチを適用したりすることができなくなります。
オープンソース・コミュニティは非常に分散化されています。
アップデートやパッチに関する情報源を一元管理できないため、すべてをデータベースに頼ることになります。

【幅広い言語のサポート】

SCAソリューションは、現在使用している言語だけでなく、1～2年以内に使用を検討している言語もサポートする必要があります。
SCAソリューションを導入しても、1年後に最新のプロジェクトで使う言語をサポートしていないことに気づくといったことは避けたいものです。
計画的に、幅広い言語をサポートするソリューションを選択してください。

【豊富なレポート】

インベントリ、ライセンス、属性、デューデリジェンス(当然行うべき努力) などのレポートから、脆弱性や深刻度の高いバグのレポートまで、管理、法務、セキュリティ、DevOps、そしてDevSecOpsなど、あらゆるユースケースに合わせた幅広いレポートツールを提供するソリューションが必要です。

【堅牢なポリシー】

組織独自のニーズを定義できるように、堅牢でありながら高い柔軟性とカスタマイズ性を持つ自動化ポリシーを備えたソリューションを選択してください。
オープンソースの選択、承認、追跡、および修復のプロセスを自動化するポリシーは、開発者の時間を節約し、正確性を大幅に向上させます。

【脆弱性の優先順位付けと修復】

先に述べたように、セキュリティ脆弱性に優先順位をつけ、修復のためのアドバイスを提供するソリューションが必要です。
自動化を進めれば進めるほど、開発を遅らせることなく、最も重要な問題を最初に解決することが容易になります。

【ガバナンスと開発者 の2つに着目】

SCAのソリューションは、大きく分けて2つのカテゴリーに分かれます。

• ガバナンスソリューションとしては、経営陣、セキュリティチーム、DevOpsチーム、法務チームによって使用され、組織のソフトウェアポートフォリオ全体の可視性とコントロールを提供します。
• デベロッパーツールとしては、開発環境に統合されたツールを使ってコードから脆弱性が検出されたオープンソースコンポーネントの利用を回避し、修正するのに役立ちます。

最良のSCAソリューションは、ガバナンスと開発者ツールの両方を提供します。
これにより、誰もが必要なツールを、必要なときに、必要な場所で利用できるようになります。

【DevOps パイプラインとの統合】

SDLCのすべての段階で、リポジトリ、ビルドツール、パッケージマネージャ、CIサーバなど、さまざまな開発環境とシームレスに統合するSCAソリューションを選択してください。
これにより、開発者はプルリクエストを行う前に、オープンソースコンポーネントを使用できるかどうかを判断することができます。

【コンテナ/Kubernetes】

コンテナとKubernetesの使用は広く普及していますが、セキュリティは依然として課題となっています。
SCAソリューションは、コンテナ化された環境の中からオープンソース・コンポーネントをスキャンし、脆弱性やコンプライアンス上の問題を特定し、自動的にポリシーを適用することができます。
また、特定のコンテナレジストリをネイティブにサポートしているかどうかも確認してください。

■SCAがアプリケーション・セキュリティ・ポートフォリオの一部であるべき理由

オープンソース・コンポーネントは、あらゆる業種のソフトウェア・アプリケーションで主要な構成要素となっています。
ですが、オープンソースへの依存度が高いにもかかわらず、多くの組織で未だ、オープンソース・コンポーネントが基本的なセキュリティ基準を満たしているかどうか、ライセンス要件を遵守しているかどうかの確認が行われていません。

今の複雑なデジタル世界の中でアプリケーションを保護することは難しいことです。
適切なソフトウェア構成分析ソリューションを使用すれば、オープンソースのリスクを軽減することに一歩近づくことができます。

WhiteSource社のブログ本文の中にもありましたが、昨今のソフトウェア開発において オープンソースコンポーネントの利用は欠かせなくなっています。
このため、アプリケーションのために開発したコード(プロプライエタリ・コード) の脆弱性をスキャンするだけでなく、アプリケーションの脆弱性をカバーすることも重要になります。

更に SCA には 脆弱性の検出以外にも オープンソース ライセンス をチェックする機能もあります。
世の中には多くのオープンソースコンポーネントがあり、開発者は比較的に自由にそれらを利用でき反面、ライセンスについて見落としがちになり、リリースした後で思わぬ問題が発生することも少なくありません。
SCAツールを導入することで、オープンソースコンポーネントの脆弱性の検査 と ライセンス・コンプライアンスへの準拠 を管理しやすくするメリットがあります。

リックソフトが取り扱っている WhiteSource は グローバルにおいてトップレベルの評価を得ているSCAツールとなります。
このWhiteSource と 次回以降に説明する SAST・DAST・IAST ツールを併用することで、お客様のアプリケーションの脆弱性を可能な限り減らすことが出来る筈ですので次回以降のブログも楽しみにしていてください。

このブログはWhiteSource社の許可の下、
https://resources.whitesourcesoftware.com/blog-whitesource/software-composition-analysis を翻訳したものです。

WhiteSource社とWhiteSourceについては、WhiteSource.com および弊社の製品紹介ページをご覧ください。