小規模なスタートアップから数十億ドル規模の大企業まで、ソフトウェアを開発する組織のほとんどは、サードパーティ製のライブラリやツールを使用して自社アプリケーションを開発しています。モダンなアプリケーションのソフトウェアをビルドして顧客にリリースするには、多くの外部コンポーネントが欠かせません。こうしたライブラリやツールをまとめてソフトウェアサプライチェーンと呼びます。
一般的な Web アプリ開発のソフトウェアサプライチェーンのコンポーネントとしては、下記のようなものがあります。
- 実行される Linux インスタンス
- libcrypt や glibc など、システム全体で使用する共有ライブラリ
- npm、NuGet、Maven などのパッケージリポジトリからインストールされるオープンソースのフレームワークやライブラリ
- 別のアプリケーション (または Stack Overflow) からコピーされたソースコード群
- データベースやインメモリキャッシュなど、ソフトウェアの補助となるアプリケーション
- jQuery、D3、React などの JavaScript ライブラリ
- Apache、IIS、nginx など、ソフトウェアを支える基盤サービス
こうしたコンポーネントのうちのいずれかにセキュリティ上の欠陥があると、その脆弱なコンポーネントが組み込まれているあらゆるアプリケーションに影響がおよびます。アクセス対象または処理対象のデータすべてが危険にさられてしまうのです。こうしたサプライチェーンの脆弱性は、脅威アクターが目的のネットワークに入り込むために悪用されます。サプライチェーンへの侵害事例では、2020 年に発覚した SolarWinds 社製ソフトウェアへのハッキングと、2021 年の Log4j 脆弱性問題の 2 件をご存じの方も多いでしょう。
そこで、ソフトウェアサプライチェーンの脆弱性を低減する一つの方法となるのが、ソフトウェア部品表 (SBOM) を整備することです。
SBOM (Software Bill Of Materials: ソフトウェア部品表)
ソフトウェア部品表 (SBOM:Software Bill Of Materials) の活用は、ソフトウェアサプライチェーンへのサイバー攻撃を減らす戦略としてきわめて効果的です。SBOM では、お気に入りの料理に必要な食材をすべてまとめたレシピのように、ソフトウェアアプリケーションのコンポーネントをすべて列挙します。
SBOM に記載するものは、ソフトウェアアプリケーションを構築するためのライブラリ、コードパッケージ、その他のサードパーティ製コンポーネントなどです。また、次の情報も含めます。
- 各コンポーネントのライセンスの種類 (シェアウェア、オープンソース、商用)
- コンポーネントのバージョン
- パッチの適用状況
- ソフトウェアサプライチェーンでの各コンポーネント間の依存関係
また、SBOM の重要性はセキュリティにとどまりません。SBOM は、ソフトウェアアプリケーションに関わるすべてのコンポーネントの透明性を確保し、追跡可能とすることにより、主要なデータ保護規則への準拠状況を示す材料にもなるのです。
SBOM に含まれる情報は、ソフトウェアサプライチェーンへのサイバー攻撃を防止するうえで非常に重要なため、米国商務省からこのトピックスに関するさまざまな文書が出されています。
さらに、米国商務省電気通信情報局 (NTIA) からは、以下のように、ソフトウェア自体や関連メタデータを特定する SBOM 構成要素リストを作成するための 3 つのフォーマットも示されています。
- SPDX (Software Package Data Exchange): SBOM の構成要素リストを作成するためのオープン規格であり、ソフトウェアコンポーネント、コンポーネントのライセンス、著作権、セキュリティリファレンスの情報をすべて含められます。
- OWASP CycloneDX: 軽量の SBOM 規格であり、リスク分析を目的として自社およびサードパーティ製のソフトウェアコンポーネントの詳細をすべて記載したリストを作成できます。CycloneDX フォーマットでは、アプリケーション、コンテナ、ライブラリ、ファイル、ファームウェア、フレームワーク、オペレーティングシステムなどのコンポーネントの種類を記録できます。
- SWID (Software Identification) タグ: 国際標準化機構 (ISO) と国際電気標準会議 (IEC) により設計されたソフトウェア識別規格です。XML ファイル形式であり、ソフトウェアコンポーネントとそれらのライセンス、パッチの適用状況、インストールバンドルの情報を記録します。
SBOM が重要な理由
ソフトウェアの脆弱性と侵害事例の主な原因は、ソフトウェアサプライチェーン、つまり、アプリケーションのコーディング、ビルド、実行に使用されるあらゆるツールやフレームワークやライブラリにあります。ソフトウェア開発の現場では、個人でも組織でも、多くのアプリケーション間でコード、ソフトウェアパッケージ、ライブラリを再利用することがますます一般的になっています。また、多くのサードパーティベンダーは、商用のコードパッケージを、Office 365 のような広く使われている生産性向上アプリケーションに組み込める状態で販売しています。
このようにソフトウェアアプリケーションの開発は複雑化しているので、それぞれのアプリケーションを開発するためのコンポーネント一式を一覧化することがきわめて重要です。一覧化により、機密リソースが悪意あるユーザーによる不正アクセスを受ける前に、セキュリティ上の脆弱性を検知して解決することが可能になるからです。
SBOM を使うべき理由には、他にも次のものがあります。
- 脆弱性のあるコンポーネントをソフトウェアプロジェクト間で再利用する事態を回避できる
- 現行のアプリケーションが抱える脆弱性をつきとめやすくなる
- ソフトウェアアプリケーションに使用されているすべてのコンポーネント (およびそれらの依存関係) を把握することで、ソフトウェアサプライチェーンのリスク管理を強化できる
- アプリケーションコンポーネントの一覧およびそれらに関連する特性の情報もすべて提示することにより、さまざまなデータ保護規則への準拠を進められる
- ソフトウェアベンダーにとっては、アプリケーションの SBOM を用意することで取引先に選ばれやすくなる
- 自社の IT 環境にあるあらゆるソフトウェアアプリケーションの構成要素を管理しやすくなる
- ソフトウェア開発ライフサイクル (SDLC) 初期の設計段階で脆弱な部分を検出することにより、無駄な時間と労力を省くことができる
- ソフトウェアサプライチェーンに関連するセキュリティリスクに対して必要な注意を喚起することができる
米国政府は大統領命令を発し、ソフトウェアサプライチェーンのセキュリティ強化計画を策定するよう、連邦政府各機関に指示しています。これにより、多くの事業者も追随する動きを見せています。
SBOM の生成方法
SBOM は、組織でも個人でも、手動または自動化テクノロジーを利用して生成できます。手動生成は小規模なプロジェクト向きであり、プロジェクトの規模が大きいと適さない場合があります。
手動で生成する方法
ソフトウェアコンポーネントをすべて、スプレッドシートまたは同様のファイルに手動で入力していきます。各コンポーネントのバージョン情報、ライセンス情報、依存関係の情報、追加の関連情報があればそれらも併せて入力します。
この方法は、コンポーネント数が少ない小規模プロジェクトには適していますが、大規模プロジェクトにはまったく向いていません。ZDNet によると、たいていの GitHub プロジェクトの依存関係は 700 近くあります。エンタープライズレベルのシステムであれば、さらに多いことでしょう。直接的および推移的な依存関係が数千にも及ぶプロジェクトの SBOM を手作業で生成するのは、まったく現実的な話ではありません。
また、手動ではヒューマンエラーも起こりやすくなります。依存関係を更新したのに SBOM の更新は忘れるということも珍しくありません。
自動で生成する方法
ほとんどのプロジェクトにとっての最善の方法は、SBOM 生成を自動化することです。自動であれば、言語、ライブラリ、Docker イメージなど、どのコンポーネントの情報もすべて最新の状態に保てます。
自動ツールを継続的インテグレーション & 継続的デリバリー (CI/CD) パイプラインに組み込めば、ソフトウェアをすべてスキャンし、関連コンポーネントの情報を随時更新できます。よく知られている依存関係スキャナーには Snyk と Anchore があります。
また、ほとんどの SBOM 生成ツールは、CI/CD ツールに適切に組み込めます。こうしたツールがあれば、ソフトウェアプロジェクトを自動的にスキャンし、プロプライエタリとオープンソースの両方のソフトウェアコンポーネントと、サードパーティ製ライブラリのライセンスや依存関係などの関連属性をすべて記録できます。
まとめ
SBOM には、コンプライアンス面やセキュリティ面、各アプリケーションのライセンス契約事項の管理の面において、たくさんのメリットがあります。さらに SBOM の生成を自動化することにより、情報を漏れなく記録し、最新に保つことが容易になります。
SBOM を使用し、コンポーネントの構成要素をサイバー脅威インテリジェンスフィードとリンクすれば、アプリケーションに潜むゼロデイ脆弱性をスピーディーに突き止めることができます。そうすることで、組織のソフトウェアの完全性に重大なダメージが及ぶ前に、脆弱性の修正を行えます。
ソフトウェアセキュリティ強化のために CI/CD パイプラインに依存関係スキャナーと SBOM 生成ツールを組み込む方法についての記事も、是非ご覧ください。
