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

上一篇文章《代码自动化扫描系统的建设(上)》 主要介绍了自动扫描系统的背景和要实现的目标，这篇里我们将会详细介绍各个层与模块的设计。
一、系统设计
1.1 基础与准备
这里我们主要使用 Linux 来搭建我们的自动化扫描系统，按照设计的角色划分，我们这里需要三台 CentOS 7 的服务器，当然服务器可以是物理设备也可以是虚拟机，如果公司内部的扫描项目较多或为以后扩展考虑意见使用物理机。
服务器数量
操作系统
扫描引擎
数据库
开发语言
角色
3台
CentOS 7
SonarQube
MySQL
Python
UI+MySQL+MQ 扫描节点 第三方引擎(SonarQube)
服务器划分:
这里我们假定一个 codeaudit 域, 三台服务器的主机名称分别为：
(1). ui.codeaudit: 负责后台管理系统的部署，包括数据库、MQ。
(2). task.codeaudit: 负责调度扫描引擎。
(3). sonarqube.codeauit: SonarQube的后台服务端。
1.2 技术说明
这里会讨论到所需的具体技术点，有些技术或方法可能不是最佳的方案，但是已经过我们测试检验是可行的。
以下为实际开发中用到的一些技能：
(1). Python/Django/Jquery/Celery
(2). Gitlab API/Sonar API
(3). Git/Gitlab CI/Jenkins
(4). Centos 7/Shell
(5). NFS/Nginx/uWSGI
(6). MySQL/RabbitMQ/Redis
(7). 安全漏洞知识
CentOS 7
CentOS 7 与 6 的版本会有一些区别，我们需要具有 Linux 的基本操作基础，了解 systemctl、firewall-cmd、crontab等命令；了解SELinux，修改SELinux状态；并能编写systemd的自启动脚本。
Git
了解 Git 的基本操作命令，使用 SSH 密钥的方式提交或拉取代码; 熟悉git clone、git log、git pull、git branch、git remote、git fetch、git for-each-ref、git ls-files等基本命令的操作。
例如：
使用git for-each-ref来得到当前分支的最后一次 commit id；
使用git ls-files来判断项目中是否存在sonar-project.properties配置文件；
使用git log -n1 /path/file来获取文件最后一次 commit 的作者。
CI/CD
不论是集成到 Gitlab CI 或是Jenkins, 我们都需要先了解项目上线的基本流程，如：开发的代码规范、测试环节（单元测试/功能测试）、发布部署环节等。一般我们会将代码扫描环节放在在测试环节后，发布部署前。
Python
这里我们使用Python进行后台的服务端开发，使用Django进行前台 UI 的开发，使用django-rest-swagger来开发 API 接口，使用Celery作为扫描任务的调度框架。
数据库与中间件
数据库我们选择使用 MySQL 5.7(或MariaDB, 他们在使用上没有太大的区别); Celery 的消息中间件可以使用 Redis 或是 RabbitMQ，这里你可以在开发的时候使用 Redis，正式部署时使用 RabbitMQ。
安全漏洞知识
(1). 了解 OWASP TOP 10 的漏洞类型原理与解决方案；
(2). 了解 CWE 的漏洞信息；
(3). 了解公司主流的开发语言。
1.3 模块设计
下图中我们自上而下按照逻辑大致划分了”四”层：UI层、存储层、服务层、任务调度扫描引擎层（由于任务调度与服务同在后台运行，所以又统称为服务层）。

