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 這些用途可以支援維護者，但AI提出的疑點不會因此自動變成已確認漏洞，也不能省略人工評估。13

找出疑點和確認問題，是兩回事。工具可以標示可疑程式碼，或產生看似合理的報告；維護者仍要判斷問題是否真實、是否重要，以及應如何處理。相關報道指出，調查漏洞、開發修補程式，再發布安全公告，可能要花6至8星期。3

開源貢獻增加，低質素提交亦帶來負擔

Linux Foundation Research一項由Red Hat贊助的調查，在 All Things Open 大會上公布。調查涵蓋234名開源貢獻者及維護者；受訪維護者估計，收到的拉取請求（pull request，即提交程式碼供項目審核的請求）中，有25%質素偏低，被形容為「AI slop」。大型項目這個比例更升至31%。2021

另一方面，59%的項目維護者表示，收到的貢獻增加了。21 更多提交可能帶來有用的程式碼和新貢獻者，但同時亦增加審核工作；尤其當提交本身有問題，維護者還要找出並解釋問題所在。

這些數字是調查估算，並非所有開源項目拉取請求的實際統計。不過，它指出一個實際難題：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 這些用途可以支援維護者，但AI提出的疑點不會因此自動變成已確認漏洞，也不能省略人工評估。13

找出疑點和確認問題，是兩回事。工具可以標示可疑程式碼，或產生看似合理的報告；維護者仍要判斷問題是否真實、是否重要，以及應如何處理。相關報道指出，調查漏洞、開發修補程式，再發布安全公告，可能要花6至8星期。3

開源貢獻增加，低質素提交亦帶來負擔

Linux Foundation Research一項由Red Hat贊助的調查，在 All Things Open 大會上公布。調查涵蓋234名開源貢獻者及維護者；受訪維護者估計，收到的拉取請求（pull request，即提交程式碼供項目審核的請求）中，有25%質素偏低，被形容為「AI slop」。大型項目這個比例更升至31%。2021

另一方面，59%的項目維護者表示，收到的貢獻增加了。21 更多提交可能帶來有用的程式碼和新貢獻者，但同時亦增加審核工作；尤其當提交本身有問題，維護者還要找出並解釋問題所在。

這些數字是調查估算，並非所有開源項目拉取請求的實際統計。不過，它指出一個實際難題：AI或可減少寫好一份貢獻所需的時間，卻未必能減少判斷它是否適合合併所需的工作。2021

提交質素和審核能力同樣重要

Google的做法反映，當湧入的安全報告太多，項目可能要重新調整接收方式。Google於10月1日暫停接收其開源軟件漏洞獎勵計劃（OSS VRP）中的新產品漏洞報告，理由是自動化提交增加，而當中絕大部分無效。Google表示會在2027年第一季提供更新。這次暫停只涉及該計劃的產品漏洞提交，並非所有Google漏洞獎勵計劃都停止。18

對開源項目來說，較務實的做法包括清楚列明貢獻要求、在合適情況下要求可重現的證據和測試，並以自動化工具協助分流，而非取代人工審核。這些是從相關報道和調查中看到的實際方向，並非唯一指定方案。11821

AI可以加快寫程式，也可以找出更多潛在缺陷；但要令軟件真正可靠，仍要有時間和資源，讓維護者逐一核實收到的內容。