文章总结： 本文探讨了基于研发过程的漏洞治理及经验，强调在不同研发模式下进行有效研发安全建设的重要性。文章从架构设计、编码、配置和应急响应四个方面提出具体治理方法，包括安全需求检视、架构安全评审、编码安全规范、静态代码扫描、开源组件扫描、安全配置基线和应急响应机制等实践，旨在帮助企业建立全面的研发安全体系，降低产品漏洞风险。
综合评分： 91
文章分类： 安全建设,应用安全,漏洞分析,代码审计,应急响应

基于研发过程的漏洞治理及经验

原创

aerfa21

我的安全视界观

2024年7月17日 06:06
北京

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

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

在上一篇中，找到了研发安全的切入点，按照常规思路就应该想出对应的解决之道。本文将深入“架构-编码-配置 + 应急响应”，针对漏洞生产源，提出治理的实践方法及经验。

01 架构设计缺陷

————————

在设计阶段要关注安全需求是否在设计中体现，对设计进行评审以发现其他潜在的安全风险，涉及的安全活动主要是：

安全需求纳入检视：部分安全性需求检查的第一道关卡，需要在设计中体现出来。通过Excel表格反馈+word证据截图或问卷调研的方式，对项目中的安全需求落实情况进行review。可以采取业务方收集证据反馈，架构师或跨业务方架构师检查，安全团队抽查的方式（前提是安全团队联动公司级架构师团队或技术委员会，将安全检查融入日常工作中，让其承担一部分安全的职责）；
产品架构安全评审：对于重要产品、产品的高危功能等应该特别关注的产品，额外进行架构安全评审。通常可以使用攻击树的分析方法（安全人员更加擅长，更高效发现可能的攻击点），与业务方开发等人员进行安全评审，重点在发现安全风险并治理、以及阻断攻击链。

02 编码忽略安全

————————

在代码层面引入的安全问题，有比较多的治理方式。比如从检查方面来说，可以对引入的第三方组件进行漏洞和后门检查，对自研的代码进行漏洞扫描；从预防或左移的角度来说，可以制定并推广安全编码规范、安全组件，想办法让开发避免引入漏洞。以下是一些常见做法及经验：

编码安全规范：网上有不少公开的安全编码规范，比如一些互联网大厂、云平台及开发社区。如果解决合规（过检查），可以完全照搬；但要是想真正解决问题，则应该进行部分参考，大概占比可达20%~30%。剩余部分应该根据历史安全测试的结果、日常运营过程中遇到的安全问题等实际已发生的风险进行制定，类似输出OWASP Top 10类别，因为多了不一定能够落地，先出一个版本再优化迭代；
静态代码扫描：理论上可以联动编码安全规范，检查其是否落地及闭环。将规范中的内容逐一落到SAST工具的检测规则上，从技术层面真正的做到规范检查，效果要比安全培训、培训后考试更好。但很多公司的代码扫描还是先关注高危漏洞，规范规则的扫描可以排在第二顺位。第二想介绍的是自动化，静态代码扫描是比较好与研发工具（如gitlab、jenkins）联动，开发提交代码就触发扫描，扫完就推动漏洞给研发并提醒修复。第三是误报，所有工具的检测规则都需要调优，常见的有结合业务特点写增强型规则、普适性规则在一些场景中误报则要加白…，一定是要投人运营才能降低误报率及提升检测能力。此外，研发安全团队一定要先优化规则，再要求或推动业务方修复漏洞，因为SAST误报真的是非常多，业务方会认为安全不专业、是麻烦事儿，以至于产生抵触情绪、不便开展后续的工作；
开源组件扫描：主要存在两个安全问题。第一个是漏洞，开源组件的CVE漏洞特别多，但是目前市面上的检测工具基本上都是先拆包、然后根据指纹和CVE漏洞库碰撞，只要版本匹配就会报存在漏洞，所以带来的误报会非常多，真正受影响的情况特别少。不过在一些监管属性比较强的行业，只要是工具报的高危漏洞都要求处理。如果是误报给出依据，若是真的漏洞则要去修复；相比在互联网这种宽松的氛围下，基本都是实际带来了可利用风险，才会去处理。无论什么行业，对于SCA工具扫描的进一步研判，都是行业中所需要的安全能力。第二个问题是开源组件投毒，如 Python或npm源管理比较松散，就会出现组件包伪造、源账号攻击等方式进行投毒。最佳方法是对源进行统一管控，但大多数公司都做不到。不过即使做到了，当首次引入时同样会面临检测的问题，然而这是绝大多数公司缺少（静态特征检测、动态跑沙箱做行为分析），基本只能依靠威胁情报进行响应；
安全组件建设：不仅是单纯的指实现安全效果的CBB，也可以是经过安全性改良/定制的开发框架。这项活动的实施难度最大，一是要有懂安全的开发人员或会开发的安全人员支撑，能够将常见的文件操作、输入输出处理、数据库操作等常规操作会发生的安全问题梳理清楚，结合开发框架或开发语言来写组件或改良框架；二是推广应用的问题，基本只是适合于新的项目，因为已上线系统发现漏洞后去改框架或换实现方法非常麻烦，不会有业务同意这么干。所以就只能瞄准新系统，亦可以把该项前置到需求或设计阶段，要求业务方使用。

