英國政府發布了關於公共部門人工智慧、開源程式碼和漏洞風險的指導意見，概述了各機構如何在安全發布原始程式碼的同時，降低人工智慧加速發現漏洞的風險。該指導方針旨在回應技術領導者日益增長的擔憂，即人工智慧輔助程式碼分析的進步是否應該迫使公共部門機構默認放棄公開原始碼的做法。

該指南指出，漏洞利用風險的主要驅動因素並非原始程式碼本身的發布，而是系統存在的弱點，包括未修補的漏洞、不安全的實作以及不安全的配置或部署實踐。使用者研究發現，公開發布原始程式碼或許能略微降低攻擊者的不確定性並加快分析速度，尤其是在結合人工智慧技術的情況下。但如果組織無法快速修復漏洞或有效維護系統，這些風險就會變得更加顯著。

該文件強調，安全運行可公開存取的服務本身就需要達到一定的運行成熟度，包括及時打補丁、安全部署、持續維護和有效的漏洞管理。雖然人工智慧可以加快漏洞發現的速度，但該指南指出，預設禁止公開程式碼並不能解決漏洞利用風險的根本原因。

英國建議為公共系統設定最低標準，要求明確所有權、採用安全設計、自動化安全維護和可靠的修復能力，同時明確指出隱私不應被視為替代控制措施。他們建議預設保持系統開放，因為將所有內容設為私有會增加交付和策略方面的額外開銷，並可能降低重用性和審查力度，開放性應作為基準，封閉性應僅在謹慎使用的情況下才應用。

如果必須有例外情況，則應明確定義並進行審查，要求提供一個簡短的威脅模型，該模型能夠識別攻擊者，解釋發佈內容增加了什麼，並概述一條切實可行的危害路徑，所有例外情況都應保持範圍狹窄、有時限，並需定期重新批准。

該指南強調需要透過縮短發現漏洞到利用漏洞的視窗期、強制執行修補程式服務等級協定 (SLA)、自動化依賴項和漏洞管理以及確保團隊能夠快速回應外部報告來加強補救能力，這一要求對程式碼是開放的還是封閉的都同樣適用。

英國政府澄清，最低運作能力要求已在現有的「預設開放」和「安全設計」指南框架下制定，而非新增安全要求。系統必須至少指定所有者，制定書面維護計劃，並明確指定責任團隊，該團隊可透過 CODEOWNERS 文件或同等控制措施進行管理，涵蓋程式碼庫、依賴項和支援生命週期。此外，還需建立明確的安全聯絡人和接收流程，並透過 SECURITY 文件或受監控的郵箱提供清晰的漏洞報告指南，並輔以結構化的漏洞分類工作流程。

儲存庫不得包含任何機密資訊或敏感的操作數據，必須實施強制控制措施，防止憑證洩露，並移除任何可能顯著增加攻擊風險的特定環境資訊。系統必須展現出安全設計基線，包括威脅建模、安全預設設定、最小權限原則和強化的公共接口，因為良好的操作規範無法彌補架構本身的不安全。

必須建立自動化的程式碼清理機制，包括相依性更新工具、漏洞和機密掃描，以及受保護的分支控制，以防止強制推送並要求對關鍵基礎設施進行檢查。必須為關鍵和高風險漏洞制定清晰的修補時間表並提供證據，必須明確標記並歸檔不再維護的程式碼庫，相關服務要麼被停用，要么被明確指定所有者和補丁路徑。

將程式碼私有化並不能有效彌補所有權、補丁能力或運作保障方面的不足，無法安全維護的系統必須進行修復或停用。如果團隊無法達到這個最低標準，領導階層必須透過提供資源（通常是透過共享服務）或停用不再需要的系統來解決根本問題；任何運作中的服務都必須明確擁有者和修補程式流程。只有在滿足這些要求之後，領導層才能應用現有的例外規則，並且僅限於發布維護良好的程式碼會造成具體且可信的危害的情況。

這些建議為組織機構設定了預設策略，為了給領導層決策提供更多背景信息，政府列出了一些注意事項，這些注意事項突出了默認關閉代碼庫的常見陷阱，並概述了影響實際風險的實用因素，無論代碼是公開的還是私有的。私有程式碼庫可能助長「安全隱患」的思維模式，降低解決潛在漏洞的迫切性，從而營造一種虛假的安全感。

政府呼籲在代碼發布後將其封閉，但這可能無法消除風險，因為即使代碼被設為私有，開源代碼仍然可以通過鏡像、分支、先前的索引或研究人員或攻擊者的早期克隆等方式，繼續被有能力的攻擊者存取。政府指出，封閉程式碼可能成為單向決策，因為私人程式碼庫會降低程式碼的重用性和外部審查，並且隨著時間的推移，會導致程式碼庫的內部版本和外部版本出現差異，從而使日後安全可靠地重新發布程式碼變得更加困難。

用於攻擊性發現的工具和實踐同樣可以應用於防禦性發現，隨著發現速度的加快，安全必須依靠持續的審查、測試和補救，其中開放性可以加強紀律，而缺乏審查並不能消除缺陷，反而可能導致漏洞持續存在。

開放性可以透過讓政府和供應商生態系統中更廣泛的審查人員參與，更早發現問題；而封閉程式碼則會將問題發現集中在交付團隊和內部監控流程中。先例也很重要，因為與人工智慧相關的廣泛封閉理由很容易在各個組織中複製，一旦規範化，就會破壞政府各部門在代碼重用、透明度和一致工程標準方面的協調性。

針對NCSC的指導意見，Averlon行銷主管Rajeev Raghunarayan在一份電子郵件聲明中寫道：「它抓住了核心問題：智能體人工智慧改變了風險模型，因為這些系統不僅生成答案，還會採取行動。這意味著組織需要認真思考智能體可以存取哪些資源、可以執行哪些操作、哪些輸入會影響它，以及誰應該承擔責任出現在出現問題時。」

Raghunarayan指出：身分和權限顯然是首要考慮因素，但網路存取同樣不容忽視。代理程式存取網際網路、下載工具、連接API或執行程式碼的能力可能至關重要。旨在動態解決問題的代理程式可能會在自身無法完成任務時下載軟體包、腳本或工具。這比僅依賴靜態權限要複雜得多，從而造成更大的攻擊面。

Suzu Labs 的總經理 Steven Swift 指出，人工智慧系統面臨的一大挑戰是問責制。他表示，即使人工智慧系統故障應該由人負責，他們也很容易將責任推卸給人工智慧，這意味著負責的人需要營造出人工智慧系統已建立完善的防護機制的假象。這通常是一種推卸責任的策略，但如果故障頻繁且嚴重到足以引發變革，那麼讓負責方承受壓力以改善其應對事件的能力仍然是有益的。

他也指出，人工智慧系統從設計上來說並不安全。LLM需要進行一些安全培訓，儘管不同類型的培訓內容有所不同，而且主要側重於一般安全問題，這意味著它永遠不會針對你的任何人工智慧系統進行特定應用的培訓。

人工智慧系統中最常見的故障之一，就是沒有將LLM輸出視為等同於不受信任的用戶輸入。由不受信任的用戶輸入引發的傳統安全問題，與因信任LLM輸出而產生的新安全問題之間有很多相似之處。主要原因是，智能體系統的設計初衷就是將LLM輸出作為系統下一步的輸入。因此，LLM輸出實際上就是後續處理的輸入。這意味著它很容易受到有意或無意的行為偏差的影響。

資料來源：https://industrialcyber.co/ai/uk-links-ai-accelerated-cyber-threats-to-operational-weaknesses-not-repository-openness-urges-remediation/