有朋友后台留言问有没有源代码审计相关的政策文件或标准文件中包括相关取费标准的?目前是没有相关标准的,本文结合市场与实践,梳理下文计费模型,综合网络素材总结归纳下文。
01 参考标准
GB/T 39412-2020《信息安全技术 代码安全审计规范》。该标准明确了代码安全的审计过程、典型审计指标及证实方法。
此外,本说明书还综合参考了以下框架与实践:
GB/T 25000 系列软件质量标准与GB/T 45717-2025《信息技术 软件测量 软件质量测量 自动化的源代码质量测度》,作为软件质量评价的补充依据。
网络安全等级保护2.0要求:涉及关键信息基础设施的系统,其审计需满足相应等级要求。
行业主流源代码安全审计实践与报价体系:结合市场通行的服务模式与计价原则,确保模型的实用性。
2. 计价模式概览
本文提出了适用于不同场景的七种源代码安全审计计价模型。
表2-1:源代码安全审计计价模型概览
为便于后续模型的阐述与计算,兹统一关键参数定义如下:
KLOC:千行代码,指物理代码行数(不含空行和注释)。
FP:功能点,用于衡量软件功能规模的度量单位。
C:核心业务模块复杂度系数。
L:编程语言与技术栈难度系数。
S:系统安全等级系数。
E:项目紧急系数。
3. 详细模型说明
3.1 项目包干计价模型
此模型适用于项目边界清晰、需求明确、代码规模中小的审计任务。
计价公式总价(P) = 基准价(B) × 复杂度系数(K)其中,K = (C + L + S) / 3
参数说明表
示例计算某等保2级企业内部管理系统(Java开发,业务逻辑一般),约定包干审计。P = 20000× (1.2 + 1.0 + 1.0)/3 = 5000 × 1.07 ≈ 21333元
3.2 人天计价模型
此模型适用于代码结构复杂、需投入大量人工进行深度审计分析的项目。
计价公式总价(P) = 人天单价(U) × 预估人天(D) × 紧急系数(E)
参数说明表
示例计算某核心交易系统需高级工程师审计,预估15人天,要求一周内完成(紧急系数1.3)。P = 3,500 × 15 × 1.3 = 68,250元
3.3 按行计价模型(KLOC)
当前主流的计价方式。当前市场上最为透明和常见的计价方式之一,尤其适用于代码结构规范、规模适中的项目。
计价公式总价(P) = 代码行数(LOC) / 1000 × 千行单价(UK) × 调整系数(A)×边际成本系数P其中,A = (C + L + S) / 3
边际成本系数P,根据代码行数的增加递减。
10万行比如为0.8,10万行-50万行比如为0.6,50万行到100万行比如为0.4
参数说明表
其中,建议基准价格区间还可以细分:
自动工具扫描:xx元/KLOC
工具辅助人工审计:xx元/KLOC
深度人工审计:xx元/KLOC
3.4 按漏洞数量与等级计价模型
此模型侧重于对安全漏洞的精准发现与评级,通常作为补充或特定安全目标的计价方式。
计价公式总价(P) = 基础服务费(F) + Σ(漏洞单价(Vi) × 漏洞数量(Ni))
参数说明表
3.5 按报告计价模型
此模型以交付物为核心,适用于需要快速获取审计结论或需要针对不同维度(如安全、性能)出具多份独立报告的场景。
计价公式总价(P) = 单份报告基准价(R) × 报告数量(N) × 报告深度系数(D)
参数说明表
4. 统一难度系数参考表
本表为计价模型中的各项难度系数提供具体参考。
表4-1:统一难度系数参考表
5. 报价建议与合同条款建议
5.1 报价流程建议
1.需求与代码梳理:明确审计目标、范围,统计代码规模与技术栈。
2.模型选择:根据项目特性和客户预算,推荐合适的计价模型。
3.系数评定:依据第4章的统一难度系数参考表,客观评定各项系数。
4.成本测算:代入公式进行详细测算,并提供分项报价单。
5.商务谈判与确认:就报价依据和条款与客户沟通,达成一致后签署合同。
6.关键合同条款建议
代码行数变化调整条款:若在审计过程中,经双方确认的实际代码行数与合同预估量差异超过±20%,则应启动价格调整机制,重新协商合同总价或签订补充协议。
6. 附录
6.1 参数说明
KLOC:千行代码,是衡量代码规模的基本单位。
人天:指一个审计工程师一天(通常按8小时计)的工作量。
有效漏洞:指经过开发方确认且可复现的安全缺陷,需在合同中明确验证标准。
审计报告:交付物应至少包括审计概述、审计方法、漏洞详情(位置、描述、危害等级、修复建议)及整体风险评估。
6.2 报告交付与质量验收要点
审计方交付的成果物可参考GB/T 39412-2020标准中关于"审计报告"的部分。报告内容的完整性、准确性、可读性,以及漏洞描述的清晰度和可修复性为核心考核点。