AI讓程式碼更快產出，也能協助找出可疑錯誤；但每份程式碼貢獻或安全通報，仍需要有人判斷是否成立、是否值得處理。OpenSSL通報量增加，加上Linux Foundation對開源社群的調查，都呈現出同一個拉鋸：開發速度可能變快，維護者手上的審查工作卻也變多了。121

OpenSSL收到更多通報，但不等於漏洞暴增

OpenSSL提供用於保護網路通訊的軟體，因此程式碼的安全與品質，影響不只限於專案本身。15

OpenSSL基金會執行董事Matt Caswell在布拉格舉行的年度會議上表示，2026年5月至7月，OpenSSL平均每月收到71份安全通報與詢問；去年同期平均每月為9份。到了8月，詢問數增至108件。1

不過，這些數字反映的是收到的通報與詢問，不是確認成立的漏洞。過去一年，OpenSSL約收到500份漏洞通報，其中63份最後成為公開揭露的漏洞。其餘不少是重複提交、輕微缺陷，或不需要發布安全公告的問題。透過AI工具找到的漏洞，多數嚴重程度也偏低，並非重大安全缺陷。即使如此，每份提交仍可能需要人工檢視。13

審查壓力也不只出現在OpenSSL。Bouncy Castle和cryptlib的維護者在會議上同樣提到，待檢視的通報變多；Bouncy Castle的Megan Woods也提醒，對AI撰寫的密碼學程式碼應保持審慎。23

AI能協助安全工作，不能代替人做判斷

OpenSSL的技術長表示，AI工具可協助程式碼審查、調查收到的漏洞通報，以及撰寫測試。3這些用途或許能支援維護者，但不代表工具提出的疑點就已確認為漏洞，也不代表可以省略人工評估。13

關鍵在於，找出疑點和確認問題是兩件事。工具可能標示一段可疑程式碼，或產生看似合理的報告；維護者仍須判斷問題是否真實、是否重要，以及應如何處理。相關報導指出，調查問題、開發修補程式並發布安全公告，可能需要六至八週。3

開源貢獻變多，品質與審查負擔也受關注

由Red Hat贊助、Linux Foundation Research進行的一項調查，在All Things Open活動上公布。調查顯示，維護者估計收到的拉取請求（pull request，簡稱PR）中，有25%屬於低品質的「AI slop」——也就是品質不足、需要額外整理或檢查的AI生成內容；大型專案的比例為31%。調查涵蓋234名開源貢獻者與維護者。2021

另一方面，59%的專案維護者表示，收到的貢獻增加了。21更多提交可能帶來有用的程式碼與新貢獻者，但也意味著維護者得花更多時間審查；若提交內容有問題，還得找出原因並向提交者說明。

這是受訪者的調查估計，不是對所有開源專案每一份PR的逐筆統計。不過，結果點出一項實際難題：AI或許降低了產出貢獻的門檻，卻不一定減少判斷程式碼是否適合合併所需的工夫。2021

從Google暫停收件，看通報品質的重要性

通報量增加也可能影響漏洞回報機制。Google於10月1日暫停接收其開源軟體漏洞獎勵計畫（OSS VRP）中的新產品漏洞提交，理由是自動化提交增加，而且公司表示其中絕大多數無效。Google承諾在2027年第一季提供後續消息。這次暫停僅適用於該計畫中的產品漏洞提交，並非Google所有漏洞獎勵計畫都停止收件。18

對開源專案而言，較務實的方向包括：清楚說明貢獻規範、在適用時要求提供可重現的證據與測試，並用自動化協助分類和初步篩選，而不是跳過人工審查。這些是從現有報導所反映的問題推導出的做法，並非單一、放諸四海皆準的解方。11821

AI可以加快寫程式，也能協助找到可能的缺陷；但要交付可信賴的軟體，維護者仍需要時間與資源，仔細確認每一份送到眼前的內容。

