ソフトウェア部品表（SBOM）とは？

概要

ソフトウェア開発の世界では、ソフトウェア部品表（SBOM）は、食品缶の側面に記載された原材料表示や栄養成分表示に例えることができます。

同様に、ソフトウェアを安全に保つには、構築にどのコンポーネントが使用されたかを把握する必要があります。そのため、開発、運用、セキュリティの各チームは、セキュリティの脆弱性を特定して修正するとともに、ライセンスや規制上の要件に備えてコンポーネントの使用状況を記録するため、ソフトウェアをリリースするたびにSBOMを作成するよう徹底する必要があります。

ラベルに記載されている原材料表示のように、SBOMには特定のソフトウェアリリースに関連するすべてのコンポーネントの詳細なリストが記載されており、潜在的な脆弱性やライセンス情報も含まれています。

How do SBOMs work?

In general, SBOMs are typically generated during the build stage of the software development process. This stage involves compiling and assembling the software from source code into executable programs or other components. Generating an SBOM at this point allows for a detailed and accurate listing of all components, libraries, and dependencies that are included in the software. This is crucial for tracking the provenance and ensuring the security of all components used in the software.

The steps below describe the typical process taken in order to generate an SBOM:

1. Identification of Components – Developers or automated tools identify all the components used in the software, including libraries, frameworks, modules, and dependencies. This can be done manually or with the help of automated tools that scan the codebase and generate a comprehensive list.
2. Versioning and Metadata – Each component in the SBOM is associated with metadata such as version numbers, license information, and dependencies. This metadata is important for tracking vulnerabilities, ensuring compliance with licensing agreements, and managing updates and patches.
3. Format and Standards – SBOMs can be represented in various formats such as SPDX (Software Package Data Exchange) or CycloneDX. SPDX is a widely used standard for documenting the contents and licenses of software packages.
4. Distribution and Sharing – SBOMs can be shared between different stakeholders in the software supply chain, including developers, vendors, customers, and regulators. This sharing facilitates transparency, collaboration, and accountability in software development, deployment and regulatory compliance.
5. Integration with Tooling and Processes – SBOMs can be integrated into various software development and security tools and processes. For example, they can be used by vulnerability scanners to identify known security vulnerabilities in software components and by license compliance tools to ensure adherence to licensing requirements.
6. Continuous Monitoring and Updates – Since software is continuously evolving, SBOMs need to be regularly updated to reflect changes in the software composition. This includes adding new components, updating versions, and removing deprecated or vulnerable components

Most SBOMs are organized in a highly structured way using formatting standards like SPDX or CycloneDX to produce nested inventories of the contents of an application’s software supply chain. Here are examples of the structure for a couple of the leading formats:

SPDX

In the current implementation of generating an SPDX report, the following fields are required:

• Package Name
• Package Version
• Detected licenses
• Detected checksums when possible

Here is how it would appear in the report:

PackageName: PyYAML
SPDXID: SPDXRef-Package-PyYAML-3.10
PackageVersion: 3.10
PackageDownloadLocation: NOASSERTION
FilesAnalyzed: false
PackageChecksum: SHA256: 3d8ee7cc23fef4279e6a0a46ea8df14f2bfe09703dd1e67b465bca5d4b500602
PackageHomePage: NOASSERTION
PackageLicenseConcluded: MIT
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION

CycloneDX

The CycloneDX implementation provides the general metadata of the report that includes information such as Cyclone DX version, author, and report generation date. It also covers detailed component information for each of the detected components and their vulnerabilities information (VEX).

 "type": "application",
  "name": "ubuntu:bionic:libsqlite3-0",
  "version": "3.22.0-1ubuntu0.4",
  "hashes": [

    {
      "alg": "SHA-256",
      "content": "1c0f71e7796c1ddb8527b9b052f9948fc8a2c1e8e9c89b084bcc36100f966714"
    }
  ],
      "licenses": [
    {
      "license": {
      "id": "GPL-2.0",
      "url": "http://www.gnu.org/licenses/old-licenses/gpl-2.0-standalone.html"
     }
    }
   ]
 }

Here is an example of how a sample SBOM can be used in an application:

     
     2020-08-03T03:19:55.999Z
     
     
     CycloneDX
     Node.js module
     2.0.0
     
     
     
     juice-shop
     11.1.2
     
     
By parsing the XML code, this SBOM provides details not just about which components exist in the application, but also metadata regarding the versions and URLs associated with each component.

