SBOMは、リリース成果物に含まれるか

SBOMとは

SBOMとは、ソフトウェアを構成するコンポーネントの名称やバージョン情報、依存関係、開発者情報などを含むソフトウェアの部品表を指す。
SBOMを関係者間で相互に共有することで、ソフトウェアサプライチェーンの透明性の強化が期待されるものである。
SBOMは、使用しているソフトウェアの依存関係にあるものまで対象とすることで、ソフトウェア開発工程における運用フェーズにて、脆弱性管理やソフトウェアライセンス管理を行う際の有用な資料となっている。
SBOMの対象は、OSSのみならず、プロプライエタリなソフトウェア、独自に作成したソフトウェアを含むものである。

いつ作成するのか

ソフトウェアの開発工程は、主に、設計、実装、テストである。最後のテスト工程にて、基準となる品質を確保できたものを、リリースして、外部に提供することになる。

SBOMを作成するのは、実装が完全に終わったタイミングが望ましい。それは、実装次第では、使用するソフトウェア(OSS)が変わる可能性があるためである。
実装が完了するのは、テスト工程の後で、品質が確保された後ということになる。

SBOMは、成果物としては、テスト工程の後になり、リリース工程の前の工程として扱われる。

現在の、ソフトウェアライフサイクルに当てはめて考えると、

• 要件定義
• 設計
• 実装(コーディング)
• テスト
• リリース
• 運用・保守

となっている。望ましいのは、SBOM作成は、4と5の間ということになる。

これは、「開発工程が終わった後に作成されるもの」と「リリース前の作業」いう重大な要素を生み出す。

作成するのは誰か

「開発工程が終わった後に作成されるもの」と「リリース前の作業」という概念が成立している中で、作成するのは誰か、を決めるのは、難しい。

現在のソフトウェア開発プロジェクトでは、複数のメンバーもしくは、複数の会社が参画していることが多い。
社内のメンバーであれば、会社の中で役割や期待を与えられていることがある。また、他の会社のメンバーであれば、業務内容を明確にして委託することになる。

開発メンバーは、往々にして、開発実績を、設計工程、実装工程に見ることが多い。
その中で、リリース成果物としてのSBOM作成を行うメンバー選定は、困難な状況になる場合がある。

一例をあげると、他の会社のメンバーにSBOM作成を依頼する場合である。業務依頼契約書には、SBOM作成が記載されている事例はなく、開発内容だけが記載されていることが多い。
このような場合、開発の現場では、SBOM作成を開発作業とみなされず、現場のメンバーが、SBOM作成を拒否することもある。
ここで、SBOMの有用性を説いても、拒否は免れないものである。そう、SBOM作成は開発ではないから。

SBOMは必要、でも作成しない

開発メンバーは、みな、SBOMが必要なのは知っている。だけど、作成したがらないのは、ソフトウェア技術者が、最も大事にしているのは、技術経歴書である。すべてが記載されており、それが、技術者自身の価値につながるものだからである。

技術経歴書の作業内容の蘭に「SBOMの作成」と記載されていたら、どうだろうか？
それだけが理由にならないが、残念ながらマイナスの評価になっているだろう。
私も、恐らくそうしている。

同じスキルの人間が２人いて、どちらか１人を選ぶとき、直近の作業がSBOM作成をしている人は選ばないだろう。

SBOMは、リリース成果物に含まれるか

SBOMがリリース成果物だったら、どうだろうか？
多くの開発者は、作成してくれるに違いない。リリース成果物は、開発者の苦労の結果、出来上がったものだからである。
正しくリリース出来てこそ、開発者の技術経歴に自信を持って記載できるのだから。

そうなると、SBOMは、リリース成果物に含めないといけないのである。
現状は、SBOMは、リリース成果物として、作成していく必要がある。