ポッドキャスト：SBOMとエンジニアリング規律がTrivyの侵害回避にどう役立つか
本文の状態
日本語全文を表示中
詳細モードで約46分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
InfoQ
CISAタスクフォースのViktor Peterson氏が、EUサイバーレジリエンス法施行を背景に、ソフトウェアサプライチェーンセキュリティの変化とSBOMの重要性を解説する。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るSource Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
トランスクリプト
オリムピウ・ポプ：みなさん、こんにちは。InfoQのエディターであるオリムピウ・ポプです。私と一緒にいるのはヴィクトル・ピーターソン氏で、彼はSBOM（Software Bill of Materials：ソフトウェア部品表）の分野、特に立法変更について、そして大きな規制の脅威なしに開発者として知っておくべき重要なことについて、より詳細な情報を提供してくれます。
ヴィクトル氏は現在いくつかのプロジェクトに取り組んでいますが、ご自身の活動について簡単に自己紹介をお願いします。
ヴィクトル・ピーターソン：お招きいただき、誠にありがとうございます。簡単な自己紹介をしますと、過去にいくつかのスタートアップ企業で働いてきました。数年前に「Secure by Design（設計段階からのセキュリティ）」の取り組みを始めた際、その一環として製品のためのSBOM生成 mandate（義務付け）を受け、私は自然とSBOMの世界に飛び込むことになりました。
当初は、これが一週間で終わる単なるチェックボックス作業だと考えていましたが、実際にはそう簡単ではありませんでした。
そこで私はこの分野に深く入り込みました。CISA（Cybersecurity and Infrastructure Security Agency：米国サイバーセキュリティ・インフラ保安庁）がSBOMの分野で活動していた当時、CISA内のワーキンググループの一つに参加し、共同議長を務めることになりました。そして私たちはSBOM生成に関するホワイトペーパーを作成しました。その結果、予想以上に興味深いものとなりました。
そして最終的に、sbomifyという新しい会社を設立しました。この会社では、ワーキンググループから作成されたブループリントを実装し、高品質なSBOMの作成を支援しています。実際には、多くの人が思っているよりもはるかに困難な作業だからです。これが私の主な目標でした。
オリムピウ・ポプ：ありがとうございます。これは非常に重要です。サプライチェーン攻撃はますます広範になっており、特に現代ではその傾向が強まっています。しかし実際には、これを推進するのは容易なことではありません。多くの人が…に注目しているだけで、それは新たな認証の一つであり、外部から押し付けられるものだと感じているからです。
実際、私は今年からそれが真実になると思います。特に欧州連合（EU）においてです。サイバーレジリエンスの観点から、サイバーレジリエンサー法（CRA: Cyber Resilience Act）が施行されます。米国にも関連する立法が存在していると思いますし、英国もこれについて言及していたと知っています。では、まず「ニンジン」に行く前に、「棒」（規制）を見ていくことから始めましょう。
SBOMを義務化する立法 [02:24]
ヴィクター・ピーターソン：SBOM（ソフトウェア・ビルド・オブジェクトのリスト）は長らく存在しています。決して新しいものではありませんが、私がCEOとして過去数年で始めた取り組みでは、米国のエグゼクティブ・オーダー14028（注：原文の4989は誤記の可能性が高いが、文脈上EO 14028を指す）に基づき、すでに米国政府にソフトウェアを販売している企業はSBOMの提供を開始する必要がありました。これが、あなたが言うように、ソフトウェアベンダーがSBOMの生成を始めるための最初の「棒」でした。
より大きな「棒」は、あなたの指摘通り、欧州のCRAです。この緩やかな施行猶予期間が今年から始まります。そして、私はほとんどの人がこれの影響を受けることを完全に認識していないと言わざるを得ません。
CRA（Cyber Resilience Act：サイバーレジリエンス法）に詳しくない方のために補足すると、これは欧州市場へ製品を販売するすべての事業者に影響する法律です。法文で使われている「試金石」の基準は、意図的に曖昧に設定されています。基本的な考え方は、インターネットに接続するものはほぼすべてが CRA に準拠する必要があるということです。そして CRA では SBOM の生成が義務付けられています。これが、私たちが今日ここにいる理由です。
Olimpiu Pop：つまり、ほぼすべての電子機器やソフトウェアに SBOM が必要だということですか？……いや、実際には、ラベルにはその製品に含まれる「成分」が表示されます。それは恐ろしいことですか？
Viktor Peterson：はい。多くの人がこの事実を完全に認識しておらず、これはヨーロッパにとっての「GDPR 的な瞬間」だと私は言えます。しかし、多くの点で人々は GDPR の時よりもこの事実に気づいていないようです。
GDPR では大きな罰金が「杖」として機能しましたが、今回の「杖」は欧州市場からの製品排除であり、単なる罰金よりもはるかに大きな制裁です。Meta や大手企業たちの事例から見てわかるように、彼らは GDPR の罰金を「欧州での事業運営コスト」として受け入れています。彼らはそこから教訓を得て、今では市場からの排除という、より強力な制裁が適用されることになっています。
オリムピウ・ポプ：私が特に気に入っていたのは、EUデジタルサービス法（CRA）の策定プロセスにおいて、コミュニティが非常に深く関与していたという点です。EUは学び、実際に耳を傾けていたように見えました。規制当局者としてその側につくのは望ましくありませんが、デジタルサービス、デジタル製品、そしてAIの消費者として、この2点については満足しています。
今回の議論の主眼はAI法ではありませんが、CRAについても同様です。実際にご覧いただいた通り、現在私が懸念しているのは、その実装方法です。特にEUの構造がそのような形になりつつある点について懸念しています。
つまり、現在立法は整っており、その後の実装と具体的な形づけは各EU加盟国の責務となります。ドイツはすでにそのための形式を整えている国の一つだと考えています。
ヴィクター・ピーターソン：はい。ドイツの連邦情報安全保障庁（BSI）が最初の具体的な実装例です。彼らの解釈に基づく「2.2」版がすでに存在し、それは徐々に進化してきました。しかし、先ほどのあなたの指摘に戻りますが、私も過度に厳格な立法は好みではありませんが、セキュリティは市場の失敗であるという事実を認識することが重要だと考えています。
私たちは長年にわたりこれを見てきました。ベンダーはセキュリティへの投資を重視しません。なぜなら、財務的な観点から見て、セキュリティに投資することは彼らの利益にならないからです。その結果として、インターネット上で一般公開されているベビーモニターカメラなどの問題が生じています。したがって、この規制が存在する理由には妥当性があります。市場は自己規制に失敗したと言えるでしょう。
開発者も SBOM に関心を持つべきです [05:51]
オリンピウ・ポープ：はい。そして、その責任を引き受け、実際にそれに関与する人々がそれを実行することが非常に重要だと考えています。しかし一方で、ソフトウェア開発者や実務家である私たちにとってのメリットは何でしょうか？付加価値も伴うからです。それらを見ていきましょう。開発者としての視点から、他の開発者に SBOM について知っておいてほしい有用な情報はどのようなものでしょうか？
ヴィクトル・ピーターソン：はい。もしこの作業を単なるチェックボックスの確認、つまり「コンプライアンスのために行っている」という形で扱うなら、生成することによる恩恵を本当に享受することはできず、報われない多くの作業を生み出すことになりますよね。
しかし現実には、これを運用として確立すれば……多くの企業がすでにこれを実践しており、これは理論上の話ではありません。多くの企業はワークフローの一部として SBOM を積極的に活用しています。彼らは SBOM をコードベースのセキュリティ監査に使用し、サプライチェーンのライセンスコンプライアンス監査にも利用しています。
したがって、多くの企業には「ソースコードやライブラリで GPLv3 コードの使用を許可しない」といったポリシーがあります。SBOM を使用してライセンスコンプライアンス監査を行うことができます。より一般的には、セキュリティ監査に使用されます。ロックファイルから SBOM を生成できれば、それによって影響を受ける CVE（Common Vulnerabilities and Exposures）を特定することができます。
そして、この上に VEX（Vulnerability Exploitability eXchange）という仕組みが存在するため、エコシステムは少し成熟しています。これにより、「はい、CVE の影響を受けていますが、この CVE はこのライブラリの特定の関数にのみ影響し、私たちはその機能を使っていません」と宣言できます。つまり、「VEX ステートメント」を発行し、「CVE に対応しますが、私たちに影響はありません」と伝えることができるのです。
したがって、これは単に「こんにちは、このライブラリには脆弱性がありますのでアップグレードしてください」と告げるだけの Dependabot や GitHub のようなものよりも、少し洗練されています。なぜなら、それが必ずしも最善の解決策ではない場合があるからです。
したがって、運用上これを使用し、実際にこの洞察を活用する場合、非常に強力なツールとなります。異なるバージョンを比較（diff）することで、ライブラリが時間とともにどのように進化していくかを正確に把握できます。
したがって、これを適切に使用し、規制への準拠のための単なる忙しさ（busywork）ではなく、運用上の手段として使用する場合、これには大きな有用性があります。
SBOM はコンプライアンスフレームワークと似ているように見えるかもしれません [08:00]
Olimpiu Pop：つまり、SOC2 や ISO 認証のような通過すべき義務として扱うべきではないということですね？
Viktor Peterson：私としては、このアナロジーも当てはまると考えています。SOC2 や ISO を見ればわかりますが、少なくともすべてのコントロール（制御項目）は基盤となっており、これらのコントロールはフレームワークへの準拠を確保するために非常に有用なものです。なぜなら、これらは空中に浮かんでいるように作られているわけではないからです。
完璧だとは言いませんが、セキュリティの向上に役立ちます。そして、それを現実世界での関与を持たない特定のチームに丸投げするのではなく、セキュリティ姿勢の向上に活用するのであれば、はい、確かに有用性があります。コンプライアンスと SBOM（Software Bill of Materials：ソフトウェア部品表）生成の全般には、多くの類似点があると考えています。
オリンピウ・ポプ：はい、同意します。私は内容については話していません。明らかにそこにベストプラクティスがあるのは明らかです。私が言いたいのは、企業が実際に、あるいは企業内の個人がそれをどう捉えているか、つまり「ああ、やらなければならないことだ」と軽く流し、「Excel を埋めるだけの作業だ」と考えているその姿勢についてです。
非常に興味深いのは、ライブラリを持っていることすら気づいていない場合がある点です。Log4Shell のことを考えてみてください。ああ、それはすでに過去の歴史ですが、Apache Struts の時代以来、おそらく Java エコシステムにおいて最大のセキュリティホールの一つでした。
面白かったのは、その当時、私がすべてのものを JavaScript エコシステムの上に構築した会社で働いていたことです。そのため、古いソースコードが存在するわけでもなく、誰もがそれを取り囲むように対応し、「私たちには影響がない」とか「まあいいか」といった調子でした。
2時間後、GCPからメールが届き、残念ながら「そのサービス」と「そのサービス」、さらに現在いくつかの顧客のために使用している「あのサービス」もLog4Shellの影響を受けており、私たちが何もしなかったため、それらをオフラインにする必要があるとのことです。では、どこで止めるべきでしょうか？
SBOM生成の課題に対処する方法 [09:53]
これは私自身、そしてSBOMについて議論する際の聴衆にとって常に疑問でした。なぜなら、それは氷山の一角に似ており、すべてのものが他のものの上に構築されており、といった具合だからです。再帰的に追跡していく場合、参照をどこかで止める必要があります。そのような問題にどのようにアプローチすべきでしょうか？
ヴィクター・ピーターソン：素晴らしい質問です。まず最初に指摘すべきは、エコシステムによって成熟度に大きな差があり、特定のエコシステム内であってもツールリングの品質が非常に異なるということです。究極的には、ほとんどのSBOMはロックファイルから生成されるため、ロックファイルの品質には大きなばらつきがあります。
しかし、SBOMの旅を始める際に最初に気づくべきことは、実際にロックファイルにものを記録しなければならないということです。例えばJavaScriptの例を見ると、JavaScriptスタックのためのSBOMを作成したい場合、単にロードしてヘッダーに含めるだけでは不十分です。ロックファイル内にそれらを含める必要があり、そこから始めるべきです。つまり、実際にそれを追跡する必要があるのです。
その作業を行うことで、あなたは目録（インベントリ）を保持することになります。これは、SBOM（Software Bill of Materials：ソフトウェア部品表）の有無にかかわらず、正しい方向への一歩です。なぜなら、今やあなたのソフトウェアに何が組み込まれているかを把握できるからです。したがって、ロックファイル（lock files）を活用し、良質なロックファイルを維持するという最初の規律が、ここで非常に重要な第一原理であると私は考えています。
次に、トランジティブ依存関係（transitive dependencies：間接依存関係）について話しますが、これは緩やかな傾斜地のようなものです。「ソースコードレベルまで全てを知りたい」と言えるかもしれませんが、現時点で多くの企業にとって、それは非常に野心的な目標だと私は思います。
まずアプリケーションのライブラリ依存関係に焦点を当て、最初の目標とすることから始めるのが良い出発点だと私は考えています。その後、オペレーティングシステムの依存関係をキャプチャするのは、多くの場合、より容易です。これらは異なる問題領域として扱い、異なる SBOM として捉え、それをキャプチャするのは比較的容易です。
ここで、例えば Docker のケースでは非常に困難になります。Dockerfile 内で何かをコピーしている場合など、状況は少し複雑になります。これは溶媒の問題（solvent problem）です。しかし、SBOM の旅を始める際に最も重要なことのひとつは、健全性チェック（sanity check）とインベントリチェックを行うことから始めることです。
私は自分の会社の一つでこの取り組みを始めた際、実際にその効果を目の当たりにしました。「おや、これを見落としていた。長らく更新されていなかったな」と気づくこともありますし、あるいは「ああ、こういうことか」と理解できる瞬間もあります。ここでは Python の例を使って説明しましょう。Python 界隈では長らく requirements.txt が標準とされてきましたが、これはすべての依存関係を取得できることを保証するものではありません。もし pip install -r requirements.txt を実行すれば、ツリー展開が行われ依存関係が取得されますが、その結果ロックファイルに正確な情報が記録されない場合があります。さらに、ハッシュ値などの整合性チェックもデフォルトでは行われません（設定は可能ですが、組み込み機能ではありません）。
つまり私が言いたいのは、こうしたプロセスを経験することで、より現代的なパッケージマネージャーが存在し、それらがより優れた依存関係の管理を実現していることに気づくということです。
例えば Python では、UV のようなツールに移行することで、パフォーマンスの向上だけでなく、依存関係のトレンドをより正確に捉える高品質なロックファイルが得られます。
JavaScript 界隈でも同様です。Bun のような新しいパッケージマネージャーを使用すれば、パッケージが適切に固定（ピン留め）されているかどうかにかかわらず、単に package.json がある場合よりもはるかに高品質なロックファイルを生成できます。
つまり、SBOM（ソフトウェア・ビルド・オブジェクトのリスト）を全く使用しなくても、「この取り組み」を開始するだけで、日頃から高品質なソフトウェアの基盤を築くことができるのが、得られる最大の利点の一つだと考えています。
オリムピウ・ポプ：では、主要なアイデアを整理すると、ロックファイルは非常に重要であり、この旅路の中で、あなたが実際に使用しているツールやビルドツール、インフラストラクチャについて見直す良い時期があります。
あなたはPythonを挙げましたが、これはその一貫性の欠如、特にタイポスquatting（類似ドメイン名を使った攻撃）やその他の種類の攻撃でよく知られていました。また、NPMエコシステムも同様に課題を抱えていました。
しかし、あなたの話を聞いていて、私たちはどちらも「垂直方向の構造がそうあるべきではない」という問題を過剰に設計しようとしたエンジニアだったと感じます。なぜなら、考えてみれば、あなたが注目しているこれらの要素はすべてデジタル製品であり、実際にはそれら各自が独自のSBOM（Software Bill of Materials：ソフトウェア部品表）を持つべきだからです。
したがって、理論的には、コンプライアンス（規制遵守）のために各企業が独自のSBOMを持つべきであり、それがさらに別のレベルへとつながります。そうであれば、直接の依存関係だけで十分でしょう。
直接の依存関係のインベントリ（目録）から始める [14:32]
ヴィクター・ピーターソン：まずその攻撃対象領域から始めるべきでしょう。つまり、あらゆるアプリケーションを眺めた場合、露出しているのはアプリケーションスタックであり、セキュリティの観点からまずインベントリチェックを行うのが理にかなっています。オペレータや脆弱性も存在し得ますが、最も一般的な攻撃ベクトルはアプリケーションレイヤーになります。したがって、無論そこが開始点となります。そして、おそらくそれはより少ないリソースで済むでしょう。はい、私はアプリケーションシステムがそもそも難しいと述べるべきです。
オリムピウ・ポプ：なるほど。つまり、アプリケーションレイヤーの依存関係を確認し、その後他のものを確認するということです。プレゼンテーションの前後で、エデラのアレックス・ゼンラ氏と少しお話ししましたが、彼は明らかにオペレーティングシステムのハードコアなレベルにいます。
彼らが多くの作業を費やしている部分を知っています。それは、コンテナで利用可能な唯一のツールに常に依存するのではなく、マイクロ仮想マシンの方がより良い場合があるという主張です。特に、これらの種類の攻撃や何らかの合理的な対策が必要な場合にそうです。したがって、SBOMを整備することに加えて、私たちは耳を傾けるべきだと考えます。新しいツールの波があり、多くの人が優れた作業を行っていますから。
ヴィクター・ピーターソン：その通りです。私も全く同感です。ただし、一つ指摘させてください。CRA（EUサイバーレジリエンス法）の影響を受ける人の99%は、ランタイムを高速化するための最新ハイパーバイザ技術のようにそれを見極めるようなハードコアなエンジニアリング企業ではありません。
彼らは、何らかのSaaS製品を持っている会社か、市場に何かしらの製品を保有している会社です。必ずしもエンジニアリングファーストの企業ではありません。これらの多くの企業にとって、エンジニアリングはコストセンターであり、彼らは最も手っ取り早いソリューションを探しただけでしょう。
したがって、それは素晴らしいことであることに間違いありませんが、コンプライアンスが必要となる大多数の企業にとっての「お手軽ボタン（手軽な解決策）」を忘れてはならないことを強調することが重要だと考えています。
SBOMの生成はパイプラインの一部であるべき [16:27]
オリムピウ・ポープ：まず第一に、アプリケーションレベルで開始し、SBOM（ソフトウェア部品表）を整備することは良い出発点です。その後、二つの異なる側面があります。一つは運用面でSBOMを活用することです。つまり、継続的インテグレーション（CI）パイプラインでSBOMを消費し、CVE（共通脆弱性識別子）や新たな問題が発生した場合に、我々が効果的かどうかを把握できるようにします。あなたが言及したように、そのコードの一部を実際には使用していない可能性があります。
そして、それはコンプライアンスに関するものです。法的な観点から言えば、コンプライアンス部門は、その生成においてどのようなライブラリを使用しているかを知りたがります。さらに規制の問題もあり、おそらく来年から施行が始まるでしょう。現在はまだ移行期間ですので、今後この動きが進んでいくと思われます。
あなたは他にもいくつか興味深い点を指摘しました。その一つは、SBOM は個人の PC で生成すべきものではなく、パイプラインという「生きた有機体」のプロセスの一部であるべきだということです。それについてもう少し詳しく説明していただけますか？
ヴィクター・ピーターソン：はい。先ほど言及した CISA のワーキンググループを想起していただければわかりますが、私たちが課した必須要件の一つは、生成を行う場合、CI/CD パイプライン内で行わなければならないというものでした。
これは SBOM の署名の重要性と密接に関連しています。どのように署名するかよりも、署名を行うこと自体が重要であり、それによって完全に追跡可能になることが求められます。特に組み込みの世界を見れば、長年にわたりファームウェアは誰かのワークステーション上でビルドされ、その後、安全でない手段で配送されてきました。
ツールは大幅に改善され、SypherやYoctoのような外観を持つようになりました。これらのツールは現在CIパイプラインで構築可能であり、SBOM（Software Bill of Materials：ソフトウェア部品表）を生成し、パイプライン内で署名することもできます。しかし重要なのは、これがあなたの設計図の一部になることです。つまり、会社全体のすべてのプロジェクトにおいてCI/CDのインフラストラクチャの一部となるべきです。そうすれば、統一された実行方法が確立され、さらに良い監査証跡（paper trail）も得られます。
したがって、遡って追跡したい場合、特定のリリースからのSBOMを確認し、差分を取ったり、運用上のデータとして活用したりできます。これにより、単なる忙しさ（busywork）ではなく、実際に有用な情報となります。
では、なぜこれをCIで行うことが重要なのかというと、信頼性のためです。そうすれば再現可能な実行方法が得られます。少なくとも、その実行プロセスの証明（attestation）が残され、遡って確認でき、監査証跡を確認することができます。
Olimpiu Pop：私はにやりと笑っています。なぜなら、あなたが「再現可能」と言ったとき、FreeBSDからの少なくとも数人の人々を知っているからです。彼らはそれについて多くの議論を持ちたいでしょう。特にFreeBSDは、最後のビットに至るまですべてのものを生成することに非常に熱心です。
つまり、重要なのは署名と使用です。例えばマシンインフラストラクチャの場合を考えましょう。これは人間が直接触れないものを指します。つまり、AIにおけるトレンドの逆です。AI分野では「人間をループ内（human in the loop）」に置くことが望まれますが、ここでは生成が一定の基準で行われることを保証する安全なインフラストラクチャ（マシン）を持つことが重要です。あなたが指摘したように、ある程度までは、ほぼ紙の追跡記録（paper trail）が存在し、監査可能な状態になります。そしてその反対側では、それがどのように作成されたかを正確に把握でき、改ざんされていないことを保証するデジタル署名が付与されています。
ヴィクター・ピーターソン：SBOMの文脈においてこれがさらに重要になる理由は、SBOMがおそらく何らかのプラットフォームへ送信されるためです。私の講演で言及したように、セキュリティアーティファクトのダウンロードと発見のためのディスカバリーメカニズムである「Transparency Exchange API」というプロジェクトに関わっています。
そのような文脈において、署名はさらに重要になりますね。転送中に改ざんされないようにするにはどうすればよいでしょうか？したがって、sbomifyで行っている範囲において、私たちのコアな前提であり根本的な信念の一つは、配布メカニズムとして私たちを信頼する必要が決してないということです。常に、その文書に対して私たちが何らかの変更を加えていないことを確認できるよう、署名が行われたCI/CDパイプラインまで遡って作業できる状態でなければなりません。
そうすれば、常に遡って確認できます。私たちや、あなたが利用している任意の TEA 提供者を信頼する必要はありません；それを信用する必要はないのです。あなたは完全に遡ることができます。そして、これが SBOM サプライチェーンにおける非常に重要な哲学的概念だと私は考えています。
オリンピウ・ポプ：振り返ると、数年前、私がこのトピックにより焦点を当てていた時期には、サプライチェーンセキュリティの3つの柱がありました。それらは以下の通りです。
SBOM。つまり、ケーキに入っている材料であり、あなたが言及したように、それらすべてを追跡する能力
署名者（signatories）について。これはナトリー（notary）に関するもので、単にこの情報を持っているだけです。おそらくそれが TEA でしょうが、あなたは…間違っていたら訂正してください。そして次に重要なのは、あなたが持っているコンテンツの再現性、つまりその内容の再現可能性です。では、まず TEA から始めましょう。
TEA は消費者に対して詳細なビルド情報を提供します [21:31]
ヴィクター・ピーターソン：つまり TEA は、発見可能な標準化された API です。例を挙げましょう。もし私が店舗からこのような箱を取り出し、それにバーコードがある場合を考えます。TEA を使用すれば、私が知る必要があるのはバーコードまたは SKU だけで、それに企業のドメインを組み合わせることで、セキュリティアーティファクトを見つけることができます。つまり、これはアーティファクトを見つけることを可能にする標準化された発見メカニズムです。
したがって、これはストレージメカニズムではありません；証明（attestation）を行うわけでもなく、ソースからの証明に依存します。今日 SBOM を作成する最も一般的な方法の一つは、Sigstore エコシステムを使用することです。そうでしょう？そしてそれはすでに GitHub と非常に良く統合されています。
つまり、これが私たちが推奨する方法ですが、他にも実施方法があります。その理由は、TEAではハッシュ値などを提供していますが、ソースに遡って検証できない場合、そのハッシュ値は実質的に無意味になるからです。なぜなら、通信途中での改ざんが可能だからです。
Olimpiu Pop：つまり、これは外部にある情報を検証する仕組みですね。例えばヨーグルトやその他の食品製品を想定してください。中身が何であるかを実際に把握し、それを検証する能力を持つことができます。
Viktor Peterson：より正確に言えば……電子店舗を想像してみてください。ウェブカメラを選ぶ場合、あるいは監視カメラを選ぶ場合です。後者の例の方が適切でしょう。なぜなら、それらはより多くの接続を持つからです。もしその製品にバーコードがあり、TEAが採用されている場合、SBOM（Software Bill of Materials）に至るまで遡って確認することができます。これは非常に強力な概念です。
Olimpiu Pop：採用の観点から、現状はどの程度進んでいるのでしょうか？
Viktor Peterson：TEAはECMAの一部であり、私たちはISO規格への昇格を目指しています。今年後半にはECMAにおける標準化プロセスに入ります。TEAはOWASPおよびCycloneDXの下に位置づけられており、それらはECMAと連携しています。
目指すのは、完全に標準化されたプロセスとなることで、より多くの採用を得ることです。今週ENISA（欧州連合機関サイバーセキュリティ局）から論文が発表され、TEAもその手法の一つとして強調されています。私たちは勢いを増しています。
私の知る限り、オープンソースで提供されているTEAの実装は2つだけです。つまり、現在ReARMとsbomifyがTEAの唯一の実装ですが、今後さらに多くの実装が登場する可能性があります。
Olimpiu Pop：ご指摘の通り、TEAはCycloneDXを生み出したグループ、つまりOWASPから派生したものでしょうか。
Viktor Peterson：はい。ただし、TEAがベンダーニュートラルであることは重要です。例えば、配布メカニズムであるSPDXに対してCycloneに偏ったものではないということです。
Olimpiu Pop：はい、その点には同意します。しかし、技術分野の私たちはサッカーファンに似ているとも思います。もし私たちが特定のサッカークラブを応援して育った場合、その支持が変更されることは稀です。そのため、以前はSBOM（Software Bill of Materials）のために前面に押し出された3つの規格がありました。現在、SPDXとCycloneDXがより大きな勢いを得ています。そして、私が希望するのは、TEAが実際にベンダーニュートラルであり、使用するフォーマットに関係なく広く採用されることです。
Viktor Peterson：はい。また、それはSBOMを超えたものです。つまり、TEAはセキュリティアーティファクトの発見メカニズムであることを強調することが重要です。したがって、それはSBOMに限定されません。VEX（Vulnerability Exploitability eXchange）ファイルやコンプライアンス文書であっても構いません。つまり、配布メカニズムとしてSBOMのみを超えたものです。
Olimpiu Pop：わかりました。先ほどお店で購入した監視カメラに戻りますが、バーコードをスキャンすると、VEXファイルやSBOMファイル、さらにはいくつかのアドバイザリ（注意喚起）が得られるのでしょうか。
ヴィクター・ピーターソン：はい、マニュアルやその他何でも構いませんよね？
オリムピウ・ポプ：つまり、この製品を使用する際にセキュリティに影響を与える可能性のあるものはすべて含まれるということです。
ヴィクター・ピーターソン：そうです。例えば、「このデバイスがライフサイクル終了（End-of-Life: EOL）状態にあるソフトウェア、あるいは非常に古いバージョンのソフトウェアを使用していることがわかりました」と発見できるかもしれません。そして、「実際に、EOL版のフレームワークやオペレーティングシステムを使用している製品は購入したくない」と判断することもできるでしょう。
規制当局は何をチェックするのか？[25:41]
オリムピウ・ポプ：規制当局が検査に訪れた際、過去数リリース分にわたる構成要素を示すソフトウェア・ビルド・オブジェクト・マニフェスト（Software Bill of Materials: SBOM）について質問してくる可能性があります。そのような状況をストレスなく対応するには、どのようにアプローチすべきでしょうか？
ヴィクター・ピーターソン：答えは「ケースバイケース」です。これは、人々がSBOMの作成を始めるまで気づかなかった点の一つです。私も、実際に大規模なSBOM作業を行うまでこれに気づきませんでした。まさにこの問題意識から、sbomifyというプロジェクトが誕生しました。
あなたがオープンソース・プロジェクトを運営している場合、GitHub上でSBOMを保管することは理にかなっています。単にリリースアーティファクトの一部として公開するだけで完了です。これで、過去の履歴を簡単に参照・追跡できる方法が手に入ります。
もしあなたが商業製品を販売している場合、それははるかに困難になります。ここで人々は、SBOM（Software Bill of Materials：ソフトウェア部品表）の旅を始めたとき、比較的単純な製品であっても、SBOMが一つだけではないことにようやく気づきます。おそらく10個、20個、30個のSBOMが存在し得ます。なぜなら、バックエンドがあり、コンテナがあり、ファームウェアがあり、実際の製品を構成する要素があまりにも多いからです。そして、あなたのSBOMはそれらすべてを表現する必要があります。これが、そのようなリリース管理を行うためにsbomifyが生まれた理由です。
では、「このソフトウェアのリリースはこれらのコンポーネントで構成されている」とどのように表現しますか？そして、これらのコンポーネントの一部、あるいは多くのコンポーネントが次のリリースでも再利用される可能性があります。本質的にトップレベルのリリースがあり、あなたはこれらのコンポーネントを指し示します。
そして、それは重要なことです。特定のリリースを構成するものの監査証跡（audit trail）を提供します。なぜなら、現実の世界では、そのようなソフトウェアリリースを行っているとき、1年後、2年後、あるいは3年後に、特定のリリースを構成するソフトウェアの特定の組み合わせを逆エンジニアリングしようとするのは非常に困難になるからです。
つまり、それは可能ですが、非常に高価になります。おそらく日付を確認し、Gitにアクセスして日付を見つけなければなりません。そしてそれは非常に困難になります。したがって、これはリリースライフサイクル管理の大きな部分であり、他のリリースにまたがるリリースにタグを付けることができることです。
そして、それが私たちがその製品で構築した大きな要素の一つであり、基本的にはリリースの切り捨てが可能になることです。これは複数のコンポーネントにまたがります。そして、それによって、「監査人が来て、『バージョン2.1.0の構成要素は何だったのか？』と尋ねた場合」という状況に対応できます。その際、「ここに、特定のバージョンとその構成要素となったすべてのコンポーネントのSBOMがあります」と答えることができます。
使用するツールは？ [28:06]
オリンピウ・ポプ：しかし、今ではツールリングについても話です。2年前、私はSyftについて調査していました。Trivyがすでに存在していることは知っています。ベンダーニュートラルなツール、あるいはパイプラインに追加して使用できるツールはどのようなものがありますか？ GitHubやその他の大手企業を脇に置き、単なる古いパイプラインを想定した場合、何を使用すべきでしょうか？
ヴィクター・ピーターソン：私は偏った回答をしますが、私たちが「sbomify action」と呼ぶものがあります。これはスーパーセットのツールであり、我々は各タスクに対して最適なツールを意見として選択します。しかし、そのロジックは外挿可能であり、我々のロジックは、エコシステム固有のツールが汎用ツールよりもより高品質なSBOMを生成する傾向があるということです。
つまり、Python用のCycloneDXツールは、例えばTrivyよりも優れたSBOMを一般的に生成するということですね。なぜなら、汎用ツールは、さまざまな言語が行えるすべてのメタデータを拡張して抽出する傾向がないからです。各エコシステムにおいて、過去数年間でパッケージ管理の分野にはかなりのイノベーションが見られています。最近ではUVやBunをその良い例として挙げました。そして、多くの汎用ツールはそれらに追いついていません。
まず、SPDXかCycloneのどちらの陣営を選ぶかを決めてください。そして一度その陣営を選べば、ツールの選択は少し簡単になります。両方とも機能を持つツールを持っています。おそらくCycloneのツールの方がSPDXのツールよりも多いと言えます。なぜなら、SPDXのツールはよりライブラリを重視するのに対し、Cycloneはよりエンドユーザー向けのツールを重視しているからです。
したがって、Yoctoの場合、彼らはSPDXのツールキットライブラリを使用して、パイプライン内で直接SBOMを構築しています。一方、Cycloneにはより多くの汎用ツールがあります。「これは私のPythonのロックファイルです。これを使ってSBOMを構築してください」という汎用ツールです。あなたが属する陣営を決めること、それが良い出発点でしょう。そして、そのエコシステム内のツールを1つ選んでください。
Olimpiu Pop: なるほど。つまり、まず開発者やエコシステムの維持者が使用するツールを選択し、実際に属しているエコシステムに密着して対応する必要があります。すべての釘に対して同じハンマーを使うのではなく、各釘に適したツールを使用するのです。
ヴィクター・ピーターソン：その通りです。表面的には、汎用ツールはあらゆることができるため魅力的に思えますが、そこには妥協があります。実際にこれを運用し、データを活用したい場合、当然のことながらデータの品質が重要です。「ゴミを入れればゴミが出る」のです。このデータに基づいて意思決定を行いたいのであれば、可能な限り高品質な SBOM（Software Bill of Materials：ソフトウェア部品表）を入手する必要があります。つまり、真の目標は高品質な SBOM を取得することです。
したがって、ワーキンググループの議論に戻ると、私たちが取り組んだのは NTIA（National Telecommunications and Information Administration：全米通信情報局）の最低要件への準拠達成です。これが SBOM におけるゴールドスタンダードと見なされています。私の知る限り、これらのツールのいずれもが、箱から出したままの状態で NTIA 最低要件に準拠した SBOM を生成することはありません。そのため、追加のツールリングが必要です。しかし、これは多くのコンプライアンス規制が徐々に指向し始めている品質のバリアと言えます。
SBOM が将来はファーストクラス・シチズンになる可能性あり [31:12]
オリムピウ・ポプ：そこで安全に過ごすために、他に何を知るべきでしょうか？
ヴィクター・ピーターソン：チームで話し合うことは、非常に良い会話の始まりだと思います。私たちが最初に話した点に戻りますが、ロックファイルの監査を行うことは、非常に価値のある演習です。パイプラインを確認し、ベストプラクティスに従っていることを確認してください。多くのコードを扱っていると、こうした事項を見失いがちだからです。放置しておくと腐敗し、忘れ去られてしまいます。
そのようなインベントリを作成し、SBOMを活用してパイプラインに適用することで、強制的にインベントリチェックを行うことになります。そして、私はそれが非常に重要だと考えています。その作業が完了すれば、ライフサイクルやリリース管理に焦点を当て、SBOMがライフサイクル管理に適切に組み込まれることを確保できます。さらにその先では、SBOMの品質に注力し始めることができます。
そしてそれが次のステップであり、NTIAやCISAにおける最小要素の定義、およびSBOM内にすべてのデータが表現されていることを確認することです。ただし、最初からそれらをすべて行おうとすると負担が大きすぎるかもしれません。私はまず何らかの形でプロセスを構築し、その後で反復、調整、そしてプロセスの精緻化を行うことをお勧めします。一度にすべてを解決しようとするのではなく、段階的に進める方が現実的です。
Olimpiu Pop: SBOMが適切であることを保証するSBOMリンターは存在しますか？
Viktor Peterson: はい、いくつかのツールが存在します。sbomifyには、これらのチェックを実行し、各種規制への準拠性を判断できるツールがあります。先ほど言及したように、CISAやNTIAの要件に関するチェックがあります。FDAもいくつかの基準を持っており、CRA（Cyber Resilience Act：サイバーレジリエンス法）も独自の解釈に基づくチェックを持っています。
私のプレゼンテーションで覚えているかもしれませんが、CRAとNTIAの間にベーン図を示しました。まさにあなたが目指すべきは、それらの両方を組み込むことです。そして、SBOM分析を実行できるsbomqsという別のツールも存在します。
NTIAの最小要素は、おそらく私たちが持つユニバーサル・スタンダードに最も近いものであり、品質の基準としてますます参照されるようになっています。
そして昨年秋に公開されたシステム最小要素のドラフトがあり、おそらく今年後半に正式発表される見込みです。これは前述の内容を基に、いくつかの変更を加えたものです。
これにより、「貴社はどのような企業か？」といった評価が可能になります。SBOMにハッシュ値が含まれているか、などです。そこには品質を単なる「〜以上」ではなく、より厳格なものにするための多くの要素が含まれています。明確に申しますが、これらの汎用ツールでは、NTIAの最小要素を完全に満たすSBOMは生成されません。
オリンピウ・ポプ：貴重な洞察をありがとうございます。他に知っておくべき有用な情報はありますか？
ヴィクター・ピーターソン：SBOMへの対応を今すぐ始めるべき時です。将来のすべてのコンプライアンス・フレームワークがSBOMを要求すると予想しています。それは「ソフトウェアに何が組み込まれているかを理解しているか」という試金石となります。すでにPCI DSS 4.0でソフトウェア・インベントリ（資産目録）の要求が示されています。
ISO規格への改訂やSOC 2の要件も、すべてSBOM（Software Bill of Materials：ソフトウェア部品表）の提出を義務付けるようになると思います。そして、私はこれが「トラストセンター」のあり方を根本から変えると考えています。過去数年間でトラストセンターに関する過度な期待や喧騒が見られましたが、SBOMはコンプライアンス文書と同様に、そしてそれ以上に重要視されるべきものであり、信頼の中心に位置づけられる必要があります。なぜなら、ソフトウェアをどのように扱うかという情報は、それ自体が極めて重要だからです。
さらに私は、各種サービスで二段階認証（2FA）を確実に導入することよりも、SBOMの提供が重要だと主張します。つまり、将来の姿として予測されるのは、SBOMがトラストセンターにおいて「ファーストクラス・シチズン（主要な構成要素）」として扱われるようになり、今後策定されるほぼすべての規制や認証基準の一部となるということです。
セキュリティツール自体も侵害される可能性がある [34:39]
オリムピウ・ポプ：録画開始前に、最近のTrivyの件について話しましたが、最後に一言コメントをいただけますか？
ヴィクター・ピーターソン：もちろんです。Aquaのチームの人々に対しては大きな同情を抱いています。彼らはSBOMコミュニティにとって非常に良い貢献を果たしてきましたが、まだその影響がどのように展開しているかを見守っている段階です。ご存知ない方のために補足すると、Trivyは長年存在する最も人気のある汎用SBOM生成ツールの一つでした。
これまでに2回のリリースで侵害され、Trivyパッケージにinfostealer（情報窃取ツール）が組み込まれていました。その結果、PyPIパッケージのLiteLLMなど他のパッケージも侵害され、 blast radius（被害範囲）が広がりました。LiteLLMは数日前に侵害されました。
まだ完全な実態は不明ですが、AquaのGitHub組織全体が侵害されたという証拠があります。彼らはTrivyを侵害した上で、AquaのGitHub組織全体に侵入することに成功しました。そのため、被害の規模は正確には不明ですが、非常に深刻な状況に見えます。
私たちはパイプラインからTrivyを削除しました。以前は、sbomifyアクションでSBOM生成ツールの一つとしてTrivyを使用していました。影響を受けたバージョンは使用していませんでしたが、安全策を講じるため、生成ツールからTrivyを積極的に削除しました。正直なところ、「過剰な安全は後悔よりまし」です。私は、この件によるさらなる波及効果が見られることを予想しています。
LiteLLMは私たちが把握している最初の事例ですが、これが最後ではないと疑っています。Trivyがinfostealerにとって魅力的な標的となる理由は、CI/CDパイプラインで実行されるためです。人々はパイプラインで長期有効な資格情報（long-lived credentials）を使用する傾向があり、それが侵入経路となっています。
したがって、ここで重要な教訓は、パイプラインにおいてOIDC（OpenID Connect）および短期有効な資格情報への移行を進めることです。また、GitHub Actionモジュールはバージョンではなくハッシュ値で固定（pin）してください。Trivy事件から得た教訓は、彼らが過度に頻繁にリリースを行っていることです。
GitタグやGitリリースは確実なものではないと考えるべきです。これらは上書き可能です。そのため、ハッシュに固定することで、自分が何を行っているかを確実に把握することができます。
これはロケットサイエンスのような難しい話でも、新しい情報でもありません。セキュリティ分野で活動している誰もがこれを行うべきであることを完全に理解しています。しかし、これを行わない場合に何が起こるのかという教訓的な話です。
オリンピウ・ポプ：わかりました。共有していただき、またお時間を割いていただきありがとうございます。
ヴィクター・ピーターソン：こちらこそありがとうございます。
言及された項目：
ソフトウェアBill of Materials（SBOM）の最小必須要素
サプライチェーン攻撃を受けたオープンソースセキュリティツールTrivy、緊急の業界対応を促す
著者について
ヴィクター・ピーターソン
ヴィクターは連続起業家でありサイバーセキュリティのイノベーターで、現在ソフトウェアのセキュリティとコンプライアンスの未来形成に注力しています。sbomifyの創業者として、Software Bill of Materials（SBOM）管理を簡素化し、Cyber Resilience Act（CRA）といった新たなサイバーセキュリティ規制を組織が乗り越えるのを支援しています。また、ヴィクターはScreenlyの共同創業者でもあります。これは世界中で10,000以上のスクリーンを稼働させる主要なセキュアなデジタルサイネージプラットフォームであり、NASA、ローズ、キャピタルワンといったセキュリティ意識の高い組織から信頼されています。
安全で効率的なテクノロジーの実践を提唱するヴィクトルは、急速に進化するサイバーセキュリティの状況に対応する企業をサポートすることに情熱を注いでいます。彼はポッドキャスト「Nerding Out With Viktor」を通じて洞察や業界のトレンドを発信し、思考のリーダーや技術者と交流しながら、テクノロジーセキュリティ、イノベーション、コンプライアンスにおける次なる展開を探求しています。
Show moreShow less
ポッドキャストの最新情報はRSSフィードでご覧いただけます。また、SoundCloud、Apple Podcasts、Spotify、Overcast、YouTubeでもご利用いただけます。
このページからは録音されたショーノーツにもアクセスできます。これらにはオーディオの該当箇所へ直接ジャンプできるクリック可能なリンクが含まれています。
原文を表示
Transcript
Olimpiu Pop: Hello everybody. I'm Olimpiu Pop, an InfoQ editor, and I have Viktor Peterson in front of me. And he will try to bring more details about what happened in the SBOM space, especially regarding the legislative changes, and also what's actually important for us to know as developers, without the big stick looking at us.
Viktor, you have a couple of things that you're working on, so please give us a short intro on what you're doing.
Viktor Peterson: Thank you so much for having me. Quick intro: done a few startups. I got kind of thrown into the world of SBOMs in one of my companies when we started doing Secure by Design a few years ago.
We had a mandate, as part of that, to start generating SBOMs for our product. I thought that would be a really tick box exercise done in a week, and then move on with it. Turns out it wasn't quite that straightforward.
So I kind of got really deep into that. I ended up joining and co-chairing one of the working groups at CISA back when CISA was actually in the SBOM world. And we ended up creating a white paper on SBOM generation. That, in turn, turned out to be a lot more interesting than I expected.
And I actually ended up creating a new company called sbomify, where we implement that blueprint from the working group, basically letting you create high-quality SBOMs because it's actually a lot more challenging than most people realise. So that was kind of the goal there.
Olimpiu Pop: Thank you. It's very important because supply chain attacks are becoming increasingly pervasive, especially nowadays. But actually it's not the easiest thing to push because a lot of the people are just looking into... And they feel like it's yet another certification, or it's something that's coming from outside.
And actually, I think starting with this year, it's true, especially for the European Union. On the cyber resilience side, the CRA is coming into force. I think the US has some legislation in place. I know that the UK did speak about it, so maybe let's start by looking at the sticks before going to the carrots.
SBOM Enforcing Legislation [02:24]
Viktor Peterson: SBOMs have been around for a long time. They're not new by any means, but what we've started as CEO over the last few years, starting with executive order 4989, in the US, we've already been selling software to the US government were required to start providing SBOMs. That was kind of the first stick, as you say, for software vendors to start generating SBOMs.
The much bigger stick is, to your point, CRA in Europe. And the soft enforcement window starts this year. And I would say most people are completely unaware that they will be affected by this.
And just for those who are not familiar with CRA, it's a piece of legislation that affects anybody selling products into the European market. And the litmus test as they use it in the legislation is obviously intentionally vague. And the idea is basically to make it so that anything that connects to the internet more or less needs to be compliant with CRA. CRA, in turn, requires you to generate an SBOM. So that's kind of why we're here today.
Olimpiu Pop: So that means that pretty much any electronic or software should have an SBOM or... Well, actually, the label shows the ingredients that are in. So that's scary?
Viktor Peterson: Yes. I mean, so many people are fully unaware of this, and it's kind of a GDPR moment, I would say, for Europe. But I guess people are less aware of this than they were about GDPR in many ways.
But unlike GDPR, where the stick was large fines, the stick here is having a product block from the European market, which is a much, much bigger stick than just fines. As you can see in the case of Meta and these big boys, they just assume the cost of GDPR fines essentially as a cost of doing business in Europe. They learned from this, and now it's the block in the fund market, which is a much greater stick to hit with.
Olimpiu Pop: What I particularly liked about the way the CRA came to be was the fact that the community was quite involved. And it seemed that the EU learned and actually listened. And I don't want to be on that side of the fence as a regulator, but I have to be happy as a consumer of digital services, digital products, and AI on these two points.
The AI Act, that's not in the focus of our discussion, but also the CRA, because actually you saw it. What I'm afraid of currently is the way it'll come to be implemented. And that's especially from the way the European Union is built.
So now you have the legislation in place, and then it's up to each of the countries of the European Union to implement it and to give it shape. I think Germany is one of the countries that already has a form for that.
Viktor Peterson: Yes. Germany's BSI is the first real implementation. I think there have been 2.2 now of their interpretation of that far, which has been kind of evolving. But just bringing back to your previous point, I'm not a fan of heavy-handed legislation either, but I think it's important to acknowledge that security is a market failure.
We've seen this for so long; vendors do not care because it's not in their interest from a financial perspective to invest in security. And the consequence of that is baby cameras being exposed to the public on the internet and so forth. So I think there's a good reason this exists: the market really failed to self-regulate, I'd say.
Developers Should Care About SBOMs Too [05:51]
Olimpiu Pop: Yes. And I think it's very important to take that responsibility and people who are actually part of it to do it. But on the other side, what are the benefits for us as software developers and practitioners, because it comes with added benefits as well. Let's look into those things. What would be useful for other developers to know about SBOMs from your perspective as a developer?
Viktor Peterson: Yes. If you purely treat this exercise as a tick-box exercise, which is, "I'm doing this for the sake of being compliant," then you're not really reaping the benefits of generating this, and you're creating a lot of work for no reward, right?
But the reality is, if you actually make this operational... A lot of companies are already, this is not theoretical. Many companies use this heavily as part of their workflow. They're using SBOMs to do security audits of their code base, and they're using it to do a license-compliant audit of their supply chain.
So a lot of companies have policies for "We're not allowed to use," say, "GPLv3 code in our source code or in our libraries." So you can use an SBOM for license compliance audits. More commonly, it's used for security audits. If you can generate an SBOM from a lock file, you can then, in turn, find CVEs that are affecting it.
And the ecosystem is a bit more mature because there's also something that's called VEX that goes on top of this, where you can say, "Yes, I'm affected by the CVE, but this CVE impacts this particular function in this library, but we're not using that." So you can issue what's called the VEX statement and say, "Yes, I can go with the CVE because we're not impacted by it."
So it's a bit more sophisticated than what you would have in say Dependabot and GitHub, which just says, "Hey, here's a vulnerability in this library, upgrade." Because sometimes that's not necessarily the best path forward.
So I think if you're using it operationally and you're actually using the insights from this, it becomes a very, very powerful tool. And you can diff different versions, and you see exactly how libraries evolve with time and so forth.
So there's a great deal of utility in this if you actually use it properly and use it as an operational vehicle rather than just busywork to be compliant with regulations.
SBOMs Might Seem Similar to Compliance Frameworks [08:00]
Olimpiu Pop: So we shouldn't treat it like a SOC2 or ISO certification chore that you have to pass through?
Viktor Peterson: I mean, I think that analogy holds true there as well, because if you look at SOC2 and ISO, at least all the controllers are underlying, the controllers can be very helpful in order to ensure your compliance with the framework, because they're not made out of thin air.
I'm not saying they are perfect, but they do help you improve your security. And if you use it to help improve your security posture rather than just farm it off to some kind of team that has no real-world involvement, then yes, you have no utilities. I think there are many analogies between compliance and SBOM generation in general.
Olimpiu Pop: Yes, I agree with you. I'm not talking about the content because obviously there are good practices in that. I'm just about the way how actually companies or individuals in companies are looking at that and just waving, "Okay, that's something that we have to do, and it's just an Excel to have to fill in."
And it's very interesting, especially as there are points when you don't even know that you have a library. I'm just thinking about the Log4Shell. Well, that's ancient history already, but it was probably one of the biggest security holes, especially in the Java ecosystem, since the era of Apache Struts.
And what was funny is that at that point in time, I was working in a company that had built everything on top of the JavaScript ecosystem. So it was not just an old source, and everybody was just coping around it, "Okay, we are not affected then," blah, blah, blah.
Two hours later, we got an email from GCP saying that, unfortunately, the service and that service and that service, and also that service that we are using currently for a couple of our customers are all affected by Log4Shell and they have to put it offline because we didn't have anything to do. And where do you stop?
How to Tackle the SBOM Generation Challenge [09:53]
Because that was always a question for me and also for the audience when discussing SBOMs, because it's like an iceberg, and everything is built on top of the other stuff and so on and so forth. And then, if you go recursively, you have to stop somewhere with your references. How should you approach that kind of problem?
Viktor Peterson: It's a fantastic question. I think the first thing to flag there is that ecosystems have very different maturity levels, and even within a given ecosystem, you have a very different quality of tooling because ultimately most SBOMs are generated from lock files, and lock files vary in quality a great amount.
But I think the first thing when you go on your SBOM journey that you realise is that you actually do have to capture things in a lock file. So, going down the example of JavaScript, for instance, if you want to actually do SBOMs for your JavaScript stack, you can't just load things and include them in a header. You need to have them in a lock file, and you should start with that. So you actually trace that.
By virtue of doing that, you have an inventory, and that is like... Regardless of whether there's an SBOM, that is a step in the right direction because you now know what's going into your software. So I think the first discipline of leveraging lock files and having good lock files is the first principle that is really, really important here.
Now, we talk about transitive dependencies, and that is kind of a slippery slope because you could say, "Well, I want to know everything down to source code." But I think it's a very, very ambitious goal for most companies right now.
I think if you can start by focusing on your application library dependencies as the first initial target, that's a really good starting point. Then, capturing operating system dependencies is kind of easier in many ways. I would treat them as different problem spaces, and different SBOMs, and capturing that is easier.
Now, it gets really difficult in the case of Docker, for instance, what if you have a Docker file where you're copying things in and so forth, it gets a bit more complicated. It's a solvent problem. But I think one of the most important things when you're starting your SBOM journey is that you start doing a sanity check and an inventory check.
And I've seen this firsthand when we started doing this in one of my companies. We're like, "Oh wow, we forgot about this. That hasn't been touched for a while." Or you realise that... I'm just going to use the Python example. Requirements.txt has been like the standard for a long time in the Python world, but it makes no guarantees that it captures all the dependencies because it will happily, if you do pip install -r requirements.txt, you will happily do the tree expansion and pull dependencies so that your lock file is not capturing that role. And it also doesn't do hashes and so forth; you can, but it's not built in.
So I guess what I'm saying is by going on that journey, you start to realise that there are more modern package managers out there that do a better job, that will capture the dependency tree much better.
So in Python, for example, moving to something like UV will give you not only a performance boost, but it also gives you a much higher quality lock file that will actually capture trends to dependency much better.
The same is true for the JavaScript world. You look at new package matches like Bun, for instance, would generate a lot better lock files than just having a package adjacent, which may or may not be pinned properly.
So I think that is one of the biggest wins that you get from day zero, without even using the SBOMs, by just getting onto that journey, you end up having high-quality software.
Olimpiu Pop: So just to frame the main idea is that lock files are quite important, and there is a good moment on this journey to revisit what you're actually using in terms of tooling, build tools and the infrastructure.
You pointed Python, which was quite known for its inconsistency and especially typosquatting and other types of attacks, and the NPM ecosystem, which again had its challenges.
But just listening to you, I think we were both two engineers who tried to over-engineer a problem that the vertical shouldn't be like that, because actually, if you think about it, all these pieces that you're looking into are all digital products, and actually, they should come with their own SBOMs.
So our direct dependencies will be more than enough, given that theoretically speaking, in order to be compliant, each and every company should have their own SBOMs, and then that will go to a different level.
Start with the Inventory of Your Direct Dependencies [14:32]
Viktor Peterson: I would start with that attack surface, almost, right? So if you're looking at any application, it's the application stack that is exposed, so starting there makes sense from a security perspective to do an inventory check first, right? Because there could be operators and vulnerabilities as well, your most common attack vector will be the application layer. So that's kind of where you want to start, regardless. And it's probably less. Yes, I would say the application system is usually harder anyway in the first place.
Olimpiu Pop: Okay. So look at the dependencies in the application layer and then look at the other ones because around your presentation, we spoke or I spoke a bit with Alex Zenla from Edera, and obviously, he's at the hardcore level of the operating system.
And I know that they have a lot of work into that part where they are just saying that, rather than always going with the only tool that is out there in containers, maybe a micro virtual machine would be better, especially if you can have these kind of attacks and something sensible. So I think there is a new wave of tooling and a lot of people who are doing a lot of excellent work. So I think we should open our ears, besides having the SBOM in place.
Viktor Peterson: Absolutely. I couldn't agree more. But the one thing I would say is that 99% of all the people that is going to be impacted by CRA, they are not the hardcore engineering companies that are going to look at it like the latest hypervisor technology to speed up the runtime.
They will be companies that have some kind of SaaS product, or they have some kind of product in the market. They're not necessarily engineering-first companies. Engineering is a cost centre to a lot of these companies, and they are just going to look for the quickest solution.
So I think it's important to highlight that, yes, that's great. And there are great ways to solve that, but we still shouldn't forget about the easy button for the vast majority of the companies that will need to be compliant.
SBOM Generation Should Be Part of the Pipeline [16:27]
Olimpiu Pop: So first and foremost, it's a good place to start the application level, look at that, have the SBOM in place. Then there are two different things. One of them is that we can use it operationally. So we can consume the SBOM in our continuous integration pipeline to ensure that whether there is a CV, there is a new problem out there, we know whether we are effective or not. As you mentioned, it might be that we are not actually using that part of the code.
And it's about being compliant. So, from the legal point of view, the compliance department will want to know what kind of libraries we are using in terms of generating that. And then it's about regulatory, and that will start coming into place, probably starting with next year. Now it's still just a transition period. So, probably that will happen moving forward.
You had a couple of other interesting points. One of them is that the SBOM is not something that you should generate on your PC, but it should be part of the process in the living organism of your pipeline. Can you have to elaborate a bit on that?
Viktor Peterson: Yes. I think, again, going back to the whole CISA working group we spun up, one of the hard requirements we had was that, for generation, you must do it in a CI/CD pipeline.
And this ties very closely to the importance of signing SBOMs. How you sign them doesn't matter so much as the fact that you do do it so that you can trace it all the way back. But in particular, if you're looking in the embedded world, for far too long, firmware's been built on somebody's workstation, and then they just shipped off over some unsecured mechanism.
Tooling has got a lot better, looking both like Sypher and Yocto. These tools can be built in the CI pipeline now, and they can generate SBOMs, and they can be signed in the pipeline, but it's important that it becomes part of your blueprint, right? It becomes part of the CI/CD fabric for all the projects across your company. So they have a unified way of doing this, and you also have a good paper trail.
So if you want to traverse backwards, you can go back and look at the SBOM from a given release and diff it, or use that data operationally so that, again, it becomes useful rather than just busywork.
So I think why it's important to do this in CI because of trust, because then you have a reproducible way of doing it. At least you have proof of attestation of how it was executed, and you can work backwards, and you can see the trade trail.
Olimpiu Pop: I'm smirking because I know at least a handful of people from FreeBSD who, when you say that, that's reproducible, they will have a lot of things to debate around it, especially FreeBSD, which they are very eager to generate everything up to the last bit.
So then the important part is signing and using, let's say, machine infrastructure. So, something that you don't have humans touching it. So it's the reverse trend as with AI. In the AI space, you want a human in the loop. Here, it's important to have safe infrastructure, such as machines that ensure it is generated in a constant manner. And as you said, up to a point, it's something that, more or less, you have a paper trail and something that is auditable. And on the other side, you know exactly how it was, and you have the digital signature on it that ensures that was not been tampered with.
Viktor Peterson: And the reason why this is even more important in the world of SBOM is that the SBOM will most likely be sent off somewhere else to some kind of platform. So I mentioned in my talk, a project that I'm involved with called Transparency Exchange API, which is kind of the discovery mechanism for downloading and discovering security artefacts.
In the context of that context, the signing becomes even more important, right? How do you prevent that from being tampered with in transit? So, in the case of, in extent as we do with sbomify, one of the core premises for us and a core fundamental belief in us is that you should never have to trust us as a distribution mechanism. You should always be able to work your way back to the CI/CD pipeline where it was signed, so that we have not made any alterations to that document.
So you can always traverse back. You never have to trust us or whatever TEA provider you're using; you don't have to trust it. You can go all the way back. And I think that's a really, really important philosophical concept in the SBOM supply chain.
Olimpiu Pop: Thinking back, there were three pillars of the supply chain security a couple of years back, the point when I was more focused on this topic, and those were:
the SBOM. So the ingredients that are going in the cake and the ability to trace all of them, as you mentioned
the signatories, about a notary, where you just have this information, and I suppose that's maybe TEA, but you have to... Correct me if I'm wrong. And then it was the ability to reproduce it, the reproducibility of the content that you have. But let's start with the TEA first
TEA Provides In-Depth Build Information to Consumers [21:31]
Viktor Peterson: So TEA is basically a standardised API that you can discover. So I'll give you an example. If I pull a box like this from a store, and it has a barcode. With TEA, all that I need to know is the barcode or SKU and combined with the company's domain, I can find security artefacts. So it's a standardised discovery mechanism that allows you to find the artefacts.
So it's not a storage mechanism; it doesn't do attestation; it relies on attestation from the source. One of the most common ways of doing SBOMs today is to use the Sigstore ecosystem, right? And that's already very well integrated into GitHub.
So that's kind of how we recommend people to do it, but there are other ways to do it. And the reason is that in TEA we provide the hashes and so forth, but the hashes are kind of useless if you can't work your way back to the source because that could be tampered with in transit.
Olimpiu Pop: So this is actually the mechanism through which you have the ability to check the information that's out there, right? Let's say you have a yoghurt or whatever food product, you have the ability to actually know what's inside, and that's the ability to check it.
Viktor Peterson: Well, it's more like... Imagine for an electronic store, and you're picking up a webcam or, well, maybe a surveillance camera is a better example because it's going to be more connected, right? But if you can find the barcode for that product and if they have adopted TEA, you can work your way all the way down to the SBOM. And that's really a powerful concept.
Olimpiu Pop: And in terms of adoption, how far along is it?
Viktor Peterson: So TEA is part of ECMA, and we are aspiring to become an ISO standard, and we're going into standardisation for ECMA at the middle of the tail of this year, and it lives under OWASP and CycloneDX, which in turn is connected to ECMA.
And the idea is to become like a fully standardised process so that it will gain more adoption. There was an ENISA paper published this week, and they can highlight TEA as one of those mechanisms as well. We're gaining momentum.
To my knowledge, there are only two implementations of TEA that are open source out there. So ReARM and sbomify are the only two implementations of TEA right now, but there will probably be more to follow.
Olimpiu Pop: As you mentioned, TEA is coming as maybe a spinoff from the group that also brought CycloneDX, so from OWASP.
Viktor Peterson: Yes, but it's important to note that TEA is vendor-neutral, right? So it's not biased towards Cyclone over SPDX, for instance, which is the distribution mechanism.
Olimpiu Pop: Yes, I agree with you, but I also agree that we, in technology, are like football fans. And if we were born cheering for a football team, it's seldom the case that it will change. And that's why I'm saying that there used to be three standards that were pushed upfront for the SBOMs. Now, SPDX and CycloneDX are actually the ones that gain more momentum. And that's my hope that TEA will be actually vendor-neutral and adopted all over the place, regardless of the format that you use.
Viktor Peterson: Yes. It also goes beyond SBOMs, right? So it's important to stress that TEA is a security artefact discovery mechanism. So it's not just limited to SBOMs. It could be VEX files, or it could be compliance documents. So it goes beyond just SBOMs as a delivery mechanism.
Olimpiu Pop: Okay. So, going back to your surveillance camera that I just bought from the shop. Scanning the barcode might bring, okay, maybe some VEX files, some SBOM files, maybe some advisories?
Viktor Peterson: Yes, manuals or anything you want, really, right?
Olimpiu Pop: So it's actually everything that can affect my security when using this product.
Viktor Peterson: Yes. So you could discover, for instance, that "Oh, this device is using an end-of-life software or a very, very outdated software." You can maybe decide that, "Actually, I don't want to buy this camera because I don't want to use something that is using an EOL version of," I don't know, insert blank, "framework" or insert blank, "operating system."
What Would Regulators Check For? [25:41]
Olimpiu Pop: The regulatory boards, when coming and checking, might ask you about SBOMs, so ingredients that went back a couple of releases. How can you approach that in a stress-free manner?
Viktor Peterson: The answer is it depends. This is one of the things that people haven't realised until they start doing SBOMs. And I didn't realise this until we were doing SBOMs. And this is literally why sbomify was born because of the problems around that we discovered firsthand when doing SBOMs at scale.
If you're an open-source project, stashing your SBOMs on GitHub makes perfect sense. You just make it part of the release artefacts and voila. Now you have an easy way to look back and trace back in history.
If you're selling a commercial product, it gets a lot more difficult. And this is where people, when they go on their SBOM journey, only start to realise that even a relatively simple product will have not one SBOM. You probably can have 10, 20, 30 SBOMs because there's the backend, there are containers, there's firmware, there are so many things that make up a real product, right? And your SBOM needs to represent all of that. And this is kind of where sbomify was born, to do that release management.
So how do you say, "Okay, this release of my software is composed of these components." And some of these components or many of these components might be reused in their next release, right? There's essentially the top-level release, and you point to these components.
And then that is an important thing, giving you an audit trail of what made up a given release. Because in the real world, when you're doing a software release like that, it's going to be rather challenging in a year or two years or three years from now to try to reverse engineer what particular constellation of software made up a given release.
I mean, you could do it, but it would be very expensive. You have to probably go on the date, to Git, and find the date, and then it's going to be very difficult. So that's a big part of this release lifecycle management, being able to tag a release that spans other releases.
And that's like one of the big things that we built out in that product, which is basically being able to cut release; it spans multiple components. And that then allows you to say, "If an auditor were to come and say, 'Hey, what was the constellation of version 2.1.0?'" You can say, "Here's the SBOM for this particular version and all the components that made up that."
What Tools to Use? [28:06]
Olimpiu Pop: But now it's about tooling as well. Two years ago, I was looking into Syft. I know that Trivy was out there. What are vendor-neutral tools or tools that you can use and add to your pipeline? Leaving aside the giants like GitHub and others, if I just play an old pipeline, what should I use?
Viktor Peterson: So I have a biased answer, which is we have something called sbomify action, which is like a super set of tools where we pick the best tool in our opinion for any given job. But the logic for that you can extrapolate from, and our logic is that the ecosystem-specific tools tend to generate better quality SBOMs than the generic tools.
So if you say the CycloneDX tooling for Python will generally generate a better SBOM than, say, Trivy, right? Because generic tools, they tend not to extrapolate on all the metadata that all the various languages can do. In each ecosystem, we've actually seen quite a lot of innovation in the package management space in the last few years. We mentioned UV and Bun as a good example of that lately. And many of the generic tools haven't really picked up with that.
First, please pick one camp: SPDX or Cyclone. And once you pick that camp, the tooling becomes a little bit easier to decide on. Both have tools that can do things. I would say there are probably more Cyclone tools out there than there are SPDX tools out there because the SPDX tools favour more libraries, whereas Cyclone favours more end-user tooling.
So in the case of Yocto, they're using the SPDX toolkit libraries to build their SBOMs directly in their pipeline, whereas Cyclone have a lot more generic tools. Generic tool says, "Here's my Python lock file, build an SBOM from that." Decide which camp you live in; that's probably a good starting point, and then pick a tool within that ecosystem.
Olimpiu Pop: Okay. So first of all, we have to choose, as developers or ecosystem holders, the tool that we are choosing, and then stay close to the ecosystem that we are actually in. Rather than using one hammer for each nail, use the appropriate tool for each nail.
Viktor Peterson: That's right. I mean, it's very compelling at the surface to look at the generic tools because they can do everything, but there's a compromise there. And if you actually want to operationalise this and actually use the data, the quality of the data matters, of course--garbage in, garbage out. If you want to make the decision on this, you want to have the best quality SBOM as possible. But then what you're really aiming for is to get a high-quality SBOM.
So, looping this back to the working group, what we set out to do was to achieve NTIA minimum element compliance. And that's kind of the gold standard for SBOMs. None of these tools, to my knowledge, will produce an SBOM that is NTIA minimum-element compliant out of the box. So you need additional tooling for that. But that's kind of the quality barrier that many compliance regulations are starting to nudge towards.
SBOMs Might Be First-Class Citizens in the Future [31:12]
Olimpiu Pop: What else should we know to be safe out there?
Viktor Peterson: It's a really good conversation to start with a team. I think going back to where we started, doing an audit of lock files is a really, really valuable exercise. Looking at your pipelines, making sure that it's best to practice because if you work on a lot of code, you forget about this stuff. You leave things, and then you forget about them, and it just sits there to rot.
So doing that inventory and applying and learning by SBOMs and applying SBOMs in your pipeline forces you to do that inventory check. And I think that's really, really important. Once you've done that, you can focus on lifecycle and release management, and on ensuring SBOMs fit into your lifecycle management. And once you've done that, then you can start focusing on the quality of SBOMs.
And that's the next step with NTIA or CISA, now minimum elements, and making sure that all that data is represented in the SBOMs. But it might be a bit too front-heavy to try to do that off the get-go. I would rather start with something, so you build the processes, and then you iterate, tweak, and refine the process rather than try to solve it all in one big bang.
Olimpiu Pop: Is there an SBOM linter that ensures that you are okay?
Viktor Peterson: So there are a few tools out there. We have tools in sbomify that can perform checks on this and determine whether they are compliant with various regulations. So there are, as I mentioned, CISA and NTIA even development, we have checks for that. The FDA got some things as well. They have checks for... CRA got their own interpretation of this.
So, if you remember in my presentation, I had a Venn diagram between CRA and NTIA. That's kind of what you want. You want to incorporate both of those. And there are various tools. There's another tool called sbomqs that can perform SBOM analysis.
But I would say NTIA minimum element is probably the closest thing to a universal standard we have that is starting to become more and more referenced in what good looks like in terms of quality.
And then there's this draft of a system in minimum elements that was published in the fall that probably going to be published later this year, that kind of takes that and makes some changes to it.
But it makes assessment of like, who are you as a company? Are there hashes represented in the SBOM and so forth? And there are quite a few things in there to make sure that your quality is tighter than just... And for clarity, none of those generic tools will produce an SBOM that is even close to complete with the NTIA minimum elements.
Olimpiu Pop: Thank you for all the insights. Is there anything else that you think is useful for us to know?
Viktor Peterson: The time to get on top of SBOMs is now. I expect all future compliance frameworks to require SBOMs. It becomes a litmus test of, " Do you know what's going into your software?” We've already seen PCI DSS 4.0 calling for software inventory.
My guess is that the updates to ISO and the updates to SOC 2 will all require SBOMs. And I think it kind of reshapes your trust centre because obviously we've seen a lot of hype in the last few years about trust centres, but I think the SBOM needs to be front and centre along with your compliance documents because that's equally important that you know what you're going to do with your software.
And I would argue it's even more important than ensuring you have 2FA on your various services. So I think, and what I predict the future will be is that we get SBOM being a first-class citizen in your trust centres, and it's going to be part of almost all upcoming regulations and certificates going forward.
Even Security Tools Can Be Compromised [34:39]
Olimpiu Pop: And last question before closing: we spoke before hitting the record button about what happened with Trivy lately. Care to comment?
Viktor Peterson: Yes. I have a lot of sympathy for the people over at Aqua. I mean, they've done a lot of good job for the SBOM community, but I guess we're still seeing how it's playing out. But for those who are not familiar, Trivy was one of the most popular generic SBOM generation tools out there that has been around for quite some time.
They have been compromised in two releases now, where they essentially had infostealers baked into the Trivy package. And that in turn has had a blast radius when there've been other packages that have been compromised because of that, including a PyPI package called LiteLLM, which was compromised a few days ago.
We don't know the extent yet, but there's evidence that the entire Aqua GitHub org has been compromised. So they managed to compromise Trivy and then worked their way into the entire Aqua GitHub org. So we don't really know how bad this is, but it looks pretty bad.
We've removed Trivy from our pipeline. So we used to use Trivy in the sbomify action as one of the SBOM generation tools. We never used affected versions, but we've still proactively removed Trivy from the generation tool, just better safe than sorry, to be honest. I anticipate seeing a greater fallout of this.
LiteLLM is probably one of the first we know of, but I doubt it's going to be the last. And the reason why Trivy is such a juicy target for infosteal is that it runs the CI/CD pipeline. And people tend to use long-lived credentials in their pipelines, which is how they manage to work their way.
So, the more of the story here is move towards OIDC and more short-lived credentials in your pipeline, make sure that you pin all your GitHub action modules to hashes rather than versions, because the moral that we learned from the Trivy incident is that they over-release.
So we can't think of Git tags and Git releases as like firm, but they're not. You can overwrite them. So, if you pin it to a hash instead, you can make sure that you know what you're doing with it.
Again, this is not like rocket science; it's not news. Everybody working in the security world is fully aware of that you should be doing this, but this is kind of a cautionary tale of what happens if you don't.
Olimpiu Pop: Okay. Thank you for sharing, and thank you for your time.
Viktor Peterson: Thank you.
Mentioned:
The Minimum Elements For a Software Bill of Materials (SBOM)
Open Source Security Tool Trivy Hit by Supply Chain Attack, Prompting Urgent Industry Response
About the Author
Viktor Peterson
Viktor is a serial entrepreneur and cybersecurity innovator, currently focused on shaping the future of software security and compliance. As the founder of sbomify, he simplifies Software Bill of Materials (SBOM) management, helping organizations navigate emerging cybersecurity regulations such as the Cyber Resilience Act (CRA). Viktor is also the cofounder of Screenly, a leading secure digital signage platform that powers over 10,000 screens globally, trusted by security-conscious organizations like NASA, Lowe's, and Capital One.
An advocate for secure and efficient technology practices, Viktor is passionate about helping companies adapt to the rapidly evolving cybersecurity landscape. He shares insights and industry trends through his podcast, Nerding Out With Viktor, engaging with thought leaders and technologists to explore what's next in tech security, innovation, and compliance.
Show moreShow less
You can keep up-to-date with the podcasts via our RSS Feed, and they are available via
SoundCloud,
Apple Podcasts,
Spotify,
Overcast
and YouTube.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み