NHS 關閉開源程式庫：SDLC-8 與英國科技守則的正面衝突
shkspr.mobi / LWN.net · 2026-05-01
英格蘭 NHS（National Health Service）於 2026 年 4 月 29 日發出 SDLC-8 指引，要求所有 NHS 公開程式庫在 2026 年 5 月 11 日前轉為私有，除非各團隊取得工程委員會的個別豁免。此舉與英國政府的《科技守則》（Tech Code of Practice）第 3 點「開放且使用開源」直接牴觸。
SDLC-8 的理據
NHS 在指引中的理據如下：「公開程式庫實質上提高了原始碼、架構決策、配置細節及上下文資訊被意外揭露的風險——尤其是考量到 AI 模型大規模程式碼攝取能力的快速進展。」指引特別點名了 "Mythos" 系列的 AI 漏洞掃描工具，認為這類工具降低了從公開程式庫中自動提取可攻擊資訊的門檻。
政策衝突的具體內容
英國政府的《科技守則》點 3 要求政府與公共機構：預設採用開源軟體、以開源方式發布自行開發的程式碼（若對使用者無安全顧慮），並積極參與開源社群。NHS 數位化（NHS Digital，現已併入 NHS England）過去曾以 COVID-19 接觸追蹤應用程式為例，展示大規模公開部署的程式庫在不發生安全事故的情況下可公開發布。
Terence Eden（曾推動英國政府採用開源政策的前顧問）批評此舉為「過度反應」：NHS 程式庫中的多數程式碼是前端介面、行政工具和資料管線，並非存取臨床資料的核心系統。他已自行備份所有 NHS 公開程式庫，以防原始程式庫在轉私有後失去存取性。
安全性論據的問題
資安研究社群對「閉源提高安全性」的論點存在長期爭議。「安全透過隱晦」（security through obscurity）作為主要防禦手段，在對手擁有足夠資源的情況下（如 AI 輔助掃描），其效果受到質疑。公開程式庫反而允許獨立研究者在漏洞被利用前發現並回報問題——這是 NHS COVID-19 應用程式案例所示範的。
SDLC-8 的豁免機制（個別團隊申請）在規模上也存在問題：NHS 擁有數百個程式庫，逐一申請豁免的流程可能在實際操作上等同於全面關閉，而非針對性管理。
原始來源：NHS Goes To War Against Open Source、LWN: Eden: NHS goes to war against open source
Spotify：用 Claude Code Plugin 打造廣告 API 的自然語言介面
Spotify Engineering · 2026-05-01
Spotify 工程團隊發表了一個案例：以 OpenAPI spec 和 Markdown 文件為輸入，透過 Claude Code Plugin，建立一個可用自然語言操作廣告 API 的工具，全程不撰寫任何已編譯的程式碼。
Plugin 架構
Claude Code Plugin 允許開發者將結構化文件（OpenAPI YAML、Markdown 說明）注入到 Claude 的工具上下文中，讓模型在會話中自動推理出哪個 API 端點對應使用者的自然語言請求，並產生對應的 API 呼叫。Spotify 的廣告 API 具有相對固定的操作集（建立廣告活動、調整預算、查詢報表），這使得 OpenAPI spec 足以提供足夠的上下文。
從 spec 到對話介面的流程
工程師首先整理既有的 OpenAPI 規格文件，為每個端點補充 operationId 和 description 欄位（這些欄位直接成為模型選擇工具的依據），並撰寫業務規則說明 Markdown（如「建立廣告活動前必須先選定受眾分群」）。Plugin 設定將這些文件掛載至工具上下文後，Claude 便可根據對話內容序列化多步 API 呼叫，並在中途確認需要使用者決策的參數。
無編譯程式碼的取捨
這個方法的優勢在於快速原型與迭代：更新 API 端點後，只需更新 OpenAPI spec，不需重新部署任何服務。限制在於：複雜的業務邏輯（分支條件、多 API 依賴的事務）仍需在 Markdown 中以自然語言描述，模型對邊緣情況的處理可靠性取決於 prompt 品質。Spotify 將此定位為「內部工具加速器」，而非面向終端使用者的生產介面。
原始來源：Spotify Engineering: Building a Natural Language Interface to the Spotify Ads API
開源維護者需要什麼：現有程式碼托管平台的功能缺口
nesbitt.io · 2026-05-02
Andrew Nesbitt 針對程式碼托管平台（code forge）的功能設計提出了系統性的批評：目前的平台設計以貢獻者（contributor）的工作流程為中心，而維護者（maintainer）面臨的核心挑戰——管理下游依賴者、協調跨專案影響——卻幾乎沒有平台級別的工具支援。
下游測試
維護者在推出新版本後，往往透過大量 issue 才得知自己破壞了哪些下游專案。Nesbitt 提出，forge 應在主分支合併後自動對已知的下游依賴者（透過 lockfile 關係圖識別）跑測試，在發布 tag 之前就提示維護者潛在的破壞性變更。這需要 forge 維護一個倒置的依賴圖（reverse dependency graph），這超出了目前大多數平台提供的功能。
依賴訂閱（Dependency Feeds）
維護者需要知道其依賴的上游狀態變化：棄用（deprecation）通知、維護狀態變更、安全公告、程式庫搬遷。目前這些資訊分散在 changelog、GitHub releases、npm 公告等不同管道，缺乏統一的訂閱機制。Nesbitt 提出 forge 應透過 lockfile 分析建立依賴訂閱 feed，讓維護者可設定通知規則。
Fork 網路可見性
當一個專案失去維護時，活躍的 fork 往往藏在原始程式庫的 "Forks" 標籤下，沒有顯示哪些 fork 實際上仍在開發、哪些 fork 合併了重要的修補。Forge 應在原始程式庫頁面主動展示活躍 fork 的統計資訊（最近提交、PR 數量、star 增長）。
CI 安全預設值
GitHub Actions 的預設設定對企業使用者有所優化（如 GITHUB_TOKEN 的預設權限），但對開源維護者而言可能造成安全隱患。Nesbitt 建議新的 forge 預設使用 pinned action 版本（而非 @main 或 @v1）並隔離快取，降低供應鏈攻擊的影響面。