POC需求报告代码审计.docx

POC需求报告代码审计.docx

《POC需求报告代码审计.docx》由会员分享，可在线阅读，更多相关《POC需求报告代码审计.docx（10页珍藏版）》请在冰豆网上搜索。

POC需求报告代码审计

XXX有限公司信息部

“数据中心安全平台建设--代码审计系统项目”需求报告

首次发布：

2017-1-19

最后修订：

1/19/2017

1.文档说明2

1.1.编写目的2

1.2.预期读者2

1.3.术语与缩写解释2

2.

错误!

未定义书签。

错误!

未定义书签。

使用范围

3.需求调研报告

4.需求汇总

1.文档说明

1.1.编写目的

本文档是中心安全平台建设--代码审计系统项目的需求调研报告，文中详尽说明了业务部门提出的项

目需求。

本文档是项目组进行需求分析的依据，也是明确项目目标和项目范围，进行系统设计的基础。

1.2.预期读者

项目组成员、项目经理、评审组，用来对项目组所调

本文档的预期读者为源代码审计项目的业务部门、

研的业务需求进行审核确认并达成共识。

1.3.术语与缩写解释

1项目总体需求

本项目作为局方2017~2018安全能力建设项目《XX公司信息安全风险管理研究》的组成之一，旨在建设代码审计系统，通过检查源代码中的缺点和错误信息，分析并找到安全漏洞，提供代码修订措施和建议，从而在系统开发阶段/运维阶段

进行深入的问题查找和消灭，融合安全开发生命周期的管理流程，逐步推进XX中

心安全生命周期及安全开发规范的落地实现。

2代码安全审计引擎建设需求

1、参与本项目的代码审计系统产品须具有国家版权局颁发的软件著作权登记

需求描述

证书，且须满足以下两点中至少一点：

1）入围Gartner<2015MagicQuadrantforApplicationSecurityTesting>

的产品；

2）经XXX我公司本地POC验证，检测能力、误报率、产品性能等指标不低于

Gartner<2015MagicQuadrantforApplicationSecurityTesting>入

围产产品的其他国产产品，并须由供应商证明产品的核心技术、整体软件国产化，属于自主可控国产产品。

2、代码审计工具（引擎）技术与功能要求：

1）支持对JAVAJSP，C，C++，PHPASP,C#，JavaScript，VBScript，

Python,HTML,XML等十几开发语言的安全漏洞的检查，能够检测出约1000

种漏洞。

并将所有安全漏洞系统地整理并依据漏洞的表现形式，形成原因和

危害程序进行科学地分类，共分为“输入验证、API误用、质量性能、异常处理、代码规范、安全控制、环境配置、信息封装”、“国内特色”9个大类，然后根据开发语言的不同，在结合国际漏洞标准组织CWE的漏洞知识库进

行细分和命名，目前约1000个子类。

2）该检测系统的云服务支持在Windows和Liunx两种系统平台上部署。

其分

析引擎可以通过分布式的部署方式可以将不同开发平台，如Windows，

Linux，Unix,MacOS上不同语言的开发项目进行统计测试。

3）检测引擎可支持多个项目并发扫描。

检测引擎应能够分布式部署，可在多台

机器（或虚拟机器）上集群式部署检测引擎来扩展并发测试能力。

女口：

检测

引擎部署在10测试机上，支持20个测试项目同时检查。

支持页面对集群机器的集中维护和启停。

4）须涵盖CVECWEOWASPTop10WAS（四种安全标准中至少两种标准。

在

上述标准的基础上实现支持检测缓冲区溢出、代码注入、跨站脚本、输入验

证、API误用、密码管理、配置错误、危险函数等缺陷检测。

支持对数据流、语义、控制流、配置、代码结果等多维角度进行分析，具备较高的检测能力

并具备较低的误报水平。

5）为用户提供企业级的安全测试管理功能，用户可以通过WEB的方式进行项

目管理，安全测试，结果查看，协同审计，出具报表等多项工作。

6）支持漏洞代码关联分析与定位，能够迅速定位某一特定安全问题所在的源

代码行，对问题产生的整个过程进行跟踪，展示漏洞产生的全过程。

提供漏

洞详细的描述及解决方案，方便分析和修复。

7）支持对问题处理的每一个动作进行记录，并须支持漏洞的查询过滤，能与之

前审计结果进行合并，减少工作量。

8）源代码安全检测无缝集成于开发测试流程，提供API并完成与用户邮件系

统、软件研发中心SVNGit版本管理工具的集成联动，代码审计工具可从代码版本管理系统中自动复制获取提交更新的独立版本源代码（可按照需

求配置需同步的版本节点，且不影响版本管理工具中存储的任何文件），代

码审计工具自动发起扫描任务进行代码审计检测，实现代码自动上传、代码

安全扫描、自动分析、邮件通知、安全漏洞缺陷导入、跟踪和统计分析等任务自动化。

9）代码审计分析与处理过程在服务端进行，对用户本地计算资源无占用。

服务

端具备高效的审计分析能力，支持百万行级的代码项目审计，且平均速度不

低于1万行/分钟。

对于多任务并发须支持任务的集中统一管理，并能够对多任务自动进行批量处理。

