開放原始碼不是安全邊界

2026年5月14日，英國Government Digital Service發布了公共部門在AI、開放程式碼與弱點風險上的指引。這份指引回答了正確的問題：AI可以降低發現弱點的成本，但儲存庫私有化仍然不會因此成為安全邊界。¹

9天前，一份公開報導指出，NHS England計畫將數百個GitHub儲存庫設為私人，原因是內部擔心AI弱點工具能大規模檢查公開程式碼。²這份焦慮可以理解。提出的控制手段卻不成立。把程式碼藏起來，是把「被發現」當成威脅；嚴肅的安全工作，會把「尚未修補的弱點」當成威脅。

開放原始碼安全要進步，靠的是降低真實暴露：程式碼中沒有機密、例外清楚、儲存庫有人負責、揭露管道可用、修補快速，並且有公開證據證明修正已送達使用者。儲存庫私有化可以支援特定例外，但不能取代這套運作方式。

重點摘要

GDS表示，公共部門團隊應預設維持程式碼開放，審慎檢視例外，並聚焦於真正會改變實際風險的務實因素。¹這個答案勝過儲存庫私有化恐慌，因為公開程式碼可能早已存在於分支、鏡像、快取、套件產物、容器映像、截圖、產生出的用戶端，以及先前複製的版本中。更重要的是，公開程式碼讓更多人能檢查、重用、回報並改進它。¹³

面對AI弱點發現，正確反應不是「全部改成私人」。正確反應是：移除機密、分類敏感程式碼、公布清楚例外、執行相依套件與機密掃描、維護弱點揭露管道、快速修補，並保留證據，證明開放程式碼有人負責。¹⁴⁵

關鍵重點

• 給工程主管：私有化在狹窄情境下可以降低暴露，但無法取代歸屬、盤點、修補與揭露。
• 給公共部門團隊：只要搭配明確例外，涵蓋機密、詐欺控制、敏感架構與未發布政策，預設開放仍然可行。
• 給安全團隊：AI提高了回應能力的價值。沒有分流管道的私人儲存庫，仍然不及格。
• 給代理團隊：程式碼可見性只是攻擊面之一。工具權限、狀態邊界、對外連線控制與發布關口，比儲存庫看起來是否私人更重要。
• 給維護者：少製造謎團。良好文件、清楚的安全聯絡方式，以及小而有人負責的服務，比一整排私人儲存庫更能降低風險。

恐慌把可見性誤認為弱點

AI弱點掃描器改變了檢查的經濟成本。過去，一個人需要時間、技能與耐心，才能搜尋整個程式碼庫。有能力的模型可以更快檢查更多程式碼，串連跨檔案線索，並產生更多候選發現。這種變化，會讓原本就有脆弱程式碼、模糊歸屬與緩慢修補路徑的團隊承受更大壓力。

但儲存庫可見性不等於弱點。公開程式碼可以暴露錯誤。私人程式碼也可以含有同一個錯誤。攻擊者往往能從二進位檔、API流量、用戶端套件、套件內容、容器層、日誌、文件、相依套件中繼資料，或舊的複製版本推測行為。GDS也提出同樣務實的觀點：把曾經公開的儲存庫改成私人，未必能阻止有能力的對手存取，因為熱門專案通常已有分支或鏡像，就連低調儲存庫也可能早已落入研究人員或攻擊者手中。¹

這項提醒很重要，因為「關起來」看似有所作為。實際上，它可能降低公共問責，卻讓技術弱點原封不動。團隊可能失去外部審查、共享修正與重用機會，卻幾乎無法防範早已複製程式碼的人。

開放原始碼也會留下稽核軌跡。公開歷史記錄顯示誰改了什麼、修正何時落地、維護者如何回應回報，以及專案是否仍受到照管。私人程式碼會讓同儕團隊、供應商、研究人員，以及可能重用或改進該工作的其他公共機關看不到這些訊號。

預設開放並不天真

GDS並未主張每一行程式碼都應放到公開網際網路上。較早的GOV.UK開放原始碼指引，已列出保留閉源的正當理由，包括金鑰、憑證、詐欺偵測演算法與未發布政策。³Technology Code of Practice也把開放與安全、隱私義務並列，而不是互相對立。⁴

更強的規則，是預設開放並搭配具體例外。這種政策形態會迫使團隊說明風險，而不是把「安全」當成包山包海的分類。機密不該存在於儲存庫中。詐欺訊號可能需要限制可見性。未發布政策服務可能需要限時暫緩公開。至於只是讓人覺得尷尬的程式碼庫，並不符合例外條件。

英國公共部門的實務手冊也指向同一方向。它描述了一項期待：政府軟體與程式碼在適當情況下，應預設採開放原始碼、以開放方式開發，並以核准授權發布。⁵DWP的開放原始碼發布政策也遵循同一模式：鼓勵以開放授權發布，同時透過明確控制保護敏感原始碼。⁶

這個區分能保護品質。以開放方式寫程式碼的團隊，往往會寫出更好的README、更清楚的安裝說明、更明確的issue歷史，以及更具體的資料邊界，因為外部人士可能會閱讀這些工作。GOV.UK指引指出，發布程式碼能改善文件、可維護性、資料清晰度與安全回饋。³當團隊因AI壓力而把一切都埋起來，這些好處也會一併消失。

真正的控制在於修補速度

AI改變的是時鐘。發現更快，回報量上升，誤報也會增加。我在當您的代理發現弱點中談過同一種能力壓力：沒有驗證與修復，發現本身意義有限。團隊需要分流、歸屬路由、修補、揭露與發布證據。儲存庫私有化不會提供其中任何一項。

