该论文聚焦物联网（IoT）领域一个长期被忽视但规模庞大的问题：厂商停止支持后仍在用户手机上运行、并持续与 IoT 设备交互的“伴侣 App”。作者将这类应用定义为 "IoT abandonware"（物联网弃置软件），并声称这是首个针对已停更 App 安全风险的大规模测量研究。研究的数据集是截至 2025 年 3 月已至少两年未更新或已停止服务的 61,500 个 Android 端 IoT 伴侣应用。方法上，作者对反编译后的二进制文件提取“潜伏与内嵌资源”，包括打包进 APK 的第三方库、硬编码域名和权限声明，并据此评估安全影响。分析分为两条主线：第一，识别出已被弃置后仍有新披露 CVE 的过时依赖组件，以及可能被域名接管（domain takeover）或被用于数据外泄的端点；第二，基于所提取权限推断敏感数据，做静态数据流分析，追踪这些数据如何流向已失效或可被劫持的外部端点。核心发现是：厂商失去控制权很久之后，持久化的分析 SDK 与第三方追踪器仍在持续汇聚用户数据和设备遥测，形成攻击者可重定向或滥用的数据流。整体上，作者在 73.6% 的样本中识别出安全风险，安装量排名前 1000 的应用中有 30 个仍在向已损坏（broken）的外部端点发送数据。该研究的意义在于把“软件供应链弃置”这一议题从桌面/服务端延伸到了 IoT 移动生态，量化了弃置 App 带来的远程利用、未授权设备访问与长期数据滥用风险，并给出了依赖、域名、权限与数据流四个可操作的观测维度。

软件供应链安全已成为现代软件工程中的核心关注点，因为现代软件对第三方依赖有着广泛依赖，且攻击面持续扩大。然而，现有的基于量化测量的分析方法和漏洞管理手段往往碎片化，并局限于特定生态系统（如npm、PyPI等），难以在跨环境之间提供可比较的风险评估。针对这一缺口，本文提出一个结构化的研究计划。首先，作者计划通过“系统化知识”（SoK）方法对当前软件供应链安全研究进行综合分析，梳理已有成果，识别关键知识空白，尤其是在依赖建模和漏洞传播分析中，对传递依赖（transitive dependencies）及其实际可利用性的处理存在显著不足。其次，基于这些洞察，论文主张构建统一的测量视角，以一致的方式表示和分析跨生态系统的依赖结构，从而支持可复现、可比对的安全测量。此外，论文重点指出AI辅助软件开发带来的新兴挑战：编码大语言模型（LLM）参与代码生成可能引入传统SCA工具无法捕获的新依赖模式，例如不稳定、语义模糊或自动生成的依赖引用。这些变化要求重新思考依赖建模方式，以适应当前软件生成实践的演变，并评估其对软件安全的长期结构性影响。本文的主要贡献在于提出研究议程，为下一代供应链安全测量与SCA工具设计提供方向性指导。适合安全研究人员、SCA工具开发者和软件供应链治理从业者阅读。

软件供应链已成为日益暴露的攻击面，原因是其依赖关系复杂而脆弱。现有的防御工具（如 GitHub Dependabot）常常产生大量误报，因为它们的粗粒度匹配无法确定易受攻击的依赖项是否真正可利用。安全分析师通常需要花费大量时间逐案评估漏洞可利用性。鉴于 LLM 在编程和网络安全方面的先进能力，最近出现的 LLM agent 有望成为该任务的候选者，但目前尚无基准对其进行评估。以往的基准针对零日漏洞场景，要求 agent 检测并利用先前未知的漏洞。相比之下，软件供应链安全关注上游依赖中的已知漏洞如何影响下游项目，这要求 agent 跨仓库推理，判断上游漏洞在下游项目中是否可利用。为填补这一空白，本文提出了 VEX-Bench，这是首个评估 LLM agent 评估软件供应链漏洞可利用性能力的基准。它包含 75 个从 GitHub 挖掘并经安全专家标注的真实世界案例，覆盖 Python、Java 和 Go 语言。作者使用三个 agent harness 评估了九个模型。结果显示，GPT-5.5 和 Claude Opus 4.6 在二元漏洞状态分类上达到了约 80% 的 F1，但只有 GPT-5.5 在细粒度理由分类上超过了 70% 的 macro-F1。这一差距凸显了从二元可利用性评估转向识别细粒度可利用性原因的挑战。代码和数据已开源（https://github.com/steven1518/vex-bench）。