SBOMとGRC：規制当局に信頼される構成要素

SBOMは、特定のアプリケーションの開発に使用されるコンポーネント、依存関係、ライブラリのインベントリについて検証済みの証拠を提供するため、ガバナンス、リスク、コンプライアンス（GRC）の取り組みにおいて非常に重要です。このため、GDPR、PCI-DSS、NIST CSFを含む多くの規制では、SBOMをコンプライアンスの確立に利用できる検証済みの証拠として認めています。

SBOMの役割とは？

スピードと規模を維持しながら、安全で高品質なソフトウェアを開発するには、開発、運用、セキュリティの各チームが全面的に協力する必要があります。SBOMは、ソフトウェア開発ライフサイクル（SDLC）全体を通じて信頼できる唯一の情報源となる、多用途なツールです。ソフトウェアの開発やデプロイにおいて、さまざまなチームや側面でSBOMが果たす役割をご紹介します。

ソフトウェアサプライチェーン

ソフトウェアコンポーネントの開発からデプロイまでの透明性と追跡可能性を確保することで、各コンポーネントの起源を特定し、検証済みで安全なコンポーネントのみが使用されるようにします。脆弱性が悪用された場合、被害を最小限に抑えるため、迅速に追跡して修復できます。

セキュリティ

セキュリティとDevSecOpsに関する重要な参照情報であり、すべてのソフトウェアコンポーネントがコードの一部となる前に、安全でコンプライアンスに準拠していることを確認するのに役立ちます。コンポーネントとそのバージョンをすべて一覧表示することで、チームは開発プロセスの早い段階で脆弱性を特定して軽減でき、継続的なセキュリティ監視とセキュリティ脅威への迅速な対応が可能になります。

DevOps

開発プロセスの自動化と監視を可能にすることで、ソフトウェアコンポーネントに関する詳細な情報を提供し、更新、依存関係、潜在的なリスクを効率的に追跡できます。CI/CDパイプラインを介した継続的インテグレーションと継続的デプロイの実施中に、ソフトウェアの安定性と信頼性を維持するうえで、この情報は不可欠です。

クラウドネイティブ

クラウドネイティブ環境では、SBOMを使用して、さまざまなマイクロサービスやコンテナ化されたアプリケーションを管理し、セキュリティを確保します。これにより、クラウドで稼働するすべてのコンポーネントが文書化され、安全であることが保証されます。コンポーネントが頻繁に変更される可能性のある、動的でスケーラブルなクラウドネイティブアーキテクチャでは、これは特に重要です。

ライセンスとコンプライアンス

ライセンス管理とコンプライアンス確保に不可欠な要素であり、ライブラリや依存関係を含むすべてのソフトウェアコンポーネントの詳細なインベントリを、各コンポーネントのライセンス条件とともに提供します。このように透明性を確保することで、DevOpsチームは各コンポーネントがライセンスに従って使用されていることを確認でき、潜在的な法的問題を回避できます。

また、セキュリティやプライバシー上の理由からソフトウェアコンポーネントの開示が義務付けられる場合があるため、規制基準への準拠にも不可欠です。これは、医療、金融、重要インフラなどの規制対象業界では特に重要です。規制に準拠しない場合、厳しい罰則が科される可能性があります。

SBOMの重要性とは？

ソフトウェア部品表は、ライセンス情報とともに、すべてのソフトウェアコンポーネント、ライブラリ、依存関係を詳細に記載した包括的な一覧として、ソフトウェア開発において重要な役割を果たします。また、規制基準の遵守において重要な役割を果たし、組織がソフトウェア開発業務における法的および運用上の健全性を確保する際の複雑さに対処するのに役立ちます。

信頼できる唯一の情報源

脆弱性がアプリケーションやその実行環境に影響を及ぼすかどうか、またどのような影響を及ぼすかを迅速に特定できるほど、実際のセキュリティ侵害に遭うリスクは低くなります。この信頼できる唯一の情報源により、他の方法よりもはるかに迅速かつ効率的にサプライチェーンの脆弱性を特定し、修正できます。侵害が発生した場合、SBOMによって迅速に対応できるため、組織は多大な金銭的損害を免れる可能性があります。

セキュリティの強化

ソフトウェアの開発者や独立した研究者によってソフトウェアのセキュリティ上の問題が発見されると、通常、その欠陥に関する情報は、NIST National Vulnerability Databaseなどの公開脆弱性データベースに報告されます。そのため、既知の脆弱性に関する情報を入手できます。

