ICS 35.240.01 L70

团 体 标 准

T/CFAS 0003-2019

信息安全技术

开源代码安全审计规范

Information Security Technology: The AuditSpecifications of Open Source Coding Security

北京长风信息技术产业联盟   发布

前     言

       开源代码安全不同于对开源软件使用和开源环境的安全监控，开源代码安全审计和漏洞评估属于代码级漏洞扫描的应用，主要是对于开源代码自身存在的缺陷以及该代码所使用和 涉及到的开源源代码包等，进行全方位的安全漏洞扫描，在该代码未成为软件产品前进行漏洞检测。将漏洞扼杀于产品未成形的摇篮之中。减少软件产品化后的安全漏洞隐患，从而真正做到防患于未然。

       本标准主要规范了开源代码安全审计和评估上的各种安全规范，将在不同阶段中所需要注意的安全问题和相关安全规范进行进一步的描述和规定，以提高开源软件的安全性和抵御攻击的能力。

       本标准的实施应遵循配套国家标准的具体规定。 本标准由北京长风信息技术产业联盟提出并归口。

       本标准起草单位: 北京长风信息技术产业联盟、中国科学院软件研究所、中科软智（北京）科技有限公司、北京中科微澜科技有限公司、北京合睿科技有限公司。

       本标准起草人:吴敬征、郭维、杨牧天、罗天悦、刘梅、倪琛、吴亚丽、武延军、孙启。

引  言

0.1 概述

开源代码安全审计可以从软件程序开发的源头进行代码级的安全审计和漏洞检测，并按照安全风险级别将代码漏洞进行有效的归类管理。因此，代码安全审计提供了一种针对代码自身安全进行高效的安全管控的方式和方法。

0.2 本文的作用

开源代码安全审计包括的标准:

a)    定义对开源代码安全审计及涉及此规范的行业内要求;

b)    为建立、实施、维护和改进开源代码安全审计的整个过程提供直接支持、详细指南和/或解释;

c)    针对特定行业提出开源代码安全审计指南;

d)     阐述开源代码安全审计的合格评定方法。

0.3本文内容

在本文件中，使用下列动词形式：

——“应当（shall）”表示要求；

——“应该（should）”表示推荐；

——“可以（may）”表示许可；

——“能（can）”表示可能性或能力。

标记为“注释”的信息用于理解或澄清相关指导要求。第 3 条中使用的“条目注释”提供了补充术语数据的附加信息，并且包含使用有关术语的条款。

信息安全技术

开源代码安全审计规范

1          范围

本标准规定了开源代码安全审计的标准化流程规范。

本标准适用于软件在开源代码安全审计过程中涉及到的信息安全相关审计流程，规范化和标准化开源代码安全审计的完整流程体系，用于有效评估和验证软件在开源代码安全审计过程中是否得当，是否符合开源代码安全审计规范标准。

本标准主要针对开源代码安全审计以及管理过程进行标准化规定，因此本标准不适用于病毒检测等非开源代码安全审计规范类标准化工作的开展。

本标准适用于软件相关的信息产品生产、技术研发、系统运营等组织、机构在相关工作中参考。

2          规范性引用文件

下列文件对本文件的应用是必不可少的，凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有修改单)适用于本文件。

GB/T 25069-2010  信息安全技术   术语

ISO/IEC 27000-2018 信息安全技术 信息安全管理体系 概述和术语

3          术语和定义

（可能包括缩略语）

3.1  访问控制 access control

作为进行授权和限制的手段，确保对于资产的访问是基于业务和安全要求（3.56）。

3.2  攻击 attack

企图破坏、泄露、篡改、损伤、窃取、未授权访问或未授权使用资产的行为。

3.3  审核 audit

获取审核证据并客观地对其评价的过程，以确定满足过程化（3.54）、系统化、独立化   和文件化的审核准则。

注1：审核可以是内部审核（第一方）或外部审核（第二方或第三方），可以是结合审核（结合两个或两个以上学科）。

注 2：内审核是由组织自己，或由外部以组织的名义进行的。

注 3：“审核证据”和“审核准则”在 ISO 19011｜GB/T 19011 中被定义。

3.4  审核范围 audit scope