本研究针对AI编程助手在自动选择、安装和配置软件时是否利用供应链安全信号的问题，进行了预注册的受控实证审计。背景是攻击者已通过伪造包名、入侵维护者账号、篡改仓库文本等方式利用助手的能力实施攻击；供应链社区为此发布了机器可验证的信任信号，包括软件物料清单（SBOM）、签名发布、构建来源证明和官方渠道声明。但编码助手是否读取或响应这些信号，在科研软件领域尚无系统测量。作者从87个项目语料库中选取6个开源科研软件项目（3个高性能计算、3个量子计算），为每个项目创建9种修改副本，分别覆盖：无信号、单一信号类、错误签发方的签名/证明、全部四种信号以及复现项目自身元数据冲突等情形。研究使用三个模型，在有无审批步骤两种操作方式下，记录1,920次注册试验的容器日志，并补充测试了三个前沿模型。结果显示，验证行为在所有条件下都极为罕见：1,920次试验中仅9次（0.5%）助手在安装前打开过任何来源信号，384次对照试验中0次，且没有一次试验运行验证命令；因此信号的存在对助手行为没有可测量的影响。研究还发现，更贵的模型并不会带来更好的验证（验证最多的一次成本为0.10美元，而能力最强、单次成本1.00美元的模型验证次数为零）。作者得出三点结论：发布信号是必要的但不充分；价格不能保证验证行为；必须将验证机制嵌入到运行助手的程序本身中。该研究公开了每次试验的成本记录、协议和全部日志，对AI供应链安全、软件工程实践和可信软件供应链研究具有重要参考价值。适合安全研究人员、AI助手开发者和科研软件维护者阅读。

该论文聚焦软件供应链（SSC）安全中的透明度问题，指出现代软件实践依赖的 SBOM（软件物料清单）及其工具虽然被引入作为确保供应链透明度的基础组件，但存在严重局限性：其漏洞检测与解释能力不足以说明可沿整条供应链传播的漏洞可利用性效应。为了弥补这一空白，作者提出一种以“传播”为中心的 SSC 安全研究方法，并引入一个四阶段传播模型：阶段1为结构性暴露（Structural Exposure），阶段2为漏洞类别存在性（Vulnerability Class Presence），阶段3为代码可达性（Code Reachability），阶段4为污点路径分析（Taint Path Analysis）。研究选取 Log4j 漏洞作为测试用例，使用三个开源项目对四款开源 SBOM 工具开展实证评估。结果表明，当前 SBOM 工具仅系统性地支持阶段1和阶段2，而阶段3和阶段4所要求的代码级分析与数据流追踪能力在现有 SBOM 生态中完全缺失。作者因此主张，只有将传播效应置于 SSC 安全研究的中心，才能阻止网络风险演化为系统性风险，并为未来现代 SSC 安全工具的研究与设计提供方向。本文适合软件供应链安全研究者、安全工具开发者以及负责供应链风险评估的蓝队工程师阅读。

