設計工程から作成した時のSBOMの有用性について

公開日：2026年3月11日

今回は、SBOMを設計工程から作成した時の有用性について、記載致します。

「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver 2.0」より、

SBOM導入のメリットは、以下の３つがあります
(1)脆弱性管理
(2)ライセンス管理
(3)開発生産性向上

脆弱性管理は、脆弱性残留リスクの低減や、脆弱性対応期間の短縮、脆弱性管理にかかるコストの低減などがあり、
ライセンス管理には、ライセンス違反リスクの低減や、ライセンス管理にかかるコストの低減などがあります。
また、開発生産性向上には、開発遅延の防止や、開発にかかるコストの低減、開発期間の短縮、コンプライアンス対応の効率化、現場のモチベーション改善などがあると言われています。

脆弱性管理や、ライセンス管理は、SBOMの特性上、容易に想像がつくので、今回は、開発生産性向上に着目していきたいと思います。

目次

• 開発遅延の防止
• 開発にかかるコストの低減
• 開発期間の短縮
• コンプライアンス対応の効率化
• 現場のモチベーション改善

●開発遅延の防止

SBOMは、脆弱性が含まれていないバージョンの特定に役立ちます。また、OSSを使用する際のライセンス条項におけるリスクを事前に把握することができます。そのため、仕様を検討している段階で、SBOMを確認することで、脆弱性の対応やライセンス条項違反による対応を防ぐことが可能となり、開発遅延の発生を防ぐことができます。

●開発にかかるコストの低減

OSSは、複数のプロジェクトで使用されるケースが多いですが、OSSの情報がプロジェクト間で共有されていない場合、各プロジェクトでOSSの情報を集めることになります。
プロジェクトで収集したOSSの情報を共有する、
つまり、SBOMを作成し、社内で利用が承認されたコンポーネントの情報を SBOM として管理しておくことで、開発の際に毎度コンポーネントを調査・承認する必要がなくなり、結果として開発工数の低減が期待できます。

●開発期間の短縮

おおよそ、OSSを使用するケースは、特定の機能や単純な処理を行う場合が多く、
他のプロジェクトでも、仕様を変更することなく、そのままの形で利用することが出来るので、流用することが多くなります。
そのため、使用するコンポーネントを選定する際、過去の SBOM を参照することで、選定に関する工数を削減することができます。

●コンプライアンス対応の効率化

最初にOSSを使用する際、認証対応、法令対応、輸出規制管理対応などのチェックを行うことで、次に使用する際の同様のチェックを省略できるため、再利用時の効率化が可能となります。

●現場のモチベーション改善

SBOM作成及び管理に関する作業は、開発メンバーにとっては、付加的な作業に見える場合が多く、多くの開発プロジェクトにおいて、実施者の人選や実施タイミングの決定が難しい局面がありますが、SBOM作成後、次のプロジェクトでの開発や他プロジェクトへのSBOM流用における開発効率向上の貢献は、現場のモチベーションの改善につながります。

開発遅延の防止に関しては、SDLC(Software Development Life Cycle or Systems Development Life Cycle)の中で早い工程に取り組むことで、効果が高くなると言われています。
つまり、実装工程よりも、設計工程でSBOMを取りいれる方が良いとされています。

CISAが発行した文書、「Types of Software Bill of Material (SBOM) Documents」には、「SBOM Type」ごとに有益性と限界が記されています。
ちなみに、CISA（サイバーセキュリティ・インフラセキュリティ庁）は、米国のサイバーセキュリティと重要インフラの保護を担当する政府機関です。

ここで記載している「SBOM Type」は、SDLCの工程と一致するものではなく、ソフトウェアの特性によって生成されるべきSBOMを定義しています。

たとえば、"Design"という、SBOM Typeは、
「SBOM of intended, planned software project or product with included components (some of which may not yet exist) for a new software artifact.」と記されており、直訳すると
「新しいソフトウェア成果物に対して、計画段階または設計段階で意図されたソフトウェアプロジェクト／製品に含まれるコンポーネント（まだ存在しないものを含む）を記載した SBOM」となります。
つまり、設計段階で、コンポーネントを明確化した際、使用するOSSを決めておくのが良いということになります。

こちらの、有益性は、
「 Highlight incompatible components ahead of licensing purchase or acquisition.
Defines approved or recommended included component list for developer use.」と記されており、直訳すると 「ライセンス購入や取得の前に、互換性のないコンポーネントを明確に示す。開発者が使用するための、承認済みまたは推奨されるコンポーネント一覧を定義する。」となります。

つまり、組み込んだOSSのライセンス条項により、独自に作成したソースコードの公開義務を負うことになった場合、機密な情報を公開することを防止する社内規定に該当し、使用できなくなる可能性があり、リリース出来なくなる等のリスクの防止や、OSSの動作仕様により、使用しているソフトウェアの修正が発生するケースを、未然に防ぐ事ができ、手戻り作業による追加工数の防止も可能となります。

また、OSSの運用リスクを把握することで、製品のサポート期間にOSSのメンテナンスが行われないことや、OSSの脆弱性対応が遅延した場合の対応についても、事前に想定することが可能となり、メンテナンスコストが低下することが期待されます。

限界については、
「This may be very difficult to generate.
Unlikely to identify as much detail as found in other SBOM types」と記されており、直訳すると「これは生成するのが非常に困難な場合がある。
他の種類の SBOM で得られるほどの詳細を特定できない可能性が高い。」となります。

つまり、設計段階で、すべてのOSSを明確に定義できるわけではありません。設計後の実装段階でOSSを追加する場合もあります。

CISAでは、SBOM は SDLC（開発ライフサイクル）の複数段階で生成され得ると考えられております。

• Design SBOM（設計段階の SBOM）
• Source SBOM
• Build SBOM
• Analyzed SBOM
• Deployed SBOM

設計段階でのSBOM作成における、限界については、他の段階で作成することで、補うことが可能ですので、設計段階におけるSBOM作成には、有益性があると言えます。

設計段階でOSSを明確にしていくためには、OSSの機能の理解の他に、ソフトウェアライセンス、OSS選定に関するスキルが必要になると考えられます。

ソフトウェアライセンスについては、多くのライセンスに触れることが重要ですが、特にソフトウェアライセンスの条項を理解することが必要となります。
こちらは、バージョンが更新されるタイミングで、ライセンスも変わることがありますので、OSSのリリースタイミングで、ソフトウェアライセンスの内容を確認することが必要になります。

OSSを選定するには、運用リスクの少ないものが良いとされており、
実際のOSSの機能と同じくらい、運用面を含めた理解が必要になってきます。

• 更新期間が長い
• 最後に更新してから２、３年たっている
• 過去の脆弱性対応に、時間がかかっている
• メンテナンスメンバーが少数、もしくは、大人数でも常に修正しているひとが同じであるなどについて、理解しておく必要があります。

最後に、SBOMは、SDLC（開発ライフサイクル）の複数段階で作成するものであり、
OSSのバージョンアップのタイミングで、ソフトウェアライセンスの内容を確認する必要もあります。
設計段階から作成することで、有用性を高めるためには、ツールを使用した運用が推奨されると考えられます。