1. 编制依据

本说明书的核心编制依据为中华人民共和国国家标准 GB/T 39412-2020《信息安全技术 代码安全审计规范》 。该标准明确了代码安全的审计过程、典型审计指标及证实方法。

此外，本说明书还综合参考了以下框架与实践：

• GB/T 25000 系列软件质量标准与GB/T 45717-2025《自动化的源代码质量测度》，作为软件质量评价的补充依据。

• 国家信息安全等级保护2.0要求：涉及关键信息基础设施的系统，其审计需满足相应等级要求。

• 行业主流源代码安全审计实践与报价体系：结合市场通行的服务模式与计价原则，确保模型的实用性。

2. 计价模式概览

本标准提出了适用于不同场景的七种源代码安全审计计价模型。

表2-1：源代码安全审计计价模型概览

计价模式	适用场景	核心计价单元	优势	潜在风险
项目包干计价	需求明确、范围固定的小型项目	每项目	价格固定，预算可控	范围变更易引发争议
人天计价	复杂度高、需深度人工审计的大型或复杂项目	人天	高度灵活，按实际投入结算	总预算可控性较差
按行计价	代码结构规范、规模适中的项目	千行代码(KLOC)	计费透明，易于横向对比	未充分考虑代码复杂度
按漏洞数量与等级计价	侧重于高危漏洞发现与修复的精准审计	每个漏洞	精准激励深度安全挖掘	可能忽视代码结构优化
按报告计价	需快速获取多份针对性报告的场景	每份报告	服务目标明确，交付物清晰	报告深度和范围可能受限
混合定价	大多数主流项目，兼顾效率与成本	基础费 + (行数/人天)	平衡全面，适用性广	计价结构相对复杂
SaaS化按需计价	持续集成/持续交付(CI/CD)流程中的常态化审计	服务时长/实例	按需付费，适配敏捷开发	长期使用总成本可能较高

为便于后续模型的阐述与计算，兹统一关键参数定义如下：

• KLOC：千行代码，指物理代码行数（不含空行和注释）。

• FP：功能点，用于衡量软件功能规模的度量单位。

• C：核心业务模块复杂度系数。

• L：编程语言与技术栈难度系数。

• S：系统安全等级系数。

• E：项目紧急系数。

3. 详细模型说明

3.1 项目包干计价模型

此模型适用于项目边界清晰、需求明确、代码规模中小的审计任务。

• 计价公式
  总价(P) = 基准价(B) × 复杂度系数(K)
  其中，K = (C + L + S) / 3

• 参数说明表

参数	说明	取值范围（示例）
基准价(B)	针对标准规模项目（如5万行以下）的固定报价	人民币 5,000 - 80,000元
核心业务模块复杂度(C)	依据业务逻辑复杂程度评定	简单(1.0) / 一般(1.2) / 复杂(1.5)
编程语言与技术栈难度(L)	依据开发语言的普及度和审计工具成熟度评定	常见语言(1.0) / 混合或特定语言(1.3) / 冷门或汇编语言(1.8)
系统安全等级(S)	依据系统所要求的安全级别评定	等保1-2级(1.0) / 等保3级(1.2) / 等保4级及以上(1.5)

• 示例计算
  某等保2级企业内部管理系统（Java开发，业务逻辑一般），约定包干审计。
  P = 5000× (1.2 + 1.0 + 1.0)/3 = 5000 × 1.07 ≈ 5350元

3.2 人天计价模型

此模型适用于代码结构复杂、需投入大量人工进行深度审计分析的项目。

• 计价公式
  总价(P) = 人天单价(U) × 预估人天(D) × 紧急系数(E)

• 参数说明表

参数	说明	取值范围（示例）
人天单价(U)	不同级别审计工程师的日费率	初级(1,500元) / 中级(2,500元) / 高级(4,000元)
预估人天(D)	基于经验对项目工作量的估算	通常为 5 - 60 人天
紧急系数(E)	因项目周期压缩需投入额外资源	标准周期(1.0) / 压缩周期(1.2 - 1.5)

• 示例计算
  某核心交易系统需高级工程师审计，预估15人天，要求一周内完成（紧急系数1.3）。
  P = 4,000 × 15 × 1.3 = 78,000元

3.3 按行计价模型（KLOC）

此模型是当前市场上最为透明和常见的计价方式之一，尤其适用于代码结构规范、规模适中的项目。

• 计价公式
  总价(P) = 代码行数(LOC) / 1000 × 千行单价(UK) × 调整系数(A)
  其中，A = (C + L + S) / 3

• 参数说明表

