英國公共部門的人工智能、開放代碼與漏洞風險
英國政府發佈指南,認為儘管人工智能加速了漏洞發現,但公共部門應繼續默認開放源代碼,同時加強修復能力。指南強調開放代碼不會創造弱點,但可能輕微減少攻擊者不確定性;因此建議保持開放,明確例外,並強化安全基線。
英國政府數字服務局與科學、創新和技術部於2026年5月14日聯合發佈了一份重要指南,旨在指導公共部門如何在人工智能(AI)加速漏洞發現的時代安全地開放源代碼。該指南針對技術領導者們日益關注的問題:AI輔助的漏洞分析是否意味着公共部門應停止默認公開源代碼?經過用户研究,指南明確指出,利用風險的主要驅動因素是系統中存在的弱點,包括未修補的漏洞、不安全的實現以及不安全的配置或部署,以及無法快速修復這些問題的能力。公開源代碼本身並不會創造這些弱點,但它可能會適度降低攻擊者的不確定性,並加快分析速度,尤其是在維護薄弱和修復緩慢的情況下。因此,該指南強化了安全運營公開訪問服務所需的最低操作能力。
指南的核心建議包括:首先,確保系統達到公開訪問的最低標準,包括明確的所有權、安全設計實踐、自動化運維以及可靠的修復能力。其次,保持默認開放的態度,因為將所有代碼設為私有會增加交付和政策成本,並減少重用和審查。第三,使例外情況明確並可審查,對於需要關閉的代碼,要求提供簡短的威脅模型,説明攻擊者、公開代碼帶來的風險以及實際的傷害路徑。第四,加強修復能力,假設發現到利用的時間窗口縮短,通過設置補丁服務等級協議、自動化依賴和漏洞管理,確保團隊能快速響應報告。
指南迴顧了政府現有的開源建議,強調用公共資金開發的代碼應默認公開和可重用,僅有有限且合理的例外。這一原則體現在服務標準、技術實踐守則、安全設計政策等多個標準中。指南假設團隊不將源代碼可見性作為主要的安全控制手段,而是遵循標準實踐,如絕不將秘密(如憑證、API密鑰、令牌和私鑰)提交到任何倉庫,並確保公共倉庫不包含會顯著增加可利用性的安全敏感實現細節,如內部主機名、IP範圍、管理端點和安全控制閾值。即使有了這些控制,如果公開代碼會創建特定、可信的傷害路徑,團隊可以作為合理的例外保持代碼關閉,但這不應成為新的基線。
AI驅動的漏洞檢測正在快速發展。英國AI安全研究所報告稱,前沿模型在受控評估中展現出顯著更強的網絡能力,例如2025年12月的《前沿AI趨勢報告》和2026年4月的《我們對Claude Mythos Preview網絡能力的評估》。這意味着部門面臨從發現到利用的時間窗口縮短。AI改變了分析的速度和規模,壓縮了弱點存在到被利用的時間,使得修復能力比以往任何時候都重要。訪問源代碼可以給攻擊者帶來優勢,減少不確定性並實現更快、更有針對性的審查,而且這種優勢可能隨着AI輔助而增長。然而,在實踐中,這種優勢相對於底層弱點的存在以及修補和緩解的速度通常是遞增的。因此,領導者的判斷不是源代碼訪問是否重要,而是實際中這種額外優勢是否足夠大,以至於有理由放棄默認公開的做法。攻擊者已經可以在沒有源代碼的情況下發現弱點,例如通過探測運行服務、模糊測試或分析二進制文件和依賴項,而防禦者可以使用相同的工具更快地進行審查和分類。
近期關於組織因AI代碼分析而限制對公共倉庫訪問的公開報道表明,領導者可能在不確定性下迅速採取全面關閉措施。本指南提供了一個替代方案:保持默認公開,但將公開作為一個有意的決定,並輔以最低維護和修復標準。在實踐中,生產風險主要受安全設計架構和實現、部署、配置、依賴項衞生和訪問控制的影響,而不是受通過公開源代碼可見的應用邏輯影響。許多嚴重漏洞是代碼中的邏輯缺陷,但攻擊者通常可以通過其他手段發現和利用它們。關鍵在於,源代碼可見性通常改變的是發現時間和攻擊者的不確定性,而不是是否存在弱點或緩解速度的主導決定因素。團隊應專注於縱深防禦方法,優先考慮安全設計交付、將秘密與代碼分離、強大的環境控制、監控和快速修復。這些控制措施無論代碼是公開還是私有都同樣有效。
指南還列出了額外的考慮因素:私有倉庫可能創造虛假的安全感,鼓勵安全通過模糊實現的思想,並降低修復根本弱點的緊迫性;公開後關閉代碼可能無法消除暴露,因為流行的倉庫經常被鏡像或分叉,即使低知名度的倉庫也可能已被研究人員或攻擊者索引或克隆;關閉可能成為一扇單向門,私有倉庫減少重用和外部審查,隨着時間的推移團隊分化,使得再次公開代碼更加困難;同樣的工具可用於防禦,開放性強化了這一紀律,而避免審查並不能消除缺陷,反而可能使弱點持續存在;開放性可以更早地暴露問題,公共代碼允許更廣泛的審查者發現問題,而關閉代碼則將發現集中在交付團隊和運營監控中;先例很重要,廣泛的“AI”作為關閉的理由很容易被複制,一旦常態化,會破壞跨政府在重用和標準方面的一致性。
最後,指南提出了公開訪問系統的最低標準:必須有指定的所有者和維護計劃;安全聯繫人和報告渠道;沒有秘密或敏感操作細節,並強制控制以防止提交秘密;安全設計基線,有證據表明系統遵循安全設計原則;自動化運維,包括依賴更新工具、漏洞和秘密掃描以及主幹保護;補丁期望,有商定的關鍵和高危漏洞處理時間表;對未維護代碼的安全姿態,如標記為存檔並退役或明確所有者。將代碼私有化並不能彌補缺乏所有權、補丁能力或運營保障的問題,因此無法安全維護的系統應進行修復或退役。如果團隊無法達到最低標準,領導者應解決底層運營差距,例如通過共享服務配備能力,或退役不再需要的系統。只有系統達到最低運營標準後,領導者才能使用現有的例外規則,即公開其他方面維護良好的代碼會創建特定、可信的傷害路徑。本指南旨在避免“默認私有”的漂移,這種漂移掩蓋了資源不足的維護。將代碼從公開轉為私有作為投資安全設計交付、所有權和修復的替代方案是一個警告信號,因為它減少了共享和審查,可能減緩跨政府和供應商的協調改進,並且無法消除運行服務中的根本弱點。各部門應將私有化視為針對特定、可信傷害路徑的例外控制,而不是能力不足的補償控制。