一、自动安检的需求背景
需求
公司如果有不同的业务线，各业务系统上线发布之前要进行基本的安全检查。业务在国内的其它城市，机房位置不定，发布时间不定，这时候就需要设计一套自动化机制，在业务上线新功能之前，进行自动安全扫描与代码审计。自助自动是在传统方式上的一种改变，是对即存安检查系统的重新组合使用。传统的扫描和代码审计有历史课题。 对于粗放型的安全扫描任务实施，可能会对业务造成伤害，比如Payload脏数据让业务方服务挂掉，为了避免此类情况发生，需要将扫描的粒度细分的更精准，可以定位到新机能具体接口入口位置，再进行扫描和代码审计。
下图是整个自助安检设计的体系图：
历史课题
1.安全扫描：一般安全扫描实施会有一个扫描列表，并且配有白名单和不可扫主机，如果被扫业务代码不够强壮， 一旦扫描payload被业务认为是无效的脏数据，服务会受影响。解决此问题，如上所述，需要定制化扫描，针对新业务上线，老业务回归扫描检查，进行细化到接口级的扫描，不是一个域名一把梭。
2.代码审计：代码审计误报率， 审计程序和策略都是人来写的，存在误报场景。但自动化安检处理可以突出重点误报率低的问题， 对代码审计特别擅长的漏洞，给于突出的展示空间，抓主要问题，核心威胁。 当业务方触发自动安全检查流程时，让代码审计与安全扫描强强联合，针对那些不能轻易通过扫描被发现的漏洞，或是非常耗时，依赖设计各种复杂Payload扫描发现漏洞的场景，让扫描和审计协同来完成，比如：挂马问题，代码审计可直接扫描代码发现问题，再联合扫描执行进行多重威胁确认。
二、子系统划分与功能互动
多业务线可复用一个安全请求接口，业务推送各自的安全检查需求，无论你在上海、北京还是其它的地方。对于业务方来说，他们不用关心安检系统的实现细节。但从安全开发者的角度，我们要清楚系统的构成， 系统是如何把安全检查请求，分发给我们各种子系统去执行，并优先返回那些必要的安检结果反馈。区别于第一个图， 我们通过纵向展开的方式，用一张图表现子系统如何通过暴漏接口与业务互动。大体流程如图，由业务方提交安检请求给接口，由网关将接口转发给安全检查处理逻辑进行安检任务的分发，将代码相关信息，PUSH给代码审计系统。将上线环境的相关的信息，PUSH给扫描系统。扫描系统是可以插件化的， 通地不同类别的插件装配，进行定制类扫描。代码审计系统可以进行复合审计，调用多种代码审计引擎进行代码审计，比对审计确认结果，找出共通问题。
为了结合实际情况，我们特别突出了安全扫描中SQL注入和WEB扫描在图上的位置，将通用CVE计与挂马检查作为代码检查的重点。一般情况，检查项目越多，误报同比会变高，如果不想被误报威胁信息淹没，前期我们可以集中处理高危的威胁，等系统问题，针对各种误报针对性解决。
三、接口设计
如图所示，接口设计我们采用了REST接口设计，业务在发布系统侧，通过发布系统客户端，发送POST数据请求给网关的REST接口服务，提交安检所要的基本必要的信息，测试的主题是谁，测试的是什么。我们给出接口字段设计，可以基本满足检查子系统的输入需要， 当接口调用时，会添上对应的测试机，后期会直接集中到发布系统里进行自动发布调用。
字段说明：
域名(domain)： 域名，具体业务那个域名下的服务更新发布了。
文件(file)：文件，新发布功能的文件名。
路由(index)：路由，发布文件发布的具体接口。
接口参数(params): 路由对应实参数。对SQL注入这种类别的检查， 有了参数才检查更有针对性。
代码地址(git address)：上线业务代码git服务器地址，方便代码审计系统去下载代码。
邮件地址(mail)：接受安全检查报告的邮箱。
接口是基本的JSON REST，具体落地实现可以采取多种语言实现方案。
四、安检流程
我们抽出一个业务处理逻辑，进行强化说明， 当业务发起安检提交请求后，如何具体触发子系统做了那些居体工作。数据接口设计完之后系统的输入已经明确，接口驱动系统工作的顺序，如下图。
1.代码拉取：取得git address字段的地址，分发调用代码审计服务，去具体的git中下载项目代码。其实可以单独通过一个字段让源码推送给的安查系统，但这样有加密成本，并且没有代码下载历史版本管理，如果出现问题，无法溯源代码操作责任人。
2.代码审计：对拉取源码进行审计。 更新的码与工程中其它代码是有依赖关系的话，如果时间允许，可审计相关文件模块，甚至整体项目代码。
3.审计报告：作成代码审计报告，安检请求同步发出， 但报告可异步发回。
4. 路由解析：代码审计系统取得代码后，对源代码进行词法语法分析，再做路由检查处理，取得具体路由的params参数。一般情况，路由的对应的参数是需要人工添加的，但对一些找不到第一开发者的项目，采用自动匹配的方式收集对应参数，这种情况需要特别处理。
5.接口扫描：对已取得的域名、路由、参数的接口进行针对性的WEB安全性检查，扫描的模块往往都是有很多种的，对同一接口，可采用多种扫描工具进行扫描，sqlmap、nmap、WVS、nessus等。如果想收集更多的信息，可采用代理方式进行扫描，在代理服务器上，可以收集更多信息。
6.扫描报告：输出扫描检查报告。 扫描的结果可入库，通过库内容对比，进行接口威胁状态跟踪。
五、子系统与实现技术栈
自助安检需多统协同：
1.发布系统客户端服务：嵌入到业务发布上线系统中的，安全检查请求客户端。可以是表单，也可是后端批处理程序。
2.网关服务：网关一般是请求的分发与重定向，简单是直接用Openresty写，复杂的可以使用Kong，活是orange这种网关产品。
3.接口服务：具体实现REST接口的后端程序，也是安查任务调度系统。
4.扫描系统：接受调度，进行安全检查，返回扫描报告。
5.代码审计系统：接受调度，进行代码审计，返回扫描报告。
6.存储系统：保存安全检查请求历史数据，跟踪检测结果。
通过安全开发实践摸索，我们总结出安全开发三件宝：网关、数据库、RPC。
1.网关服务：网关应用作为后端应用的入口，负责转发与授权等基本工作内容，网关本身也是代理。网关是抽离业务抽象出来与7层操作直接相关的公通模块，将公通的功能，从业务中独立出来，降低业务代码维护成本， 网关代码还可重用。
关于中间件推荐， 一般情况推荐给读者商业产品， 读者及单位不一定买，发出来还有广告嫌疑。推荐闭源产品， 代码不开放有版权也不能直接给您， 所有最后推荐开源产品原型，但又可能被说都是用开源堆砌系统。
推荐几款开源的网关：
OpenResty: Openresty在Nginx的基础上丰富了很多功能，构建网关OR是不错的选择。
Kong: kong本身也是基于Openresty技术， 现在很多大的公司在用。
Orange：同样基于Openresty的一个纯开源的网关产品，内嵌基础WAF功能。
假设读者手里有SAE的云豆，可以体验云版的Orange，一键部署，方便测试，想要测试码朋友，可以看文章最后的二维码联系方式联系免费提供。 软件是开源的，服务是免费，要有云豆。
2.数据库：数据存储是最基础的服务，现在都支持接口化服务，我们通过网关将数据库存储通过接口封装隐藏起来，使用者不用关心具体实现的技术差异。 对于调用都来说， 数据是存ES还是其它地方不重要， 只要性能达标没有瓶颈不关注低层实现。在我们的场景下，ES存一般性数据，Clickhouse存实时性高的数据，RabbitMQ和kafka进行数据缓存，Redis存共享数据。
如果有什么值得特别提的，那就是Clickhouse可以支持Mysql协议， 操作CK与操作Mysql体验接近一些，用操作Mysql的动作，实际确是在用强大的ClickHouse做处理数据， CK属于开源产品。 关于ES与Clickhouse之间的数据迁移，有一篇文章可供参考：《Clickhouse与威胁日志分析》，是在Freebuf上发布过的。还有一篇 《ELK大数据与威胁日志的数据迁徙方法》，让Clickhouse与ES共生，提供安全分析服务。
3.RPC服务：如果REST是给前端提供的后端服务， 那RPC就是给后端服务提供服务的后端服务。把业务不想关的公通功能RPC化Docker部署，业务相关的DSL配置描述化部署，简化业务系统的复杂性和不必要的耦合。无论使用什么语言实现rpc服务，对调用方来说是黑盒，只要遵循协议要求。
大家用的RPC技术Google的产品占一定比例，但其实像Django这种框架也支持RPC技术，Django RPC，这个版本在Django 1.5时代已存在。
六、总结
梳理了自助接口扫描与代码审计系统架构，描述了各个子系统间的协调互动与具体技术栈。对有类似应用场景的单位，通过类似机制实现自动安检只待时日，使用开源、商业、自研技术，可就地取材。这篇抛砖引玉，一些挑战的课题还在等待我们解决， 比如路由参数的自动识别，代理扫描工具的实现方案，代码审计如何开放调度接口等。
声明：本文来自新浪安全中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