#

03 配置发生错误

————————

在产品发布与部署阶段，不合规的方式或不良操作习惯，可能带来一些安全问题。不过如果具备统一的发布和部署能力，则可以规避很多潜在风险，只需关注“源头”。尤其是针对PASS层的软件：

安全配置基线：属于基础安全的范畴，但基础不牢真会地动山摇。去年之前我们集中力量投入到应用层的安全性检测，默认了业务线给出的内部微服务有gateway管控、内部数据库、大数据组件服务有iptables的说辞，尤其是对基础服务投入很少。随之而来从SRC收到很多关于pg硬编码、版本过低可提权、redis未授权获取root权限等漏洞，从而导致产品被攻陷。比较有效的治理方式是基于攻击视角的安全基线，众所周知CIS安全基线比较全，但实施的时候就会比较麻烦，所以需要按照攻击思路来精简。如针对Redis，关注启动服务不使用root权限、设置账密验证或在配置文件中指定访问IP源、禁用可以执行系统命令的函数，这并非绝对或死板执行，需要根据业务实际情况进行调整，原则就是常说的最小化（服务最小访问、权限最小）等；
黑盒漏洞扫描：定期对操作系统镜像模板、最小化容器模板、数据库模板、大数据开源组件模板等进行黑盒扫描并修复漏洞，以检验默认配置执行情况；在测试阶段再次进行主机漏洞扫描和web漏洞扫描，发现近期暴露出的漏洞及配置类漏洞，以保证基础软件默认安全。

04 应急响应托底

————————

上述内容都做好了，是不是产品就没有漏洞呢？答案是否定的，就如没有绝对的安全一样，投入的资源越多、被外部发现的概率就会越小，但永远不会出现无漏洞。其中，有两个主要的原因：

漏洞是动态的：产品使用到的开源组件现在没有漏洞，但在未来可能被爆出存在可利用的漏洞，故此产品也会受到牵连；
SDL并不是万能的：通常在研发安全体系中，会出现安全工具能力不足或被bypass、安全测试或开发人员出现纰漏等问题，导致漏洞未被发现。

所以需要建设预警和响应机制，进行托底式的快速响应。在预警部分，通过资产管理摸清产品中使用到开源软件和组件，对外部情报源如开源软件官网、安全公司威胁情报、安全微信群、安全媒介等进行监控并告警；在响应部分，需要设置跨组织的应急响应团队（如安全、业务线、公关、法务、交付等）、流程和响应要求，以应对突发的产品安全事件。由此保障这些组织、流程、机制等的正常运转，才能做到相对可控。

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

More…

— 深耕研发安全 —

— SDL 100问 —

— 软件供应链对抗探索 —

——— 实战演习 ———

——— 安全运营 ———

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

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

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

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

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

免责声明：

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

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

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

本文转载自：我的安全视界观 aerfa21《基于研发过程的漏洞治理及经验》

Tags: 代码审计安全培训安全建设安全开发安全运营应急响应应用安全渗透测试漏洞分析

你可能错过

制造业为何频遭勒索？问题已不只是漏洞，而是身份与配置管理

首页劫持

【专题报告】扼海之争：美伊2026年第二次高强度对抗复盘

9月21日威胁情报IOC分享

基于研发过程的漏洞治理及经验

#

在产品发布与部署阶段，不合规的方式或不良操作习惯，可能带来一些安全问题。不过如果具备统一的发布和部署能力，则可以规避很多潜在风险，只需关注“源头”。尤其是针对PASS层的软件：

你可能错过

制造业为何频遭勒索？问题已不只是漏洞，而是身份与配置管理

首页劫持

【专题报告】扼海之争：美伊2026年第二次高强度对抗复盘

9月21日 威胁情报IOC分享

9月21日威胁情报IOC分享