1.3.1 UI 层
提供扫描系统的后台管理、API接口、漏洞知识库等一系列的交互功能入口，不同的人员或系统可以根据各自的需求通过不同的交互接口来满足自己需求。如：CI/CD系统可通过 API 接口创建扫描任务并获取扫描结果；安全审计人员可通过后台进行规则或插件的添加；开发人员可通过漏洞知识库来获取相关语言或技术的漏洞信息。
1.3.2 存储层
主要包括关系型数据库、消息中间件(指MQ)、NFS(网络文件系统)，这里我们使用了 MySQL 5.7 的数据库； RabbitMQ 是作为 Celery 调度框架的消息中间件；NFS担当网络共享存储，用于存储代码与扫描日志。
1.3.3 调度层
扫描任务的执行流程，主要可分为：
(1). 初始化：扫描任务的环境初始化，如：日志目录、日志文件、加载插件、加载漏洞规则等；
(2). 分析项目：项目代码统计、依赖组件统计、漏洞知识库关联等；
(3). 扫描漏洞：调用第三方扫描引擎、统计扫描结果；
(4). 漏报处理：使用黑名单规则和插件进行扫描；
(5). 误报处理：使用白名单规则和插件进行误报处理；
(6). 闭环漏洞：针对高危漏洞在 GitLab 或 Jira 系统中创建一个 Issue。
1.3.4 服务层
后台的服务，其主要包括：GitLab 系统中的项目同步、报表生成、调度进程监控。
二、系统功能
2.1 数据库设计
2.1.1 权限相关
权限控制，这里使用 django 自带的权限表来进行权限控制，我们可以通过auth_group表来创建用户组，为不同的用户组赋予不同的角色权限auth_group_permissions，你可以访问官方地址：https://docs.djangoproject.com/en/2.1/topics/auth/default/#topic-authorization来获得更多关于权限的信息。
django 权限表如下：
auth_group
auth_group_permissions
auth_permission
auth_user
auth_user_groups
auth_user_user_permissions

2.1.2 项目相关
项目表主要包括：项目组、项目、分支与TAG、统计信息、依赖组件、插件规则、扫描任务等相关表。

2.1.3 漏洞知识库
漏洞知识库，这里主要存储漏洞类型、漏洞知识等内容。

[1] [2] [3] [4]  下一页

上一篇文章《代码自动化扫描系统的建设(上)》 主要介绍了自动扫描系统的背景和要实现的目标，这篇里我们将会详细介绍各个层与模块的设计。
一、系统设计
1.1 基础与准备
这里我们主要使用 Linux 来搭建我们的自动化扫描系统，按照设计的角色划分，我们这里需要三台 CentOS 7 的服务器，当然服务器可以是物理设备也可以是虚拟机，如果公司内部的扫描项目较多或为以后扩展考虑意见使用物理机。
服务器数量
操作系统
扫描引擎
数据库
开发语言
角色
3台
CentOS 7
SonarQube
MySQL
Python
UI+MySQL+MQ 扫描节点 第三方引擎(SonarQube)
服务器划分:
这里我们假定一个 codeaudit 域, 三台服务器的主机名称分别为：
(1). ui.codeaudit: 负责后台管理系统的部署，包括数据库、MQ。
(2). task.codeaudit: 负责调度扫描引擎。
(3). sonarqube.codeauit: SonarQube的后台服务端。
1.2 技术说明
这里会讨论到所需的具体技术点，有些技术或方法可能不是最佳的方案，但是已经过我们测试检验是可行的。 copyright 无奈人生
以下为实际开发中用到的一些技能：
(1). Python/Django/Jquery/Celery
(2). Gitlab API/Sonar API
(3). Git/Gitlab CI/Jenkins
(4). Centos 7/Shell
(5). NFS/Nginx/uWSGI
(6). MySQL/RabbitMQ/Redis
(7). 安全漏洞知识
CentOS 7
CentOS 7 与 6 的版本会有一些区别，我们需要具有 Linux 的基本操作基础，了解 systemctl、firewall-cmd、crontab等命令；了解SELinux，修改SELinux状态；并能编写systemd的自启动脚本。
Git
了解 Git 的基本操作命令，使用 SSH 密钥的方式提交或拉取代码; 熟悉git clone、git log、git pull、git branch、git remote、git fetch、git for-each-ref、git ls-files等基本命令的操作。
例如：
使用git for-each-ref来得到当前分支的最后一次 commit id；
使用git ls-files来判断项目中是否存在sonar-project.properties配置文件；
使用git log -n1 /path/file来获取文件最后一次 commit 的作者。
CI/CD
不论是集成到 Gitlab CI 或是Jenkins, 我们都需要先了解项目上线的基本流程，如：开发的代码规范、测试环节（单元测试/功能测试）、发布部署环节等。一般我们会将代码扫描环节放在在测试环节后，发布部署前。

