源代码自主率测评

什么是源代码自主率测评

源代码自主率，指在送检软件的有效代码总量中，由送检方自主开发、且不因引用外部开源代码而受协议约束的那部分所占的比例。它回答的问题不是「代码写得好不好」，而是「这套软件的代码资产在多大程度上属于自己、在多大程度上受制于他人」。

测评的技术依据是 T/ISC 0043—2024《软件代码自主率测评方法》。测评过程包括代码成分扫描、开源许可证识别、代码行数统计、源代码安全审计与依赖软件自主可控性评估，产出是一个可被引用的百分比数值，以及一份逐项列明的开源组件依赖清单。

需要先把本页的性质说清楚。源代码自主率测评属于代码审计与软件成分分析，不在我司 CNAS 实验室认可范围之内，我司目前未开展该项检测业务。本页整理的是标准口径、送检要求与结果使用方式，作用是帮助客户在准备验收材料、招标技术要求或申报佐证时把口径定准，避免把「软件测试报告」与「代码自主率测评报告」当成同一件事。若确需实施测评，应由具备相应能力的第三方机构承担。

这两类报告的区别值得单列一段。软件测试报告测的是「跑起来怎么样」——功能、性能、信息安全，对象是可运行的程序；代码自主率报告看的是「代码是谁的」——成分构成、许可证类型、行数归属，对象是源代码本身。前者不需要源码，后者必须交付完整源码。一套功能测试全部通过的软件，代码自主率完全可能是 40%，两个结论同时成立，并不矛盾。

标准依据与适用场合

T/ISC 0043—2024 由中国互联网协会归口发布，2024 年 1 月发布、2 月 28 日实施，现行有效。该标准由中国信息通信研究院牵头，联合中国移动设计院、中国电力科学研究院、中国民航信息网络、中国石油昆仑数智等单位共同起草，适用范围写明了两个方向：软件开发企业自评，以及第三方检测机构开展软件产品的代码自主率检测。

作为团体标准，它本身不具强制力。但它已被大量招标文件、验收细则与申报指南引用，实际上成为这一领域的技术共识口径。这带来一个操作上的提醒：招标文件里写的「代码自主率不低于 X%」，未必等于按本标准算出的 X%。有的文件只要求「自主开发代码行数占比」，不引入许可证惩罚项；有的把开源组件数量占比单独设限；还有的只要求提供成分清单而不要求给分。委托前应逐字核对招标或验收文件的技术条款，确认计算口径、测评范围（全量源码还是指定模块）与报告形式，再确定测评方案——口径没对齐就开测，是最常见的返工原因。

常见引用场景有四类，各有侧重：政务信息化项目验收与决算审计，关注是否达到合同或验收细则的阈值；国有企业采购与供应商准入，关注结果能否横向比较；首版次软件、首台（套）等申报，关注能否支撑「自主知识产权」的表述；信息技术应用创新项目的适配与迁移评估，关注开源依赖是否存在可行的替代路径。

测评内容

标准将检测内容分为四项，其中只有一项是纯粹的代码扫描。这一点常被误解为「跑个工具出个数」，实际工作量的大头在人工审核与确认环节。

• 相关软件自主可控性。对软件运行所依赖的操作系统、数据库、Web 中间件及其他必需软件分类评估：送检软件不含该类，视为合格；含有的，要看是否具备充分可替代性（包括国产替代路径），或是否为完整开源软件且送检方具备修改能力与授权。某一类不合格，该类按 25% 计分。
• 开源组件依赖性。标准要求工具检测与人工审核组合使用：先用成熟的商业成分分析工具扫描识别成分构成，再由人工判断组件缺陷的危害程度与许可证风险，最后与送检方确认开源组件依赖清单。这一环节既是计算的输入，也是最易产生分歧之处——工具识别的组件版本与送检方自述不一致时，须逐项核对。
• 代码总行数。统计源代码部分的行数，配置文件计入，注释与空行扣除，原则上按分行符计算。
• 代码安全性。先对源代码做静态安全审计，再对运行环境做系统扫描，漏洞结果由检测方专家审核后计入扣减。

