该论文针对去中心化构建的包生态系统中工件可验证性问题展开研究。作者指出，可复现构建虽然能增强对分布式软件工件的信任，但仅靠构建确定性并不足以实现工件验证——验证者还必须能够恢复生成该工件所需的源代码状态、构建环境、依赖项和构建指令。而去中心化构建生态系统因使用异构工具、维护者自定义工作流以及碎片化元数据，使得独立验证变得困难。论文提出了一种独立验证者模型，该模型仅依赖注册表可派生的元数据，并定义了一个带有分级等价级别的工件比较模型。作者将这些模型实现为一个工件验证管道，并用于测量四个流行的去中心化构建包生态系统中的工件可验证性。研究结果表明，除了构建确定性之外，可验证性还受到缺少源代码和构建元数据、隐式发布转换以及非常规构建实践的制约。来源证明和嵌入式版本控制系统的元数据能改善验证效果，但并未提供完整的重建规范。这些发现指出了具体的元数据缺口以及为使工件验证在包注册表规模上具有实用性所需的生态系统级变更。该研究适合软件供应链安全研究人员、包注册表维护者以及构建系统开发者阅读。

该论文针对软件包生态系统中发布路径的权威性问题，提出了一种前驱感知的发布权威记录方法。该方法通过比较每个包版本与其直接前驱版本在发布者、仓库、CI工作流、来源凭证、签名和中介证据等多个维度的差异，来识别发布路径上的不连续点。作者对npm、PyPI、Maven Central、crates.io和RubyGems五个注册表进行了有目的的抽样审计，时间跨度为2024年4月至2026年6月，分析了45,812个版本、43,100个有效前驱比较和942个包坐标。Go作为VCS/代理/校验和日志边界适配器单独报告。通过透明规则识别出204个策略触发的发布路径不连续事件。这些触发策略作为主要候选队列。统一的语义距离规则选出了320个版本，覆盖了190/204个触发事件；一个描述性的特定注册表规则选出了337个版本，覆盖了全部204个触发事件。在60行的盲测共享核心中，三名从业者将20/30个触发事件评为立即审查，9/30评为监控，1/30评为无需审查，所有30个对照均评为无需审查。这些信号是基于公开发布路径证据的审查线索。外部对齐中的精确恶意版本与策略触发事件无重叠。同路径入侵、未改变的受损CI、以及公共快照中缺失的版本需要独立于本发布路径记录之外的证据。