ちょっと想像してください。次のミーティングの前に、何か軽いものをつまむことにしました。たとえば、チーズ味のクラッカーにしましょう。最初の 1 枚を口に入れようとしたとたん、健康第一を呼びかける音声が流れ、原材料を確認しよう、と促されました。

そのクラッカー、食べますか？

ソフトウェア開発がチーズ味のクラッカーだとすると、署名済みのソフトウェア部品表（SBOM）は原材料一覧、生産地表示、そして食品の安全性を保証する公式の封印のような役割を果たします。最終的なソフトウェアを構成する全コンポーネントについての、検証済みで改ざん防止機能のある総合的な目録のようなものです。

最終的なソフトウェア成果物の構成部品は膨大な数に及ぶことも多く、SBOM はその個々の構成部品を識別するだけでなく、その連続性、完全性、真正性を検証するうえで重要な役割を果たします。

何が言いたいかというと、ソフトウェアに対する信頼が必要なら、作成するどのソフトウェアにも、署名済みの SBOM が必要だということです。その理由を 6 つあげてみました。

署名済みの SBOM と署名のない SBOM

SBOM に署名するというのは、SBOM の作成者が、署名された時点でのソフトウェア構成表の真正性を検証するということです。署名後にどんな追加、変更、削除があっても、無許可なので疑わしいとすぐに識別することができます。

SBOM は、その作成者と下流の消費者との間で一種の契約としても機能します。署名のない SBOM は、署名のない契約書のようなものです。記載されている情報が正しいかどうかわかりませんし、双方が検証していなければ、何か問題が発生した場合に当事者の責任を問う根拠にもできません。

1. 改ざんを防止し、途切れることのない信頼のチェーンを確立する。

署名済みの SBOM とは、改ざん防止の封印のようなものです。作成者によって検証された時点からソフトウェアの内容が変更されていないことを、ユーザーと利害関係者に対して保証します。

サプライチェーン環境では特にこれが重要です。ソフトウェアコンポーネントが複数の人の手を経由することが多いからです。署名済みの SBOM は、ソフトウェアコンポーネントの信頼性と完全性を高める、検証可能な証拠保全のチェーンを実現します。

2. 規制に対応し、強力なセキュリティポリシーを示す。

ソフトウェアセキュリティに対する規制の審査が厳しくなるなか、多くの業界や政府が SBOM の使用を義務付け始めています。たとえば、米国の「国家のサイバーセキュリティの向上に関する大統領令」では、ソフトウェアサプライチェーンを理解して安全性を確保する際の SBOM の重要性が特に強調されています。

こうした規制環境で SBOM に署名するというのは、具体的にコンプライアンスを示すだけでなく、セキュリティのベストプラクティスに対する組織の取り組み方を強調することにもなります。

3. オープンソースコンポーネントのリスクを緩和し、パッチの適用と更新が迅速に。

最近のソフトウェアは複雑化する一方です。開発の基盤としてオープンソースコンポーネントを利用することも少なくないため、そのどこからでも脆弱性が入り込む可能性があります。コンポーネントが多ければ多いほど、脅威を検出して緩和する範囲と負担は大きくなります。

署名済みの SBOM があれば、企業は各コンポーネントのステータスを速やかに確認できます。特に、コンポーネントのプロバイダーが VEX（Vulnerability-Exploitability eXchange）情報を発行している場合には、脆弱性の追跡も、それに応じたパッチの適用と更新も大幅に効率的になります。

4. 十分な透明性を確保し、意思決定を改善する。

ソフトウェア開発プロセスにおける透明性は、ユーザーと利害関係者のどちらにとっても、妥協の余地がない条件となってきました。そして、そこで重要なのは単に信頼を確立することだけではありません。透明性は、意思決定の改善にもつながります。署名済みの SBOM は、各コンポーネントについて検証済みの十分な情報を開示することになるため、たとえば開発者であれば、使用するコンポーネントについての選択基準となる情報が増え、既知の脆弱性やライセンス上の問題があるコンポーネントを避けることができます。

5. インシデント対応を合理化し、損害を最小限に抑える。

万一セキュリティインシデントが発生した場合は、時間が勝負です。署名済みの SBOM は、インシデント対応プロセスを大幅に合理化できる即効性のリファレンスとして機能します。検証済みのコンポーネントリストをすぐに利用できるため、インシデント対応チームは影響を受けたコンポーネントを速やかに特定し、必要な措置を講じることができます。これにより、損害と復旧に要する時間を最小限に抑えます。

6. 強固なセキュリティ文化を促し、製品の品質が向上。

SBOM への署名は、DevSecOps のようなセキュアなソフトウェア開発ライフサイクルにシームレスに適合します。最初の段階からセキュリティ文化を奨励し、どのコンポーネントも個別に精査・検証されます。セキュリティへのアプローチがこのくらいプロアクティブであれば、最終的な製品の脆弱性を大幅に減らすことができ、ソフトウェアアプリケーションの安全性向上、信頼の強化、公開後の問題に伴うリスクの低減につながります。

まとめ: 軽食にはもちろん、ソフトウェアには不可欠。

今日のソフトウェア開発環境で、SBOM に署名することは必須です。ソフトウェア製品の完全性とセキュリティを強化し、規制要件を満たすことができますし、セキュリティリスクを緩和して透明性を促し、インシデント対応を合理化して、安全な開発業務を奨励する取り組みだからです。

ソフトウェアが世界に広がっていくほど、ソフトウェアのセキュリティは SBOM 署名のような取り組みに大きく左右されるようになります。健康志向の消費者なら、口にする食品の原材料を気にするものです。それと同じように、ユーザーや利害関係者との間で信頼関係を構築しようとするセキュリティ意識の高い企業は、SBOM 署名を採用し、ソフトウェアサプライチェーンの健全性の確保に努めなければなりません。

デジタルトラストに関する最新情報

ソフトウェアの信頼性、コードサイニング、デジタルトラストなどのトピックについて詳しくお知りになりたい場合、記事を見逃さないようにデジサートのブログを参照してください。