文章总结： 文章详细介绍了DevSecOps实施中的研发安全规范体系建设，强调规范建设是系统化工程，需要遵循四级原则。文章提出了编码安全规范的设计技巧，包括明确目标、定制化内容和从开发视角出发。同时，文章分享了安全规范落地的实践经验，如通过培训、联动白盒检测工具和IDE风险提示等方式确保规范有效执行，并建议将规范执行情况与绩效考核挂钩以提高执行效果。
综合评分： 89
文章分类： 安全建设,应用安全,安全运营,安全培训,安全工具

DevSecOps实施关键：研发安全规范

原创

aerfa21

我的安全视界观

2024年9月9日 08:02

很久以前，就想写一篇关于SDL与DevSecOps的文章，但疏于实践一直未能动笔。想写的原因很简单，因为总是听到有人说SDL落后、DevSecOps相关技术更高超。一提到研发安全建设，不分研发模式都在赶时髦一样地说DevSecOps。从我的观察来看，不结合研发模式来做研发安全，都是不成功的。

在数字化浪潮的推动下，一些公司已经完全步入DevOps模式，有的则出现瀑布、敏捷或DevOps并存，且后者是居多的。所以如何在多种研发模式下进行有效的研发安全建设，成为一个必须解决的难题。经过近十年的实践，终于在探索解法上有一点点收获与经验，于是有了“深耕研发安全”这一系列文章。

本文是第六篇，DevSecOps实施的第三个关键准备（3/4），系统化的介绍研发安全相关规范体系。从设计思路、技巧到实践经验，描述了规范的应用，以全面支撑研发安全工作在公司层面的开展。

01规范建设是系统化工程

好的规范设计是一个系统性工程，需要综合考虑公司的业务需求、研发流程、技术环境、法律法规和行业规定等多方面因素。然而，规范相关的工作常被轻视或忽视，尤其是在技术氛围浓厚的团队。

按照体系化的思路，研发安全的规范和体系设计亦可以遵循四级原则，并且在研发流程中是如下体现：

开发框架（一级文件）：指公司级开发框架体系，是开发过程与公司战略目标承接的基础，指引所有研发团队的工作；
安全提测管理流程（二级文件）：描述研发过程中安全提测的操作步骤、要求和标准，是研发安全的最高级别文件，范围涵盖研发的各个阶段（需求管理、设计管理、开发管理、验证管理、发布管理和生命周期）；
研发安全相关规范和管理办法（三级文件）：在各研发阶段中的安全要求和规范，如安全需求规范、安全设计规范、编码安全规范、安全测试规范、应急响应管理办法、安全加固规范等；
研发安全相关模板和操作手册（四级文件）：支撑三级文件落地的具体指导书、实施细则、清单、操作手册和模板等，如安全需求基线（知识库）、安全设计基线（知识库）、威胁建模报告模板、安全测试报告模板等。

02编码安全规范设计技巧

每个研发安全团队几乎都会制定编码安全规范，提供给开发进行学习和参考，试图在开发过程中减少常见漏洞的引入，从而保护产品免受攻击。也就是说编码安全规范的质量好坏，一定程度上影响着整件事的成败。所以至少要注意以下三方面：

明确制作规范的目标：最初的目标肯定是为了规避安全漏洞，每个公司的技术栈不同、产出的漏洞类型也不一样，应该通过历史安全事件、安全测试结果等分析出内部的Top 10类型漏洞，制定先要解决的漏洞类型计划，从而编写规范内容；后期可能会为了合规性检查、供应链公司安全检查等，此时应避免提供内部针对性强的规范，要准备一份大而全的交出去，以免暴露典型漏洞；
三分借鉴七分得定制：在研发安全推进的初级阶段，大而全的编码安全规范产生的效果反而不太好，所以应该先聚焦解决3-5类漏洞，待漏洞逐渐收敛就可以追加内容。规范不是一成不变的，需要与时俱进的更新，与时是指当前公司内部的研发安全态势、当前的安全措施及效果等；
从开发人员视角出发：如果编写规范的参与者都是安全团队，则一定要小心写成自己熟悉、对开发陌生的语言。安全人员通常习惯漏洞描述、原理及解决方案的思路，而开发人员则更习惯看对输入与输出的处理、内部资源的操作。在规范中加入错误代码、正确代码示例也有助于理解，并且在写完后一定要组织资深开发或架构师进行评审，以确保规范的有效性。

