内容回顾

该模型共包含10个阶段，如下：

（1）Plan计划阶段

• 解决安全技术栈：需由安全人员评估以往安全设计中不完善的坑点，并给出解决方案

• 确定DevSec的衡量指标

• 威胁建模

• 安全工具培训：SDL所涉及的安全服务更多，但DevSecOps基本靠自动化，因此需要包含针对安全工具的使用培训

（2）Create生成（编码）阶段

编码过程中的安全问题：市面上几乎都是通过IDE安全插件的方式实现

（3）Verify验证（测试）阶段：SAST/DAST/IAST/SCA

（4）Preproduction预发布阶段

• Chaos Monkey（混沌工程）

• Fuzzing：与SAST/DAST/IAST等基于已知经验发现安全问题不同，fuzzing捕捉的是完全未知的安全问题

• 集成测试：单元测试风险较低，但联动后风险相对不可控，因此需要做集成测试

（5）Release发布阶段

软件签名：传输等过程中的防篡改

（6）Condifure配置阶段

签名验证、完整性测试、纵深防御

（7）Detect检测阶段

RASP、UEBA、网络流量监控、渗透测试——即线上运维阶段

（8）Respond响应阶段

安全编排（基于发现的威胁作智能阻断，形成playbook）、基于RASP和WAF的安全防护、混淆

（9）Predict预测阶段

该阶段关注的重点是威胁情报——

• 漏洞情报：最新的漏洞及其利用方式

• TTPs的威胁情报：具体的攻击手法、攻击者画像等新型威胁情报对开发安全来说更有用，而不是传统的URL、IP、恶意文件等信息

（10）Adapt适应阶段

根据拦截结果调整开发安全过程，更改策略，对自身应急响应的方案、纵深防御体系等不断适配、调整、优化。

补充说明：

安全培训在DevSecOps中强调不多，但实际落地时还是必要环节。安全培训不应该是模式化的，而应该根据用户实际场景总结出不同的培训内容。

默安DevSecOps体系几乎覆盖开发安全的所有流程，包括STAC模块覆盖的安全需求、威胁建模，SAST模块覆盖的自动化代码审计、第三方组件的安全问题，IAST模块的主被动IAST、主被动DAST以及小部分SCA，哨兵云模块覆盖的主机层、应用层安全问题及24小时应急响应服务。在默安的DevSecOps体系规划中还包括对开发安全流程作全面管控和持续运营的统一平台。

此外，默安还提供多方面的开发安全体系建设服务，解决安全落地过程中人手缺乏的问题，适配不同组织中不同的开发模式。

（1）挑战

一般的DevSecOps客户对白盒扫描速度要求极高；DAST显然疲软，扫描持续时间长，还会在扫描过程中产生一定脏数据，不适用于DevSecOps流程，并被IAST取代。

（2）具体实现

在白盒阶段，通过和Pipeline平台的API对接，获取代码仓库的地址、用户名密码，执行漏洞扫描；在测试阶段，通过与Pipeline平台对接做自动化agent安装、数据流获取和漏洞信息的反馈。

（3）结果

包含全流程安全测试的整个开发流程持续大约45分钟，控制在1小时以内，速度满足客户预期。

Jenkins集成方式主要有两种：

（1）Jenkins插件

• 用于自由风格和流水线模式；

• 将扫描结果展示到Jenkins平台；

• 设置代码安全质量阈值，决定Jenkins流程的是否中断。

（2）Jenkins pipeline辅助组件

• 根据用户参数协助生成pipeline脚本；

• 提供二进制程序，一条命令创建项目发起扫描。

  
  

与Jira的协同工作流程如下：安全人员对IAST等工具检测结果作review并同步到Jira，研发作确认或修复，再次将状态同步到Jira，测试人员复检（不是由测试人员做漏洞验证，而是自动化的一键验证），再反馈给安全人员，确定是否需要重新渗透等。

漏洞流转流程建议在Jira之类的漏洞管理平台上独立管理，不推荐在产品流程过程中作漏洞管理。安全不应改变用户原本流程，而应契合用户的工作习惯。

最后罗列5个我们认为比较好的DevSecOps新方向：安全需求与威胁建模平台、漏洞自动化修复、AVC漏洞关联分析、ASTO安全测试编排以及实现持续运营的流程管控平台。

安全开发大讲堂第五讲 

《大企业小企业，SDL差异几何？

——来自一个安全开发“全栈人”的实战故事》