SBOMとは何か

重要なポイント

ソフトウェア部品表（SBOM）は、アプリケーションで使用されるオープンソースおよびサードパーティのソフトウェアパッケージをすべてリストアップします。
これは、サードパーティ製ソフトウェアのセキュリティ、ライセンスコンプライアンス、およびその他のリスクを監視および評価するために使用することができます。
SBOMには複数の形式があり、最も一般的なのはCycloneDXとSPDXです。
SBOMはプログラムで生成し、ソフトウェアのビルドプロセスに組み込むことができます。

そもそもSBOMとは何か？

現代のソフトウェアは、より速く革新し、プロジェクトのユニークな側面に焦点を当てるために、オープンソースパッケージを使用して組み立てられています。ソフトウェア開発プロセスは、オープンソースコンポーネントが部品や原材料として機能し、新しい製品に組み立てられるという、従来の製造プロセスに酷似しているのです。

従来の製造業における部品表（BOM）は、最終製品を構成するすべての原材料、製造部品、数量のリストです。製造や流通のあらゆる段階で、欠陥や不良のある部品を素早く特定できるため、コンプライアンス、リスク管理、製品の安全性確保に有効です。

ソフトウェア部品表（SBOM）とは、アプリケーションに含まれるすべてのパッケージとライブラリのリストを指します。これは、デジタル版の製造業の部品表のようなものです。部品表がすべてのサブアセンブリを含むように、SBOMは推移的依存関係またはコンポーネントの依存関係も含みます。そして、従来の部品表と同様に、SBOMは、危険なパッケージがアプリケーションに含まれているかどうかを簡単に確認することができます。

ソフトウェア部品表は、プロジェクトの依存関係を管理し、オープンソースコンポーネントのリスクを管理するための最初のステップとなります。近年、オープンソースコンポーネントを標的としたサイバー攻撃が急増しており、ソフトウェアのサプライチェーンへの攻撃は2021年だけで300%も増加しています。SBOMは、依存関係を把握し、脆弱性、ライセンス問題、その他のリスクのあるコンポーネントを探すために使用することができます。ベンダーによっては、自社のセキュリティ管理のために、ソフトウェア購入時にSBOMを要求するところもあります。米国電気通信情報局は、ソフトウェア部品表に関するガイドラインを共同で発表し、将来的にベンダーにSBOMを要求するための土台を築きました。これらの規格は、その使用に関する情報を含むSBOMの最低要件を概説しています。最低要件は以下の通りです。

データフィールド – 必須のデータフィールドは、コンポーネントの識別のための一般的な情報を提供し、サプライヤ名、コンポーネント名、バージョン、依存関係、SBOMの作成者、およびデータがSBOMに追加された時間を含んでいます。
自動化サポート – SBOMは、自動的に生成し、解析するためのサポートを含まなければなりません。自動化をサポートする目的は、組織間の相互運用性です。ある組織からのSBOMは、新しいツールを採用する必要なしに、簡単に解析できるべきです。現在、SPDX、CycloneDX、ソフトウェア識別タグがこの自動化サポートに対応したフォーマットとして受け入れられています。
実践とプロセス – このセクションでは、ソフトウェア部品表を使用するための要件を概説し、頻度、深さ、アクセス、および既知の不明点の文書化に関するガイダンスを提供します。

NITAの仕様詳細はこちら

なぜSBOMが必要なのか？

ソフトウェア部品表の主な利点は、アプリケーションの依存関係を一貫性のある読みやすいプロファイルにすることです。このレポートは、プロジェクトのビルドステップ中に自動的に生成され、常に最新の依存関係情報を確保することができます。また、SBOMは依存関係のリストアップ方法を標準化し、エコシステムに関係なく、一貫して簡単にレビューすることもできます。つまり、開発者やセキュリティ専門家にとって、ソフトウェア部品表は、新たに公開された脆弱性をチェックするための素晴らしい手段なのです。また、この標準化により、自動化も容易になります。例えば、Nexus LifecycleのInnerSource Insight機能は、ネイティブではSBOMのないJavaとnpmしかサポートしていませんが、ソフトウェア部品表があれば十数種類のエコシステムに対応することができます。

依存関係データを標準化することで、これらの情報を共有することが可能になります。ソフトウェア部品表を標準フォーマットで提供することで、あなたの顧客は、その情報をどのように利用すればよいかを知ることができます。

SBOMはすべて同じなのか？

