在软件的整个使用期内持续维护

为维护明确服务负责人

有用的软件在首次发布后仍会变化。依赖会发布修复，运行时会停止支持，证书会到期，业务规则会改变。配置时授予的访问权限，也可能保留得比预期更久。

维护服务、负责人、已部署版本、依赖和支持日期的清单。既纳入计划工作，也纳入新发现触发的工作。为两类工作分配资源。没有负责人的维护积压清单，不能保护服务。

区分维护与即时事件响应。凭据暴露，或存在正在被入侵的证据时，可能必须在正常开发周期完成前遏制影响。将这些情况交给安全响应流程。

根据实际暴露安排优先级

严重程度描述潜在后果。优先级还取决于利用情况、相关行为能否被触发、数据、现有控制措施和延迟成本。流量很低的内部服务，也可能持有重要凭据。

CISA 的已知遭利用漏洞目录记录了有利用证据的漏洞。可将它作为安排优先级的依据。未列入目录，不能证明漏洞安全。参见 CISA 目录。

考虑以下虚构发现。时间限制属于示例组织，不是通用截止期限。

不要自动把每项发现都变成重大升级。选择受支持的修复，检查兼容性，并测试重要行为。为临时缓解措施记录负责人和到期条件。

追踪修复进入生产

使用可追溯序列：发现、决定、修改、审查、部署和验证。记录生产实际使用的制品标识符。修改后，重新扫描相关制品或环境。

以虚构的易受攻击 PDF 软件包为例，团队在 10:00 合并升级，但 11:00 时生产仍运行昨天的镜像。代码仓库修复已完成，生产修复尚未完成。

部署后，既验证软件包版本，也验证 PDF 生成功能。漏洞扫描不能证明导出仍然正常。功能测试也不能证明有漏洞的组件已被移除。

NIST 的 SSDF 包括持续识别漏洞并响应。应在整个生命周期应用这些实践，包括很少收到新功能请求的软件。参见 NIST SSDF。

使用自动化，并明确其局限

Taiga Maintaining 扫描已连接的代码仓库，并可将发现转化为修复 initiative。检查最近一次成功扫描、受影响版本和生成的修改。代码仓库扫描不能证明生产环境中受影响的行为能否被触发。参见 Maintaining。

自动化可以减少重复工作，但服务仍需要明确部署责任和验证。保留清楚的发布决定、紧急访问和例外到期条件。

维护也包括退役。通过受控流程移除不再使用的路由、凭据、集成和基础设施。删除前检查保留要求和依赖服务。让运行中的服务退役，并分配剩余的数据保留或审计职责。

下一课将详细介绍持续漏洞扫描与修复。