一 近期研究带来的新问题
【研究事实】2026年9月16日提交至 arXiv 的 SCA-Agent 论文提出，在 Code、Build、Release、Deploy、Runtime 五个阶段关联组件的来源、传播和最终状态。作者在105个 Java、JavaScript、Python 项目上开展评估，报告漏洞暴露评估 F1 为96.69%。这些数字属于作者实验结果，不是本文独立复测，也不是企业项目的预期准确率。[1]
该论文是近期研究，时间早于本次24至72小时新闻窗口。它没有对应需要紧急升级的软件漏洞，也不能据此宣称某种商用 SCA 工具已被全面替代。本文关注的是可吸收的工程方法，而非将实验分数作为选型结论。
对团队更有用的问题是：某个告警为什么出现，组件是否进入交付物，应当修改哪个直接依赖，以及还缺什么证据才能判断部署影响。把这四个问题回答清楚，比单纯增加一张扫描结果表更接近修复工作。
二 从清单并集走向可追溯关联
以下为面向工程落地的分析。假设一个演示项目在构建阶段安装文档生成器，发布时只保留业务代码；同时，镜像基础层又引入了系统库。如果把所有扫描结果直接取并集，会把构建用途和运行用途混在一起；若只扫描源码，又可能漏掉基础镜像带来的组件。
多阶段数据不能只按名称合并。组件身份至少要考虑生态、名称、版本及证据来源；制品摘要用于绑定实际字节，构建运行标识用于绑定一次执行。文件名相同不必然代表同一个包，同一个包在重新打包后也不必然保持原始文件结构。
建议将观察记录与关联结论分开保存。观察记录描述某次扫描在某个对象上发现了什么；关联结论描述为什么认为它来自某条依赖链。关联使用了锁文件、制品元数据或人工核对，都要保留理由。证据冲突时应暴露冲突，避免模型用一个看似合理的版本覆盖原始发现。
SLSA 来源证明可以为构建输入和输出提供关联信息，但它并不自动给出所有运行时加载关系。团队可把它作为证据来源之一，与组件识别结果和部署记录共同使用，而不是把证明文件直接当作完整 SBOM。[2]
三 必须保留证据不足这一状态
工程上最危险的压缩，是把“这次没看到”写成“生产不存在”。运行时采样只覆盖观察窗口中的负载；压缩包扫描可能未展开嵌套文件；静态链接或重打包可能影响识别。只要这些范围没有明确，就不宜自动发出不受影响结论。
下面用固定集合模拟发布阶段的证据判定。complete 表示测试夹具声明该范围已完整枚举，仅在此演示范围内有效。它不是由扫描器任意返回的安全开关，也不是通用组件检测算法。
def release_state(component, observed, complete):
if component in observed:
return "present"
if complete:
return "absent_in_scope"
return "unknown"
release = {"pkg:demo/runtime-lib@1.0"}
assert release_state("pkg:demo/runtime-lib@1.0",
release, False) == "present"
assert release_state("pkg:demo/docs-tool@1.0",
release, False) == "unknown"
assert release_state("pkg:demo/docs-tool@1.0",
release, True) == "absent_in_scope"
assert release_state("pkg:demo/runtime-lib@1.0",
release, True) == "present"
验证结果：4项断言通过。仅使用固定内存数据，无网络请求或外部命令执行。
四 给 AI 分析代理划定权限和证据边界
建议让代理负责寻找线索、提出关联和解释差异，将制品摘要计算、签名验证及允许发布的最终判断留给确定性组件。模型可以建议进一步检查某个构建产物，但不能凭推断伪造一次成功扫描记录。
不可信仓库里的 README、注释、脚本和工具输出都是待分析材料，其中的指令不应改变分析任务权限。构建行为需要隔离环境、资源限额、受控网络及无生产凭据的身份。因为分析工具能调用构建系统，SCA 的执行环境本身也属于供应链攻击面。
对每条 AI 生成的关系，记录支持它的文件位置、采集工具、对象摘要和置信说明。无法重放的关联不应直接进入自动豁免；确需人工接受的结论应有审批、到期时间及重新核验条件。以上是本文建议，不是声称论文已实现这些生产控制。
五 从一个项目开始实施
第一步选一条真实交付链，固定源码提交、构建任务与产物摘要。分别保留锁文件扫描、实际构建依赖、交付物扫描和部署实例清单，先用规则关联已知组件，再处理需要人工确认的重打包场景。
第二步做差异归因。某组件从构建到发布消失，应检查打包规则和产物范围；某组件部署后才出现，应检查基础镜像、挂载卷、初始化脚本和动态下载。不要只把差异数量当成工具准确率。
第三步把结论连接到工单。工单应说明组件在哪个交付物中、由谁引入、能升级哪个依赖、有哪些运行环境，以及证据缺口。对构建期恶意行为的风险要单独处理，未进入运行镜像不代表构建过程没有风险。
第四步设定验收指标。建议跟踪有证据支持的关联比例、unknown 占比、人工驳回率、跨版本复测稳定性和处理时长。测试样本包括被剔除的开发依赖、运行镜像新增组件、同名不同版本、重打包组件及不完整采样。
结语：全生命周期 SCA 的价值在于让组件告警能够解释、能够回溯、能够行动。AI 可以辅助整理分散证据，但证据范围和权限边界必须由工程系统明确约束。