该论文提出了一种名为 Mal-LLM 的恶意源代码检测框架，旨在应对软件供应链中嵌入恶意代码的安全挑战。现有检测方法包括基于签名、行为分析和传统机器学习模型，但这些方法普遍缺乏结果的可解释性，难以向安全分析人员清晰解释为何某段代码被判为恶意。Mal-LLM 结合了传统机器学习模型的成本优势和大型语言模型（LLM）的语义理解与可解释性。其工作流程分为两个阶段：首先，传统机器学习模型对软件供应链中海量的源代码进行初步筛选，快速缩小可疑范围；然后，LLM 利用定制化的提示模板（包含角色扮演和思维链技术）对筛选出的可疑代码进行深入分析与解释，生成人类可读的判定理由。论文通过大量实验验证了框架的可行性，重点考察了LLM在框架中输出的模糊性与冗余性、'经验'和'恶意'等提示词对判定结果的影响，并探讨了从企业视角降低LLM使用成本的策略。该研究为恶意代码检测提供了兼顾效率与可解释性的新思路，适合安全研究人员、SOC分析师以及软件供应链安全工程师阅读。

该论文研究开源软件依赖评估中的信任信号可靠性问题。实践者通常使用廉价信号（如星标数、下载量、贡献者活跃度）作为直接代码审查的替代，假设这些信号能反映软件包的真实可信度。既有研究已记录个别信号被操纵，但尚未全面考察所有依赖采纳信号的系统性崩溃及其生态响应。本研究通过多语种文献回顾（252 个 Google 搜索结果和 870 个 Reddit 讨论主题），对语料库进行编码分析，旨在帮助从业者理解下载量、贡献者活动等信任信号的可信度。结果表明，廉价信任信号在向三股同时作用的压力下崩溃：对抗性操纵（攻击者故意制造虚假信号）、与合法行为难以区分的游戏技术（如刷星、虚假下载）、以及非对抗性的 AI 驱动通货膨胀（如 AI 工具自动生成贡献或使用，导致信号失真）。文档记录的响应多为建议而非实际措施：54.6% 的 Google 搜索来源包含应如何做的建议，但没有真正的行动。常见建议包括用另一种廉价信号替代或聚合多个信号，但这些方案同样可被游戏。对于 AI 驱动的非对抗性通胀，两个语料库都未记录实际行为改变。已知补救措施与实际实践之间的差距指向一个“柠檬市场”：当伪造信号的成本低于真实获得信号时，好与坏的依赖变得不可区分，劣质包可能驱逐优质包。依赖个体从业者去验证廉价信号不可持续。论文主张成本更高的信号，如加密签名/认证，应强制成为所有依赖采纳流程的默认要求，而非少数人自愿选择的额外保障。

这篇研究论文关注软件供应链中的信任问题，特别是随着AI生成依赖项等新威胁的出现，供应链信任正在受到侵蚀。作者通过对38名来自工业界和开源社区的从业者进行半结构化访谈，从社会学既有信任概念出发，采用主题分析法，研究从业者实际采用的信任信号、信任控制手段以及他们对信任侵蚀的应对方式。研究发现，从业者普遍感知到信任正在逐渐丧失，而维持信任的成本日益高昂，因此有风险意识的从业者不断增加控制措施。为了应对这种不断上升的信任成本，他们会将验证流程自动化、将信任决策委托给'守护者'（如安全团队或外部审计），甚至考虑完全退出软件供应链。该研究的核心贡献在于，通过信任视角理解软件供应链动态，提出了'信任守护者'、'系统信任'、'信号'等术语和概念框架，为未来构建运作良好且具备适度信任水平的软件供应链提供了干预设计的理论基础。这项研究为安全实践者提供了关于供应链信任现状的实证基线，有助于他们制定更明智的决策。适合软件供应链安全研究者、安全工程师、开源社区维护者以及依赖供应链的企业安全团队阅读。

SCORED '22是ACM软件供应链攻防研究与生态防御研讨会（ACM Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses）。该研讨会聚焦于软件供应链安全这一关键领域，旨在汇集学术界与工业界的研究人员，共同探讨软件供应链面临的攻击威胁、防御策略以及生态系统的整体韧性。主要议题包括但不限于：供应链攻击的建模与分析、依赖管理安全、构建与分发管道完整性、软件物料清单（SBOM）的生成与应用、供应链安全自动化工具、以及针对供应链攻击的检测与响应机制。研讨会鼓励从攻击者视角出发的进攻性研究，以理解攻击手法和攻击面，同时也强调防御性研究和生态级解决方案。该会议为安全社区提供了一个交流平台，推动软件供应链安全领域的理论进展和实践落地。适合软件供应链安全研究人员、安全工程师、DevSecOps从业者以及关注供应链风险的组织代表阅读。

