验证进入发布版本的内容

先问是否需要这个依赖

智能体可能推荐一个看起来能解决问题的软件包。这只是提议，不能证明软件包存在或适用。安装前，验证具体的软件包仓库、发布者、软件包名称和版本。

对于虚构的 CSV 导出功能，运行时可能已经提供所需能力。新增软件包仍可能合适，但会增加维护工作和执行路径。比较自行实现的投入与持续管理该依赖所需承担的职责。

审查许可证和受支持的运行时。检查维护活动和相关安全公告。熟悉的名称，在另一个软件包仓库中可能指向不同软件包。安装成功只能说明安装完成。

检查安装与构建行为

依赖可能在安装或构建期间执行代码。限制这些环境中的凭据和网络访问。不要向处理不可信 pull request 的任务暴露生产秘密信息。

如果生态系统支持，使用已提交的锁文件，并要求构建遵守该文件。将锁文件修改与源代码修改一起审查，包括意外引入的传递依赖。锁定版本有助于重现构建，但不能让有漏洞的版本变安全。

NIST 的 SSDF 覆盖整个生命周期的软件保护和开发实践。设计构建环境时，应采用这一更广泛的视角。阅读框架。

区分组件清单与来源证明

软件物料清单（SBOM）记录软件中的组件。当某组件引发关注时，它有助于识别受影响的发布版本，但不能单独证明组件安全。

来源证明说明制品如何产生。SLSA 定义了记录构建及其输入信息的来源证明格式。验证时，必须将这些信息与可信生产方及拟使用的制品关联起来。仅有一个名为“provenance”的文件还不够。参见 SLSA 来源证明。

对于导出服务，记录一条可以检查的证据链：

1. 已审查提交标识接受的源代码。
2. 构建标明其输入和执行环境。
3. 制品具有固定的摘要值。
4. 检查标明所检查的制品或源代码。
5. 部署记录放入目标环境的制品。

如果没有明确的验证流程，不要在批准后采用不同方式重新构建。latest 这类可变标签，以后可能指向另一个镜像。

判断扫描发现意味着什么

评估漏洞发现需要上下文，包括受影响版本、相关行为能否被触发、暴露情况、可用修复和后果。记录任何临时例外背后的证据，并指定负责人、到期条件和复核触发条件。

不要因为一项发现不适用，就禁用整个扫描器。扫描未完成时，不要声称结果干净。超时、不支持的软件包或不可用的安全公告源，都意味着缺少证据。

最后，规划发布后的更新。新公告可能影响昨天已接受的制品。服务负责人需要组件清单、响应流程，以及产出修复版本的能力。

继续学习持续漏洞管理，把重复扫描与经过验证的生产修复连接起来。