审核（3.3）的程度和边界。

[资料来源：ISO19011:2011，定义 3.14，修改：删除注 1]

3.5  鉴别 authentication

为确保一个实体声称的特征是正确的而提供的保障措施。

3.6  真实性 authenticity

一个实体是其所声称实体的特性。

3.7  可用性 availability

根据授权实体的要求可访问和可使用的特性。

3.8  基本测度 base measure

用某个属性及其量化方法定义的测度（3.42）。注 1：基本测度在功能上独立于其他测度。

[资料来源：ISO/IEC15939:2017，定义 3.3，修改：删除注 2]

3.9  能力 competence

应用知识和技能实现预期结果的才能。

3.10 保密性 confidentiality

信息不能对未授权的个人、实体或过程（3.54）可用或泄露的特性。

3.11 符合性 conformity

对要求（3.56）的满足。

3.12 后果 consequence

事态（3.21）影响目标（3.49）的结果。

注 1：一个事态（2.25）可能导致一系列后果。

注   2：后果可以是确定的或不确定的，并且在信息安全（2.33）的语境下通常是负面的。注 3：后果可以被定性或定量地表示。

注 4：初始后果可能通过连锁效应升级。

[资料来源：ISO Guide 73:2009，定义 3.6.1.3，注释 2 在“并且”之后被更改。]

3.13 持续改进 continual improvement 反复提高性能（3.52）的活动。

3.14控制 control

规避风险（3.61）的措施。

注  1：控制包括任何规避风险（3.61）的过程（3.54）、方针（3.53）、设备、实践或其他措施。

注 2：控制可能不一定总是达到预期或假定的风险规避效果。[资料来源：ISO Guide 73:2009，定义3.8.1.1——注 2 有改变]

3.15控制目标 control objective

描述控制（3.14）的实施结果所要达到目标的声明。

3.16 纠正 correction

消除已查明的不合格（3.47）的措施。

3.17 整改措施 corrective action

消除不合格（3.47）成因以防再次发生的措施。

3.18 导出测度 derivedmeasure

定义为两个或两个以上基本测度（3.8）值的函数的测度（3.42）。[资料来源：ISO/IEC 15939:2017，定义 3.8，修改：删除注1]

3.19成文信息 documented information

组织（3.50）需要控制和保持的信息及其载体。

注 1：成文信息可以以任何格式，在任何载体中，来自任何来源。注 2：成文信息可能涉及

——管理体系（3.41），包括相关过程（3.54）；

——为组织（3.50）运行所创建的信息（文件）；

——结果实现的证据（记录）。

3.20 有效性 effectiveness

实现所计划活动和达成所计划结果的程度。

3.21 信息安全治理governance of information security

指导和控制组织（3.50）信息安全（3.28）活动的体系。

3.22 指标 indicator

提供估算或评价的测度（3.42）。

3.23 信息需求 information need

对目标（3.49）、目的、风险和问题进行管理所必需的洞察能力。[资料来源：ISO/IEC 15939:2017，定义 3.12]

3.24信息处理设施 information processing facilities

任何的信息处理系统、服务或基础设施，或者其安置的物理位置。

3.25 信息安全 information security

对信息的保密性（3.10）、完整性（3.36）和可用性（3.7）进行保护。

注 1：另外，也可包括诸如真实性（3.6）、可核查性、抗抵赖（3.48）和可靠性（3.55） 等其他特性。

3.26信息安全持续性 information securitycontinuity

确保信息安全（3.28）持续作用的过程（3.54）和规程。

3.27 信息安全事态information securityevent

识别到的一种系统、服务或网络状态的确定情况，表明可能违反信息安全（3.28）方针

（3.53）或控制（3.14）失效，或者一种可能与信息安全相关但还不为人知的情况。

3.28 信息安全事件information securityincident

单一或一系列不希望发生或意外发生的，极有可能损害业务运行和威胁信息安全（3.28）  的信息安全事态（3.30）。

3.29信息安全事件管理

信息安全事件管理 information security incidentmanagement

发现、报告、评估、响应、处理和总结信息安全事件（3.31）的过程（3.54）。

3.30 信息安全管理系统

