很久以前，就想写一篇关于SDL与DevSecOps的文章，但疏于实践一直未能动笔。想写的原因很简单，因为总是听到有人说SDL落后、DevSecOps相关技术更高超。一提到研发安全建设，不分研发模式都在赶时髦一样地说DevSecOps。从我的观察来看，不结合研发模式来做研发安全，都是不成功的。
在数字化浪潮的推动下，一些公司已经完全步入DevOps模式，有的则出现瀑布、敏捷或DevOps并存，且后者是居多的。所以如何在多种研发模式下进行有效的研发安全建设，成为一个必须解决的难题。经过近十年的实践，终于在探索解法上有一点点收获与经验，于是有了“深耕研发安全”这一系列文章。
本文是第六篇，DevSecOps实施的第三个关键准备（3/4），系统化的介绍研发安全相关规范体系。从设计思路、技巧到实践经验，描述了规范的应用，以全面支撑研发安全工作在公司层面的开展。
好的规范设计是一个系统性工程，需要综合考虑公司的业务需求、研发流程、技术环境、法律法规和行业规定等多方面因素。然而，规范相关的工作常被轻视或忽视，尤其是在技术氛围浓厚的团队。
按照体系化的思路，研发安全的规范和体系设计亦可以遵循四级原则，并且在研发流程中是如下体现：
开发框架（一级文件）：指公司级开发框架体系，是开发过程与公司战略目标承接的基础，指引所有研发团队的工作；
安全提测管理流程（二级文件）：描述研发过程中安全提测的操作步骤、要求和标准，是研发安全的最高级别文件，范围涵盖研发的各个阶段（需求管理、设计管理、开发管理、验证管理、发布管理和生命周期）；
研发安全相关规范和管理办法（三级文件）：在各研发阶段中的安全要求和规范，如安全需求规范、安全设计规范、编码安全规范、安全测试规范、应急响应管理办法、安全加固规范等；
研发安全相关模板和操作手册（四级文件）：支撑三级文件落地的具体指导书、实施细则、清单、操作手册和模板等，如安全需求基线（知识库）、安全设计基线（知识库）、威胁建模报告模板、安全测试报告模板等。
02 编码安全规范设计技巧
每个研发安全团队几乎都会制定编码安全规范，提供给开发进行学习和参考，试图在开发过程中减少常见漏洞的引入，从而保护产品免受攻击。也就是说编码安全规范的质量好坏，一定程度上影响着整件事的成败。所以至少要注意以下三方面：
明确制作规范的目标：最初的目标肯定是为了规避安全漏洞，每个公司的技术栈不同、产出的漏洞类型也不一样，应该通过历史安全事件、安全测试结果等分析出内部的Top 10类型漏洞，制定先要解决的漏洞类型计划，从而编写规范内容；后期可能会为了合规性检查、供应链公司安全检查等，此时应避免提供内部针对性强的规范，要准备一份大而全的交出去，以免暴露典型漏洞；
三分借鉴七分得定制：在研发安全推进的初级阶段，大而全的编码安全规范产生的效果反而不太好，所以应该先聚焦解决3-5类漏洞，待漏洞逐渐收敛就可以追加内容。规范不是一成不变的，需要与时俱进的更新，与时是指当前公司内部的研发安全态势、当前的安全措施及效果等；
从开发人员视角出发：如果编写规范的参与者都是安全团队，则一定要小心写成自己熟悉、对开发陌生的语言。安全人员通常习惯漏洞描述、原理及解决方案的思路，而开发人员则更习惯看对输入与输出的处理、内部资源的操作。在规范中加入错误代码、正确代码示例也有助于理解，并且在写完后一定要组织资深开发或架构师进行评审，以确保规范的有效性。
03 安全规范落地实践经验
说起规范的落地，我们可能第一时间会想到培训和考试，这虽有作用但都只能解决知道的问题。在推行培训的过程中，需要“因地制宜”地考虑到不同场景，把培训尽可能融入流程、做成体系。比如，以编码安全规范的落地为例：
新员工入职组织培训：可以将安全培训嵌入到新员工入职的课程中，包括校招和社招开发序列人员。校招生估计没怎么接触过安全、社招人员的安全意识肯定参差不齐，这时候应围绕编码安全规范对他们进行常见漏洞介绍和攻击危害展示，使其明白安全的重要性及提升安全意识，并灌输自己写的代码自己负责安全质量理念，以及鼓励他们在日常工作中主动发现安全隐患并修复；
常写漏洞的开发人员：借鉴“解决不了问题，就解决人”的思路，针对每个BU经常写漏洞的研发人员，把他们集中起来组织安全培训和考试，重点介绍他们的漏洞案例，介绍危害性和不安全原由，引出编码安全规范并倡导自行引入白盒检测工具进行自检；
常态化的安全分享会：当编码安全规范有更新、白盒安全工具有新增或优化、外部发生重大漏洞时，在公司内部借助一些分享会或自行组织分享，传播研发安全的知识，提升大家的安全兴趣和意识。
做好上面的事儿，基本就能让开发人员知道编码安全。但知道并不等同于做到，从知道到日常工作中做到的路还比较远。所以一定要想出办法，能够及时提醒、监督或检查是否做到：
联动白盒检测工具：把编码安全规范尽可能的落到白盒的检测规则上，理想状态下是一一对应，但现实基本上是一对多（一条规范对应多条检测规则）。主流思路是依据规范来写检测规则，保障规范的有效落地，直接检查是否编码安全，也不让白盒检测工具因为规则多导致的误报而难以落地。不过也有例外的情况，比如已经知晓白盒工具上的某条、某些检测规则十分精准，此时规范中又没有要求，那么也可以上规则、后补充规范。此外，规范内容和工具检测规则均需要持续调优；
风险提示左移到IDE：目前比较“左移”的做法是在IDE上进行代码漏洞检测和风险提示，较为常见的方式是IDE联动白盒检测工具，因为检测规则都在工具上、IDE插件仅是串联作用。随着大模型的应用，后续在IDE上的效果应该会更好。（目前试过国内的几家，但检测漏洞方面表现都不够理想，至少还没到放心使用的水平。）
针对编码安全规范的落地，在流程上做了宣导，在技术上做了检测，那还会发生意外情况吗？答案应该是的，比如有针对bypass代码扫描流程的、假装完成编码安全培训的...为了应对诸如此类的奇葩情况，在安全提测管理流程设计时，就要把不按照要求执行产生漏洞或事件的情况考虑进去，最好的方式就是在事发后做处罚警示。实际不一定做，但要保留该权利，最好是想办法和BU的绩效考核挂上钩。
长按识别二维码，和我交流
More...
-- 深耕研发安全 --
-- SDL 100问 --
SDL100问：我与SDL的故事 SDL 1/100问：SDL与DevSecOps有何异同？ SDL 2/100问：如何在不同企业实施SDL？ SDL 3/100问：SAST误报太高，如何解决？ SDL 4/100问：SDL需要哪些人参与？ SDL 5/100问：在devops中做开发安全，会遇到哪些问题？ SDL 6/100问：如何实施安全需求？ SDL 7/100问：安全需求，有哪些来源？ SDL 8/100问：安全需求怎么实现自动化？ SDL 9/100问：实施安全需求，会遇到哪些难题？ SDL 10/100问：安全需求和安全设计有何异同及关联？ SDL 11/100问：设计阶段应开展哪些安全活动？ SDL 12/100问：有哪些不错的安全设计参考资料？ SDL 13/100问：安全设计要求怎么做才能落地？ SDL 14/100问：有哪些威胁建模方法论？ SDL 15/100问：有哪些威胁建模工具？ SDL 16/100问：如何开始或实施威胁建模？ SDL 17/100问：威胁建模和架构安全评审，有何异同？ SDL 18/100问：编码阶段，开展哪些安全活动？ SDL 19/100问：如何选择静态代码扫描(SAST)工具？ SDL 20/100问：如何选择开源组件安全扫描(SCA)工具？ SDL 21/100问：SCA工具扫描出很多漏洞，如何处理？ SDL 22/100问：SCA工具识别出高风险协议，如何处理？ SDL 23/100问：如何制定一份有用的开发安全规范？ SDL 24/100问：如何做到开发安全规范的有效实施？ SDL 25/100问：应该如何选型代码安全扫描工具？ SDL 26/100问：代码安全扫描应该设置哪些指标？ SDL 27/100问：如何提升开发人员的安全意识？ SDL 28/100问：在编码阶段加入安全检查后，如何处理带来的时间压力？ SDL 29/100问：白盒检测工具存在局限性，如何进行补偿？
-- 软件供应链对抗探索 --
--------- 实战演习 ---------
--------- 安全运营 ---------
--------- 软件安全 ---------
--------- 企业安全 ---------
--------- 渗透测试 ---------
--------- 安全开发 ---------
--------- 个人体验 ---------
如有侵权请联系:admin#unsafe.sh