百度《企业级自动化代码安全扫描实战》读后感

近日百度安全应急响应中心发布了《企业级自动化代码安全扫描实战》读者可以管中窥豹实例了解静态代码分析在互联网公司的落地情况了解该领域的业界的技术趋势和进展查漏补缺发现企业内部建设不足对标评估自研安全能力立足自有工具现状制定改进计划。

一、概述

软件安全行业在全球不断出现重大安全事件的敲打下于设计阶段、协议、编译阶段、框架实现、加密方案方面已经有了众多优秀改进各项软件工具包括p3c、npm audit fix、findbugs可以让研发人员更快速得实现健壮的代码商业安全工具和开源社区共建如nodejsscan、findsecbugs、golint、rips协助安全人员相对准确地找到安全缺陷企业专职安全团队中SDL人员的完善投入和和专业化使得安全组织可以发力于流程建设和应急响应。安全审计人员主要任务逐步为将自动化融入到技术之中。但是业界每个公司的看到的“微软安全开发生命周期”已经耦合于组织内部的开发模式或者自称为敏捷sdl实现难以移植值得庆幸的是源代码审计环节可以快速适配企业在各个阶段的安全建设固定作为价值交付的产出。源代码安全检测普遍做法一般为人工reviewseay、ctrl+f、ide辅助词法分析阶段使用支持各种语言的多项开源源代码安全检查工具增改适配规则导出查看分析报告验证重视安全的企业采购商业源代码安全工具在具备二次开发和调用api接口的情况下同企业内部的jira、禅道、漏洞平台打通结合起来达到运营闭环和数据推动改进效果。

大型企业一般面临三个问题

1、不同部门用的技术栈不同前后端技术也不一致要对不同开发风格适配和维护各项开源工具的编译命令和规则、报告并不现实所以一般是使用商业安全工具为基础设施进行一套自动化的代码扫描接入和推广在追求覆盖率的情况下实现对不同部门业务线制定不同的扫描规则和“门槛指标”。

2、存量代码太多由于基于svn、gitlab、stash各有各的痛点在没有存储和代码检索平台的情况下人工无法在应急响应时快速准确判断是否受影响、在事后难以增加判断增量的感知控制手段。大量新增代码不同分支、对应不同线上线下域名、环境、发布平台。任何一件事的量级增加都是对工程化的巨大考验。

3、人力紧张知道安全专家接入到需求阶段效果最好成本最低但是依赖人工终将处于疲劳的应接不暇的阶段而人的工作终究会有漏报在事后回顾aar时也没有更好的改进手段只能做专项。如果黑盒扫描器一样源代码的高阶实现有且只有依赖于自动化手段。

为什么要做安全部门自己做源代码检测企业内部配置的专职QA或者RD自测时通过测试用例来保证需求清单的功能特性得到实现这种前提下将漏掉一些安全方面的考虑缺失对软件安全缺陷的检测。由安全部门制定检测规则可以具备更好的准确性、及时跟进和可信度也有利于后续的度量。

什么是漏洞源代码检测的安全和质量部门的检测有何不同：

因源码扫描作为安全运营的一个阶段将安全流程在需求、架构、设计、编码、测试、验证阶段进行度量和维护。

二、自动化代码挖掘技术

基于污点传播分析的自动化挖掘技术

回顾下有经验的安全测试人员在实施人工代码审计时的流程来观察思考软件该怎么做。首先灵活指定和假定输入源是否可信、能否被污染这类似于参考了威胁建模的信任边界和数据流概念一般认为来自于网络请求header、cookies、参数socket网络通讯数据库存储的数据是不可信的当然你可以设计来自于环境变量、配置文件、反序列类为不可信据此可以指定需要关注的程序内部函数继续分析查看上述的污染源是否经过安全处理即净化。这里的安全函数如阿里的midway-security、owasp的esapi检测和识别会是误报较多的场景有时候扫描工具不支持识别该净化函数有时候是对漏洞理解不足导致净化函数使用不正确。安全团队在实施时也会考虑提供净化函数提供给业务接入以简单高效解决问题最后在修复阶段需要复查是否是完善的修复方案能否被绕过、净化函数的覆盖率。最后是触发阶段审计时执行测试用例希冀被危险函数触发执行。所以这是一种基于数据传递流程进行的一次检查。

了解到上面的普遍性技术就清楚整个检测技术的要点文章介绍了php的检测思路具体可以看看cobra的代码实现。其实对于java各自框架和反射机制、nodejs灵活的框架和写法非商业工具还是会遇到各项困难有时候直接用正则匹配未必不是一个捷径反正都是基于规则进行检测的只要保证低误报率即可。

三、企业级研发与部署方案

企业级实际场景和挑战

商业扫描基于license的情况一般是不直接安装于rd的个人机基于ide也需要在本机安装扫描软件找八哥、checkmars基于云、coverity、foritify、cobot笨重以至于华为公司需要安排专职人员负责持续集成来搭建环境进行代码编译扫描后再上传到商业安全工具平台导出结果。而结果直接交给业务线并不能统计和保证效果最后出现安全问题还是被认为没有将安全能力赋予业务。哪怕提供了详细的报告报告的可读性、整改实际情况都是一项挑战。

安全人员顺其自然想到做一个平台支持推广、自动化功能和接入实现系统工程化的集中管控任务序列处理、工单联动最后出具图表通知和提供api进行对外输出。

软件上线前必须通过安全扫描隐含的前提是需要明确卡位哪些是新业务对于迭代任务是否需要接入将安全作为一个环节融入在软件研发的持续集成活动中。

安全红线在于指标在确定扫描规则的准确性的情况下可以对不安全的组件、严重、高危漏洞进行阻断发布。

整体架构

架构方面大都类似扫描接口获取到任务上线列表、复查请求、手动创建任务、创建策略依据优先级指定扫描规则下发至CI进行编译异步检测是否成功、推送扫描结果ci带动扫描引擎将商业安全工具和自研的规则跑起来引擎管理层收集结果入库或本地生成报告。在源代码管理层配置各项账户拉取代码由于部分语言的代码扫描时需要编译需要将代码保存在机器上。痛点是数据量大存在同企业发布平台拉取的代码重复的情况这里建议将代码做索引以便搜索和查询。比对汽车之家的源码平台建设可以看到百度在任务管理、增量存储方面做得更为先进。

SDL中实践

由于将安全扫描作为发布的必须环节实际上将业务的编译阶段相当于重复了一次必须保证扫描结果较快基于解释性语言的话扫描会慢得多。这里的增量策略的必要性在于某些扫描引擎不支持增量扫描所以开发匹配识别增量文件扩展拉取引用的函数和代码文件补全语义分析或者控制流分析流程。好处是这里可以清晰地获取到数据的调用流转过程程序自动对此生成调用关系链图帮助业务在修复时快速了解漏洞的前因后果减少人工答疑时间。

无变更文件不进行扫描的特殊场景是账户密码文件等不经常变更需要对此进行甄别识别配置文件明文密码的情况。

企业内部凌晨反而经常是资源紧张的时候可以单独跑序列对扫描失败的任务、漏洞已经修复待检验的代码在周末进行复扫自动关闭工单。