参数	说明	取值范围（示例）
千行单价(UK)	每千行代码的审计费用基准	人民币 800 - 2,500元/KLOC
代码行数(LOC)	有效代码行数（不含空行与注释）	实际统计
调整系数(A)	综合难度调整	参见C, L, S参数定义

• 建议基准价格区间

  • 自动工具扫描：xx元/KLOC

  • 工具辅助人工审计：xx元/KLOC

  • 深度人工审计：xx元/KLOC

3.4 按漏洞数量与等级计价模型

此模型侧重于对安全漏洞的精准发现与评级，通常作为补充或特定安全目标的计价方式。

• 计价公式
  总价(P) = 基础服务费(F) + Σ(漏洞单价(Vi) × 漏洞数量(Ni))

• 参数说明表

参数	说明	取值范围（示例）
基础服务费(F)	覆盖审计准备、基础扫描及报告编写	人民币 10,000 - 30,000元
漏洞单价(Vi)	依据漏洞危险等级定价	高危(2,000 - 5,000元) / 中危(500 - 1,500元) / 低危(100 - 400元)
漏洞数量(Ni)	经确认的有效漏洞数量	审计后发现

3.5 按报告计价模型

此模型以交付物为核心，适用于需要快速获取审计结论或需要针对不同维度（如安全、性能）出具多份独立报告的场景。

• 计价公式
  总价(P) = 单份报告基准价(R) × 报告数量(N) × 报告深度系数(D)

• 参数说明表

参数	说明	取值范围（示例）
单份报告基准价(R)	每份标准审计报告的费用	人民币 5,000元起
报告数量(N)	需要出具的独立报告的数量	1份起
报告深度系数(D)	依据报告内容的详细程度和审计深度调整	摘要报告(0.7) / 标准报告(1.0) / 深度分析报告(1.5)

4. 统一难度系数参考表

本表为计价模型中的各项难度系数提供具体参考。

表4-1：统一难度系数参考表

系数类别	级别	系数	描述
核心业务复杂度(C)	简单	1.0	基础CRUD操作，逻辑链路短
	一般	1.2	包含部分业务流程，有状态判断
	复杂	1.5	多系统交互，复杂算法或金融交易逻辑
编程语言与技术栈(L)	常见语言	1.0	Java, Python, Go, JavaScript等
	混合/特定语言	1.3	混合框架，C++，Objective-C等
	冷门/汇编语言	1.8	汇编，RPG，COBOL或高度定制化语言
系统安全等级(S)	等保1-2级	1.0	非核心内部系统
	等保3级	1.2	涉及敏感信息或提供核心服务的系统
	等保4级及以上	1.5	关系国计民生或国家安全的重要系统

5. 报价建议与合同条款建议

5.1 报价流程建议

1. 需求与代码梳理：明确审计目标、范围，统计代码规模与技术栈。

2. 模型选择：根据项目特性和客户预算，推荐合适的计价模型。

3. 系数评定：依据第4章的统一难度系数参考表，客观评定各项系数。

4. 成本测算：代入公式进行详细测算，并提供分项报价单。

5. 商务谈判与确认：就报价依据和条款与客户沟通，达成一致后签署合同。

5.2 关键合同条款建议

• 代码行数变化调整条款：若在审计过程中，经双方确认的实际代码行数与合同预估量差异超过±20%，则应启动价格调整机制，重新协商合同总价或签订补充协议。

• 复测及加固服务计价说明：

  • 首次复测：在开发方修复漏洞后，提供一次范围内的免费复测。

  • 额外复测/加固：若因修复不达标或需求变更导致多次复测，建议按原单人天单价的70% 另行计算费用。

• 支付节奏：建议分为合同签订后（预付30%）、审计报告交付后（支付60%）、复测完成并通过验收后（支付10%）三个阶段支付。

• 验收标准：明确以报告的交付、以及报告中所有高危及以上漏洞的修复率达到100% 等作为验收合格的标准。

6. 附录

6.1 参数说明

• KLOC：千行代码，是衡量代码规模的基本单位。

• 人天：指一个审计工程师一天（通常按8小时计）的工作量。

• 有效漏洞：指经过开发方确认且可复现的安全缺陷，需在合同中明确验证标准。

• 审计报告：交付物应至少包括审计概述、审计方法、漏洞详情（位置、描述、危害等级、修复建议）及整体风险评估。

6.2 报告交付与质量验收要点

审计方交付的成果物应符合GB/T 39412-2020标准中关于"审计报告"的要求。质量验收应以报告内容的完整性、准确性、可读性，以及漏洞描述的清晰度和可修复性为核心考核点。