03安全规范落地实践经验

说起规范的落地，我们可能第一时间会想到培训和考试，这虽有作用但都只能解决知道的问题。在推行培训的过程中，需要“因地制宜”地考虑到不同场景，把培训尽可能融入流程、做成体系。比如，以编码安全规范的落地为例：

新员工入职组织培训：可以将安全培训嵌入到新员工入职的课程中，包括校招和社招开发序列人员。校招生估计没怎么接触过安全、社招人员的安全意识肯定参差不齐，这时候应围绕编码安全规范对他们进行常见漏洞介绍和攻击危害展示，使其明白安全的重要性及提升安全意识，并灌输自己写的代码自己负责安全质量理念，以及鼓励他们在日常工作中主动发现安全隐患并修复；
常写漏洞的开发人员：借鉴“解决不了问题，就解决人”的思路，针对每个BU经常写漏洞的研发人员，把他们集中起来组织安全培训和考试，重点介绍他们的漏洞案例，介绍危害性和不安全原由，引出编码安全规范并倡导自行引入白盒检测工具进行自检；
常态化的安全分享会：当编码安全规范有更新、白盒安全工具有新增或优化、外部发生重大漏洞时，在公司内部借助一些分享会或自行组织分享，传播研发安全的知识，提升大家的安全兴趣和意识。

做好上面的事儿，基本就能让开发人员知道编码安全。但知道并不等同于做到，从知道到日常工作中做到的路还比较远。所以一定要想出办法，能够及时提醒、监督或检查是否做到：

联动白盒检测工具：把编码安全规范尽可能的落到白盒的检测规则上，理想状态下是一一对应，但现实基本上是一对多（一条规范对应多条检测规则）。主流思路是依据规范来写检测规则，保障规范的有效落地，直接检查是否编码安全，也不让白盒检测工具因为规则多导致的误报而难以落地。不过也有例外的情况，比如已经知晓白盒工具上的某条、某些检测规则十分精准，此时规范中又没有要求，那么也可以上规则、后补充规范。此外，规范内容和工具检测规则均需要持续调优；
风险提示左移到IDE：目前比较“左移”的做法是在IDE上进行代码漏洞检测和风险提示，较为常见的方式是IDE联动白盒检测工具，因为检测规则都在工具上、IDE插件仅是串联作用。随着大模型的应用，后续在IDE上的效果应该会更好。（目前试过国内的几家，但检测漏洞方面表现都不够理想，至少还没到放心使用的水平。）

针对编码安全规范的落地，在流程上做了宣导，在技术上做了检测，那还会发生意外情况吗？答案应该是的，比如有针对bypass代码扫描流程的、假装完成编码安全培训的…为了应对诸如此类的奇葩情况，在安全提测管理流程设计时，就要把不按照要求执行产生漏洞或事件的情况考虑进去，最好的方式就是在事发后做处罚警示。实际不一定做，但要保留该权利，最好是想办法和BU的绩效考核挂上钩。

长按识别二维码，和我交流

More…

— 深耕研发安全 —

— SDL 100问 —

— 软件供应链对抗探索 —

——— 实战演习 ———

——— 安全运营 ———

——— 软件安全 ———****

——— 企业安全 ———****

——— 渗透测试 ———****

——— 安全开发 ———****

——— 个人体验 ———****

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：我的安全视界观 aerfa21《DevSecOps实施关键：研发安全规范》

Tags: 安全培训安全工具安全建设安全开发安全运营应用安全渗透测试

你可能错过

【客户端安全】代理绕过127监听CDP+Websocket协议未授权RCE漏洞

别再把LLM当扫描器用了：CyberStrike把Claude订阅变成了一个会自己思考的红队操作员

【AI安全】恶意仓库指定审查员：Claude Code为何在绿灯测试中执行载荷

朝鲜黑客组织（Kimsuky）利用 OpenCode人工智能代理大规模生产 LNK 攻击中的钓鱼诱饵