Software 開発は、プロセスを合理化するために、あらかじめ組み込まれたサードパーティのコンポーネントを活用することに大きく依存しており、その中にはオープンソースのものもあります。これらのコンポーネントは最新のウェブ・アプリケーションの構成要素ですが、同時に脆弱性をもたらし、サイバー犯罪者にシステムへの潜在的な侵入口を提供する可能性もあります。
ソフトウェアを構成するコンポーネントを可視化し、依存関係の脆弱性を管理するために、SBOM（ソフトウェア部品表）と呼ばれるリストを管理することは、アプリケーションのセキュリティ、リスク管理、および、コンプライアンスを強化する上で不可欠です。
SBOMとは？
A Software Bill of Materials (SBOM)は、アプリケーションで使用されるすべてのクローズドおよびオープンソースのコンポーネント、ライブラリ、依存関係の詳細なインベントリです。より簡単に言うと、物理的な製品に構成部品と材料のリストが付属しているように、ソフトウェアにも構成部品があります。
開発者やベンダーは、オープンソースと商用コードを組み合わせてソフトウェアを構築することが多い。SBOMは、ソフトウェア製品の基盤となるコードコンポーネントの透明性とトレーサビリティを確保するために、これらのコンポーネントを体系的に詳述し、サプライチェーンセキュリティの促進と規制へのコンプライアンスの確保を支援する。
SBOMのメリットとは？
SBOMの核心は、3つの主要な利点を提供することである：
透明性
これにより、開発者、監査人、エンドユーザーを問わず、利害関係者がソフトウェアスタックに含まれるコンポーネントを理解できるようになる。
Vulnerability Management
セキュリティは、ソフトウェア開発における最も差し迫った懸念事項の1つである。SBOMは、ソフトウェア製品のコンポーネントを迅速に特定することができ、脆弱性の特定、対処、および修復を容易にする。
セキュリティ勧告が発表されると、通常、ソフトウェアコンポーネントの脆弱性に関する最新情報が含まれる。SBOM を最新のセキュリティ勧告と相互参照することで、組織は自社のアプリケーションがリスクにさらされているかどうかを迅速に判断し、適切な安全性を確保するために必要な緩和策を講じることができる。
SDLCSoftware 開発ライフサイクル）における統合
ソフトウェアが開発パイプラインを進むにつれて、概念化と設計から展開と保守に至るまで、継続的に更新される。SBOM は、SDLC のすべての段階において、ソフトウェアのコンポーネント、依存関係、および関係の明確なイメージを保証する動的な記録として機能します。
誰がSBOMを必要としているのか？
大雑把に言えば、ソフトウェアの消費者とは、営利・非営利を問わず、サードパーティ・コンポーネントやサードパーティ・ソフトウェア・ユーティリティをサプライヤから入手するあらゆる事業体を指す。これらのサプライヤーは多岐にわたる：
- 商業ソフトウェア出版社
- ソフトウェア・コンポーネントを提供する契約ソフトウェア開発者
- FOSS（フリー＆Software）サプライヤーは、オープンリポジトリまたはパッケージマネージャでコードを管理する。
注目すべきは、これらのサプライヤーが複数の帽子をかぶっていることだ。製造者であったり、開発者であったり、保守者であったり、プロバイダーであったりする。理想的には、これらのエンティティは、ソフトウェア機能のSBOMも管理すべきである。覚えておくべきユニークな違いは、ほとんどのサプライヤーは消費者でもあるということである。しかし、上流コンポーネントを持たないサプライヤーは、一般にルートエンティティーとしてタグ付けされる。
公共部門におけるSBOM
連邦機関は、SBOM基準の採用と施行において極めて重要な役割を果たしている。彼らの監視は、単にベンチマークを設定するだけでなく、より大きな公共の利益のためにこれらのベンチマークへの適合を保証することである。2021年5月に発行された米国大統領令14028は、NIST（国立標準技術研究所）を含む広範な管轄権を持つ複数の機関に、ソフトウェア・サプライ・チェーンのセキュリティと完全性に関連するさまざまなイニシアチブを通じてサイバーセキュリティを強化することを課している。
大統領令 14028 の第 10 節（j）では、SBOM を「ソフトウェアを構築する際に使用されるさまざまなコンポーネントの詳細とサプライチェーン関係を含む正式な記録」と定義している。SBOM は、連邦省庁が脆弱性を特定し是正する際の透明性、実証性、スピードを向上させる可能性を秘めている。
SBOMの種類と定義
ソフトウェアの開発および展開の段階によって、さまざまなタイプのSBOMが生成され、それぞれが独自の目的を果たし、ソフトウェアコンポーネントに関する明確な洞察を提供する。ここでは、6種類の一般的なSBOM文書を紹介する。
ソース
開発環境から直接作成されるため、製品の成果物を構築するために必要なソースファイルと依存関係についての洞察を提供します。これは通常、SCA（ソフトウェア構成分析）ツールから生成され、時には手作業による明確化が必要になる。
Build
ソフトウェア構築プロセスの一環として作成され、ソースファイル、ビルドされたコンポーネント、およびその他の依存関係からのデータを統合します。これは、リリース可能なソフトウェア成果物の作成中に生成されるため、特に価値が高い。
分析済み
このSBOMは、実行可能ファイルや仮想マシンイメージなどのソフトウェア成果物のビルド後の分析から得られる。これには多様なヒューリスティックが含まれ、「サードパーティ」SBOMと呼ばれることもある。
配備済み
システム上に存在するソフトウェアの網羅的なインベントリ。システムにインストールされているソフトウェアコンポーネントのSBOMを文書化することで作成され、ソフトウェアの実際の展開に関する洞察を提供する。
SBOMの要素とは何か？
NTIA（National Telecommunications and Information Administration：米国電気通信情報局）によると、SBOM の最小要素には、ソフトウェアのサプライヤー名、コンポーネント、そのバージョン、一意の識別子、依存関係の関係、SBOM データの作成者、タイムスタンプが含まれる。さらに、SBOM データが効果的かつ包括的であるためには、以下の要素を含むべきである：
- データフィールド： ソフトウェアのコンポーネント名、バージョン、属性の詳細を明確に定義したデータフィールドを持たなければならない。これにより、すべての利害関係者がソフトウェアの構成を完全に理解することが保証される。
- 自動化のサポート： ソフトウェア開発の動的な性質を考慮すると、SBOMは自動的に更新され、ソフトウェア開発と配備のパイプラインに統合できる必要がある。これにより、リアルタイムの正確性と効率が保証される。
- プラクティスとプロセス： 単に構成要素を列挙するだけでなく、SBOM はその作成、維持、および活用を管理するベストプラクティスおよびプロセスに組み込まれるべきである。
SBOMフォーマット
一般的なSBOMフォーマットには次のようなものがある：
- Software Package Data Exchange） - Linux Foundationが開発。
- CycloneDX-アプリケーション・セキュリティによく使用される
- Software Identification Tagging）-ISO/IEC19770-2で定義。
各コンポーネントをカタログ化することで、SBOM は、組織が各ソフトウェアに関連するライセンスを明確に識別できるようにし、ライセンス条項の遵守を維持し、潜在的な法的落とし穴を回避することを保証する。
SDLC におけるコンプライアンスとSecure の維持
サプライチェーン攻撃の増加により、連邦政府と民間部門はソフトウェア識別の重要性を認識している。SBOM は、ソフトウェアコンポーネント、特にサードパーティコンポーネントを詳細に記述する上で極めて重要である。SBOM データは脆弱性の防止に役立ち、SBOM 作成の透明性を確保する。すべてのソフトウェアには、セキュリティ対策を強化するために包括的な SBOM を含めるべきである。
各コンポーネントをカタログ化することで、SBOM は、組織が各ソフトウェアに関連するライセンスを明確に識別できるようにし、ライセンス条項の遵守を維持し、潜在的な法的落とし穴を回避することを保証する。
OPSWAT SBOMを使用することで、開発者は既知の脆弱性を特定し、ライセンスを検証し、OSS（オープンソースソフトウェア）、サードパーティの依存関係、コンテナのコンポーネントインベントリを生成することができます。堅牢なSBOMソリューションによるソフトウェアサプライチェーンのセキュリティ確保について詳しくは、OPSWATSupply Chain ご覧ください。