AI讓程式碼更快產出，也能協助找出可疑錯誤；但每份程式碼貢獻或安全通報，仍需要有人判斷是否成立、是否值得處理。OpenSSL通報量增加，加上Linux Foundation對開源社群的調查，都呈現出同一個拉鋸：開發速度可能變快，維護者手上的審查工作卻也變多了。121

OpenSSL收到更多通報，但不等於漏洞暴增

OpenSSL提供用於保護網路通訊的軟體，因此程式碼的安全與品質，影響不只限於專案本身。15

OpenSSL基金會執行董事Matt Caswell在布拉格舉行的年度會議上表示，2026年5月至7月，OpenSSL平均每月收到71份安全通報與詢問；去年同期平均每月為9份。到了8月，詢問數增至108件。1

不過，這些數字反映的是收到的通報與詢問，不是確認成立的漏洞。過去一年，OpenSSL約收到500份漏洞通報，其中63份最後成為公開揭露的漏洞。其餘不少是重複提交、輕微缺陷，或不需要發布安全公告的問題。透過AI工具找到的漏洞，多數嚴重程度也偏低，並非重大安全缺陷。即使如此，每份提交仍可能需要人工檢視。13

審查壓力也不只出現在OpenSSL。Bouncy Castle和cryptlib的維護者在會議上同樣提到，待檢視的通報變多；Bouncy Castle的Megan Woods也提醒，對AI撰寫的密碼學程式碼應保持審慎。23

AI能協助安全工作，不能代替人做判斷

OpenSSL的技術長表示，AI工具可協助程式碼審查、調查收到的漏洞通報，以及撰寫測試。3這些用途或許能支援維護者，但不代表工具提出的疑點就已確認為漏洞，也不代表可以省略人工評估。13

關鍵在於，找出疑點和確認問題是兩件事。工具可能標示一段可疑程式碼，或產生看似合理的報告；維護者仍須判斷問題是否真實、是否重要，以及應如何處理。相關報導指出，調查問題、開發修補程式並發布安全公告，可能需要六至八週。3

開源貢獻變多，品質與審查負擔也受關注

由Red Hat贊助、Linux Foundation Research進行的一項調查，在All Things Open活動上公布。調查顯示，維護者估計收到的拉取請求（pull request，簡稱PR）中，有25%屬於低品質的「AI slop」——也就是品質不足、需要額外整理或檢查的AI生成內容；大型專案的比例為31%。調查涵蓋234名開源貢獻者與維護者。2021

另一方面，59%的專案維護者表示，收到的貢獻增加了。21更多提交可能帶來有用的程式碼與新貢獻者，但也意味著維護者得花更多時間審查；若提交內容有問題，還得找出原因並向提交者說明。

這是受訪者的調查估計，不是對所有開源專案每一份PR的逐筆統計。不過，結果點出一項實際難題：AI或許降低了產出貢獻的門檻，卻不一定減少判斷程式碼是否適合合併所需的工夫。2021

從Google暫停收件，看通報品質的重要性

通報量增加也可能影響漏洞回報機制。Google於10月1日暫停接收其開源軟體漏洞獎勵計畫（OSS VRP）中的新產品漏洞提交，理由是自動化提交增加，而且公司表示其中絕大多數無效。Google承諾在2027年第一季提供後續消息。這次暫停僅適用於該計畫中的產品漏洞提交，並非Google所有漏洞獎勵計畫都停止收件。18

對開源專案而言，較務實的方向包括：清楚說明貢獻規範、在適用時要求提供可重現的證據與測試，並用自動化協助分類和初步篩選，而不是跳過人工審查。這些是從現有報導所反映的問題推導出的做法，並非單一、放諸四海皆準的解方。11821

AI可以加快寫程式，也能協助找到可能的缺陷；但要交付可信賴的軟體，維護者仍需要時間與資源，仔細確認每一份送到眼前的內容。