该论文针对开源软件供应链中代码级后门注入的威胁提出了一种自动化检测方法 Lily。代码级后门是一种隐蔽的代码改动，通过秘密触发器授予隐藏权限，难以被发现。此前针对广泛使用项目的后门注入尝试（如恶意提交、被篡改的发布包、受污染的第三方依赖）往往仅靠运气和人工审查才被阻止。现有持续集成（CI）流水线无法检测此类攻击，而下游二进制分析工具则需要大量人工分析。Lily 将后门检测机制集成到两个环节：一是 CI 流水线，用于在代码提交阶段阻断恶意提交；二是发布审查流程，用于防止被篡改的发布包或受损依赖进入大型生态系统（如 Linux 发行版）。Lily 有两个核心贡献：第一，它增强了兼容 CI 的模糊测试（fuzzing），能够基于历史和当前软件执行来检测可疑行为的触发器，从而在 CI 和更新验证流程中实现快速且精确的后门检测；第二，它将代码变更分析与模糊测试数据相结合，即使发布更新涉及数百万行代码改动，也能精确地将维护者定位到暴露后门的代码区域。论文还概述了攻击者可能规避 Lily 的五种策略，并评估了相应的防御措施。作者在数百个良性提交/发布和带后门提交/发布的实验表明，Lily 能以较低的误报率实现高检测精度，可靠地识别恶意代码，抵抗对抗性尝试，并且能够阻止真实世界中的后门事件。

该研究论文探讨了软件物料清单（SBOM）在增强软件供应链安全方面的潜力。研究背景指出，软件供应链攻击日益频繁，如SolarWinds事件，凸显了透明度和可追溯性的缺失。核心问题是如何利用SBOM来识别和缓解供应链中的漏洞和风险。研究方法包括对现有SBOM标准（如SPDX和CycloneDX）的分析，以及案例研究评估SBOM在漏洞响应、许可证合规性和依赖关系追踪中的实际效果。主要贡献是提出了一个框架，将SBOM集成到DevOps流程中，实现自动化的安全审计和风险评估。实验证明，该方法能显著缩短漏洞发现到修复的时间，并提高供应链整体的可见性。适合安全架构师、DevOps工程师和合规管理人员阅读。

本文提出 VeriPort，一个端到端的自动化补丁回溯系统，旨在解决开源依赖中已知漏洞的修复难题。当前，安全补丁通常仅针对最新版本发布，开发者面临两难：要么升级到最新版本（可能引入破坏性变更），要么手动将补丁回溯到旧版本。现有回溯方案只能针对单个指定版本，且无法提供充分证据证明补丁能阻断漏洞利用并保持原有功能。VeriPort 能够根据给定的漏洞公告，将该补丁可扩展地回溯到该包的所有受影响版本。对于每个回溯版本，VeriPort 构建一条证据链，以确认补丁阻断了漏洞利用并保留了预期行为。作者使用 BackportBench 基准测试（包含 128 个回溯任务）进行评估，VeriPort 成功解决了 95.3% 的任务，比现有最佳方案 Claude Code 高出 22.7 个百分点。此外，研究团队将 VeriPort 部署在 169 个高/严重等级 CVE 上，生成了超过 5000 个经过验证的回溯补丁。更重要的是，VeriPort 还发现了 2100 个版本被错误报告为受影响，以及 127 个之前未被识别的脆弱版本（涉及 92 个公告），其中 23 个公告已在上游得到修正（删除了 387 个错误版本，新增了 81 个正确版本）。该论文适合安全工程师、开源维护者和依赖管理工具开发者阅读。