現代のソフトウェア開発において必要不可欠な、ソフトウェアの構成情報を可視化する「SBOM※1」。
サイバートラストが提供する「Enterprise Pack for AlmaLinux ※2」の開発プロジェクトにおいて、SBOM 生成機能の実装に際して難題が発生し、リリースできるかどうかという瀬戸際に追い詰められました。今回は、開発を担当したエンジニア・S さんの視点から、発想の転換と技術で壁を突き破った開発秘話をお届けします。
- ※1：
- ソフトウェアに含まれるコンポーネントや依存関係、ライセンスの種類などをリスト化したソフトウェア部品表。ソフトウェアサプライチェーンにおいてトランスペアレンシー（透明性）とトレーサビリティ（追跡可能性）を確保するための有効な手段として、世界的に普及が進んでいます。
- ※2：
- SBOM の提供や更新を可能にした AlmaLinux ベースの Linux OS と、日本語での技術サポートおよび EoL後最長 6 年の延長利用を実現する延長サポートを包括して提供するサービス。
突如として現れた「SBOM生成」の壁
開発のベースとしていたのは、AlmaLinuxのビルドシステムやビルド時の情報を蓄積したデータベースから情報を取得してSBOMを作成する「alma-sbom」というツールでした。ビルド時の正確な情報を取得できるこの手法は、当初、最も信頼性が高く、理にかなった解決策であると考えられていました。
しかし、この設計には大きな穴があることが発覚しました。
AlmaLinux 9.x 系のパッケージを精査したところ、「alma-sbom」やデータベースが導入される前にビルドされた古いパッケージが多数存在していました。これらのパッケージの情報はデータベースになく、SBOM を生成できなかったのです。
「情報がデータベースに存在しない」。
この事実は、データベースを頼りにしていた設計にとって致命的でした。
このままでは製品リリースが危ぶまれる──。
リリースを遅らせるか、機能を制限した状態でリリースするかという二者択一を迫られました。
「受動」から「能動」へ、設計思想の転換
窮地に追い込まれた S さんが出した答えは、既存の手法への固執を捨て、設計思想を根底から変えるという大胆な決断でした。「データベースから情報を取得する」という受動的なアプローチから、「ツール自体が情報を解析する」という能動的な設計への転換です。
Sさんは、「alma-sbom」の機能拡張に舵を切りました。データベースが利用できない場合には、RPM パッケージそのものを直接解析し、SBOM を生成できる機能を実装したのです。データベースの情報を最大限に活かしつつ、それが使えない場合でもパッケージから情報を抽出・補完できる。この「ハイブリッドなアプローチ」により、穴を完全に埋めることに成功し、予定通り「Enterprise Pack for AlmaLinux」をリリースすることができました。
コミュニティへの還元という「エンジニアの信念」
この開発において、S さんがもう一つこだわったのは、この新たに開発した機能を「自社の製品のためだけの解決策」で終わらせないことでした。
彼は苦労して作り上げたパッチを AlmaLinux の Upstream（開発コミュニティ）に提案しました。自社の製品に活用するだけでなく、その修正が世界中の AlmaLinux ユーザーの資産となり、オープンソースの発展に寄与することを望んだからです。
無事に Upstream への提案が受け入れられ、グローバルに利用されている AlmaLinux にパッチがマージされました。サイバートラストのエンジニアとして、コミュニティに貢献できたことは何物にも代えがたい誇りとなりました。
エンジニアの熱量がプロダクトの価値を生む
S さんは「仕事ですから」と淡々と振り返りますが、事業本部長から掛けられた「よくやった」という言葉にはエンジニアとしての確かな達成感を得たはずです。
「自社の製品の品質を向上させることはもちろん、コミュニティ全体のエコシステムを豊かにしていくことで結果的に世界中のシステムの安全に繋がっていく。そのエンジニアとしての責任を胸に、これからもコミュニティと共に技術を前に進めていきます。」
設計思想の転換を恐れず、常に「より良い解決策」を追い求め、OSS の発展にも真摯に貢献するその姿勢こそが、これからもサイバートラストの製品を支え、信頼を守り続けていきます。