在甲方做业务SDL的几年，在落地方面也做了不少努力。一是得看着业务高P的脸色，二是得假装硬气的扮猪吃老虎，一路走来可谓是一把辛酸泪。
闲话不多扯，我们团队在SDL方向，针对公司现状进行威胁建模，进行了多个维度的治理。
在本文笔者会根据过往的治理工作，在业务建设从0到1进行剖析，给大家落地经验的参考。
基础审计运营
在安全建设初期，我们会着重针对事前、事中、事后为基准，进行SDL基础能力补全优化。
事前审计
在事前的维度，我们会以域名和服务Key为单位，对前后端的资产进行梳理，嵌入SOC进行运营管理，并进行安全审计流程闭环。
在项目上线前，我们会对提测前的代码进行人工Review，进行安全合规的风险评估。
对于安全检查大致包括：
- OWASP TOP 10
- OWASP API Security TOP 10
- 常见的逻辑漏洞
此外，我们还会根据研发同学的习惯，制定相关核查制度，进行重点检查，提升检察效率。
对于数据合规会重点检查：
- 数据接口是否脱敏
- 数据存储是否加密
- 传输是否加密
- 数据关联性是否解耦
还有部分没有全部例举出来，会严格的按照合规白皮书的标准来实施。
在审计完毕后，会在SOC平台进行数据留存，发工单向业务同学督促修复。
如果出现了延期，系统工单会进行逐级递进，通知其上级，直到业务方响应闭环为止。
虽然这些制度可能比较难推行，但确实是非常有必要的，这需要自上而下的认可才能完成。
只有把代码安全的指标，像代码质量考核那样，加入业务研发同学的KPI之中，才能真正引起大家对安全的重视。
事中监督
在每个项目的大型迭代时，我们也会进行人工安全审计。
除了针对迭代出现的安全问题以外，主要还会检查部分误添加的线上测试数据，以及研发同学无意中进行的硬编码、弱口令配置、敏感数据打印等等。
由于当时工具比较原始，除了借助半自动化的代码审计工具（如IDE、Fortify）以外，也会读取第三方设备收集入库的日志，自行写脚本筛选核查。
当然这些工作，后面也逐步被接入CICD流水线的自动化平台所替代。
事后管控
在各个系统正常运营期间，我们需要做的是借助各种安全入侵防护产品（自研or商采），譬如IDS、WAF、RASP之类的进行纵深体系检测，再借助风控与法务部门的力量，对出现的风险事件进行溯源和应急响应。
为啥这里说的是纵深检测而不是纵深防御，其实是早期在使用安全产品的时候，更多的需要去借助人工去复核，没有很好的进行产品联动。
当然大家可能觉得是因为没有采购同一家产品，造成了兼容性缺失的问题，才会导致工作量指数级别上升。
其实笔者觉得这块儿的工作，无论是厂商本身来做，还是依靠团队人工对信息流进行补齐，都是相对次要的。
更关键的点在于，是我们需要优化好安全运营规则，让更严重的事务和更优先的级别，及早的被我们感知到并进行应急处理，而不是淹没在海量告警和镭射动态展示大盘之中。
自动化能力建设
在这个阶段，我们投入了更多的精力去建设团队的安全自动化能力，以求解放人力去搞研究工作。
在此期间，我们针对性的对缺失的安全能力，对标业内互联网企业的标杆进行剖析，发现主要有几个点是亟待改善的。
黑盒安全能力
我们利用线下测试环境和镜像流量，重点建设了主被动扫描器（DAST），其中包含黑盒漏扫和基线核查平台；同时，也针对交互式扫描（IAST）能力进行强化，对代码执行进行污点插桩和编号，监控系统的输出和落地执行结果，方便向源头进行追溯。
白盒安全能力
针对白盒扫描（SAST），我们接入了多个扫描引擎。除了质量CICD流水线平台自带了安全插件进行优化外，还对商业化的白盒安全产品进行了外采接入；除此之外，自研的引擎里，还加入了针对Git平台的关键词和配置、组件版本依赖检查（支持分支），保障在接入流水线后，能尽可能完整的覆盖到所有代码的检查。
数据合规检查
针对这块儿，我们着重对数据库里存储敏感数据字段进行核查，也结合XIDS对流量里包含的敏感数据进行了监控。
同时，我们还结合DLP监管的记录，以及对明暗水印机制的设计，对数据外泄事件起到了一定的防控作用。
安全SDK治理
每个公司的技术栈是不同的，所以针对内部应用最多的技术栈代码，针对性的开发安全SDK也显得比较重要。
除了本身对研发团队提出安全编码制度以外，我们还对研发团队提供了安全SDK，也提供了IDE安全检查插件，通过微侵入式的方法，在一定程度上保障了代码的安全。
当然，这样产出的代码，可能在交付给第三方合作厂商时，会单独进行脱敏分支开发，在一定程度上会提升成本。但考虑到这方面的业务量不多，还是合算的。
风险链路治理
在SDL建设到了这个阶段，我们已经有了一定的安全自动化能力，那么如何去实现突破呢？
在梳理业务链路中的风险后，我们开始针对威胁进行建模，从体系架构上自上而下进行治理。
其中，我们重点关注了IPDRR和STRIDE模型，并辅以DREAD模型进行威胁评级，针对原有安全能力的缺失进行优化联动，也对现有的安全风险点进行收敛治理。
从不同的业务场景，以及不同的数据流程，分别对风险定制了削减措施，分配人力形成项目组，推进治理优化工作。
具体的风险链路大盘，这里由于内容敏感不方便直接发出来，我们就简单谈谈重点项目的建设工作。
资产库的收敛
在原先的工作中，我们自己的资产库更多的会去依赖于运维部门的注册信息，然后我们内部通过扫描器进行的资产补充。
后来发现这样做有个问题，我们在针对细粒度的资产标签，譬如新增端口、机器所属域、服务类型列表、迭代接口等等，无法及时的掌控，这样对我们的纵深体系的监测是不利的。
所以在我们着重进行了这方面能力的补充，通过被动监控流量，以及主动对代码AST树进行梳理的方式，对复杂的调用进行网状关系绘制，以及对标签关联的资产进行聚类。
这样，在出现问题后，我们也能很快的进行阻断和溯源定位。
内部巡检
针对内部的一些通用型漏洞，由于信息关联度问题，我们在原来的工作中没有很好的进行横向打通。
在不断加强内部对于0day、1day的识别能力后，我们能更好的去识别入侵事件。
在后面的SOC运营平台的建设工作中，会针对漏洞元素进行细粒度的手动标签，也支持了自动化识别，加强了针对资产的测试环境和边界环境，及时进行横向巡检，将风险扼杀于摇篮之中。
边界治理
在针对诸多风险进行治理时，必不可少的需要考虑到对边界安全进行收敛。
在这方面的工作中，我们可以考虑做以下的工作：
- 针对出入的流量进行重点核查
- 对开放的外网服务进行一键式深度防护
- 启用备份机制，随时对出现漏洞升级故障的边界服务进行替换
- 对边界资产进行即时扫描防控
- 自动化核查应该把边界的优先级提升到最高
我们前面对于资产库的优化工作，也是能为边界安全的治理提供效能的。
接口人制度
我们原来的业务方接口人，都是资产定位到项目组为止。
这样的话，很难在具体风险发生时，最快速度联系到个体接洽解决，在推进修复的过程中也很容易扯皮。
所以后来我们采用了业务方接口注册制度，让业务方主动去做项目归属个体和人员backup的填写，并且结合内部的人力资源存留的注册信息，定期向业务方确认项目变动情况。
总之，我们需要保障在项目存活的安全生命周期中，实现人员响应可控、权限周期可控、人员备用可控。
第三方合作建设
在第三方合作体系的建设过程中，我们也参照业内的情况，做了不少工作。
在这方面的治理上，虽然有不少标准可以参考，但并没有统一的方案。
其中需要治理的内容有：
- 第三方合作商的业务
- 第三方SDK的引入核查
- 第三方流量接入时的监控前置
- 第三方账号监控的核查
这些东西太多，只能稍微例举几项。真正想要做好，需要对各业务线的情况进行深入了解，结合企业自身的情况进行定制。
同时，这也是外部审计公司很难在短时间内给出完整方案的，需要内部的安全人员去做更多的探索。
后面的话，针对这块儿可能会单独提出来跟大家聊聊，讨论下有哪些通用的解决方案。
指标订立和回归
在针对SDL实现流程化管理，对治理成果进行验收时，我们需要重点注意的是，得对前期订立的指标做验证回归。
这些无论是在安全工作的KPI中体现，还是向业务方进行成果透明化展示，都是有意义的。
这里举例几个方面，给大家参考下指标订立的原则：
风险收敛
我们针对需要重要防控的项目，在风险收敛比例和收敛耗时方面，是需要订立一定的指标的。
如果在这期间发生了安全风险引起的资损事件，会侧重考核我们是否做出了合适的应对措施，针对资损事件进行弥补和挽回。
漏洞回归
对于漏洞指标订立，我们会针对高危漏洞的数量、漏洞类型趋势进行统计。
其中，会区分外部SRC提交和内部发现情况，从不同维度进行趋势计算。
同时，我们针对黑白盒自动化漏扫的召回率和精确率，也会做同期的月度、季度、年度对比。
最终，我们也会添加插件数、服务数、接口数等作为变量，从综合层面去判定成果，避免在判定权重方面发生缺失。
服务健康
这个有点类似于QA的质量考核指标，如果一个服务经常出现代码风险，经常出现漏洞，通常这个服务的健康评分会比较低。
这个是针对业务方的，也是对我们治理结果的的反馈之一。
对于服务安全，我们订立了几个指标，譬如漏洞修复率、安全产品接入率、漏洞反复率、风险发生率、鉴权接入率等等。
最后，通过单个服务乃至业务线作为基准元素，我们也会反过来对比考核各个业务线安全的质量，从而在更高的维度评价业务安全的产出。
结语
上面的一些总结，是从业务安全早期治理内容来讲的，涉及的内容相对简单。
后面的续篇，会继续对单方向的重点进一步剖析，以及针对具体实施细节进行描述。