ライブラリやソフトウェアコンポーネントの標準化されたリストという考え方は新しいものではありません。長い間、さまざまなソフトウェアグループがソフトウェア部品表のための複数の異なるフォーマットを作成し、それぞれが独自の目的と利点を持つようになりました。ここでは、最も一般的な2つのSBOM形式を紹介します。

CycloneDX – Open Web Application Security Project (OWASP)が作成したSBOMフォーマットで、サイバーセキュリティを考慮して構築されました。Sonatypeではこの形式を好んで使用しており、弊社製品でサポートしているSBOM形式でもあります。CycloneDXの最大の利点は、SBOMに脆弱性情報を含めることができること、または、コンポーネントの脆弱性情報と共に誤検知を示すことができる独立したVEX（Vulnerability Exploitability Exchange）にリンクすることができることです。
SPDX (Software Package Data Exchange) – このフォーマットは、パッケージデータの収集と共有を容易にするために、Linux Foundationによって開発されました。主な焦点は、セキュリティよりもむしろライセンスコンプライアンスです。

CycloneDXとSPDXは、米国電気通信情報局（National Telecommunications and Information Administration）のソフトウェア部品表（Software Bill of Materials）の最低要件を満たしています。以下は、CycloneDX 1.4 SBOMの一例です。

<?xml version="1.0" encoding="UTF-8"?>  
<bom xmlns="http://cyclonedx.org/schema/bom/1.4" serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79" version="1">  
  <metadata>  
    <component type="application" bom-ref="acme-app">
      <name>Acme Application</name>
      <version>9.1.1</version>  
    </component>  
  </metadata>  
  <components>  
    <component type="library">  
      <name>acme-library</name>   
      <version>1.0.0</version>
      <hashes>
        <hash alg="SHA-1">9188560f22e0b73070d2efce670c74af2bdf30af</hash>
        <hash alg="SHA-256">d88bc4e70bfb34d18b5542136639acbb26a8ae2429aa1e47489332fb389cc964</hash>
      </hashes>
      <cpe>cpe:/a:acme:application:9.1.1</cpe>
    </component>
    <component type="library">
      <group>com.fasterxml.jackson.core</group>
      <name>jackson-databind</name>
      <version>2.8.0</version>
      <licenses>
        <license>
          <id>Apache-2.0</id>
        </license>
      </licenses>
      <purl>pkg:maven/com.fasterxml.jackson.core/[email protected]?type=jar</purl>
    </component>
  </components>
  <vulnerabilities>
    <vulnerability>
      <id>CVE-2018-7489</id>
      <source>
        <name>NVD</name>
        <url>https://nvd.nist.gov/vuln/detail/CVE-2019-9997</url>
      </source>
      <ratings>
        <rating>
          <source>
            <name>NVD</name>
            <url>https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H&version=3.0</url>
          </source>
          <score>9.8</score>
          <severity>critical</severity>
          <method>CVSSv3</method>
          <vector>AN/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H</vector>
        </rating>
      </ratings>
      <cwes>
        <cwe>184</cwe>
        <cwe>502</cwe>
      </cwes>
      <description>FasterXML jackson-databind before 2.7.9.3, 2.8.x before 2.8.11.1 and 2.9.x before 2.9.5 allows unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 deserialization flaw. This is exploitable by sending maliciously crafted JSON input to the readValue method of the ObjectMapper, bypassing a blacklist that is ineffective if the c3p0 libraries are available in the classpath.</description>
      <recommendation>Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.6.7.5, 2.8.11.1, 2.9.5 or higher.</recommendation>
      <advisories>
        <advisory>
          <title>GitHub Commit</title>
          <url>https://github.com/FasterXML/jackson-databind/commit/6799f8f10cc78e9af6d443ed6982d00a13f2e7d2</url>
        </advisory>
      </advisories>
      <created>2021-01-01T00:00:00.000Z</created>
      <published>2021-01-01T00:00:00.000Z</published>
      <updated>2021-01-01T00:00:00.000Z</updated>
      <analysis>
        <state>not_affected</state>
        <justification>code_not_reachable</justification>
        <responses>
          <response>will_not_fix</response>
          <response>update</response>
        </responses>
        <detail>An optional explanation of why the application is not affected by the vulnerable component.</detail>
      </analysis>
      <affects>
        <target>
          <ref>pkg:maven/com.fasterxml.jackson.core/[email protected]?type=jar</ref>
        </target>
      </affects>
    </vulnerability>
  </vulnerabilities>
  <dependencies>
    <dependency ref="acme-app">
      <dependency ref="pkg:maven/org.acme/[email protected]?type=jar" />
      <dependency ref="pkg:maven/org.acme/[email protected]?type=jar" />
    </dependency>
    <dependency ref="pkg:maven/org.acme/[email protected]?type=jar">
      <dependency ref="pkg:maven/org.acme/[email protected]?type=jar" />
    </dependency>
    <dependency ref="pkg:maven/org.acme/[email protected]?type=jar">
      <dependency ref="pkg:maven/org.acme/[email protected]?type=jar" />
    </dependency>
    <dependency ref="pkg:maven/org.acme/[email protected]?type=jar" />
  </dependencies>