计算上有一个容易吃亏的地方：自主率不是「自研行数 ÷ 总行数」。标准给出的计算式带有许可证惩罚项，开源代码的协议约束力越强、传染性越高，扣减越重。这意味着两套自研比例相同的软件，仅因引入的开源组件许可证组合不同，最终数值可能相差一二十个百分点。如果企业是在投标前才发现这一点，通常已来不及替换组件——这也是建议把测评前置到技术选型阶段的原因。

送检资料与前置条件

标准列出的送检材料共八项，缺一项即无法启动：

两项前置条件需要提前安排。一是检测环境由检测方与送检方共同搭建：送检方按安装手册完成运行环境与代码编译环境部署，并确保所部署的是送检系统的完整代码；检测方提供硬件与操作系统环境。二是检测前须验证两项事实：所安装软件包含功能清单中的全部功能，所用操作系统、数据库、中间件与清单一致。这项验证不通过，测评无法开始。

从实际经验看，卡住进度的通常不是技术问题，而是材料的一致性：软件名称在著作权证书、安装手册封面与申报表中的写法不统一，或开源组件清单凭印象填写、与工具扫描结果存在成批差异。这类问题不涉及技术判断，但每发现一处就要回流一次确认，耗时往往超过测评本身。

实施流程与周期

常规流程为：需求与口径确认 → 材料齐备性检查 → 环境共建与前置验证 → 工具扫描与人工审核 → 行数统计与安全审计 → 组件清单确认 → 报告编制与交付。

周期主要取决于三项因素：代码规模、开源成分复杂度、安全漏洞数量与整改轮次。十万行量级、成分清晰的项目，通常在两至三周内完成；百万行以上、多语言混合、存在大量二次封装组件或历史遗留代码的项目需要更长时间，其中人工审核往往是最耗时的一段。若招标或验收有固定截止时点，建议至少预留四周，并在此前先做一次内部自查——用同类工具先扫一遍，把明显的许可证冲突与严重漏洞处理掉，可以显著减少正式测评的往返次数。

适用对象与不适用情形

适用对象包括：需在项目验收或决算中提交自主可控证明的建设单位；以自主率作为投标技术指标、需要第三方佐证的软件企业；拟申报首版次软件、首台（套）等项目并需支撑「自主知识产权」表述的申报单位；开展信创适配、需评估开源依赖替代路径的单位；以及出于代码资产盘点、并购技术尽职调查等目的需要厘清成分构成的机构。

以下几类情形建议先确认，避免花了费用却拿不到可用的结论：

• 无法交付完整源码。只能提供部分模块，或核心算法以二进制形式交付的，测评对象不完整，报告会注明覆盖范围，可能不被受理方接受。
• 目标是证明「功能合格」而非「代码归属」。这类需求应委托软件测试，两类报告的结论不可互相替代。
• 招标技术条款与本标准口径不一致。需先与受理方澄清计算方式，否则按标准出具的报告可能与评分表对不上。
• 仅需要内部参考数据。企业自评即可满足的情形不必委托第三方；第三方报告的价值主要体现在对外证明力。

结果的使用与改进方向

拿到报告后有几个判断值得注意。第一，分数高低本身不构成结论，要对照受理方的具体要求看——有的场景阈值设在 60%，有的设在 80%，还有的只要求提供清单与说明，不设分值。第二，报告中的开源组件依赖清单往往比那个百分比更有实用价值：它直接指出哪些组件构成主要扣减、哪些存在许可证冲突风险。第三，安全漏洞扣减项是可改进的：因不合理配置导致的漏洞，若送检方可通过合理配置消除，标准允许忽略，这意味着整改后复测通常能提升数值。

如果目标是提高自主率，可行路径大致三条：替换传染性强的许可证类型组件、以自研实现替代通用开源实现、清理历史遗留的重复与废弃代码。三条路径都需要在版本迭代中完成，无法在测评当期临时处理。把自主率纳入研发日常管控——例如在代码入库环节就设置许可证白名单与成分扫描——比每次投标前突击测评更经济，也更经得起评审追问。