10）支持检测代码中是否引用的开源代码模块，并检测开源模块中是否存在安

全漏洞，最大程度降低开源代码引入的安全风险（加分项）。

11）支持与漏洞扫描工具集成联动，对扫描工具检测到的问题，根据程序的流程

记录漏洞产生的程序的执行过程，定位到对应的源代码（加分项）。

12）具备漏洞问题自动划分优先级，按照问题的严重性和可能性进行威胁级别的划分，如危险、高、中、低等多个级别，须集成完善的漏洞分级标准和定义库，支持对源代码安全缺陷扫描结果进行分类分级汇总。

13）能够支持通过浏览器方式远程查看和审计测试结果，查看漏洞点及产生过

程信息。

能支持安全问题的查询和过滤功能，方便审计人员针对某一特定条

件进行精准查询，对满足条件的漏洞进行统一审计和标注。

14）能够支持对项目的两次测试结果的比较报告，并罗列审计状态的比较和计

算出漏洞修复率。

15）用户能够根据企业自身需要来调整和修改问题的默认分级策略，

方便审计。

如：

用户可以自定义漏洞的级别，添加TOP10级别。

16）支持输出包括HTMLPDFEXCEL等多种格式的检测报告，报告内容可对缺

陷等级、缺陷类型、修复建议、跟踪路径根据需求进行配置。

缺陷报告应可依据不用的用户角色生成管理人员报告与开发人员报告。

管理人员报告主要包括缺陷等级及缺陷类型等基本统计信息，开发人员报告除了包括缺陷等级及缺陷类型等基本统计信息外，还应包括缺陷分类、缺陷描述、修复建

议、风险点、缺陷跟踪信息等详细信息。

17）该测试系统提供知识分享平台，用户可以方便查看、学习各个开发

语言的安全漏洞知识，提高安全开发水平。

同时支持用户对漏洞知识进行自定义，添加或补充用户自身总结的安全漏洞经验。

18）该测试系统提供对项目结果进行评分功能，用户可以根据项目的重要性，漏

洞的级别，漏洞审计的结果等因素对评分进行权重设计，自定义各项评分因

子，并根据用户自定义产生评分评级报告。

19）该测试系统提供测试的标准或基线管理功能，方便用户将企业的安全测试标准、基线进行发布和推广。

3、漏洞管理功能与技术要求：

1）管理功能实现对代码审计工具（引擎）的使用调度与管理，须为基于企业云

部署方式，集群式架构，可分布式处理多用户、多任务的测试需求。

支持无限扩展并发测试任务数，测试性能强大，稳定。

能够实现扫描任务发起、漏

洞通告、跟踪和统计分析等任务的自动化，实现XX公司安全生命周期的落

地。

2）该测试系统的用户角色应分为系统管理员，管理员，安全审计员，安全测试

员，漏洞查看员五个不同有角色，方便用户根据项目测试的实际情况组合使

用。

3）支持日志功能，每次扫描均须日志记录，记录内容包括但不仅限于：

扫描的对象、扫描开始时间、完成时间、发起人员、扫描结果情况等。

4）支持展示每一个源代码缺陷分析任务的相关信息，信息应包括任务名称、开

发语言、发起时间、完成时间、检测状态、缺陷总数、等级分布以及创建者信息。

5）支持展示每一个源代码缺陷分析任务所检测的对象（文件列表）、测试过程

的分析引擎日志，方便用户查看是否存在测试不完整或测试不正确的情况。

6）该测试系统应能够提供测试的计费管理功能。

可以对用户账号充费，可以设

置充值金额，同时也可以对单次测试的收费额度进行设置。

7）支持根据多种条件对源代码缺陷分析任务进行查询。

8）支持对测试任务的相关情况进行报表统计与管理，查询与生成报表的条件

包括但不仅限于：

测试时间，部门、项目级、开发语言、测试人员等，统计

的结果包括但不限于：

测试状态、测试的漏洞总数、严重漏洞数等内容。

并以报表形式导出。

3其他需求

1、供应商须为原厂或须具备原厂授权的总代理或行业金牌代理资质。

2、供应商需提供至少一年的维保服务，服务期内免费提供代码审计系统版本、

检测规则、管理平台的升级与相关维保服务。

2.需求汇总

提示：

经过多次调研将最终确定的需求分类汇总于此表。

编号

需求项

具体描述

需求等

级

需求来源

是否可

实现

备注

1.功能需求

1.1

代码安全审计引

擎建设需求

必须

是

1.2

1.3

1.4

2.性能需求

2.1

2.2

2.3

2.4

3.安全需求

3.1

3.2

3.3

3.4

4.管理需求

4.1

漏洞管理功能与

技术要求

必须

是

4.2

4.3

4.4

5.供应商需求

5.1

必须

是

5.2

5.3

5.4

6.售后服务需求

6.1

6.2

6.3

6.4

7・OOOOO。

7.1

7.2

7.3

7.4

注：

完成需求的调研和汇总后，通过流程由需求方进行确认。

技术评审会上根据设计方案对需求的可实现程度进行进一步确认，说明哪些需求

可实现，哪些需求不可实现。