一个页面，看清应用从需求到上线的安全治理状态

一款业务应用准备上线。

开发已经完成， 测试也接近尾声，安全负责人开始做最后一轮确认：SAST有结果，SCA有结果，DAST也做过，之前的渗透测试报告还在，几个安全团队的任务，也都有记录。

资料其实不少，但把这些信息放在一起之后，一个问题反而变得更难回答：这个****应用，现在到底算不算准备好了？从需求、开发，到测试、上线和运行，这个应用的安全工作到底做到哪一步了？

这其实是很多企业做应用安全时都会遇到的情况：安全能力越来越多，产生的数据也越来越丰富。只是这些数据通常分散在不同工具和系统里：扫描结果归扫描结果，漏洞归漏洞，任务归任务。

安全团队看到的是一张张问题列表，很难快速围绕这个马上要上线的“应用”形成一个完整判断，这时候很尴尬的情况就是：

• 报告都在，但结论不好下；
• 问题很多，但不知道卡在哪个阶段；
• 任务不少，但看不清哪些会影响上线；

所以，企业不仅需要更多安全数据，更需要一个能讲清楚应用安全状态的视图。

应用安全治理，正在面对新的“过程可见”挑战

过去，企业做应用安全治理，更多关注已经发现的问题：

• 这个应用有没有高危漏洞；
• 这个组件有没有已知风险；
• 这条工单有没有关闭；
• 这个扫描有没有跑出结果；

这些能力当然很重要，它可以帮助安全团队发现和处置风险。

但随着应用规模变大、研发流程变快，安全负责人和安全团队不仅要知道“发现了什么问题”，还要知道“这些问题出现在研发过程的哪个阶段”。

而这些信息很难仅靠几个工具页面，就快速判断整个应用的安全情况，更难给出对应的解决方案，比如：

• 同样是高危风险，出现在编码阶段、测试阶段、上线前，治理动作完全不同；
• 同样是“安全未达标”，原因可能是能力没有覆盖，也可能是只覆盖了一部分，还可能是手动检查项已经过期；

给每个应用一张“安全生命周期视图”

基于这一场景，墨菲安全SGP（企业安全风险治理决策平台）推出【应用安全生命周期管理】能力。

简单来说，就是围绕单个应用，把需求设计、编码开发、构建与依赖、测试验证、部署上线、持续监控等阶段串起来，再把每个阶段相关的安全能力、执行记录、风险问题和处置任务放到同一张视图里。

这样，安全团队打开一个应用，就能看到：

• 哪些阶段已经达标；
• 哪些阶段存在未覆盖或部分覆盖；
• 哪些安全能力最近执行过；
• 哪些结果是 0 漏洞；
• 哪些问题还没有闭环；
• 哪些检查项已经过期或没有完成；

它的重点不在于多加一块页面，而在于把原来分散的工具结果，整理成一个围绕应用研发过程的判断依据。

应用安全生命周期管理能帮企业解决什么问题？

1、建立适合不同应用的安全治理要求标准

企业内部的应用类型很多，面临的安全要求也不完全相同。

面向互联网提供服务的核心业务应用，通常需要：

• 在编码阶段，接入 SAST、SCA 等检测能力；
• 在测试阶段，完成 DAST 和渗透测试；
• 上线后，还要持续关注主机、接口和运行风险。

内部管理工具或低风险应用，适用的安全能力和检查强度可能有所不同。

如果所有应用都套用同一套安全要求，安全团队很难兼顾治理效果和执行成本：

• 要求过少，关键风险可能没有覆盖；
• 要求过多，也会给研发流程增加不必要的负担。

SGP 的应用安全生命周期管理支持企业结合自身研发流程，配置应用需要经过的生命周期阶段，以及每个阶段需要接入的安全能力和手动检查项。

安全团队可以围绕需求设计、编码开发、构建与依赖、测试验证、部署上线、持续监控等阶段，明确每一类应用应该完成哪些安全工作。

