很久以前，就想写一篇关于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问 --
-- 软件供应链对抗探索 --
--------- 实战演习 ---------
--------- 安全运营 ---------
--------- 软件安全 ---------
--------- 企业安全 ---------
基于堡垒机的自动化功能实践1****
--------- 渗透测试 ---------
--------- 安全开发 ---------
--------- 个人体验 ---------