信息安全管理系统（ ISMS ）专业人员 information security management system (ISMS) professional

建立、实施、维护并持续改进一个或多个信息安全管理系统过程（3.54）的人员。

3.31 信息共享社区 informationsharing community 同意共享信息的组织（3.50）群体。

注 1：组织（3.57）可以是一个人。

3.32 信息系统 information system

应用、服务、信息技术资产或其他信息处理组件的集合。

3.33 完整性 integrity

准确和完备的特性。

3.34 利益相关方

利益相关方 interested party(首选术语)；stakeholder(许用术语)

对于一项决策或活动，可能对其产生影响，或被其影响，或认为自己受到其影响的个人或组织（3.50）。

3.35内部语境 internal context

组织（3.50）寻求实现其目标的内部环境。注 1：内部语境可以包括如下方面：

——治理、组织结构、角色和职责；

——方针（3.53）、目标（3.49）和需要实现它们的战略；

——在资源和知识方面的能力（如资本、时间、人员、过程（3.54）、系统和技术）；

——信息系统（3.35）、信息流和决策过程（正式的和非正式的）；

——与内部利益相关方（3.37）的关系及其认知和价值观；

——组织的文化；

——组织采用的标准、指南和模型；

——契约关系的形式和程度。

[资料来源：ISO Guide 73:2009，定义 3.3.1.2]

3.36 风险程度 level of risk

以后果（3.12）和其可能性（3.40）的组合来表示的风险（3.61）大小。[ISOGuide 73:2009，定义 3.6.1.8，修改：删除定义中的“或风险组合”]

3.37可能性likelihood

某事发生的机会。

[ISO Guide 73:2009，定义 3.6.1.1，修改：删除注 1 和注 2]

3.38 管理体系 management system

组织（3.50）中相互关联或相互作用的要素集，用来建立方针（3.53）和目标（3.49） 以及达到这些目标的过程（3.54）。

注 1：一个管理体系可能专注于单一学科或多个学科。

注 2：体系要素包括组织结构、角色和责任、规划、运行。

注3：一个管理体系范围可能包括组织的整体、组织的特定且确定的功能、组织的特定且确定的部门，或者跨组组织的一个或多个功能。

3.39测度 measure

作为测量（3.43）结果赋值的变量。

[资料来源：ISO/IEC15939:2017，定义 3.15，修改：删除注 2]

3.40 测量 measurement

确定一个值的过程（3.54）。

3.41 测量函数 measurement function

组合两个或两个以上基本测度（3.8）的算法或计算。  [资料来源：ISO/IEC 15939:2017，定义 3.20]

3.42测量方法 measurement method

用于按指定的尺度量化属性的通用逻辑操作序列。

注 1：测量方法的类型取决于量化属性（3.4）操作的性质。可区分为两种类型：

——主观的：包含人为判断的量化；

——客观的：基于数字规则的量化。

[资料来源：ISO/IEC15939:2017，定义 3.22，修改：删除注 2]

3.43 监视 monitoring

确定系统、过程（3.54）或活动状态的行为。

注 1：为确定状态可能需要检查、监督或严密观察。

3.44 不合格 nonconformity 不满足要求（3.56）。

3.45目标 objective

要实现的结果。

注 1：目标可以是战略性的、战术性的或操作性的。

注2：目标可以涉及不同学科（诸如金融、健康与安全以及环境目标），可以适用于不同层次（诸如战略、组织、项目、产品和过程（3.54））。

注 3：目标可以以其他方式表示，例如，作为预期结果、意图、操作准则，作为信息安全目标，或者使用具有类似含义的其他词（例如，目的或标靶）。

注4：在信息安全管理体系的语境下，组织制定与信息安全策略一致的信息安全目标以实现特定的结果。

3.46组织 organization

具有自身的功能、责任、权威和关系来实现其目标（3.49）的人或一组人。

注 1：组织的概念包括但不限于个体经营者、公司、法人、商行、企业、机关、合伙关系、慈善机构或院校，或部分或其组合，不论注册与否，公共的还是私营的。

3.47外包 outsource

安排外部组织（3.50）执行部分的组织功能或过程（3.54）。

注 1：外部组织在管理体系（3.41）的范围之外，尽管外包的功能或过程在范围之内。

