ソフトウェア部品表 (SBOM) とは
ソフトウェア部品表 (SBOM) は、ソフトウェア・アプリケーションを構成するコンポーネントのリストです。このリストには、ソフトウェア製品内で使用されているすべてのコンポーネント、ライブラリ、モジュールが含まれ、他のソフトウェアが読み取ることのできる形式で提供されます。ソフトウェアのレシピを構成する材料のリストだと考えてください。
組織に SBOM が必要な理由
ほとんどの先進的なソフトウェアは、複数の既製のサードパーティ・コンポーネント (コードライブラリなど) を組み合わせて構築されています。多数のコンポーネントを組み合わせると、物事が複雑になります。
SBOM を作成して管理することで、それらのコンポーネントのバージョン、ライセンス、依存関係、および時間の経過とともに加えられた変更を追跡することができます。SBOM は信頼できる情報源として機能する最新のドキュメントであり、セキュリティリスクの特定および回避やコンプライアンス要件への対応に役立ちます。
製品のデジタル構成に透明性をもたらす SBOM は、ソフトウェア・ライフサイクルのあらゆる段階のユーザーにとって有用です。それらのユーザーには以下を実行する人々が含まれます。
- ソフトウェアの開発または製造： ビルダーは、コンポーネントが最新のものであり、ニーズに合致していることを確認できます。
- ソフトウェアの選択または購入： 購入者はソフトウェアの内部構成を分析することで、購入前にリスクを評価できます。
- ソフトウェアの運用：システム管理者と IT チームは、共通脆弱性識別子 (CVE) のリストと照合してソフトウェアをチェックできます。
- ソフトウェアの使用：ベースラインのセキュリティ対策の強化により、エンドユーザーとコンシューマーに間接的にメリットがもたらされます。
SBOM に含まれる情報
SBOM には、ソフトウェア・アプリケーション内のすべてのサードパーティ・コンポーネント、ライブラリ、モジュールと、それらを定義する属性がリストされています。米国商務省電気通信情報局 (NTIA) のような業界の標準フレームワークに基づき、SBOM には少なくとも次のものが含まれている必要があります。
コンポーネント名とサプライヤー名： ソフトウェアモジュールの名前と、それを開発した実体、ベンダー、またはオープンソース・メンテナー
バージョン番号：リリースバージョンやビルドバージョン (特定のコードに既知の欠陥があるかどうかを識別するのに役立ちます)
一意の識別子：自動化ツールがコンポーネントをグローバルな脆弱性データベースと照合するのに役立つ、標準化されたリファレンスキー (共通プラットフォーム列挙のパッケージ URL)(コードの中に既知の脆弱性が存在する場合にアラートで通知されます)
依存関係：コンポーネントがどのように連携し、何が何に依存しているかを示すマップ
ライセンス情報：コードの各部分を管理するオープンソースまたは商用ライセンス (Apache 2.0 や MIT ライセンスなど)
作成者とタイムスタンプのデータ： SBOM が作成された日時と作成責任者を記録するメタデータ
米国サイバーセキュリティ・インフラストラクチャセキュリティ庁 (CISA) は、これらの要件を拡張し、追加のガイダンスを含むアップデートされたリストをリリースしています。
SBOM の作成方法
SBOM はソフトウェアのビルドプロセス中に作成されます。SBOM は、継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインに統合されたソフトウェア構成分析 (SCA) ツールで作成されます。このプロセスでは、自動化されたスキャンを使用してオープンソース・パッケージやコードベース内のサードパーティ・コンポーネントを識別、管理、追跡し、そのデータを機械可読形式でエクスポートします。
SBOM のデプロイおよび配布方法
SBOM をデプロイするということは、インベントリー・メタデータ (ソフトウェア内の各コンポーネントを識別、ラベル付け、追跡する記述データ) をソフトウェアリリースにアタッチして、他のユーザーが読み取れるようにすることを意味します。
SBOM ファイルはリポジトリ内にあり、コンパイルされたコードバイナリーまたはコンテナイメージもそこに配置されています。商用ソフトウェアの場合、SBOM はアプリケーション・プログラミング・インタフェース (API) のエンドポイントやカスタマーポータルを通じて企業ユーザーに提供、またはセキュリティチームに直接提供されます。
SBOM の保守方法
SBOM は、いつでも表示できるスナップショットですが、絶えず進化しています。開発者が新しいコードをコミットしたり、ライブラリを更新したり、新しいプロダクションビルドをプッシュしたりするたびに、新しい SBOM バージョンが生成されます。
メンテナンスには監視も含まれます。SBOM の監視とは、専用の管理ツールを使用して、インベントリーの内容を National Vulnerability Database (NVD) などのデータベースと継続的に相互参照することです。このセットアップにより、新しい脆弱性が発見されたときにセキュリティチームに警告が発せられるため、セキュリティチームは迅速に対応することができます。
SBOM の主な形式と標準
SBOM は、自動化されたツールがソフトウェアアップデートを即座にスキャンして脆弱性を検出できるように構成されています。つまり、マシンが処理しやすいようにフォーマットされる必要があるということです。SBOM の主な標準には次のようなものがあります。
CycloneDX (OWASP)： アプリケーションのセキュリティとリアルタイムの脆弱性管理に重点を置く CycloneDX は、先進的なビルドパイプラインのための軽量なソリューションを必要とする、動きの速い DevOps チームに最適です。
Software Package Data eXchange (SPDX)：オープンソース・ライセンスのコンプライアンスと詳細な法的監査に重点を置く SPDX は、最も詳細な SBOM 形式を求めている企業のコンプライアンス担当者や法務チームに最適です。
Software Identification (SWID)： ソフトウェア資産管理 (SAM) とエンドポイント・インベントリーの追跡に重点を置く SWID は、ネットワーク上のデバイスにどの商用アプリケーションがインストールされているかを追跡したい IT システム管理者に最適です。
SBOM がセキュリティに役立つ仕組み
SBOM は、ソフトウェアの依存関係 (アプリケーションがタスクを実行するために利用する外部の事前記述済みコード) を、構造化された検索可能なデータに整理します。これによってリスクの自動検出が可能になります。具体的には、SBOM によって次のような複数の領域でサイバーセキュリティ対応が向上します。
ゼロデイ対応： 重大な脆弱性 (Log4j や Heartbleed など) が発生した場合、チームは SBOM インベントリーに対して 1 つのクエリを実行し、影響を受けるすべてのアプリケーションを数秒で強調表示することができます。
継続的なセキュリティ監視：スキャナーは SBOM をグローバルな脆弱性データベースと継続的に相互参照し、コンポーネントが安全でなくなった場合は自動的にチームに警告します。
過渡的な依存関係の可視性： ソフトウェアは、他のコンポーネントに依存するコンポーネントに依存します。これにより、一連のレイヤーおよび (過渡的な) 関係が作成され、それらは分析のために可視化する必要があります。SBOM はこれらのリンクをマッピングし、各接続の全体像を可視化できるため、コードの評価が容易になります。
SBOM とソフトウェア構成分析 (SCA)
ソフトウェア構成分析 (SCA) ツールは、ソフトウェアの依存関係を分析し、そのプロセスの一環として SBOM を生成します。SCA は SBOM を作成した後、SBOM を監視し、脆弱性スキャンのために外部データベースにクエリを実行します。
SBOM はストレージファイルであることに注意してください。何かをアクティブにスキャンするわけではありません。実際に作業を行うのは SCA であり、SCA が情報源として SBOM を使用します。
SBOM 導入の課題
SBOM は重要な情報を追跡し、透明性を提供しますが、導入にはいくつか課題があります。
ツールの不正確さや情報の欠落： 自動スキャナーは完璧ではありません。深くネストされた依存関係や曖昧な詳細情報を見逃してしまうため、ソフトウェア・インベントリーが不完全になる可能性があります。
アラート疲れ： セキュリティツールにより、重大ではない脆弱性まで検知し、大量の誤検出でチームを疲弊させてしまうことがあります。
一貫性のない命名： ツールやソフトウェアベンダーによっては、同じソフトウェアライブラリに異なる方法で命名する場合があります。このため、自動スキャナーでコンポーネントを正確に識別して脆弱性データベースと照合することが難しくなる場合があります。
ベンダーおよび知的財産に関する懸念： 商用ソフトウェアベンダーの中には、企業秘密やプロプライエタリー情報を誤って公開したくないため、顧客に完全な SBOM を公開することを懸念する場合があります。
専門知識の欠如： データを解釈し、脆弱性に対処する方法を決定するには、DevSecOps に関する専門的な知識が必要です。
SBOM のベストプラクティス
SBOM の有用性を最大限に活用するには、自動化を優先するとともにソフトウェア開発ライフサイクルを標準化する次のようなアプローチを採用する必要があります。
自動化と監視
- SCA ツールを CI/CD ワークフローに直接統合し、ビルドのたびに SBOM が自動的に生成されるようにします。
- ソフトウェアが更新、再コンパイル、または再パッケージされるたびに SBOM が自動的に生成される運用を定着させます。古いスナップショットに依存しないことが重要です。
- コンポーネントを継続的に監視して稼働中のセキュリティデータベースと照合できる自動化された脆弱性プラットフォームに、生成された SBOM をルーティングします。
標準、形式、メタデータ
- メタデータに、サプライヤー名、コンポーネント名、バージョン番号、直接的および一時的な依存関係など、最小限のベースライン要素を含めます。
- 命名における曖昧さを防ぐために、パッケージ URL (PURL)、共通プラットフォーム列挙 (CPE)、暗号学的ハッシュなどの標準化された識別子を付加します。
- CycloneDX や SPDX など、業界標準の機械可読形式を採用します。
- 社内製品全体で JSON または XML 形式を必須にして、処理を統一します。
ストレージ、セキュリティ、ガバナンス
- 各 SBOM バージョンをリポジトリ (JFrog Artifactory や GitHub Releases など) に保存し、特定のコードリリースに直接リンクさせます。
- SBOM を作成および変更する際には暗号署名を必須とします。
- 不完全なデータや一部がマスキングされたデータでソフトウェアを提供するサードパーティベンダーに自動的にフラグを立てる、または拒否するポリシーを確立します。
- 運用上の所有権を明確にすることで、各チーム (セキュリティ、法務、DevSecOps) が SBOM 内で必要なものを監視し、アクセスできるようにします。
SBOM とソフトウェア・サプライチェーンのセキュリティ
ソフトウェア・サプライチェーンを防御するためには、ソフトウェアがどのように作成され提供されたかを示す検証可能な証拠が必要です。
ソフトウェア・サプライチェーンに AI 要素を組み込む場合は、次のことを確実に実行してください。
- CI/CD における AI を、独自の認証情報とスコープを持つ新しい主体として扱う
- AI エージェントに到達するテキストはすべて、プロンプトインジェクションの可能性があると想定する
- 規制対象となるものだけでなく、あらゆるリリースの SBOM と AIBOM を生成する
- AI を使用して既知のパターンを大規模にスキャンする
- セキュリティ責任者を指名する。（「全員が責任者」は「誰も責任を負っていない」と同義）
同時に、次のことは必ず避けてください。
- AI が生成したプルリクエストを低リスクとして扱う
- 「AI がスキャンした」と「人間がレビューした」を混同する
- 署名の手順ををスキップする
AIBOM とは
AI 部品表 (AIBOM) は、従来の SBOM を拡張したものであり、モデルの重み、トレーニングデータソース、ファインチューニングの手順、推論の依存関係に関する詳細が含まれます。モデルの提供、組み込み、ファインチューニングを行うプロジェクトには、AIBOM が必要です。
SBOM のユースケース
さまざまな業界の組織が、SBOM を維持・管理することでメリットを得ることができます。コードを管理可能で透明性のあるデータに変換する SBOM は、サプライチェーンの違反や規制上の罰則から守るための重要な手段となります。また多くの場合、複数の関係者間における信頼構築や連携強化にも役立ちます。以下に、SBOM がデータ保護に役立つ例を紹介します。
医療
- HIPAA (米国医療保険の相互運用性と説明責任に関する法律) では、ePHI (保護対象電子健康情報) を処理するすべてのシステムに対して継続的なリスク評価を行うことを求めています。SBOM は、医療 IT ソフトウェアの脆弱性をスキャンするために必要な詳細なインベントリーを提供します。
- 医療機器メーカーは、ペースメーカー、点滴ポンプ、MRI システムなどのデバイスを市場に投入する前に、 SBOM を提出して脆弱なコードが含まれていないことを証明する必要があります。
金融
- モバイルバンキングおよび取引アプリケーションのセキュリティチームは、SBOM を使用してソフトウェア・コンポーネントを監視し、金融詐欺や個人データの漏洩などのリスクから顧客を保護しています。
- 金融機関が FinTech パートナーや決済ゲートウェイなどのサードパーティベンダーを利用する場合、SBOM は、リスクのある精査されていないコードがコア金融ネットワークに組み込まれるのを防ぐのに役立ちます。
政府機関
- SBOM は、軍事機器や人工衛星システムにデプロイされたソフトウェアの出所や整合性を検証するのに役立ちます。また、この情報はサプライチェーンの改ざんを防ぐのに役立つだけでなく、悪意ある人物によって悪用されかねないソフトウェアの脆弱性を政府機関が特定するのにも役立ちます。
- SBOM は、都市の水道、電力網、送電網などを動かす産業用制御システム内のコンポーネントの監視に使用できます。
テクノロジー
- SaaS (Software-as-a-Service) を販売する企業は、SBOM を共有することでセキュリティ監査プロセスをスピードアップし、より迅速に契約を締結することができます。
- 開発中に SBOM メタデータをスキャンすることで、コードがコンパイルされて法的責任にさらされる前に、制限的ライセンスを検出することができます。
AI 駆動型の自動化に関する業界トレンド
グローバルなソフトウェアエコノミーにおいて競争力の維持を目指す企業にとって、SBOM の作成と維持はもはや必須です。欧州連合サイバーレジリエンス法 (EU CRA) などの規制フレームワークは、EU で販売されるすべてのデジタル製品にソフトウェア・サプライチェーンの透明性を求めています。これらの規制に基づき、製造業者は脆弱性を 24 時間以内に EU のサイバーセキュリティ当局に報告する必要があります。エンジニアリングチームにとって、自動化された SBOM を維持することは、この期限を守るのに十分な速さでコードを監視できる最も実用的な方法です。
規制の観点からスピードと透明性への期待が高まる中、テクノロジー業界はそのスピードに対応しようとしています。具体的には以下のことが見られます。
SBOM の自動生成
先進的なソフトウェア開発スピードは加速し、チームが手作業でインベントリーを作成して対応する方法では追いつかなくなりました。そのため組織は、ソフトウェア構築プロセスの各段階で SBOM を自動的に作成するツールに投資しています。
継続的な検証、監査、ガバナンス
業界は SBOM を 1 回限りのコンプライアンス・チェックポイントとして扱うのではなく、SBOM 中心のワークフローを採用してソフトウェア・サプライチェーンを継続的に管理しています。
AI 駆動型の脆弱性自動修正
SBOM は脆弱性を見つけるのには役立ちますが、修正することはできません。従来、コード内の脆弱性を発見するには、アプリケーションをオフラインにして、コミュニティやチームがパッチを適用するのを待つ必要がありました。今ではハッカーが AI を使用して、人間の開発者が修正を作成するよりも早く脆弱性を悪用しています。この速度に対応するために、各業界は AI を使用してリスクを自動的に識別し、リアルタイムで修復することを検討しています。多くの場合、これにはバックポートされたセキュリティパッチと呼ばれる手法が含まれます。
バックポートされたセキュリティパッチとは
ジャケットの破れを新しい布で直すように、バックポートされたパッチは、より新しくて丈夫な素材を使用して破損したものを修復します。
バックポートされたセキュリティパッチは、コードの一部 (新しいバージョンのソフトウェアでセキュリティ修正として機能する) を抽出し、それを古いバージョンのソフトウェアに組み込みます。このソリューションは新しいバージョンにアップデートするよりも混乱が少なく、新しい機能や API の変更が導入されないため、ソフトウェア・アーキテクチャの安定性を維持できます。
Red Hat のサポート内容
Red Hat は SBOM の作成、管理、自動化における経験を活かし、組織がソフトウェア・サプライチェーンを保護し、進化するコンプライアンス基準に対応できるよう支援します。Red Hat は、Lightwell などの戦略的なセキュリティ・イニシアチブを通じて、ソフトウェア・サプライチェーンのセキュリティの向上を継続的に推進しています。
Lightwell は、Red Hat と IBM が共同で推進する、オープンソースソフトウェアのサプライチェーンの保護を目的とした取り組みです。これは SBOM の継続的デリバリーおよび信頼検証レイヤーとして機能します。Lightwell は、AI 駆動のエンジニアリングを使用して、オープンソースコードのコード修正を生成、検証、デプロイします。また、バックポートされたセキュリティパッチ、署名済みのコンプライアンス適合アーティファクト、および更新された SBOM ドキュメントを提供することで、強制的なバージョンアップを行わずにエンタープライズ向けオープンソースを維持管理する Red Hat の定評あるモデルを拡張します。
