軟體開源信任：為什麼社群審查
二、社群審查是什麼：從程式碼評審到治理機制
很多人以為「社群審查」就是在 GitHub 上點個 Approve、留一句 LGTM（Looks Good To Me）。這只是最表層的一環。完整的社群審查其實是一套多層次的機制，涵蓋程式碼、流程、治理與生態四個層面。理解這四層，你才能判斷一個專案的「審查強度」到底夠不夠。
程式碼層面的審查：Pull Request 與多人複核
第一層是我們最熟悉的 Pull Request（PR）流程。健康的專案通常具備幾個特徵：
這裡有個關鍵細節：審查者的數量與品質，比審查的形式更重要。一個專案如果只有一位維護者，那他的「審查」實質上就是自我審查；如果審查者只會看語法風格而不看邏輯，那也只是形式主義。xz 事件之所以能成功潛伏兩年多，正是因為攻擊者精準地利用了「維護者疲勞」與「審查者不熟悉壓縮演算法」這兩個弱點。
流程與治理層面的審查：發布簽章、維護者制度
第二層是流程治理。這一層處理的是「誰有權發布」與「發布出去的成品是否可驗證」。
生態層面的審查：套件倉庫與安全公告
第三層是套件生態系本身的審查。npm、PyPI、Maven Central、crates.io 這些倉庫，近年陸續導入了多項機制：
此外，OpenSSF 推動的 SLSA（Supply-chain Levels for Software Artifacts）框架與 Sigstore 簽章生態，試圖把「建置流程」也納入可驗證的範圍。這代表社群審查已經從「看程式碼」進化到「看整條生產線」。
三、為什麼社群審查無可替代
讀到這裡，你可能會問：商業掃描工具（SAST、SCA、DAST）這麼發達，為什麼還需要社群審查？答案不是「工具沒用」，而是「工具與社群審查處理的是不同層次的問題」。以下三個面向，說明了社群審查為什麼在短期内無法被取代。
攻擊者與審查者的不對稱：時間與人數
供應鏈攻擊的本質是一場不對稱戰爭。攻擊者只需要找到一個弱點、一次機會、一位疲憊的維護者；防禦者卻必須守住每一個版本、每一條依賴、每一個建置環節。商業工具的邏輯是「用規則比對已知模式」，它們擅長抓已知的漏洞特徵、已知的惡意網域、已知的危險 API 呼叫。但 xz 事件的後門是經過精心設計、針對特定環境觸發、並且藏在使用者不易閱讀的測試資料中，任何以規則為基礎的掃描器都幾乎不可能事先辨識出來。
相對地，社群審查的優勢在於「情境理解」。一位長期參與該專案的開發者，會注意到「這個 PR 的重構方向不太對」、「這個新維護者的提交風格突然改變」、「這個 tarball 為什麼比 Git 標籤多了幾個檔案」。這些直覺來自長期的上下文累積，是靜態規則難以複製的。
商業掃描工具的盲區
我們可以把常見工具的盲區整理成一張表，方便理解：
工具類型
擅長處理
典型盲區
SCA（軟體組成分析）
已知 CVE、授權條款、依賴版本
尚未被編號的後門、惡意套件、維護者帳號劫持
SAST（靜態分析）
常見注入模式、危險函式呼叫
刻意設計的條件式後門、混淆過的邏輯、建置流程攻擊
DAST（動態分析）
執行期可觸發的漏洞
潛伏期長的後門、特定環境才觸發的邏輯
套件信譽系統
下載量、發布頻率、已知惡意清單
聲譽良好但被滲透的專案、合法交接後的惡意變更
換句話說，工具處理的是「已知的未知」（known unknowns），而社群審查處理的是「未知的未知」（unknown unknowns）——那些還沒有人想到要去防的問題。
透明度帶來的可追溯性
社群審查還有一個常被低估的價值：它把「信任」變成可以事後檢驗的東西。當一個專案的所有提交、討論、審查意見、發布紀錄都公開在版本控制平台與郵件論壇上，任何人在事後都可以回溯「這個變更是誰提的、誰審的、為什麼通過」。這種可追溯性有兩個效果：
相對地，閉源軟體的內部審查再嚴謹，外部使用者也只能「相信廠商的說法」。開源社群審查即使不完美，至少讓外部研究者有介入的可能——而這正是 xz 事件能被發現的根本原因。
四、社群審查的極限與失靈案例
推崇社群審查，不代表要把它神化。事實上，正因為它依賴「人」，它就有人的極限。認識這些極限，才能在採用開源軟體時做出更務實的風險判斷。
維護者疲勞與單人專案風險
開源生態最脆弱的環節，不是技術，而是人的永續性。大量關鍵套件由少數志工在業餘時間維護，他們面對的是無止境的 issue、PR、安全通報與使用者抱怨，卻往往沒有對應的報酬。這種結構性疲勞導致幾種典型現象：
這也解釋了為什麼「維護者健康度」應該成為軟體評測的一部分。一個專案如果只有一位活躍維護者、沒有資金來源、沒有治理文件，即使程式碼寫得再漂亮，它的長期風險仍然偏高。
審查的社會工程學攻擊
xz 事件最令人不安的地方，不在技術，而在它是一場長達數年的社交工程。攻擊者先以「有用的貢獻者」姿態出現，耐心處理繁瑣的 bug、回應社群、建立信任，再逐步取得維護權限。整個過程沒有駭入任何系統，而是利用了開源社群「歡迎貢獻者」的開放文化。
這揭露了一個殘酷現實：越開放的社群，越容易被滲透。防禦方式不是關閉大門，而是建立更嚴謹的信任階梯——例如新維護者需要經過一定期間的觀察、敏感變更需要多人覆核、發布流程需要獨立驗證。OpenSSF 的「開源專案安全指南」與各大基金會（如 Apache、CNCF）的畢業標準，都是朝這個方向演進。
另一個常被忽略的失靈點是審查者的同質性。如果一個專案的審查者都來自同一家公司、同一個文化背景，他們很可能有相同的盲點。多元的審查者組成，本身就是一種防禦機制。
五、實務指南：如何判斷一個開源專案是否值得信任
談完理論，回到實務。以下這份清單，是我們在論壇評測專欄中常用的「開源信任檢核表」，你可以直接套用在任何你正在考慮採用的專案上。
審查清單：從提交紀錄看健康度
依賴足跡：這個套件本身又依賴多少其他套件？依賴樹越深，風險越高。
歷史事件：是否曾發生安全事件？事後處理是否透明、是否改善了流程？
社群訊號：討論區、郵件論壇、安全公告的活躍程度，是否有多元參與者？
這份清單不需要每一項都滿分，但它能幫你畫出一個「風險輪廓」。如果一個專案在「維護者數量」與「發布簽章」上都掛零，那它即使功能再好，也不適合放進關鍵系統。
六、企業導入開源軟體的審查框架
對個人開發者來說，上述清單已經夠用；但對企業而言，開源審查必須制度化，否則就會變成「出事再找人」的救火模式。以下是我們建議的三層框架。
SBOM 與依賴管理
第一步是看得見。企業必須能回答：「我們的產品用了哪些開源元件？版本是什麼？授權是什麼？由誰維護？」這聽起來簡單，但在實務上，多數團隊對自己的依賴樹只有模糊概念。解法是建立 SBOM（軟體物料清單），採用 SPDX 或 CycloneDX 等標準格式，並整合進 CI 流程，讓每次建置都自動產生對應的 SBOM。
有了 SBOM，才能進一步做「依賴風險評分」：把每個元件的維護者數量、最近更新時間、已知漏洞數、授權類型等指標彙整成分數，優先處理高風險項目。市面上已有 Scorecard、Dependency-Track 等工具可以協助，但關鍵仍是把流程寫進開發規範，而不是買了工具就結束。
內部審查流程設計
第二步是審得動。企業不可能對每一個開源依賴都做深度人工審查，因此需要分級制度：
中風險元件（如資料處理、序列化）：需要自動化掃描與定期更新。
低風險元件（如工具函式庫）：可依賴自動化監控與快速更新機制。
此外，企業應該建立「開源採用政策」，明定：哪些授權可以接受、哪些來源必須封鎖、新依賴必須經過誰核准、發現漏洞時的應變流程與時限。這些規範不必複雜，但必須書面化、可稽核。
第三步是回饋社群。這聽起來像公益，其實是自保。企業若大量使用某個開源專案，卻從不回報漏洞、不貢獻修補、不贊助維護者，長期下來就是在消耗公共財。xz 事件之後，越來越多企業開始設立「開源專案辦公室」（OSPO），專責處理開源治理、貢獻與合規。這不只是形象問題，而是風險管理的延伸。
七、結論：信任是需要維護的公共財
回到最初的問題：為什麼社群審查？因為在一個由數百萬個互相依賴的套件所構成的生態裡，沒有任何單一工具、單一廠商、單一標準能夠提供完整的保證。商業掃描器能幫你抓已知漏洞，SBOM 能幫你看見依賴，簽章能幫你驗證來源，但真正能在第一時間察覺「這個變更不對勁」的，仍然是那個願意多看一眼的人。
社群審查的價值，不只在於它抓到了多少問題，更在於它把「信任」從一個模糊的感覺，變成一組可以檢查、可以討論、可以改進的機制。它讓開源軟體不是「因為免費所以隨便用」，而是「因為透明所以可以負責」。
但我們也必須誠實：社群審查正在承受巨大的壓力。維護者疲勞、資金不足、攻擊者日益專業化，這些問題不會因為我們寫幾篇文章就消失。作為使用者，我們能做的至少有三件事：
開源生態是人類歷史上最大規模的協作實驗之一。它的安全性不是天上掉下來的，而是由無數次審查、爭論、修正與意外發現累積而成的。下次你在終端機敲下安裝指令時，不妨想一想：這一行指令背後，有多少人曾經認真看過那段程式碼？而你自己，又願意為這份信任付出多少注意力？
——本文由「雅寶社區 · 頂客論壇」軟體評測專欄整理，歡迎在討論區分享你的開源審查經驗與實務做法。
```