3.48 性 能 performance 可测量的结果。

注 1：性能可以涉及定量或定性的调查结果。

注 2：性能可涉及活动、过程（3.54）、产品（包括服务）、系统或组织（3.50）的管

理。

3.49 方针 policy

由最高管理者（3.75）正式表达的组织（3.50）的意图和方向。

3.50 过程 process

将输入转换成输出的相互关联或相关作用的活动集。

3.51 可靠性 reliability

与预期行为和结果一致的特性。

3.52 要求 requirement

明示的、通常隐含的或强制性的需要或期望。

注1：“通常隐含”意指组织或利益相关方的惯例或常见做法，所考虑的需要或期望是不言而喻的。

注 2：指定要求是明示的，例如在成文信息中。

3.53 残余风险 residual risk

风险处置（3.72）后余下的风险（3.61）。注 1：残余风险可能包含未识别的风险。注 2：残余风险也可以被称为“保留风险”。

3.54评审 review

针对实现所设立目标（3.49）的主题，为确定其适宜性、充分性和有效性（3.20）而采   取的活动。

[资料来源：ISO Guide 73:2009，定义 3.8.2.2，修改：删除注 1]

3.55 评审对象 review object被评审的特定事项。

3.56评审目标 review objective

描述评审（3.59）结果要达到什么的陈述。

3.57 风险 risk

对目标（3.49）的不确定性影响。

注 1：影响是指与期望的偏离（正面的或负面的）。

注2：不确定性是对事态及其结果或可能性的相关信息、理解或知识缺乏的状态（即使是部分的）。

注 3：风险常被表征为潜在的事态（如 ISOguide 73:2009，3.5.1.3 定义的）和后果（如ISOguide 73:2009，3.6.1.3 定义的），或者它们的组合。

注 4：风险常被表示为事态的后果（包括情形的改变）和其发生可能性（如ISO guide 73:2009，3.6.1.1 定义的）的组合。

注5：在信息安全管理体系的语境下，信息安全风险可被表示为对信息安全目标的不确定性影响。

注 6：信息安全风险与威胁利用信息资产或信息资产组的脆弱性对组织造成危害的潜力相关。

3.58风险接受 riskacceptance

接纳特定风险（3.61）的有根据的决定。

注  1：可不经风险处置（3.72）或在风险处置的过程（3.54）中做出风险接受。注 2：接受的风险（2.68）要受到监视（3.46）和评审（3.58）。

[资料来源：ISO Guide 73:2009，定义 3.7.1.6]

3.59 风险分析 risk analysis

理解风险（3.61）本质和确定风险等级（3.39）的过程（3.54）。

注 1：风险分析提供风险评价（3.67）和风险处置（3.72）决策的基础。注 2：风险分析包括风险估算。

[资料来源：ISO Guide 73:2009，定义 3.6.1]

3.60 风险评估 risk assessment

风险识别（3.68）、风险分析（3.63）和风险评价（3.67）的整个过程（3.54）。   [资料来源：ISO Guide 73:2009，定义3.4.1]

3.61风险沟通与咨询 riskcommunication and consultation

组织就风险（3.61）管理所进行的，提供、共享或获取信息以及与利益相关方（3.37）   进行对话的一组持续和迭代的过程（3.54）。

注   1：这些信息可能涉及到风险的存在、性质、形式、可能性（3.41）、重要性、评价、可接受性和处置。

注2：咨询是对问题进行决策或确定方向之前，在组织（3.50）和其利益相关方之间进行知情沟通的双向过程。咨询是

——通过影响而不是权力来影响决策的过程；

——决策的输入而非联合决策。

3.62 风险准则 risk criteria

评价风险（3.61）重要性的参照条款。

注   1：风险准则是基于组织的目标以及外部语境（3.22）和内部语境（3.38）。注 2：风险准则可来自标准、法律、方针（3.53）和其他要求（3.56）中。

[资料来源：SOURCE: ISO Guide 73:2009, 3.3.1.3]

3.63 风险评价 risk evaluation

将风险分析（3.63）的结果与风险准则（3.66）比较以确定风险（3.61）和/或其大小是  否可接受或可容忍的过程（3.54）。