对于确实不适用的能力，也可以结合应用实际情况进行标记。

这样一来，企业能够先把应用安全治理要求定义清楚，再依据真实的扫描记录、检查结果和风险数据判断执行情况。应用负责人知道每个阶段要完成什么，安全团队也有了统一且可落地的治理依据。

2、对照治理标准，支撑应用上线前的安全判断

当应用进入上线评估阶段，安全团队可以直接对照预先配置的治理要求，查看各项安全能力是否已经接入、是否完成执行，以及发现的问题是否已经处理。

例如，某应用的 DAST 显示为“部分覆盖”，还可以继续定位到未完成检测的具体地址。安全负责人由此能够快速确认还缺哪些检查、涉及哪些对象，以及这些缺口是否会影响本次发布。

上线评估有了统一依据，也能减少临近发布时跨平台查数据、找研发确认和反复解释的工作。

3、持续跟踪巡检执行情况，推动存量应用补齐薄弱环节

应用上线后，安全治理仍会持续推进。尤其是运行多年的存量应用，可能只接入过部分安全能力，某些检测已经很久没有成功执行，部分风险也可能长期停留在开放状态。

通过应用安全生命周期视图，安全团队可以持续查看：

• 哪些研发阶段一直没有安全能力覆盖；
• 哪些能力已经接入，但长期没有成功执行；
• 哪些检测已经执行，结果为 0 漏洞；
• 哪些风险仍未闭环；
• 哪些手动检查尚未完成或已经过期；
• 哪些能力结合当前应用情况可以标记为暂不适用。

例如，一次 SCA 扫描成功完成，结果为 0 漏洞，页面会明确展示为“已执行，0 漏洞”。这说明检测真实发生过，也产出了健康结果。如果页面没有执行记录，安全团队则需要继续核查能力是否已经接入、扫描是否成功运行，以及应覆盖的对象是否完整。

对这些状态进行区分，可以减少把“没有数据”当成“没有风险”的误判。安全团队既能证明已经完成的安全工作，也能发现长期没有覆盖、没有执行或没有闭环的薄弱环节。

对于管理大量应用的企业，这种持续巡检方式还能帮助团队逐步识别共性问题：

• 哪些研发阶段整体覆盖不足；
• 哪些安全能力经常执行失败；
• 哪些类型的风险总是在上线后才被发现。

企业可以据此调整治理重点，推动安全能力在更合适的研发阶段发挥作用。

从“有没有做安全”到“安全做到哪一步”

应用安全治理的难点，很多时候不在于发现一个漏洞，而在于把应用从需求到上线的安全过程讲清楚。

• 哪些阶段已经达标？
• 哪些能力还没覆盖？
• 哪些风险需要优先处理？
• 哪些任务已经推进到闭环？
• 哪些结果可以作为上线判断依据？

这些问题讲清楚之后，安全团队才能更好地和研发、业务、管理层协同。

• 对安全负责人来说，它能支撑上线前判断，也能沉淀管理层看得懂的应用安全水位。
• 对 SDL 和 DevSecOps 团队来说，它能帮助定位薄弱阶段，推动安全能力前移。
• 对应用负责人来说，它把安全要求拆成明确的阶段、能力和整改动作，减少反复沟通。

应用安全生命周期管理的价值，就在于让企业围绕每个应用，看清从需求到上线的安全状态。

当每个关键阶段都有据可查、有因可溯、有事可做，应用安全治理就能从一张问题列表，变成一个可以持续推进的过程。

对于正在持续建设SDL、DevSecOps和应用安全治理体系的企业来说，这意味着安全管理可以拥有一个更加贴近业务研发过程的统一视角。

从需求开始，到应用上线，再到持续运行。安全工作真正发生在哪里、做到什么程度、还有哪些工作需要继续推进，都可以围绕一个应用被完整地呈现出来。

这或许也是应用安全治理从“工具覆盖”走向“过程治理”之后，一个值得关注的变化。