新プラットフォームsbomifyがSBOMのソフトウェアインベントリ作成を効率化

原文リンク(2024-09-19)

ソフトウェア部品表(SBOM)を扱い、配布する際に企業が直面する困難に取り組むために、sbomifyという新しいプラットフォームが発表された。その目的は、業界における規制の要求が高まり続ける中、SBOM手続きの合理化と自動化を図ることにある。

ソフトウェア部品表（SBOM）は、開発プロセスで利用されるライブラリやツールなどのソフトウェア要素のリストで構成される。SBOMは、米国政府によるSecure by Designフレームワークのような最近のサイバーセキュリティの取り組みに照らして、より重要性を増しており、このことは、民間および公的部門でのSBOMの使用を奨励している。

ソフトウェア・サプライチェーンの攻撃に関連する潜在的なコストと風評被害は、SBOMがいかに重要であるかを示している。SBOMは依存関係を把握し、脆弱性や潜在的なライセンス問題を特定するのに役立つ。スタンドアロンのSBOM生成ツールも存在するが、GitLabのようなプラットフォーム企業は、この機能をDevSecOpsワークフローに統合し、ソフトウェア開発ライフサイクルに統合している。

GitLabに寄稿したSandra Gittlen氏は、SBOMは現代のソフトウェア開発において非常に重要であり、迅速なデリバリーには様々なソースからのコードを使用することが多いと述べている。Gittlen氏は、Synopsysの2024年レポートによると、商用コードベースの96%にオープンソースの要素が含まれており、その84%に脆弱性が含まれていると説明している。このような慣行は、2020年のSolarWindsへの攻撃やlog4jの脆弱性で示されたように、セキュリティ侵害のリスクを増大させる。

Screenly社の創設者であり、sbomifyの開発者であるViktor Petersson氏は、多くの企業、特に規制業界の企業は、SBOMの需要に対応するための支援を必要としていると指摘した。SBOMを共有する従来の方法、たとえば電子メールや社内のファイル・サーバーは、非効率的でエラーが発生しやすいことが判明した。この見解は、CISAのSBOMに関する共有入門書と一致しており、効率的で安全なSBOM共有手法の必要性を強調している。

さまざまな業界のCTOやCISOと議論した結果、ほとんどの企業がいまだにSBOMの管理を手作業に頼っていることが明らかになった。このような時代遅れの方法は、最新の継続的インテグレーションと継続的デプロイメント（CI/CD）環境のダイナミックな性質としばしば相容れない。sbomifyは、CI/CDパイプラインと直接統合することで、これらの問題に対処することを目指している。このプラットフォームは、新しいソフトウェアリリースごとに最新のSBOMを自動的にアップロードし、関係者が最新の情報にリアルタイムでアクセス可能にする。このアプローチにより、手作業による更新の必要性がなくなり、古いファイルで作業するリスクが軽減される。

InfoQの取材に応じたPetersson氏は、新しいツールが必要になった背景を次のように語った。

「SBOMのライフサイクルには、生成、配布、分析という3つのフェーズがあります。」

「生成と分析の両方において、市場には多くのツールがあった。しかし、配布の段階では、Secure by Designコンプライアンスの一環として私たちがやりたかったこと、SBOMを顧客と継続的に共有することを可能にするものがなかった。個々の SBOMを共有するツールはあったが、顧客向けの SBOMポータルを作成できるものはなかった。この発見は、CISAのSBOM共有入門書にも反映されており、ほとんどのSBOM共有は電子メールでアドホックに行われていると述べ、より自動化することを求めていた。そこで生まれたのがsbomifyだ。」

「statuspage.ioのようなものだが、セキュリティ・アーティファクトのためのものだと考えてほしいです」

• Viktor Petersson

「sbomifyは、社内外の関係者が常に最新のSBOMをダウンロード可能にするプラットフォームを提供する。statuspage.ioに近いが、セキュリティ成果物向けだと考えてほしい。」とPetersson氏は付け加えた。「SBOMはCI/CDパイプラインで自動的に構築され、招待された関係者がダウンロードしたり、多くの分析プラットフォームのいずれかにエクスポートしたりするように自動的にアクセス可能になる。」