注  1：风险评价有助于风险处置（3.72）决策。[资料来源：ISOGuide 73:2009，定义 3.7.1]

3.64风险识别 risk identification

发现、识别和描述风险（3.61）的过程（3.54）。

注 1：风险识别涉及风险源、事态（3.21）及其原因和潜在后果（3.12）的识别。

注 2：风险识别可能涉及历史数据、理论分析、知情者和专家的意见以及利益相关方

（3.37）的需要。

[资料来源：ISO Guide 73:2009，定义 3.5.1]

3.65 风险管理 risk management

指导和控制组织（3.50）相关风险（3.61）的协调活动。   [资料来源：ISO Guide 73:2009，定义2.1]

3.66风险管理过程 riskmanagement process

管理方针（3.53）、规程和实践在沟通、咨询、语境建立以及识别、分析、评价、处置、   监视和评审风险（3.61）活动上的系统性应用。

注 1：ISO/IEC 27005｜GB/T31722 使用术语“过程”（3.54）来描述全面风险管理。在风险管理（3.69）过程中的要素被称为“活动”。

[资料来源：ISO Guide 73:2009，定义 3.1，修改：增加注 1]

3.67 风险责任者 riskowner

具有责任和权威来管理风险（3.61）的人或实体。  [资料来源：ISO Guide73:2009，定义 3.5.1.5]

3.68风险处置 risk treatment

改变风险（3.61）的过程（3.54）。注 1：风险处置可能涉及如下方面：

——通过决定不启动或不继续进行产生风险的活动来规避风险；

——承担或增加风险以追求机会；

——消除风险源；

——改变可能性（3.40）；

——改变后果（3.12）；

——与另外一方或多方共担风险（包括合同和风险融资）；

——通过有根据的选择保留风险。

注2：处理负面后果的风险处置有时被称为“风险缓解”、“风险消除”、“风险防范”和“风险降低”。

注 3：风险处置可能产生新的风险或改变现有风险。

[资料来源：ISOGuide 73:2009，定义 3.8.1，修改：将注 1 中的“决策”替换为“选择”]

3.69 安全实现标准 security implementationstandard 为实现安全而规定授权方式的文件。

3.70威胁 threat

可能对系统或组织（3.50）造成危害的不期望事件的潜在原由。

3.71 最高管理者 top management

在最高层指导和控制组织（3.50）的人或一组人。

注 1：最高管理者具有在组织内授权和提供资源的权力。

注2：如果管理体系（3.41）的范围只涵盖组织的一部分，则最高管理者就是指指导和控制组织这部分的人或一组人。

注 3：最高管理者有时被称为执行管理，可以包括首席执行官、首席财务官、首席信息官以及类似的角色。

3.72可信信息通信实体 trusted information communication entity

支持在信息共享社区（3.34）内进行信息交换的自主组织（3.50）。

3.73 安全漏洞 vulnerability

可能被一个或多个威胁（3.74）利用的资产或控制措施（3.14）的弱点。计算机信息系   统在需求、设计、实现、配置、运行等过程中，有意或无意产生的缺陷。这些缺陷以不同形式存在于计算机信息系统的各个层次和环节中，一旦被恶意主体所利用，就会对计算机信息系统的安全造成损害，从而影响计算机信息系统的正常运行。

3.74       漏洞管理 vulnerability management

漏洞管理是建立、实施、运行、监视、评审、维护和改进组织漏洞安全来实现业务目标的系统方法。它是基于漏洞风险评估和组织的漏洞风险接受程度，为有效地处置和管理漏洞风险来设计的。分析信息资产保护要求，并按要求应用适当的控制措施确保这些信息资产，有助于漏洞管理的成功实施。

3.75       漏洞库 vulnerability database

漏洞库是为了更好的进行信息安全漏洞的管理及控制工作而建立的一项漏洞安全信息数据库。

4          信息安全开源代码安全审计规范标准

4.1 概要

造成软件出现安全问题的主要原因来源于软件代码自身存在的错误（BUG）和缺陷引起   的安全漏洞，以及通过利用安全漏洞实施的各种攻击。

