論文の概要: Poking Around in the Dark: Why a Shared Understanding of Components Matters
- arxiv url: http://arxiv.org/abs/2606.02442v1
- Date: Mon, 01 Jun 2026 16:12:26 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-06-02 21:34:32.49349
- Title: Poking Around in the Dark: Why a Shared Understanding of Components Matters
- Title（参考訳）: 暗闇の中でポーキングする: コンポーネントの共通理解が重要な理由
- Authors: Felix Reichmann, Wolfgang Krane, Alena Naiakshina, Martin Johns, Simon Koch,
- Abstract要約: 一般的な4つのSBOM生成ツールを分析し、それらが関連するコンポーネントをどのように定義し、識別するかを理解する。
我々はこれらをPython、Java、Go、PHP、Rust、Cといったプログラミング言語の根底にある真実を使って評価します。
現在の曖昧な定義とツールの下では、SBOMはコンポーネントの包摂において曖昧さと盲点を示す。
- 参考スコア（独自算出の注目度）: 15.79463883263798
- License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
- Abstract: By listing the components included in an application, Software Bills of Materials (SBOMs) are intended to support the timely identification of vulnerable components and ensure the security of the software supply chain. However, we question the underlying assumption that there is agreement on the components to be listed in an SBOM and that current technology is sufficient to secure the software supply chain. First, we propose a ground-up analysis of Component Inclusion Mechanisms (CIM) in the software's development lifecycle. Then we systematically analyze the four popular SBOM generation tools, cdxgen, syft, trivy, ORT, and the Microsoft sbom-tool, to understand how they define and identify relevant components. Finally, we assess these using a ground truth across the programming languages Python, Java, Go, PHP, Rust, and C. While today's tools are a step toward identifying components, our results show that no tool covers all identified CIMs and that common gaps exist across tools. We demonstrate that, under the current vague definitions and tooling, SBOMs exhibit ambiguity and blind spots in component inclusion. Thus, a security-grade SBOM is not achievable with the evaluated tools, necessitating further progress to ensure software supply chain security. We need to go back to the drawing board to clarify which components should be included in an SBOM and revise SBOM generators accordingly. Without a shared understanding of what a component is, any effort to secure software supply chains with SBOMs will fail.
- Abstract（参考訳）: アプリケーションに含まれるコンポーネントをリストアップすることで、SBOM(Software Bills of Materials)は、脆弱なコンポーネントのタイムリーな識別をサポートし、ソフトウェアサプライチェーンのセキュリティを確保することを意図している。
しかし、SBOMにリストすべきコンポーネントと、現在の技術がソフトウェアサプライチェーンを確保するのに十分であるという前提に疑問が持たれている。
まず,ソフトウェア開発ライフサイクルにおけるコンポーネント包摂メカニズム(CIM)の基盤解析を提案する。
次に、一般的な4つのSBOM生成ツール、cdxgen、syft、trivy、ORT、Microsoft sbom-toolを体系的に分析し、それらのコンポーネントの定義と識別方法を理解する。
最後に、Python、Java、Go、PHP、Rust、C言語にまたがる基礎的な真実を用いてこれらを評価する。今日のツールがコンポーネントを特定するためのステップである一方で、私たちの結果は、すべてのCIMをカバーするツールは存在せず、ツールに共通するギャップがあることを示している。
現在の曖昧な定義とツールの下では、SBOMはコンポーネントの包摂において曖昧さと盲点を示す。
したがって、セキュリティグレードのSBOMは評価ツールでは達成不可能であり、ソフトウェアサプライチェーンのセキュリティを確保するためにさらなる進歩が必要である。
我々は、SBOMにどのコンポーネントを含めるべきかを明らかにするために、描画ボードに戻り、それに従ってSBOMジェネレータを変更する必要がある。
コンポーネントが何であるかを共通理解しなければ、ソフトウェアサプライチェーンをSBOMでセキュアにするための努力は失敗するでしょう。
関連論文リスト
- Securing LLM Agents Need Intent-to-Execution Integrity [49.490963596514185]
我々は, LLMエージェントの確保には, エージェントの実行がユーザの意図を忠実に反映した場合に規定するエンドツーエンドの正当性を定義する必要があると主張している。
LLMエージェントはコンパイラと構造的に類似しており、セキュリティ違反はユーザ意図を保存しない誤った実行に対応する。
emphTool整合性、emph命令整合性、emphJudgment整合性、emphData整合性。
論文 参考訳（メタデータ） (2026-05-16T12:53:31Z) - Hidden Dependencies and Component Variants in SBOM-Based Software Composition Analysis [0.7057291175356535]
SBOM(Software Bills of Materials)は、サプライチェーンの攻撃が激化する中で、脆弱性管理の重要な技術として登場した。
本稿では,コンポーネントレベルの依存関係として表現されない隠されたコードレベルの依存関係と,スキャナによって一貫した識別ができないコンポーネントの変種(クローン)の2つのミスマッチパターンについて検討する。
これらのミスマッチは、一般的なSBOMベースの脆弱性スキャナー間での、一貫性のない脆弱性レポートとステートメントの一貫性のないハンドリングにつながる可能性がある。
論文 参考訳（メタデータ） (2026-04-23T04:46:41Z) - ToolRosetta: Bridging Open-Source Repositories and Large Language Model Agents through Automated Tool Standardization [51.92237664440418]
ToolRosettaは、オープンソースのコードリポジトリとAPIを自動的にMPP互換のツールに変換するフレームワークである。
ユーザタスクが与えられた場合、ToolRosettaはツールチェーンを自律的に計画し、関連するツールチェーンを特定し、実行可能なMPPサービスに変換する。
論文 参考訳（メタデータ） (2026-03-10T07:19:43Z) - A Large Scale Empirical Analysis on the Adherence Gap between Standards and Tools in SBOM [54.38424417079265]
ソフトウェア・ビル・オブ・マテリアル(Software Bill of Materials, SBOM)は、ソフトウェア情報を整理する機械読み取り可能なアーティファクトである。
標準に従って、組織はSBOMの生成と利用のためのツールを開発した。
本稿では,我々の自動評価フレームワークであるSAPを用いて,接着ギャップの大規模2段階解析を行った。
論文 参考訳（メタデータ） (2026-01-09T08:26:05Z) - SBOMproof: Beyond Alleged SBOM Compliance for Supply Chain Security of Container Images [3.101218489580587]
政府は最近、ベンダーがエンドユーザや規制当局と資料のソフトウェア法案を共有することを要求するサイバーセキュリティ規制を導入した。
SBOMは、ソースコードにアクセスしなくても、ソフトウェアコンポーネントのセキュリティ脆弱性を特定するために使用できる。
本研究は、SBOM生成および脆弱性スキャンのためのツールの包括的な研究を通じてこの問題を評価する。
論文 参考訳（メタデータ） (2025-10-07T11:17:51Z) - Supply Chain Insecurity: The Lack of Integrity Protection in SBOM Solutions [0.0]
SBOM(Software Bill of Materials)は、ソフトウェアサプライチェーンのセキュリティを確保するための最重要事項である。
ビデン大統領が発した大統領令により、SBOMの採用は米国内で義務化されている。
我々は、SBOMのアウトプットに組み込むことができる信頼について、より深く、体系的に調査する。
論文 参考訳（メタデータ） (2024-12-06T15:52:12Z) - Specifications: The missing link to making the development of LLM systems an engineering discipline [65.10077876035417]
我々は、構造化出力、プロセスの監督、テストタイム計算など、これまでの分野の進歩について論じる。
モジュール型かつ信頼性の高いLCMシステムの開発に向けた研究の今後の方向性について概説する。
論文 参考訳（メタデータ） (2024-11-25T07:48:31Z) - The Impact of SBOM Generators on Vulnerability Assessment in Python: A Comparison and a Novel Approach [56.4040698609393]
Software Bill of Materials (SBOM) は、ソフトウェア構成における透明性と妥当性を高めるツールとして推奨されている。
現在のSBOM生成ツールは、コンポーネントや依存関係を識別する際の不正確さに悩まされることが多い。
提案するPIP-sbomは,その欠点に対処する新しいピップインスパイアされたソリューションである。
論文 参考訳（メタデータ） (2024-09-10T10:12:37Z) - A Landscape Study of Open Source and Proprietary Tools for Software Bill
of Materials (SBOM) [3.1190983209295076]
Software Bill of Materials (SBOM) は、アプリケーションで使用されるすべてのサードパーティのコンポーネントと依存関係を在庫するリポジトリである。
最近のサプライチェーンの侵害は、ソフトウェアのセキュリティと脆弱性のリスクを高める緊急の必要性を浮き彫りにしている。
本研究では,SBOMに関連するオープンソースおよびプロプライエタリツールの現在の状況を評価するための実証分析を行う。
論文 参考訳（メタデータ） (2024-02-17T00:36:20Z) - On the Security Blind Spots of Software Composition Analysis [46.1389163921338]
Mavenリポジトリで脆弱性のあるクローンを検出するための新しいアプローチを提案する。
Maven Centralから53万以上の潜在的な脆弱性のあるクローンを検索します。
検出された727個の脆弱なクローンを検出し、それぞれに検証可能な脆弱性証明プロジェクトを合成する。
論文 参考訳（メタデータ） (2023-06-08T20:14:46Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。