CISA的Vulnerability Disclosure Policy平台正是為此而存在。該平台提供聯邦民用機關一個管道，用於接收、分流並路由公共安全研究人員回報的弱點。⁷CISA的協調式弱點揭露計畫也涵蓋關鍵基礎設施中的弱點，包括開放原始碼軟體與AI系統，並強調在公開揭露前協調緩解措施。⁸

NCSC則透過弱點回報與揭露指引，為英國組織提供同樣的營運框架，包括工具包，以及政府部門可直接採用的回報路徑。⁹共同主軸很簡單：接受外部人士會找到錯誤，然後讓回報與修補真正可運作。

這個框架會把AI弱點發現，從「隱藏的理由」轉為「改善回應迴路的理由」。如果模型能在您的公開程式碼中找到錯誤，團隊應該問5個問題：

無論程式碼開放或關閉，這些答案都能降低風險。隱藏儲存庫只會改變今天誰能看到原始碼。它不會創造負責者、修補程式或揭露管道。

更好的決策規則

團隊需要一套決策規則，把尷尬、暴露與真正敏感區分開來。

這條規則也能避免一種常見失敗：因為團隊無法分類任何東西，所以乾脆全部關閉。儲存庫盤點應回答服務做什麼、碰到哪些資料、誰負責、執行哪些機密掃描、哪些相依套件重要，以及回報如何送到維護者手中。如果團隊沒有這些答案，代表存在營運缺口。改變儲存庫可見性或許能把缺口藏在公眾視線之外，但缺口仍然存在。

代理讓邊界問題更大

AI程式碼代理讓同一個教訓更鮮明。儲存庫邊界無法阻止代理在允許權限內做出不安全決策。我在代理沙箱安全只是一項建議中寫過這種模式：危險動作通常發生在權限集合之內，而不是之外。同樣的組合問題也推動了軟體供應鏈攻擊：每個單獨看似合理的部分，最後串成一條有害路徑。

看不見的代理問題也適用於開放原始碼政策。團隊無法治理看不見的東西：工具路徑、產生出的產物、快取、發布狀態、揭露佇列與負責者移交都很重要。

開放原始碼政策應該向代理安全學習。有用的邊界位於動作層與回應層：

• 在工具接觸不受信任的輸入前，先進行分類；
• 從程式碼、歷史記錄、日誌、套件與產生出的資產中移除機密；
• 依信任層級分隔建置快取與發布產物；
• 限制自動化工作流程的對外網路路徑；
• 在發布、部署或宣稱修正完成前，要求證據；
• 為外部研究人員提供安全且有文件記載的回報路徑。

這些控制不仰賴原始碼保密。它們仰賴團隊知道敏感材料在哪裡，以及哪些動作可能造成傷害。如果儲存庫含有真正的機密，暴露後才改成私人，是在解錯問題。應輪替機密、盡可能從歷史記錄移除、使舊產物失效，並記錄事件處理路徑。發布邊界之所以重要，是因為對外輸出需要比本地分析更強的關口。

這就是為什麼GDS的指引方向正確。它沒有否認AI改變了弱點發現。它拒絕的是膚淺結論。AI讓脆弱系統更容易被檢查，所以答案應該是讓系統更容易被負責、稽核、回報與修復。

我今天會怎麼做

面對AI驅動的儲存庫恐慌，團隊應在改變預設值前，進行一輪48小時開放程式碼檢視：

1. 盤點公開儲存庫，並把每個儲存庫對應到負責者。
2. 針對目前樹狀結構與git歷史執行機密掃描。
3. 檢查每個儲存庫是否有安全聯絡方式或揭露政策。
4. 找出詐欺、濫用、即時架構與未發布政策例外。
5. 確認相依套件更新、修補發布與復原路徑。
6. 只關閉或延後符合具名例外的特定儲存庫。
7. 公布決策規則，避免未來團隊重演同樣恐慌。

這項計畫會給主管一個真正的控制面。它也會創造證據。未來審查者可以看見為什麼某個儲存庫維持開放、另一個為什麼改成私人，以及哪些工作降低了實際風險。

常見問題

AI會讓公開程式碼更危險嗎？

AI可以讓公開程式碼更容易被檢查，所以團隊應預期弱點回報與自動化探測會增加。真正的危險來自未修補弱點、暴露機密與薄弱回應迴路。公開可見性可能增加發現機會，但私有化不會移除底層錯誤。¹

團隊是否應該把儲存庫設為私人？

是。若程式碼包含或揭露機密、詐欺控制、敏感即時架構、未發布政策或其他具體傷害，團隊應限制其可見性。例外應予記錄，並在理由失效時重新檢視。³⁶

為什麼不先全部關閉，等團隊完成檢視再說？

全面關閉會以不確定的保護，換掉真實的公共利益。GDS警告，曾經公開的程式碼可能已存在於鏡像、分支或複製副本中。¹短期而精準的檢視，勝過一個無限期、還會隱藏歸屬問題的預設值。

團隊要稱一個公開儲存庫足夠安全前，至少應包含什麼？

至少包括：沒有機密、有負責者、有授權、清楚的設定說明、相依套件更新實務、安全聯絡方式或弱點揭露管道，以及能快速送出修正的發布流程。

這和AI程式碼代理有什麼關係？

代理擴大了同一個邊界問題。風險很少只存在於一個可見檔案中。它存在於權限、產生出的產物、快取、對外請求、建置狀態與發布權限之中。良好的代理安全與良好的開放原始碼政策，都需要在這些邊界上留下證據。

參考資料