加拿大AI公司将开源模型和第三方Python组件打包销售，发现依赖库存在已公开的严重安全漏洞后，应立即排查受影响的软件版本、评估利用风险、修复并向客户提供安全更新。
客户通知没有适用于所有软件漏洞的统一法定时限。 如果漏洞已经导致客户个人信息遭到未经授权的访问、披露或丢失，还要判断是否触发隐私法的强制报告和通知义务。适用《个人信息保护和电子文件法》（PIPEDA）的企业，如果发生符合该法门槛的个人信息安全保障漏洞，须尽快向隐私专员报告并通知受影响个人；每宗个人信息安全保障漏洞的记录须保留24个月。
源5 源6
对企业来说，最重要的是建立三套管理机制：软件组件清单（SBOM）、漏洞修复记录和客户通知记录。即使暂时没有证据证明漏洞已被利用，也应保留风险评估和处置过程，避免日后无法说明哪些客户收到过受影响版本、企业采取了什么措施。
一、发现严重漏洞后，企业有哪些责任？
首先要区分三种情况。
第一种：发现漏洞，但尚无证据证明遭到利用。
例如，企业发现某个Python依赖库存在公开的远程代码执行漏洞，攻击者可能通过特定接口触发，但企业的软件配置暂时没有暴露该接口。
企业应立即确认：
- 哪些产品和版本包含该组件；
- 组件是否实际运行，漏洞代码是否可被触发；
- 产品部署环境是否满足漏洞利用条件；
- 是否存在可用补丁或安全替代版本；
- 是否需要暂停下载、发布或部署受影响版本。
加拿大网络安全中心（Canadian Centre for Cyber Security）的软件供应链安全指引明确提醒，开源组件可能存在开发者尚未发现的漏洞，软件供应商需要建立组件清单、漏洞识别、修补和通知相关利益方的管理程序。源1
第二种：漏洞已经被利用，但尚未确认个人信息泄露。
企业需要调查攻击者是否获得系统权限、是否植入恶意代码、是否访问客户环境，以及是否通过供应商的可信访问关系进入客户网络。
此时应当启动安全事件响应，通知受合同约束的客户和必要的合作方，并根据事件影响考虑暂停相关服务。
是否必须通知客户，要进一步查看软件许可协议、服务合同、数据处理协议、网络安全条款和行业监管要求。
第三种：漏洞已经造成个人信息安全保障事故。
这时需要进一步适用隐私法。
如果企业受PIPEDA约束，发生涉及其控制的个人信息的安全保障漏洞，并且根据具体情况有合理理由认为该事故造成个人重大伤害的真实风险（real risk of significant harm），企业必须向Privacy Commissioner of Canada报告，并通知受影响个人。
重大伤害包括经济损失、身份盗用、身体伤害、声誉受损和就业机会损失等。通知应尽可能在企业确定事故发生后及时进行。源5
二、加拿大不同地区的客户通知规则
隐私报告义务取决于企业经营范围、个人信息流向和适用法律。
| 适用地区或法律 | 主要要求 |
|---|---|
| 联邦PIPEDA | 达到重大伤害真实风险门槛，须报告并通知个人 |
| BC PIPA | 组织没有普遍强制报告和通知义务，但监管机构强烈建议在存在重大伤害风险时报告 |
| Quebec Law 25 | 机密性事故存在严重伤害风险时，须及时通知监管机构和受影响个人 |
BC企业尤其需要注意
BC的《个人信息保护法》（Personal Information Protection Act，PIPA）适用于省内受该法管辖的私人组织。
BC Office of the Information and Privacy Commissioner（OIPC）明确指出，目前BC PIPA没有对私人组织设立普遍强制的隐私事故报告义务，但监管机构强烈建议企业在存在重大伤害风险时主动报告。
企业还应考虑合同义务、客户关系和个人采取保护措施的需要，决定是否通知受影响客户。源7
因此，BC的AI公司发现Python依赖库漏洞后，如果只是存在潜在代码执行风险，尚无个人信息受到影响的证据，通常不能直接认定已经触发隐私事故通知义务。
但如果攻击者已经利用漏洞访问客户资料，就必须重新评估。
跨省经营的企业
PIPEDA仍可能适用。
例如，BC公司在温哥华开发AI软件，客户分布在安省和美国，个人信息在商业活动中跨省或跨国流动，相关信息处理可能受到联邦PIPEDA约束。
PIPEDA也适用于联邦监管企业，以及其他符合该法适用范围的商业活动。
企业不能只根据总部所在地判断适用哪部隐私法。源7
Quebec企业
Quebec的Law 25对个人信息机密性事故设有明确要求。
根据《私营部门个人信息保护法》第3.5条，企业发现涉及其持有个人信息的机密性事故后，应采取合理措施降低伤害风险并防止类似事故再次发生。
如果事故存在造成严重伤害的风险，企业须及时通知Commission d’accès à l’information和受影响个人。
第3.8条还要求企业建立机密性事故登记册，并在监管机构要求时提供副本。源8
三、企业必须建立SBOM软件组件清单
对销售AI软件的企业而言，最容易出现的问题是只知道自己使用了某个Python库，却不知道具体哪个产品版本包含它。
例如：
- AI模型使用Python运行环境；
- 模型调用PyTorch或其他机器学习组件；
- API服务依赖FastAPI等框架；
- 数据处理模块使用NumPy、Pandas等组件；
- 容器镜像还包含其他系统软件和第三方依赖。
当某个组件曝出漏洞时，企业必须能够反向查找所有受影响产品。
软件物料清单（Software Bill of Materials，SBOM）就是为此建立的软件供应链组件清单。
2026年，加拿大网络安全中心参与发布SBOM最低要素联合指引，明确其适用于开源软件、人工智能软件和软件即服务（SaaS）。该指引建议软件开发者、采购者和运营者建立并索取符合要求的SBOM。源2
一份实用的SBOM至少应记录以下信息：
| 记录项目 | 应保存的内容 |
|---|---|
| 组件名称 | Python库或模型组件名称 |
| 供应商 | 组件提供方或开发者 |
| 版本号 | 实际使用的准确版本 |
| 唯一标识 | 可用于查询组件的标识符 |
| 文件哈希 | 用于验证组件完整性的哈希值 |
| 依赖关系 | 哪个产品或组件调用了该依赖 |
| 许可证 | 组件适用的许可信息 |
| 生成信息 | SBOM作者、工具、时间及生成阶段 |
联合指引规定了SBOM应包含的最低数据字段，完整清单见指引全文（该页面链接到CISA发布的《2026 Minimum Elements for a Software Bill of Materials》）。源2
企业还应当保存每次正式发布的软件包及其对应SBOM，确保可以从客户购买的版本追溯到实际依赖组件。
四、发现漏洞后怎样修复？
建议建立以下处置流程：
flowchart TD
A[发现公开漏洞] --> B[定位受影响组件]
B --> C[核对产品版本]
C --> D{是否可以利用}
D -->|可以| E[立即隔离和修复]
D -->|暂未发现| F[持续监控和评估]
E --> G[测试安全补丁]
F --> G
G --> H[发布修复版本]
H --> I[通知受影响客户]
I --> J[保留处置记录]
实际操作中需要注意以下事项。
1. 先确认漏洞是否真实影响产品。
公开漏洞数据库中出现某个组件名称，并不意味着所有使用该组件的产品都存在相同风险。
应当核对受影响版本范围、漏洞触发条件、运行配置和实际部署方式。
2. 优先采用官方安全修复版本。
如果组件维护者已经发布修复版本，应当评估升级并进行兼容性测试。
如果暂时没有补丁，可以考虑关闭存在风险的功能、限制网络访问、隔离受影响服务或替换组件。
3. 检查模型和Python依赖之间的关系。
AI公司不能只检查直接安装的Python库，还要检查间接依赖。
例如，企业直接安装的组件没有漏洞，但其下级依赖库存在漏洞，仍可能影响最终产品。
4. 发布修复版本并管理旧版本。
企业应保留修复前后的版本信息、补丁内容、测试结果和发布记录。
NIST的Secure Software Development Framework（SSDF）建议软件开发者获取和维护安全的软件组件，记录组件来源和SBOM信息，并建立更新已部署组件的机制，在版本迁移成功前保留旧版本。源3
五、哪些记录必须保存？
企业最好建立统一的软件供应链安全档案。
建议分成五类：
组件和发布记录
- 模型名称及模型版本；
- Python组件名称和版本；
- 直接及间接依赖关系；
- SBOM及其生成时间；
- 组件来源、哈希值和许可证；
- 每次软件发布的版本号。
漏洞调查记录
- 漏洞编号（CVE，如有）；
- 漏洞公开信息和风险等级；
- 受影响组件及版本范围；
- 是否存在实际利用条件；
- 受影响产品和客户范围；
- 是否发现攻击或未经授权访问。
修复记录
- 修复方案及负责人；
- 补丁版本和发布时间；
- 测试报告；
- 暂时无法修复时采取的缓解措施；
- 重新开放服务的审批记录。
客户通知记录
- 哪些客户收到通知；
- 通知时间和渠道；
- 漏洞影响及风险说明；
- 建议采取的措施；
- 修复版本和升级方式；
- 客户反馈及后续处理。
隐私事故记录
- 涉及的个人信息种类；
- 受影响个人数量；
- 事故发生和发现时间；
- 访问、使用或披露情况；
- 伤害风险评估；
- 是否向监管机构和个人通知；
- 未通知时的判断理由；
- 后续整改措施。
特别注意：PIPEDA第10.3条及《Breach of Security Safeguards Regulations》第6条规定，适用该法的企业须将每宗个人信息安全保障漏洞的记录保留24个月，自企业确定事故发生之日起计算。监管机构可以要求企业提供相关记录。源6
这个24个月是隐私事故记录的法定保留期限，不能直接套用为所有SBOM、软件发布记录或一般漏洞报告的统一保存期限。
BC PIPA目前没有同样的普遍强制通知规定，但企业仍应保留调查、风险评估和整改资料，以便说明处理过程。源7
六、不要把安全宣传变成误导性承诺
AI公司销售软件时，还需要注意《Competition Act》的虚假或误导性宣传规定。
加拿大Competition Bureau指出，企业推广产品时，任何在实质方面虚假或具有误导性的陈述都可能受到该法约束。
如果企业在宣传中声称：
- 产品不存在已知安全漏洞；
- 所有第三方依赖均经过完整安全审计；
- 软件符合某项安全认证；
- 产品能够保证客户数据绝对安全；
就必须确保这些说法有事实依据。
尤其是已经知道严重漏洞，却继续使用未经限定的绝对安全承诺，可能带来额外的法律风险。
判断是否构成误导，还要考虑宣传文字的字面含义及其给消费者留下的整体印象。源9
七、NIST框架是否属于加拿大强制规定？
NIST的Secure Software Development Framework（SSDF）Version 1.1于2022年2月发布，是已经定稿的安全软件开发框架。
它将软件安全管理分成组织准备、保护软件、生产安全软件和漏洞响应四个方面，为软件开发者和采购者提供共同的安全管理语言。源3
需要注意，NIST SSDF属于技术管理框架，不能直接当作加拿大所有AI公司的法定义务。
加拿大网络安全中心的Baseline Cyber Security Controls同样属于面向中小企业的安全建议，包括制定事件响应计划、自动安装操作系统和应用程序补丁、备份加密数据，以及保护云服务和外包IT服务等。源4
这些建议可以成为企业建立内部安全制度的基础。
八、AI公司发布软件前的检查清单
准备将开源模型和Python组件打包销售的企业，可以逐项检查：
- 核对模型、代码及第三方组件的许可证。
- 建立直接和间接依赖组件清单。
- 为正式发布的软件版本生成SBOM。
- 记录组件版本、来源、哈希值和依赖关系。
- 建立公开漏洞监控和安全补丁管理机制。
- 明确漏洞分级、调查、隔离和修复负责人。
- 保存漏洞评估、修复测试和版本发布记录。
- 在客户合同中明确安全事件通知、补丁发布及客户配合义务。
- 制定客户通知模板和隐私事故响应程序。
- 判断是否适用PIPEDA、BC PIPA或Quebec Law 25。
- 对个人信息事故建立独立登记和保存制度。
- 定期核对产品宣传中的安全承诺是否有实际依据。
最关键的做法是：每一个对外销售的软件版本，都应该能够追溯它包含哪些组件、哪些版本存在漏洞、修复发生在什么时候，以及哪些客户需要采取升级措施。
对加拿大AI初创公司而言，SBOM、漏洞修复和客户通知应当成为软件发布及售后维护的一部分。发现公开漏洞后，及时评估和修复是基本的安全管理要求；是否必须向客户或监管机构报告，则要根据实际安全影响、个人信息风险、适用法律和合同分别判断。
拓展阅读
受PIPEDA管辖的AI创业公司误传客户数据：风险达标须尽快报告…：同样围绕「受PIPEDA」的站内帖。
安省AI公司采集人脸、声音和位置数据…：还是「PIPEDA」这件事，另一篇站内帖。
AI模型泄露用户个人信息，公司每起事件都要留档24个月…：同样围绕「AI模型」的站内帖。
PIPEDA给你30天要回自己数据的权利：加拿大个人信息访问指南：其他目的地的资料帖，与本文相邻的一条线。
参考资料
[源1] Canadian Centre for Cyber Security — Protecting your organization from software supply chain threats (ITSM.10.071)（核于 2026-11-12）
[源2] Canadian Centre for Cyber Security — Joint guidance on minimum elements for a software bill of materials（核于 2026-11-12）
[源3] NIST — Secure Software Development Framework (SSDF) Version 1.1, SP 800-218（核于 2026-11-12）
[源4] Canadian Centre for Cyber Security — Baseline Cyber Security Controls for Small and Medium Organizations（核于 2026-11-12）
[源5] Government of Canada — Personal Information Protection and Electronic Documents Act, Section 10.1（核于 2026-11-12）
[源6] Government of Canada — Breach of Security Safeguards Regulations, Section 6（核于 2026-11-12）
[源7] Office of the Information and Privacy Commissioner for British Columbia — Report a privacy breach（核于 2026-11-12）
[源8] Éditeur officiel du Québec — Act respecting the protection of personal information in the private sector, Sections 3.5–3.8（核于 2026-11-12）
[源9] Competition Bureau Canada — False or misleading representations（核于 2026-11-12）