在项目团队之前，我们最初的业务接口人员都是面向资产的。这种情况下，出现特定风险时，很难尽快联系到个人，在推动修复的过程中容易扯皮。因此，我们后来采用了业务端接口注册系统，允许业务端主动填写属于项目的个人和人员的备份，并结合内部人力资源的注册信息，定期向业务端确认项目变更。

总之，在项目生存的安全生命周期中，需要保证可控人员响应、可控权限周期和可控人员待命。第三方合作建设。在搭建第三方合作体系的过程中，我们参考行业内的情况做了大量的工作。在治理这方面，虽然有很多标准可以参考，但是没有统一的规划。

其中，需要治理的内容有:第三方合作伙伴的业务。第三方SDK介绍验证。第三方流量访问时监控前端。第三方账户监控验证。这些东西太多了，只能举几个例子。如果真的想做好，就需要深入了解各个业务线的情况，并根据企业自身情况进行定制。同时，外部审计公司很难在短时间内给出完整的方案，这就需要内部安全人员做更多的探索。

后面可能会单独提到这一块，和大家聊一聊，讨论有哪些常用的解决方案。指标的建立和回归。在对SDL实施过程管理和验收治理结果时，需要注意的是，前期建立的指标需要进行验证和回归。无论是反映在安全工作的KPI中，还是向业务方透明地显示结果，这些都是有意义的。下面举几个例子给你参考一下设置指标的原则:风险趋同。对于需要重要防控的项目，我们需要在风险收敛率和收敛时间方面设定一定的指标。如果在此期间发生了安全风险导致的资产损失事件，我们将重点评估我们是否采取了适当的措施来弥补和追回资产损失事件。

漏洞回归。对于脆弱性指标的建立，我们将统计高风险脆弱性的数量和脆弱性类型的趋势。其中会区分外部SRC提交和内部发现，从不同维度进行趋势计算。同时，我们会对同期自动漏扫黑白盒的召回率和准确率进行月度、季度和年度对比。最后，我们将添加插件、服务、接口等的数量。作为变量从综合层面判断结果，从而避免判断权重的缺失。

这和QA的质量评估指标有些类似。如果一个服务经常存在代码风险和漏洞，那么该服务的健康得分通常会更低。这是针对业务方面的，也是对我们治理结果的反馈之一。对于服务安全，我们建立了漏洞修复率、安全产品访问率、漏洞重复率、风险发生率、认证访问率等几个指标。最后，以单个服务甚至一条业务线为基准要素，我们还会依次对每条业务线的安全质量进行比较和评估，从而在更高的维度上评价业务安全的产出。