资质与服务边界

我司持有中国合格评定国家认可委员会（CNAS）实验室认可证书，认可领域为软件测试，可就认可范围内的检测项目出具带 CNAS 认可标识的软件测试报告。具体获认可的项目、参数与检测标准，以证书附表所列内容为准。证书情况可在企业荣誉栏目查阅。

源代码自主率测评不在上述认可范围之内，我司目前未开展该项检测业务，也不出具该类报告。本页提供的是标准口径解读与送检准备指引，不构成检测服务承诺。以下几点需要说明：

• 不代为出具结论。凡涉及自主率数值、成分认定与许可证合规判断的结论，须由具备相应能力的机构出具。我司不提供此类结论，也不对第三方报告的结果承担责任。
• 不承接材料包装。送检材料应由送检方按其真实情况编制，诚信承诺书所承诺的内容具有法律意义。我们可以就材料齐备性提供技术提示，但不代为编制或修饰。
• 软件测试报告不能替代自主率报告。两者测试对象、依据标准与结论指向均不同，任何一方都无法覆盖另一方。准备材料时请分别列项，不要指望用一份报告顶两项要求。
• 可承接的部分。软件功能、性能效率、信息安全性、兼容性、易用性等质量特性测试，以及首版次申报所需的技术佐证测试，属我司认可范围内的业务，可另行委托。

常见问题

自主率报告和软件测试报告能互相替代吗？
不能。测试报告的对象是可运行的程序，结论是功能、性能、安全等质量特性是否满足要求；自主率报告的对象是源代码，结论是代码成分的归属与比例。前者说明「软件好不好用」，后者说明「代码是谁的」。申报或验收材料若同时要求两项，须分别准备。

招标文件要求自主率不低于 80%，能保证算到吗？
没有任何机构可以事先保证数值。自主率由源码的实际成分决定，测评的作用是把既有事实量化出来，不能改变事实。可行的做法是在投标前先做一次自查扫描，评估当前版本的取值范围；若差距明显，只能通过替换组件或补充自研实现来改善，而这需要研发周期。任何承诺「包过某个百分比」的说法都不可信。

只提供部分源码可以测评吗？
技术上可以按约定范围实施，但报告会明确标注覆盖的代码范围与未覆盖部分。如果受理方要求的是整个产品的自主率，只测部分模块会导致报告与申报对象不一致，评审时容易被质疑。建议在方案阶段就确定范围，并把取舍理由记录在方案中。

开源组件清单能不能由检测方代为整理？
不能作为送检方材料使用。标准要求清单由送检方提供，检测方的职责是用工具扫描并与之比对确认。若清单缺失，正规做法是先由送检方补齐，再由工具结果校正。直接由检测方代填，等于让被检测方与检测方共用同一份事实来源，独立性不成立。

自主率低的软件是不是有质量问题？
两者没有必然关系。自主率衡量的是代码归属与依赖程度，不是代码质量。大量成熟软件大量使用开源组件、自主率不高，但功能与稳定性表现良好。反过来，全部自研的软件也可能存在严重安全漏洞。判断质量应看测试报告与安全审计结论，不应把自主率当质量指标使用。

同一套软件两次测评结果为什么会不同？
常见原因有三个：版本发生了变化，成分构成随之改变；开源组件清单的确认口径不同，例如是否把构建工具、测试框架计入；许可证类型的判定不同，同一组件在不同版本间更换协议的情况并不罕见。所以自主率是特定版本、特定依赖关系下的计算结果，跨版本比较意义有限，报告也会载明对应版本。

什么时候应该先做软件测试、再做自主率测评？
如果项目同时要求两类材料，建议先做软件测试。原因在顺序而非优先级：测试过程中会暴露功能缺陷与安全漏洞，这些修复往往涉及代码改动，改动后自主率需要重新计算；先测后评，可以避免测评做完又因修复而返工。若自主率是投标的硬性门槛，则可在研发阶段先做自查，把组件选型的风险提前处理掉。