ただし、ほとんどの場合、アプリケーション自体の内部からそれを簡単に行う方法はありません。アプリが特定のライブラリを使用しているかどうかを、単にコマンドを実行して確認することはできません。アプリケーションをスキャンして依存関係やその他のコンポーネントを特定することはできますが、スキャンには時間がかかり、容易に拡張できるものではありません。そのため、攻撃者が悪用を始める前に重大なセキュリティリスクを特定しながら、企業がリリース期限を守るための時間を常に確保できるとは限りません。

SBOMは、アプリケーションのサプライチェーン内に存在するコンポーネントをリアルタイムで可視化することで、この課題を解決します。この情報により、DevOpsチームとセキュリティチームは、既知の脆弱性がアプリケーション内のコンポーネントに影響を及ぼすかどうかを迅速に判断できます。

SBOMのベストプラクティス

SBOMはソフトウェアサプライチェーンの可視性を高め、潜在的なセキュリティ脆弱性の混入を防ぐうえで大きな役割を果たしますが、新しいアプリをビルドする際にSBOMを作成するだけでは、セキュリティリスクを最小限に抑えるには不十分です。さらに、あらゆる状況でSBOMの有効性を確保するため、以下の手順を実施する必要があります。

• 継続的な更新 – アプリケーションは常に変化し、SBOMもそれに合わせて変化する必要があります。アプリケーションのコンポーネントや依存関係を追加または削除した場合、あるいはコンポーネントのバージョンを変更しただけの場合でも、SBOMをそれに応じて必ず更新してください。
• 自動生成 – SBOMは手動で作成することもできますが、時間がかかり、大規模な運用への拡張が難しく、非効率です。また、人為的な見落としやミスのリスクも高まります。セキュリティを強化するためには、アプリケーションをスキャンしてその内容を識別し、識別されたコンポーネントに基づいてSBOMを自動的に生成する必要があります。
• 豊富なメタデータ – SBOMに含まれるバージョン、ソース、脆弱性に関するデータが多いほど、重要な状況でSBOMがより役立ちます。多くの場合、メタデータによって提供される情報は、特定の脆弱性が実際に悪用可能かどうか、またその修正方法を迅速に判断するうえで重要です。
• 一貫性 – SBOMの形式にはさまざまな方法があるため、それぞれの形式の長所と短所を検討し、組織に適した形式を決定する価値があります。ただし、特定の構造を選択した後は、SBOMを効果的に生成するために必要な形式とデータ型の一貫性を保つことが非常に重要です。

JFrogのSBOMソリューション

ソフトウェア部品表（SBOM）を適切に管理することは、セキュリティとコンプライアンスの観点から、常にベストプラクティスとされてきました。しかし、米国政府および欧州連合による最近の発表を受け、特に緊急性が高まっています。

2023年10月、ホワイトハウスは大統領令を発令し、AI開発者がアプリケーションを一般公開する前に、その構成に関する詳細情報を米国政府に提供するよう促しました。同様に、2025年に法制化される見込みのEUのデジタル運用レジリエンス法（DORA）は、デジタル金融サービスの運用レジリエンスを強化するため、金融機関にソフトウェアアプリケーションの内容を提供することを求めています。

コンプライアンスまたはセキュリティのいずれの目的であっても、SBOMは共通の標準形式で提供されることが重要です。この目的のため、JFrog XrayはSPDX、CycloneDXおよびその他の標準形式をサポートしており、ソフトウェアコンポーネントと依存関係の一覧を記載した機械可読ファイルを生成できます。重要なのは、SBOMの要件を理解し、アプリケーションに最も適した形式でエクスポートすることです。

ソフトウェア開発ライフサイクル全体を通じてソフトウェアアプリケーションを管理するうえで、JFrog PlatformはDevOps、DevSecOps、MLOps向けのユニバーサルなソフトウェアサプライチェーンソリューションです。この中には50を超えるインテグレーションが含まれており、ソフトウェア開発エコシステムの主要ツールのほとんどを網羅しています。また、ソフトウェアサプライチェーン全体を自動化、統合、拡張可能かつ安全に管理できます。。

JFrog PlatformでのSBOMの作成・管理方法を含む詳細については、ご都合のよいときにデモを予約するか、オンラインガイドツアーにご参加ください。