观点

AI 软件供应链安全怎么做？从资产清单到智能体权限治理

企业治理 AI 软件供应链，需要同时看清代码、模型、数据和工具的来源，并把资产记录连接到准入、权限、测试和变更流程。本文给出分阶段落地方法，解释 AI-BOM 的作用以及智能体调用外部工具时的安全边界。

CRA 报告义务自2026年9月11日起适用，主体义务另有时间安排。本文区分漏洞与严重事件的触发条件，解释24小时、72小时及最终报告期限，并给出产品范围、责任分工和证据准备要点。

C/C++ 代码审查的结论往往取决于宏、头文件和编译器选项。本文解释真实构建信息如何帮助静态分析还原有效代码、追踪跨函数路径，并给出评估 AI Code Review 证据质量的方法和分析能力的适用边界。

CRA 准备工作需要把产品、组件、测试、修复和责任记录串联起来。本文用四步工程流程说明SBOM和安全检测各自提供哪些证据，如何保留例外与复测记录，以及为什么工具报告不能替代完整的符合性判断。

Public Domain不能替代对来源、版本、法域与第三方内容的核查。以SAX公开声明为线索，本文说明如何回应客户的许可审查，以及为何不能承诺所有权利在全球范围内一律消失。

Apache 2.0项目中发现GPLv2组件时，不能只修改仓库LICENSE，也不能把进程隔离视为自动豁免。本文区分GPLv2-only与or-later，说明独立聚合、组合分发和替代授权的判断顺序。

MySQL许可判断应分别看数据库、连接器、版本与交付方式。内部使用、独立服务连接和组合分发的事实不同，FOSS例外也非闭源商用通用豁免。本文提供可执行的核查顺序。

LGPL动态链接并非自动无风险，静态链接也不等于必须公开全部自有源码。以LGPL 2.1为例，本文说明库修改、重新链接、版权材料及逆向调试条款的核查方法，并提示PDF组件还需继续审查底层依赖。

罗盒诉玩友案提示，开源许可争议不能只看软件是否收费。本文依据公开判决和GPLv3文本，梳理版本授权、代码组合及源码提供证据，并说明个案结论不能直接推广为所有项目的统一规则。