突如として現れた「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 の発展にも真摯に貢献するその姿勢こそが、これからもサイバートラストの製品を支え、信頼を守り続けていきます。