ARTICLE · 1031459
动辄十几万的“软件自主可控报告”,有没有更合理的替代方案?
甲方的合规需求没有错，错的是用十几万的成本去满足一个几千块就能解决的需求。
如果你是一家中小软件公司的老板，最近大概率会遇到这样的场景，你花了半年打磨出一款工业管理软件，产品过硬，功能不输大厂。好不容易等到一个不错的招标机会，翻开招标文件，技术要求全都满足，商务条件也能谈。然后你看到了一条不起眼的条款——
“投标人须提供第三方机构出具的《软件自主可控测评报告》。”
你打电话问了几家测评机构，报价从八万到十几万不等，周期一两个月。你算了算，这一个单子的利润，可能还不够付这份报告的钱。
这些数字对于大型国企和上市公司来说或许只是九牛一毛，但对于年营收几百万的中小软件厂商，这意味着一笔实实在在的“合规税” 。
1.甲方到底要什么？
其实，甲方要的东西并不复杂。
翻看某甲方的自主可控测评招标文件，评估要素写得很清楚：源代码自主率、源代码组成及来源、知识产权成果、开源协议合规性。
某电网的招标文件要求更直接，提供软件物料清单，详细列明所有组件、库、依赖项及其版本、许可证和来源信息，并声明软件是否为100%国产自主可控。
换句话说，甲方的核心诉求就一个—— “我需要知道你交付的软件里，有多少是自己的，有多少是开源的，有没有合规风险。”
这个诉求完全合理。但问题是，当前“自主可控测评”这个品类，把简单的事情复杂化了。
你去翻任何一份自主可控测评报告的评估要素，会发现它涵盖技术能力评估、知识产权评估、研制背景评估三大板块——不仅要测代码，还要审查企业股权构成、法人国籍、董监高人员背景。一个几十万行代码的软件产品，真正的技术评估可能只占报告的五分之一，但是一般都是十几万起步的报告。
而这些背景调查的成本，最终都摊在了中小厂商头上。
不是不需要合规，是需要合理的合规
2024 年 11 月 1 日，国标 GB/T 43848-2024《网络安全技术 软件产品开源代码安全评价方法》正式实施，从开源代码来源、安全质量、知识产权和管理四个维度，给出开源代码成分的评价要素与流程。
国际上，ISO/IEC 5230:2020（OpenChain）则把重点放在“企业开源许可合规体系”上：政策、角色、识别、跟踪、审查、留痕、可审计。
这说明什么？说明行业已经有了成熟的标准体系，来回答“软件里有多少开源代码、有没有合规风险”这个问题。代码开源率检测，正是这套标准体系下的技术手段。
它的原理并不复杂，通过软件成分分析工具，对代码仓库进行分层扫描，解构到模块、文件、函数级别，精准识别开源代码占比，输出包含开源/闭源代码行数占比、许可证类型分布、组件级漏洞影响面等核心数据的检测报告。国标明确说明，99%的软件产品都含有开源代码，关键在于知道它们在哪里、是什么许可证、有没有安全漏洞。
一份代码开源率检测报告能回答的问题，和自主可控报告中“源代码自主率、源代码组成及来源、开源协议合规性”的技术评估部分，在核心信息上高度重叠。但两者的成本差距，却是数量级的。
招标文件里的一句话，能改变很多事
问题的根源不在于技术，而在于招标文件的写法。
很多甲方的招标文件撰写者，其实并不清楚“自主可控报告”和“代码开源率检测报告”之间的区别。他们只知道“要合规”，于是把“自主可控报告”作为默认选项写进了招标文件——可能是从上一份文件里复制过来的，可能是咨询机构建议的，也可能只是“大家都这么写”。
但他们不知道的是，这一行字，把一批有实力、有产品、只是没有预算去做一份十几万报告的中小厂商，直接挡在了门外。
如果招标文件把“须提供《软件自主可控测评报告》”改为“须提供第三方机构出具的代码开源率(溯源率、自研率)检测报告或软件自主可控测评报告”，情况会完全不同。
中小厂商可以用几千到几万元的成本，拿到一份同样能证明代码成分透明性、开源合规性和安全风险状况的第三方报告。而甲方获得的实质性信息——开源代码占比、许可证风险、漏洞状况——并不比自主可控报告少。
事实上，已经有不少招标项目在走这条路。有招标文件直接要求“第三方测评机构出具的代码开源率测试报告”作为投标证明材料。有医院信息化项目明确以“代码自主率大于95%”作为评分项，要求提供第三方检测机构出具的检测报告。还有项目在合同中直接约定“对源代码进行开源率检测，最终输出《代码扫描检测》报告，明确代码开源率”。
这些案例证明，代码开源率检测报告完全可以在招投标场景中承担合规证明的功能，而且已经在这么做。
“自主可控”的核心应该是“可控”，而不是形式上的“自主”。 一份代码开源率检测报告，恰恰能帮助甲方真正了解一个软件产品的“可控”程度——它的代码组成是什么样的，哪些部分是自研的，哪些部分来自开源社区，开源部分是否合规、是否安全。这比一份笼统的“自主可控测评报告”提供的信息颗粒度更细、技术含量更高。
而对于那些真正拥有核心自研技术的软件产品，开源率检测报告中的“闭源代码占比”“自主代码行数”等数据，本身就是最有力的自主可控证明。不需要一份几十页的背景审查报告，几行代码统计数据就能说明问题。
给甲方的三条建议
如果你是甲方单位的采购负责人、技术负责人或招标文件撰写者，以下三条建议或许值得考虑：
第一，在招标文件中增加代码开源率检测报告作为替代选项。 措辞可以是：“投标人须提供第三方机构出具的软件自主可控测评报告，或出具的代码开源率检测报告。”这一句话的改动，成本为零，但能显著扩大合格供应商的范围。
第二，如果确实需要自主可控测评报告，请区分核心要素和附加要素。 源代码自主率、开源组件合规性、漏洞风险评估是核心，应该保留；研制背景评估（企业股权、法人国籍等）可以简化为声明函形式。核心的技术评估，完全可以通过代码开源率检测来完成。
第三，参考部分单位的做法，用软件物料清单（SBOM）作为基础合规要求。 SBOM能清晰列明软件的所有组件、依赖和许可证信息，是国际通行的软件供应链透明度标准。在此基础上，再根据项目安全等级决定是否需要更高层级的测评，而不是一刀切。
当一份十几万的报告成为参与招标的硬性门槛时，被挡在门外的不仅是中小厂商，更是甲方自己的选择空间。让技术的问题用技术解决。让中小厂商把精力花在产品上，而不是花在凑报告上。
这大概是对“自主可控”最务实的理解。
本文由信创之道整理，供学习交流使用，如若有误，欢迎后台指正。
