關於軟件供應鏈安全、開源治理與 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，是能驅動決策的：哪些漏洞可被利用、哪條依賴該先修、哪個許可證會帶來風險。
