CAN、UDS、ISO-TP、J1939 背后，最容易被忽视的不是大系统，而是那些安静跑在供应链里的长尾组件。
一辆车的软件供应链里，最容易被低估的，往往不是云平台、移动 App、账号系统这些显眼入口。
更容易被忽略的，是一个小型协议库、一段解析代码、一个 CAN 网关工具、一个车辆监控项目里的导入模块。
它们不出现在发布会主屏幕上，不会被销售材料重点介绍，也很少被管理层单独拿出来问：这个组件谁在维护？谁做过安全审计？出问题后谁负责修？
但只要它处理外部输入，它就是安全边界。
2026 年 5 月 1 日，16 个汽车与嵌入式开源组件相关的 CVE 进入公开状态。公开记录涉及 AGL、Open-SAE-J1939、isotp-c、uds-c、socketcand、cannelloni、OpenAMP、OVMS3 等项目，覆盖 CAN、UDS、ISO-TP、J1939、CAN 网关、车载应用框架、车辆监控系统和嵌入式加载路径。
按问题计数，这批记录对应 17 个漏洞；其中 socketcand 的两个相近问题由同一个 CVE 跟踪，所以公开编号是 16 个。
这篇文章只谈公开编号、行业风险和防守动作。不展开攻击材料，不讨论还在协调中的问题，也不把这些 CVE 写成一条直达车辆核心能力的远程攻击故事。
公开记录照出的，是另一件更扎实的事：
汽车开源软件供应链里，有一批很小、很基础、很安静的组件，正在承担超出自身维护资源的安全责任。
这不是漏洞秀。
这是长尾账单。
小库，不等于小风险
汽车安全常被讲成几个熟悉入口：车联网云、手机 App、蓝牙钥匙、OTA、账号体系。
这些入口当然要守住。但软件定义汽车不是只由这些入口组成。车端还有大量底层组件在做更基础的工作：接收一帧报文，重组一段诊断数据，解析一个采集文件，转发一次本地调用，加载一段嵌入式镜像。
这些动作听起来普通，安全问题也常常藏在普通动作里。
一个长度字段，被当成可信值。
一个分片序号，被直接带进数组访问。
一个本地服务，被默认放在“可信环境”里。
一个历史开源库，被下游项目复用多年，却没有进入同等级别的审计流程。
车端攻击面并不总是从高大上的入口开始。它也可能从一个“小到没人开会讨论”的组件开始。
代码行数不大，不代表风险小。
维护者少，不代表使用范围小。
项目名不响，不代表它不在供应链里。
汽车安全账，不能只按项目名气来算。
它要按信任边界来算。
这批 CVE 暴露的不是单点，而是一类习惯
把这 16 个公开 CVE 放在一起看，最有价值的不是某个编号，而是背后反复出现的工程习惯。
第一种习惯，是过度相信协议字段。
CAN、CAN FD、UDS、ISO-TP、J1939 里，长度、序号、DLC、分片状态都是日常字段。正常设备会发正常数据，正常流程会走正常路径。工程代码写久了，人很容易把这种“正常”当成安全前提。
攻击者不会配合这种前提。
外部字段一旦影响内存复制、数组访问、缓冲区大小或状态机推进，就不能只靠协议文档里的理想情况兜底。协议栈越靠底层，这个问题越难被上层业务看见。等数据变成对象、结构体、事件或回调时，风险已经被包装过一层。
第二种习惯，是低估本地边界。
汽车安全里，最不严肃的叙事，是把所有风险都写成“一步到核心系统”。现实没这么戏剧化。更常见的路径，是分层推进：应用、诊断设备、售后工具、网关、车载主机、本地服务，每一层都可能成为下一层的入口。
所以，本地问题不等于低风险问题。本地边界决定一个受限组件能不能影响更高权限服务，一个普通输入能不能进入更敏感的解析路径，一个局部缺陷会不会变成后续动作的跳板。
第三种习惯，是把开源长尾交给运气。
不少汽车相关开源组件来自社区项目、研究项目、个人维护项目，或者多年复用下来的小库。维护者未必有安全预算，项目未必有持续 fuzzing，CI 未必跑 sanitizer，商业 SAST、MISRA-C、供应链响应流程更不一定覆盖到它们。
这不是指责开源维护者。
问题落在下游：当 OEM、Tier-1、工具厂商、集成商把这些组件放进产品生命周期后，长期审计、补丁回流、回归测试、漏洞响应由谁负责？
这笔账不会因为组件小就消失。
它只会延后。
Innora 值得讲的，不是“AI 找到了漏洞”
这组公开 CVE 很容易被写成一句简单的话：AI 找到了汽车漏洞。
这句话有流量，但太轻。
Innora 更值得被看见的，是把 AI 放进了一条安全研究流水线，而不是把 AI 当成神谕。
这条流水线里，模型负责加速阅读，研究员负责判断边界。一个候选点要站得住，不能只靠一句“看起来危险”。它要有真实路径，要有上下文，要经得起最小化验证，也要在公开表达时收住不该公开的细节。
给厂商的是完整材料和修复建议。
给公众的是公开事实和防守方向。
这里面，AI 不是主角。
主角是证据、判断和边界。
一个成熟的 AI 安全团队，不能只会生成“疑似漏洞”。它要把疑似变成证据，把证据变成公开记录，把公开记录变成修复建议，再把经验沉淀成下一轮审计流程。
Innora 这组结果的价值，就在这里：它展示的不是一个模型的灵感，而是一套能交付的工程能力。从目标选择到代码审计，从变体追踪到动态验证，从漏洞协调到风险表达，还要把技术结果翻译成行业能执行的防守动作。
AI 安全进入工程化阶段后，拼的不是谁更会讲故事，而是谁能把故事落到证据、编号、修复和流程上。
别把它写成“车被攻破”
汽车安全传播有个老问题：为了吸引注意力，把局部漏洞写成完整攻击故事。
这样容易出圈，也容易失真。
对这组公开 CVE，更稳的边界是：
它们不是量产车辆演示。
它们没有证明某个具体车型会受到直接影响。
它们不涉及车厂私有固件测试。
它们证明的是：一批汽车与嵌入式开源组件里，存在已经公开编号的安全缺陷；这些缺陷覆盖协议解析、网关转换、车载框架、本地服务、文件导入和嵌入式加载路径；其中一部分在现实攻击路径里可能承担放大器或跳板角色。
这已经足够严肃。
不需要再加戏。
懂车端安全的人都知道，一条完整路径通常由入口、权限、持久化、横向移动、诊断访问、总线接入、网关策略、日志与更新机制共同组成。
把一个漏洞吹成整条路径，是营销。
把一组公开 CVE 放回供应链治理，是专业。
OEM 和 Tier-1 现在要补的，不是稿子，是流程
这批 CVE 对防守方的价值，不在围观漏洞，而在回头盘流程。
把小型 C/C++ 依赖放进 SBOM。
SBOM 不能只登记大框架、大供应商、大中间件。CAN、UDS、ISO-TP、J1939 这类小型协议库，也要进入 CycloneDX 或 SPDX 清单。至少要知道用了哪个项目、哪个版本、谁维护、上次提交是什么时候、是否被 fork 过、补丁如何回流。
没有清单，就没有响应。
让 sanitizer 成为日常门槛。
ASAN/UBSAN 不该只出现在安全研究员的桌面上。对 C/C++ 协议解析器、文件导入器、诊断服务、网关转换器来说，它们应当进入 CI。许多边界问题不需要昂贵平台才能发现，需要的是把异常样本和回归样本放进流程。
**给协议解析器一套硬规则。**
不是每个项目都能立刻上完整商业工具链，但高收益规则可以先落地：边界复制、整数转换、条件判断、危险标准库用法、长度字段与缓冲区容量的一致性。
协议解析器不是普通业务代码。
它是外部世界进入内部状态的第一道门。
给关键长尾依赖建立托管 fork。
关键依赖长期无人维护，或者只有单维护者，下游不能只等上游。更稳的做法，是建立内部托管 fork：保留来源，跟踪上游，应用补丁，跑 CI，维护回归样本，明确安全响应责任。
维护一个小型解析库，成本通常低于一次供应链事故后的被动排查。
披露通道不要只靠一个入口。
对汽车开源长尾项目，维护者邮件、GitHub Security Advisory、CVE 请求最好并行使用。公开编号只是开始，能降低风险的是补丁、测试、版本发布和下游通知。
AI 安全的分水岭：从能说，到能交付
过去一年，AI 红队、AI 安全、自动化漏洞挖掘被频繁讨论。
行业最终看的不会是演示视频。
行业看交付物。
有没有真实漏洞？
有没有公开记录？
有没有误报过滤？
有没有可重复证据？
有没有负责任披露？
有没有把研究经验反哺到防守流程？
这组汽车开源组件 CVE 的意义，就在这里。
它让“AI 辅助安全研究”从口号落到硬对象上：公开 CVE 编号、可归类的问题模式、可执行的防守建议、可审计的披露边界。
Innora 不需要把 AI 描述成万能。
更有说服力的表达是：经验丰富的研究员掌握 AI 工具后，把原本分散、低效、依赖个人直觉的安全审计，推进成更快、更稳、更可复盘的工程流程。
这是 CTO、产品安全负责人、OEM 安全团队和 Tier-1 供应链团队该关注的变化。
模型会制造噪声，但流程能过滤噪声。
模型会给候选，但证据决定结果。
模型能加速阅读，但人要对结论负责。
结语
16 个公开 CVE 之后，最该记住的不是编号本身。
而是这笔账：
汽车软件供应链的安全，不只属于云端平台、移动入口和明星组件。
它也属于那些没人写宣传稿的小型协议库、解析器、网关工具、诊断组件和本地服务。
它们安静地存在于系统里，也安静地承担着信任。
Innora 把这笔账翻出来，不是为了制造恐慌，而是为了让行业更早补上它：清单化、验证化、持续化、责任化。
AI 带来的变化，也不是让漏洞研究变得神秘。
恰恰相反。
它让成熟的漏洞研究更像工程：可重复、可解释、可披露、可改进。
这就是汽车开源组件长尾安全账的起点。
公开 CVE 编号
本组汽车与嵌入式开源组件相关公开 CVE：
CVE-2026-37525、CVE-2026-37526、CVE-2026-37530、CVE-2026-37531、CVE-2026-37532、CVE-2026-37534、CVE-2026-37535、CVE-2026-37536、CVE-2026-37537、CVE-2026-37538、CVE-2026-37539、CVE-2026-37540、CVE-2026-37541、CVE-2026-42467、CVE-2026-42468、CVE-2026-42469。
注：按问题计数为 17 个；其中 socketcand 的两个相近问题由 CVE-2026-37538 统一跟踪，因此公开编号为 16 个。
公开来源
- CVE Services API：https://cveawg.mitre.org/api/cve/
- CVE-2026-37525 示例记录：https://cveawg.mitre.org/api/cve/CVE-2026-37525
- CVE-2026-42469 示例记录：https://cveawg.mitre.org/api/cve/CVE-2026-42469
- CVE Program 说明：https://www.cve.org/