本标准主要规范了应用开源代码在软件程序编写过程中，开源代码安全审计的各个实施办法和流程的标准化规范，将在不同阶段中所需要注意的安全问题和相关安全规范进行进一 步的描述和规定，规范化软件开源代码安全审计的流程步骤，以提高软件自身的安全性，达到有效管控软件开源代码漏洞风险的目的。

通过软件开源代码安全审计和漏洞检测技术，全方位的排查和管理开源代码的安全漏洞，辅助性的提供修复解决方案，间接的修复并减少软件的安全漏洞，从而有效的抵御攻击。还可以通过对开源代码安全漏洞的管理，进一步预警和预测漏洞可能带来的安全问题，增强风险的可控性。

4.2 开源代码安全审计规范综述

4.2.1   概述和原则

开源代码安全审计主要在于以规范标准的审计流程为工作手段，进行规范化标准化的开源代码安全审计工作。由组织集中管理，目的在于保护其开源代码信息资产的基础安全。基 于开源代码漏洞风险评估和组织对开源代码漏洞风险接受程度的指标，应用标准化设计手段，进行有效地处置和管理开源代码漏洞风险。分析开源代码信息资产保护要求，并按要求 应用适当的控制措施确保这些开源代码信息资产的安全，有助于开源代码安全审计工作的成功实施。下列基本原则也有助于开源代码安全审计工作的成功实施：

a)    意识到漏洞管理的重要；

b)     分配开源代码安全审计的责任；

c)     涵盖管理者的承诺和利益相关方的利益；

d)     提升社会价值；

e)     进行漏洞风险评估来确立适宜的控制手段，从而达到可接受的漏洞风险程度；

f)     将安全作为信息系统的基本要素；

g)     主动防范和发现漏洞安全事件；

h)     确保漏洞管理方法的全面性；

i)    持续对漏洞管理进行再评估，并在适当时进行修正。

4.2.2    开源代码安全审计流程规范

图 1 开源代码安全审计流程

安全代码审计的第一步就是对每一个源代码文件的所有者的分配权限、相关所有文件等建立一个数据库。在这一阶段，不能遗漏任何待评审的代码。在这种情况下，通常可以使用最近一次更新过该文件的用户面进行更新。在数据库中创建一个包含文件名、文件属主、优先级、评审者、评审结果及评论的表格。

下一步就是明确评审优先级，可根据漏洞的危害程度将漏洞等级分为“严重”、“高危”、  “中危”、“低危”四个等级。多数标记应由威胁模型驱动，戒胁模型所识别出的最高风险  组件就是待评审的高优先级代码段，可以执行一些简单的规则来明确优先级。代码审计应当也能够覆盖用于为其他使用人员讲解的示例代码。

需要注意的是，属主并不参与审计代码，但其可以指定某人对代码进行审计。其中一种最佳方案是只有两个属主交换他们的源代码文件并互相交叉审计。

1)         开源代码在开发阶段告一段落后必须遵循使用、进行漏洞扫描的原则，计划准备进行全面的漏洞检测和评估工作，根据需求制定可实施方案，进行测试执行，通过人工审计后生成相应的漏洞评估结果报告。

2)         每一次开源代码迭代后，所波及的所有版本变更代码，均必须对开源代码漏洞进行新一轮检测和评估，并生成相应的漏洞评估结果报告。

3)         开源代码的代码库管理人员，无论是在开发周期内还是在开发结束以后，有义务在一定周期内进行开源代码漏洞检测工作，并生成漏洞评估结果报告。

4)         每一次重大漏洞发现并公开后，必须遵从紧急安全响应机制，在第一时间对代码库进行开源代码漏洞检测工作，并生成漏洞评估结果报告。

5)         任何私自卸载、改装、屏蔽等影响开源代码检测的行为均属于违规行为，不符合规范的执行。

6)         进行开源代码检测后的漏洞结果报告，必须由专人负责统计和管理，由专业人员进行评估，并第一时间提交给有关部门的负责人。

7)         进行开源代码检测后，所产生的漏洞必须尽快根据漏洞结果报告的建议修复方式进行漏洞的修复工作，负责人有义务监督并管理整个漏洞修复的实施过程。

代码审计分析流程如图 2 所示：

图 2代码审计分析流程