为什么“你家”漏洞那么多

概述

这里提到的“你家”就是指企业，为什么会存在那么多的漏洞呢？目前的安全趋势下解决漏洞问题看似是一件小事，其实往大了说是一件大事，俗话说，“千里之堤毁于蚁穴”。我们不能每次遇见漏洞问题就大事化小，小事化了的态度。或者说在检查机关或者市场监管机构下，说是要进行大规模批量检查的时候，紧急组织一批安全人员处理所遇到的安全合规的问题；又或者说是业务处于运营期间而发生的一系列的安全问题。总是让我们猝不及防。为此，解决这一治标不治本的错误方法，寻找从根处解决这一根本问题，寻根究源积极从源头上杜绝此类现象再次发生，降低漏洞的修复成本，为业务系统的运行打造良好的健康的安全的运行环境。

内容

借鉴国外成功的最佳实践，结合国内安全情况制定的安全开发体系框架；在提出规定的同时，观察实际结果，形成整体的闭环。该框架主要分为四个方面：包括开发安全管理体系、开发安全知识赋能、开发安全产品支撑、开发安全阶段运营。开发安全管理体系提出各阶段要求、规范、流程，开发安全产品支撑管理体系的自动化落地，开发安全知识赋能各环节人员对体系、产品的理解，开发安全阶段运营则进行各环节技术点的支持与落地。

那么，怎么让开发安全的每个阶段能够有条不紊的进行着呢，这就需要将安全活动贯穿到SDL的每个环节之中；
需求分析阶段：STAC实现基于业务场景，对业务系统从数据、合规、连续性等方面进行安全需求分析
安全设计阶段：STAC对安全需求进行分析，利用SDFK基于安全设计核心原则进行安全设计
开发阶段：制定安全编码规范，在代码编写中通过SAST【静态应用程序安全测试】、基于代码仓库的安全巡检，提供与程序员对话的源码安全审计
测试阶段：IAST【交互式应用程序安全测试】建立内部安全测试模式，提供常见漏洞、业务逻辑漏洞检测，自动化完成安全测试
上线运行：通过SDPP流程管理平台将安全需求、代码安全检测、应用安全测试等安全活动进行流程管理，帮助项目管理人员可视化审查每个阶段的安全活动，统一化漏洞闭环管理。通过自研的漏洞管理平台实现资产管理和漏洞发现
其中SAST支持本地上传代码或SVN/GIT/TFS/MERCURIAL代码仓库源代码检测，在不改变原有的研发流程情况下，无感知的对代码仓库源代码进行增量测试及周期巡检，定时对代码安全质量进行全面体检，最大程度降低对研发工作的侵入性，融入研发流程，最大程度降低对研发工作的侵入性,全面覆盖研发人员在编码中和编码后的安全问题；漏洞验证引擎），根据比如数据流完整性的可信度是大于等于90%的 然后我们综合右边的完整性和合理性去进行判断漏洞是否存在底下都是编译引擎（编译原理），第三方组件引擎，漏洞识别引擎，漏洞验证引擎，统计、展示信息。漏洞精确的决策引擎，我们会对可信度打标签，可以调整，一般传统代码审计产品都是定死的；开源组件，解析项目里的开源组件，我们首先预置了一些，比如java 到maven上把所有的组件爬下来，组件是什么版本，这个版本有什么问题；漏洞识别引擎：基于语法树引擎，正则引擎，机器学习引擎，多引擎分析，降低误报率；还可以依据客户需求，通过调节漏洞检出率，检出率越高，漏洞覆盖率高，发现漏洞越多，检出率越低，精确度越高，误报率略低。支持选择项目扫描的漏洞类型，扫描的漏洞结果包括漏洞风险描述，修复建议，修复代码示例和风险溯源，可准确定位漏洞位置，帮助研发进一步整改，也减少了安全和研发的沟通成本封装好的函数，研发不用了解漏洞怎么产生的，只要知道怎么调用这个函数就可以解决了；第三方组件引擎，对配置、数据流、控制流、符号表等全面解析，语法引擎：提取变量，函数，类，执行流，基于这些去跟第三方组件里的函数，类对比，不是去对组件包本身进行分析 配置文件，编译过程中依赖关系，编译过程中二进制码；快速定位合规风险：提供 开源许可证的完整信息、是否开源、是否商用；同时进行了第三方平台的无缝对接；

iast 通过代码数据流和请求两种方式进行流量收集，进行漏洞检测，同时支持逻辑漏洞（水平垂直越权漏洞，验证码相关漏洞）检测，还可以对软件成分进行分析；帮助用户梳理项目中的第三方组件使用情况，对第三方组件的版本风险，安全漏洞分析，开源许可证风险进行评估；

而通过代码进行检测的方式是添加插桩Agent探针到应用服务器上，就相当于给应用服务器安装了一个传感器，主要控制台可以根据“传感器”发出的警报进行联动测试；又像是一个C/S端，将客户端放置在被测的业务系统上，一旦业务系统发生了什么反应服务端就可以在第一时间得到响应；还像是木马回连一样；总之这样的模式是基于代码层面的一种检测手段，不关注参数是否加密，它避免了加解密的场景、验证码和请求的重复释放（重放攻击）；还有一个好处就是代码经过时进行检测，进行污点标记若有过滤函数则去消除，否则就是污点沉降进行上报漏洞的；不用多次的重放攻击测试，避免了脏数据的存在，大大加快了漏洞的检出速率；还有与主动请求方式的配合就会弥补到漏洞不能进行复利用。相当于进行了二次检测进一步进行漏洞的确认；还可以利用检测代码代码的方式进行检测业务系统中是否存在第三方组件，这些组建是否是开源的，是否是商用的，是否是有许可证的，是否存在CVE的漏洞，以及存在的库名的信息；很好的帮助用户检测业务系统中的代码哪些地方存在安全风险，这样可以得到及时的修复；

基于请求模式下进行流量方式的检测，使用了URL去重的方式大大减少了不必要的检出的URL，从而提高了工具的使用率也减少时间成本的投入，大大提高了工作效率；IAST还增加了特有的业务逻辑的检测功能，高效的解决了一部分人工投入的成本，解放了一部分的工作内容；对业务系统的所有的API接口进行测试，设置高低权限账户自动切换COOKIE值的信息，利用扫描到的URL地址进行页面数据的对比测试，进行确认越权漏洞的情况；利用爆破等方式进行用户枚举，验证码等漏洞的检测，大大的降低了人工的工作时间；当然了在请求流量下支持所有语言的检测毕竟它走的是HTTPS/HTTP的协议，走的是应用层的协议；一些get\post等方式的请求，插入payload进行自动化尝试去检测系统中存在的漏洞，比如：app、web等都是可以去检测的，只是设置的代理方式不同，有点像抓包工具的原理一样，比如：burpsuit等；