Python
这里我们使用Python进行后台的服务端开发，使用Django进行前台 UI 的开发，使用django-rest-swagger来开发 API 接口，使用Celery作为扫描任务的调度框架。
数据库与中间件
数据库我们选择使用 MySQL 5.7(或MariaDB, 他们在使用上没有太大的区别); Celery 的消息中间件可以使用 Redis 或是 RabbitMQ，这里你可以在开发的时候使用 Redis，正式部署时使用 RabbitMQ。
安全漏洞知识
(1). 了解 OWASP TOP 10 的漏洞类型原理与解决方案；
(2). 了解 CWE 的漏洞信息；
(3). 了解公司主流的开发语言。
1.3 模块设计
下图中我们自上而下按照逻辑大致划分了”四”层：UI层、存储层、服务层、任务调度扫描引擎层（由于任务调度与服务同在后台运行，所以又统称为服务层）。

1.3.1 UI 层
提供扫描系统的后台管理、API接口、漏洞知识库等一系列的交互功能入口，不同的人员或系统可以根据各自的需求通过不同的交互接口来满足自己需求。如：CI/CD系统可通过 API 接口创建扫描任务并获取扫描结果；安全审计人员可通过后台进行规则或插件的添加；开发人员可通过漏洞知识库来获取相关语言或技术的漏洞信息。

copyright 无奈人生

1.3.2 存储层
主要包括关系型数据库、消息中间件(指MQ)、NFS(网络文件系统)，这里我们使用了 MySQL 5.7 的数据库； RabbitMQ 是作为 Celery 调度框架的消息中间件；NFS担当网络共享存储，用于存储代码与扫描日志。
1.3.3 调度层
扫描任务的执行流程，主要可分为：
(1). 初始化：扫描任务的环境初始化，如：日志目录、日志文件、加载插件、加载漏洞规则等；
(2). 分析项目：项目代码统计、依赖组件统计、漏洞知识库关联等；
(3). 扫描漏洞：调用第三方扫描引擎、统计扫描结果；
(4). 漏报处理：使用黑名单规则和插件进行扫描；
(5). 误报处理：使用白名单规则和插件进行误报处理；
(6). 闭环漏洞：针对高危漏洞在 GitLab 或 Jira 系统中创建一个 Issue。
1.3.4 服务层
后台的服务，其主要包括：GitLab 系统中的项目同步、报表生成、调度进程监控。
二、系统功能
2.1 数据库设计
2.1.1 权限相关
权限控制，这里使用 django 自带的权限表来进行权限控制，我们可以通过auth_group表来创建用户组，为不同的用户组赋予不同的角色权限auth_group_permissions，你可以访问官方地址：https://docs.djangoproject.com/en/2.1/topics/auth/default/#topic-authorization来获得更多关于权限的信息。 内容来自无奈安全网
django 权限表如下：
auth_group
auth_group_permissions
auth_permission
auth_user
auth_user_groups
auth_user_user_permissions

2.1.2 项目相关
项目表主要包括：项目组、项目、分支与TAG、统计信息、依赖组件、插件规则、扫描任务等相关表。

2.1.3 漏洞知识库
漏洞知识库，这里主要存储漏洞类型、漏洞知识等内容。
内容来自无奈安全网

[1] [2] [3] [4]  下一页

www.wnhack.com

。 (责任编辑：admin)