</bom>

クリエイターのためのSBOM

プロジェクトを構築する組織にとって、部品表を管理することは、プロジェクトの依存関係を追跡するのに有効な手段です。アプリケーションのパッケージのバージョンを正確に記録しておけば、脆弱性のあるコンポーネントを簡単に見つけることができます。依存関係の情報を保存するために単一の標準を使用することによって、開発者とセキュリティチームは、脆弱なコンポーネントを見つけるために標準化されたプロセスを使用することができます。また、より一貫性を持ち、エコシステム間で作業する際の認識負担を軽減することができます。

消費者のためのSBOM

アプリケーションを使用、消費、購入する人にとって、ソフトウェア部品表は2つの点で役に立ちます。1つは、購入前に製品を評価する場合、もう1つは、サードパーティアプリケーションによる組織のリスクを監視する場合です。

アセスメント

お客様が新製品を検討される際、ソフトウェア部品表を提供することで、お客様の製品が社内のセキュリティおよびアーキテクチャの要件を満たしていることを確認することができます。製品への洞察は、アプリケーションのセキュリティにさらなる自信を与えてくれます。つまり、より透明性の高い運用が可能になります。ほぼすべてのソフトウェアがオープンソースコンポーネントを利用していることを考えると、SBOMを持つサードパーティソフトウェアは、顧客が攻撃ベクトルを監視できるため、持たないソフトウェアよりもリスクが低くなります。これが、2つ目の用途であるサードパーティのリスクの監視につながります。

モニタリング

顧客は、提供されたSBOMを使用して、自社のセキュリティを監視することができます。Nexus Lifecycleを含む多くのツールは、SBOMをスキャンし、部品表に記載されているコンポーネントIDに基づいて脆弱性のリストを生成することができます。これにより、独自のサードパーティソフトウェアを使用している場合でも、自社のセキュリティを管理することができます。

SBOMを作成する方法は？

自動化されたツールでソフトウェア部品表を生成するのは簡単です。Nexus Lifecycleは、ユーザーインターフェースまたはAPIリクエストでSBOMを作成できます。CycloneDXは、オンデマンドまたはビルドプロセス中にプログラムでSBOMを生成できるツールを多数提供しています。詳しくは、CycloneDXツールセンターをご覧ください。

Nexus Lifecycleは、ボタンをクリックするだけで、スキャンしたアプリケーションのSBOMを生成することができます。Lifecycle UIでソフトウェア部品表を生成するには：

Nexus Lifecycleでアプリケーションをスキャンします。
ポリシー評価（CLIからスキャンする場合）のリンクに従うか、UIからレポートのスキャンにナビゲートします。
右上のオプションのドロップダウンをクリックします。
SBOMの表示をクリックします。

このファイルを保存するには、ページ上の任意の場所で右クリックし、「名前を付けて保存」オプションを選択します。

いつSBOMを共有すべきか？

ソフトウェア部品表の情報は、あなたのソフトウェアの構成に関する情報を含んでおり、あなたのアプリケーションの潜在的な脆弱性を特定するために使用することができます。つまり、SBOMをいつ、どのように共有するかについては、ある程度の裁量を持ちたいものです。ソースコードが専有または非公開のプロジェクトでは、ソフトウェア部品表を既存の顧客と適格なリードに公開することをお勧めします。

オープンソースプロジェクトでは、一般に公開されたソフトウェア部品表を維持することによるリスクはほとんどありません。プロジェクトの依存関係情報はすでに公開されており、公開されたSBOMは、セキュリティとライセンスのコンプライアンスに特に関心のあるコミュニティのメンバーにとって有用である可能性があります。

ベストプラクティスとして、私たちは、製品の誤検出を呼び出すための公開アドバイザリーページを作成することを強くお勧めします。この情報は、SBOMとともにVEXに含めるべきですが、この情報を公開することで、さらなる透明性を提供し、ユーザーが安全性を監視する別の方法を提供します。