随着国际技术竞争日益激烈，软件自主可控的重要性日益凸显。无论是企业选型还是产品研发，软件自主可控是证明产品能力、识别潜在风险、满足合规要求的关键依据。究竟关注哪些核心要点？
01 技术掌控能力，代码自主率是基础
技术掌控能力是自主可控的核心考察点，主要关注软件代码自主率。这不仅包括代码自主率，即软件中自主可控成分所占的百分比，更重要的是要突破“代码来源模糊”和“自研比例难界定”的痛点。
测评过程中，需借助专业工具将软件代码与开源库、第三方代码库进行比对。例如，若某系统代码与某开源框架相似度超过80%且未标注授权信息，则需立即追溯代码来源，确认是否具备合法使用权限。
02 持续交付能力，开源许可证合规性是关键
持续交付能力考察的是开源及第三方组件许可证的合规性。现代软件开发几乎无法避免使用开源组件，但其许可证合规性直接关系到法律风险。
需清晰识别软件中所有开源代码对应的许可证类型（如GPL、Apache、MIT等），分析是否存在许可证冲突、违规使用等合规风险。例如，若使用了具有“传播性”的GPL许可证代码而未合规声明，可能导致整个项目被迫开源，引发法律纠纷。
03 网络安全能力，全面排查漏洞与后门
网络安全能力要求考察代码缺陷、组件漏洞、资产漏洞及其他潜在的网络安全风险应对能力。这涉及到对软件自身安全缺陷及潜在恶意代码植入风险的全面排查。
测试方法包括静态测试（在非运行环境下对软件源代码或二进制代码进行检测，包括成分分析和安全测试）、动态调试（在仿真运行环境下对运行态程序进行安全测试）以及实网测试（在实际网络环境下对运行态程序进行安全测试）。具体采用哪种方式根据软件形态以及对安全性的考核度。
04 供应链安全，第三方组件的深度依赖分析
供应链安全验证是软件自主可控测试落地的另一关键维度，需防范“第三方组件带毒入场”和“供应链断链”等风险。测评报告不应仅识别直接依赖，还需深入分析多级依赖关系，评估溯源整个软件供应链的健壮性与可控性。
这就要求软件资产具备完整的软件物料清单（SBOM），能够清晰反映软件的构成及每个组件的情况，以实现自主可控能力评价和风险管理。报告需评估软件对操作系统、数据库、中间件等基础软硬件，特别是对国外闭源或存在断供风险技术的依赖情况。
4.1 网络交互行为可控性考核
此部分考核软件在运行过程中，所有出站（Outbound）和入站（Inbound）的网络连接行为。
通信对象可信度
域名与IP解析：软件连接的服务器域名、IP地址归属地是否可明确识别？是否依赖境外的服务提供商（如AWS、Azure、Google Cloud等）？
域名解析路径：软件使用的DNS服务器是自主可控的国内服务器，还是不可控的公共DNS（如8.8.8.8、1.1.1.1）？是否存在DNS污染或劫持风险？
证书链验证：TLS/SSL通信中所使用的证书颁发机构（CA）是否可信、可控？是否可能被CA机构实施中间人攻击？
通信内容安全性
加密算法合规性：是否采用国家密码管理局认证的商用密码算法（SM2/SM3/SM4）？是否使用了安全传输协议？是否使用了已破译或不安全的弱加密算法？
数据泄露风险：通过流量分析技术（抓包分析），检测上传至外部服务器的数据内容是否包含敏感信息（如用户隐私、系统信息、业务数据、加密密钥等）。所有数据传输是否都遵循“最小必要原则”？
通信协议可控性：软件使用的私有通信协议是否具备自主知识产权？其安全性是否经过独立评估？
通信行为合规性与透明度
行为白名单：软件的所有网络连接行为是否都有明确、合理的业务目的？是否存在未知的、“偷偷摸摸”的后台连接？
用户知情与授权：任何涉及用户数据的网络传输行为是否征得了用户明确授权？软件是否有清晰的隐私政策说明数据去向和用途？
4.2 升级更新机制可控性考核
此部分考核软件的更新机制是否存在被供应链攻击、劫持、断供的风险。
更新服务器可控性
服务器主权：更新服务器的域名/IP是否自主可控？其托管方和地理位置是否不存在断供风险？是否有备用的、位于国内的更新镜像源？
更新通道安全：从查询更新到下载安装的全流程，是否全部使用加密通道（HTTPS）？是否对更新包进行了数字签名验证？
更新内容可信性与完整性
数字签名与验证：更新包是否由开发方使用强密码算法进行数字签名？软件安装更新前是否严格校验签名，以确保更新包未被篡改？
完整性校验：是否通过哈希值（如SM3）校验更新包的完整性？
更新内容审计：能否获取更新内容的详细日志和变更说明？对于重大更新，能否进行安全性和兼容性测试后再部署？
更新机制灵活性
更新开关权限：用户或系统管理员是否有权完全关闭自动更新功能，并选择何时、以何种方式（全量/增量）进行更新？
离线更新能力：在隔离的网络环境中，是否支持通过离线包（如U盘、内部服务器）完成更新？这是涉密和高安全等级环境的刚性需求。
回滚机制：当更新出现问题时，是否提供安全、便捷的版本回退方案？
4.3 测评方法与技术
流量分析（Packet Analysis）：使用Wireshark、Fiddler等工具抓取和分析软件产生的所有网络流量。
主机行为监控：使用Process Monitor、Sysinternals Suite等工具监控软件的文件、注册表、进程行为，找出与更新相关的操作。
沙箱与动态分析：在隔离的沙箱环境中运行软件，模拟各种网络条件（如断网、DNS污染），观察其行为。
静态代码分析：审查与网络通信、更新逻辑相关的代码模块，分析其采用的算法、连接的硬编码地址等。
模糊测试（Fuzzing）：对软件的更新解析模块进行模糊测试，验证其处理恶意更新包时的健壮性。
05 持续维护与生态兼容：确保全生命周期可控
除了上述要点，还会关注开发团队的持续技术支撑、迭代更新及应急响应能力，确保持续可控。同时，信创生态兼容性也是重要考察点，即在实际主流国产CPU、操作系统环境中进行严格适配性、功能性与性能测试，验证其在信创环境下的可用性与成熟度。
一款软件即使代码自主率高，若无法在主流国产化环境中稳定运行，其“自主可控”价值也会大打折扣。
应用软件自主可控关注的点
代码自主率分析
重点评估软件中自主开发代码的比例，通常以文件数量、代码行数或模块占比为衡量依据。尤其关注核心模块的源代码归属，识别是否存在直接使用或高度借鉴国外核心技术的情况。
第三方成分与开源使用情况
对软件中使用的开源组件、共享库、第三方商业代码进行成分检测，明确其来源、版本及许可证类型。重点关注是否使用国外闭源组件、是否存在供应链中断风险。
开源许可证合规性
识别软件中所有开源代码对应的许可证类型，分析是否存在许可证冲突、违规使用等合规风险，如GPL传染性许可证未合规声明等。
知识产权与版权风险
检测代码是否涉及国外软件产权保护内容，比对已知知识产权库，排查潜在侵权代码片段，帮助企业规避法律纠纷。
供应链安全与依赖层次分析
不仅识别直接依赖，还深入分析多级依赖关系，评估整个软件供应链的健壮性与可控性，尤其关注对高风险国家技术的深层依赖。
安全漏洞与后门风险
结合成分分析，检测软件中是否包含已知安全漏洞、恶意代码或可疑后门，评估其在真实环境中的安全威胁。
国产化兼容性验证
测试软件在国产CPU、操作系统及基础软硬件环境中的兼容性、功能完整性和性能表现，确保其在信创环境中可替代国外产品。
持续可控与维护能力
评估开发团队是否具备持续迭代、漏洞修复和应急响应能力，确保软件全生命周期可控。
合规度
内容需贴合国家及行业对自主可控的政策法规要求，为企业提供合规性证据，支持项目验收和市场准入。
使用了第三方/开源组件的软件
不可避免的是，很多工业软件或者系统软件会用到第三方组件或者国外开源组件 等，这些如何判断为自主可控？
1. 技术维度的“可控” – “我能理解、我能修改、我能替代”
可获取性与可构建性，使用的开源组件源代码是否持续、稳定地可获取？我能否不依赖原开发者的环境，独立、顺利地完成编译和构建？
可分析性与可审计性，我能否对这部分代码进行安全漏洞扫描和后门检测？其代码是否足够清晰，可供专家进行深度代码审计？
可维护性与可修复性，当该组件出现安全漏洞或需要适配新系统时，我的团队是否有能力对其进行修复、打补丁和迭代更新，而不必完全依赖原项目方？
可替代性，我是否对该组件的技术依赖层次和影响范围有清晰的了解？如果该组件因许可证变更或断供而无法使用，我是否有备选方案（国产替代或自研）？替换的成本和周期是多少？
2. 法律与知识产权维度的“可控” – “我能合法用，权责清晰”
许可证合规性：对组件所使用的开源许可证（如GPL, Apache, MIT等）有彻底的识别和理解。是否存在许可证冲突？
3. 供应链维度的“可控” – “来源可靠，供应稳定”
来源多样性：是否过度依赖单一来源的组件？关键组件最好有多个供应商或分叉（Fork）版本可供选择。
供应链透明度：能否清晰地绘制出所有直接和间接（嵌套）依赖的图谱？是否了解每一层依赖的维护者、社区活跃度及所在国家？
持续供应保障：对于关键组件，是否采取了本地镜像、代码托管备份等措施？即使网络中断或原始仓库被删除，也能保证获取到代码。
信息安全测试、源代码审计等问题，欢迎咨询微信（微信：Kefocus）