SBOMの機能は他のツールでも利用できる。例えば、GitLabのアプローチは、SBOM処理のいくつかの重要な分野を網羅している。SBOMの生成と管理のために、GitLabの依存関係リスト機能は脆弱性とライセンスデータを単一のビューに集約し、依存関係グラフ情報はスキャンレポートに含まれる。SBOMはCycloneDXフォーマットで生成され、UI、パイプライン、API経由でエクスポートできる。

GitLabはSBOMの取り込みとマージもサポートしており、セキュリティの透明性を高めるためにサードパーティのSBOMを取り込める。GitLabは、CI/CDジョブを使って複数のSBOMを1つのファイルにマージできる。SBOMの信頼を構築するために、GitLab Runnerによって生成されたすべてのビルド成果物に対して認証を生成し、外部サービスへのハンドオフを回避することでプロセスの安全性を維持できる。

クラウドセキュリティ企業Wizの記事の中で、Swaroop Sham氏はいくつかのオープンソースツールについて論じている。そのほとんどは、SPDXやCycloneDXのような標準フォーマットでSBOMを出力する。

• Syftは、コンテナイメージとファイルシステムからSBOMを生成する人気のCLIツールだ。標準的なコンテナ形式をサポートし、Linuxディストリビューションを自動的に検出する。
• マイクロソフトのSBOMツールは、スケーラビリティのために設計された、オープンソースのエンタープライズ対応のジェネレーターである。マイクロソフトのコンポーネント検出ライブラリを使用し、様々なパッケージ・マネージャーをサポートしている。
• Trivyは、SBOM機能も備えたセキュリティスキャナーだ。

Petersson氏は、手作業による紙ベースのSBOMシステムから企業を移行させるという発展的な問題について、さらに洞察を加える。「多くの企業にとって、法規制とコンプライアンスからの後押しがあると思う。米国大統領令14028号はすでにこの問題に大きな影響を及ぼしており、米国政府にソフトウェアを販売するベンダーはSBOMを提供することが義務付けられている。今年初めに発表されたNISTのCSF 2.0は、SBOMを義務付けるには至らなかったが、ソフトウェアの透明性を求めている。EUのサイバーレジリエンス法（CRA）は、特定のセクターに対してSBOMを義務付けると予想されている。また、CISAのSecure By Designのように、根本的なソフトウェアの透明性を求める取り組みもある。」

「私は、法規制とコンプライアンスが後押しになると考えています。」

• Viktor Petersson

Petersson氏はまた、SBOMの世界で現在見られる3つの重大な問題を挙げながら、sbomifyの次期バージョンについて語った。

多くのツールはSBOMを生成できるが、これでは完全なSBOMにはならないとPetersson氏は説明する。「次に、このSBOMを多くのベンダー情報とライセンス情報で補強する必要がある（その後、拡充と集約の段階が続く）。これは、面倒でミスの起こりやすいプロセスです。sbomifyを使って、自動化された方法で、顧客のためにこれを合理化する方法を模索している。」

統合も計画されている。Petersson氏は続ける。「SBOMの本当の価値は、監査のアウトプットから生まれる。顧客は一般的に、セキュリティ監査かライセンス監査、時にはその両方に関心がある。sbomifyでは、すべての関連ツールと統合するハブになりたいと考えており、SBOMを当社に送っていただくと、当社はそれをすべての利害関係者だけでなく、すべての分析ツールに連携する。」

Petersson氏はまた、コンポーネント、プロジェクト、製品の階層構造を導入することで、複雑なシステムで複数のSBOMを管理するという課題に対処するため、sbomifyを進化させることについても述べた。これにより、複数のSBOMを単一のツリー構造のSBOMに集約し、コンテキストと使いやすさを維持可能になる。関係者のきめ細かなアクセス制御が可能になり、製品要素の論理的な構成が維持される。このソリューションは、インフラストラクチャのさまざまな側面にわたって多数のSBOMを持つ企業にとって有益だ。

sbomifyへの早期アクセスはGoogleフォームからリクエストできる。