freeBuf
主站

分类

云安全 AI安全 开发安全 终端安全 数据安全 Web安全 基础安全 企业安全 关基安全 移动安全 系统安全 其他安全

特色

热点 工具 漏洞 人物志 活动 安全招聘 攻防演练 政策法规

点我创作

试试在FreeBuf发布您的第一篇文章 让安全圈留下您的足迹
我知道了

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

代码自动化扫描系统的建设(上)
FreeBuf_13920 2018-09-21 14:30:13 580274

代码审计一直是企业白盒测试的重要一环,面对市场上众多商业与开源的审计工具,你是否想过集众家之所长来搭建一套自动化的扫描系统呢?也许这篇文章会给你一些思路:)

一、背景

1. 为什么需要自动化扫描?

互联网的快速发展,程序员是功不可没的。从软件开发的瀑布模型到现在的敏捷开发, 软件的开发周期从数年到数月、从数月到数天,时间不断变换缩减。传统的代码扫描方式已经不能跟进新时代的软件开发流程中,这就需要改变我们的代码扫描方式,它应该在有限的时间内尽量发现足够多的安全问题,并能够结合 CI (持续集成) 来触发代码扫描。

2. 自动化扫描时扫描引擎用什么?

你可以使用任何提供 API 接口的开源或商业的扫描引擎。这里我们把扫描引擎(指第三方的审计工具)与自动化系统剥离(解耦)开来,扫描引擎只负责安全漏洞扫描;自动化系统负责漏洞收集、分析、处理等动作。同时你也可以通过自动化系统的后台来添加一些安全规则。

3. 怎么触发自动化扫描?

两种方式:

 管理后台手动触发

 CI(持续集成)/CD(持续交付) 系统中触发

4. 如何解决漏报和误报?

两种方式:基于规则基于插件,这里使用白名单表示误报、使用黑名单表示漏报。

基于规则

这里的规则是指基于文本的处理方式,如:使用正则表达式来匹配文件中的某些特征,使用字符串来判断是否存在敏感信息等。

PS: 这里有一些细节需要注意。

a. 正则表达式:

是否区分大小写

是否支持多行匹配

b. 字符串:

是否首部包含

是否尾部包含

是否在当前字符串中

基于插件

插件的自由度较大,其本质是把要扫描的文件信息作为插件执行入口的上下文,文件信息包括:路径、名称、内容等。你也可以在插件中写一些判断逻辑或调用第三方工具。

5. 漏报率和误报率怎么样?

漏报率暂时无法很好的测量, 漏报率 = 漏报数/(漏洞数+漏报数) × 100% 而实际中很少有人(这里指非安全审计人员)会发现漏报,理论上你写的规则或插件越多越会减少漏报。

误报是可以通过白名单规则或插件处理的,理论上可以百分百消除误报,但是需要手动进行设置。

6. Web 通用型漏洞可以都覆盖么?

Web 通用型漏洞以 OWASP 2017 TOP 10 为例,其大多数都在黑盒测试的范围内。适用白盒测试仅限于:A3:2017-Sensitive Data ExposureA9:2017-Using Components with Known Vulnerabilities,而这两项也是我们自动化扫描系统的基本要求。

7. 扫描出来的漏洞如何形成闭合?

这需要结合公司自身的软件开发方式而定,大多数公司采用Gitlab + Confluence + Jira + Jenkins的工作方式,那么我们可以通过 Jira 或 Gitlab 的 API 接口来创建问题工单。

二、设计要求

1. 目标

系统功能:

尽量发现足够多的安全问题

 硬编码问题

 敏感信息泄露

 使用存在已知漏洞的组件

 危险函数识别

可集成第三方扫描引擎

可自动化处理误报

可通过 CI 方式触发扫描

可根据条件自动创建 Issue

扫描目标主要分为两种:一种为线上 Git 扫描;一种为离线扫描。线上 Git 扫描其主要应用场景为企业内部使用如 Gitlab 这种代码托管系统,我们定时同步 Gitlab 上的项目信息,通过 CI 来调用 API 接口进行扫描,自动化扫描就是这种模式,其执行流程为:“后台服务定时同步项目” -> "API接口下发扫描任务" -> “后台调度执行扫描”。离线扫描其形式为审计人员手动上传一个 zip 或 rar 的源码包,扫描系统自动解压后进行代码扫描。

这两种模式的执行流程略有不同,所以后端实现也略有不同,第一种的执行流程要比第二种较为复杂,我们这里会以第一种方式来实现自动化扫描。

2. 要求

系统要求:

 单个项目扫描控制在 20 分钟以内

 支持调度节点监控

 支持漏洞知识库管理

 支持 API 接口

 支持分布式部署, 方便扩展来提升扫描能力

时间控制是为了保证 CI/CD 过程不会太长,避免影响项目发布。调度节点监控,这里存在两种情况:一种是调度进程的心跳监控;一种为扫描任务的超时监控。漏洞知识库主要为了与组件分析模块分析出的依赖组件进行漏洞匹配。API 接口是为了方便第三方(代指CI/CD)调用来下发扫描任务或查询结果。分布式部署方式,可以水平扩展来提高调度节点和API节点的处理速度与能力。

3. 模块设计

主要系统:

 代码托管子系统

 自动化扫描子系统

 第三方扫描子引擎

这里从整体角度来观察,大致分为三个子系统,自动化扫描子系统依赖代码托管子系统,但不依赖扫描引擎(泛指第三方商业或开源审计产品)子系统,这是由于自动化扫描子系统内部集成了组件漏洞识别、黑白名单规则、黑白名单插件等功能,最后我们用一张图来说明。


代码自动化扫描系统的建设

三、总结

代码扫描固然重要,但是它不会解决所有项目的安全问题。项目安全应该从多个维度、多角度的来进行。如:项目立项时开始SDL;开发迭代过程中的代码扫描;项目上线前的黑盒测试。

参考链接

CI (持续集成)

CD (持续交付)

OWASP 2017 TOP 10

*本文作者:MyKings,转载请注明来自 FreeBuf.COM

# 代码审计 # 代码自动化扫描
免责声明
1.一般免责声明:本文所提供的技术信息仅供参考,不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》,作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。
2. 适用性声明:文中技术内容可能不适用于所有情况或系统,在实际应用前请充分测试和评估。若因使用不当造成的任何问题,相关方不承担责任。
3. 更新声明:技术发展迅速,文章内容可能存在滞后性。读者需自行判断信息的时效性,因依据过时内容产生的后果,作者及发布平台不承担责任。
本文为 FreeBuf_13920 独立观点,未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
FreeBuf_13920 LV.3
这家伙太懒了,还未填写个人描述!
  • 2 文章数
  • 4 关注者
代码自动化扫描系统的建设(下)
2018-09-30
一款轻量级Web漏洞教学演示系统(DSVW)
2017-02-16
浅析ReDoS的原理与实践
2017-01-05
文章目录