关于软件供应链安全、开源治理与 AI 安全的观察、解读与实践。
行业报告显示绝大多数代码库都含有多年未更新的开源组件。停更组件不再有安全补丁、不再有人响应漏洞报告，是最容易被忽视的供应链风险。讲清识别、评级与四种处置策略。
许可证风险的难点不在单个许可证，而在组合：GPL 混入专有代码、Apache-2.0 遇上 GPLv2、声明与文件实际不符……拆解五种最常见的冲突形态与四级处置动作，全部可工程化落地。
人民银行等五部门《关于规范金融业开源技术应用与发展的意见》把开源治理写进了金融机构的合规义务。本文拆解监管要求的四个关键词，并给出台账、准入、监测、应急四位一体的落地框架。
两千多种开源许可证里，真正需要企业警惕的是哪几类？按传染性把风险分层，讲清宽松型、弱传染、强传染与商业限制条款的边界，以及三步落地的治理方法。
供应链投毒正从 npm 包蔓延到 MCP 服务器与 Agent Skill。回顾 xz、Shai-Hulud 与 postmark-mcp 等真实事件，解释为什么“恶意检测”不够，准入级能力审计才是新防线。
多项研究显示 AI 生成代码在约四成场景中引入可利用漏洞，而使用 AI 助手的开发者反而更自信。本文梳理实证数据、四个风险机理，以及“生产时刻检测”的治理路径。
《欧盟网络弹性法案》已生效：2026 年 9 月起漏洞报告义务落地，2027 年 12 月全面适用，违规最高罚 1500 万欧元或全球营收 2.5%。给出海企业的六条应对清单。
两类 SCA 的差距不在功能列表，而在检测原理：清单级只相信声明，片段级验证事实。解析五大盲区场景、各自的适用边界与一份可操作的选型评估清单。
一文讲清 SBOM 的三种标准格式（SPDX、CycloneDX、SWID）、全球法规要求（美国 EO 14028、FDA、欧盟 CRA、中国金融行业），以及从生成到运营的四步落地路径。
当代码由 AI 大量生产、依赖由 Agent 自动引入，传统“扫描 + 清单”的安全范式开始失效。我们需要把安全从“事后检查”前移到“生产时刻”。
很多团队把 SBOM 当成一份交差用的清单。但真正有价值的 SBOM，是能驱动决策的：哪些漏洞可被利用、哪条依赖该先修、哪个许可证会带来风险。
