2026-05-07 的 Tempest Security Daily 訊號集中在兩條主軸:其一是 Cal.com 把長年使用 AGPL-3.0 授權的程式碼改為閉源,共同創辦人喊出「open source is dead」,開源社群與資安觀察者一片譁然;其二是 AI 生成程式碼大量湧入 SDLC,迫使應用程式安全(AppSec)團隊重新檢討既有的把關策略。兩條訊號看似不同主題,實際上指向同一個問題——當 AI 寫程式變成日常,開源生態與企業 AppSec 流程都面臨「來源信任」與「掃描覆蓋率」的雙重壓力。本期以 9 則摘要拆解這兩條訊號背後的脈絡,給台灣 AppSec、平台工程與供應鏈安全主管做為評估參考。
主訊號:Cal.com 放棄 AGPL-3.0,共同創辦人宣告「開源已死」
原文報導,Cal.com 已關閉其商用程式碼庫,放棄多年來使用的 AGPL-3.0 授權,引發協助打造該專案的開發者社群強烈不滿,並在更廣泛的開源世界引起連鎖反應。共同創辦人暨執行長 Bailey Pumfleet 直言「Open source is dead」。對台灣資安主管而言,這條訊號並不只是一家公司商業模式的轉向,而是一個警訊——當企業在內部使用 AGPL/GPL 等強傳染性授權專案時,授權方一旦改弦易轍,既有部署的合規定位、未來 patch 來源、以及社群 fork 是否能持續維護,都會直接影響企業的供應鏈安全規劃。原文:[https://ift.tt/HhSTX2a]
主訊號:AI 生成程式碼湧入 SDLC,AppSec 策略被迫改寫
另一則原文指出,AI 寫程式工具已從實驗階段進入日常開發,協助軟體團隊起草函式、解釋陌生程式碼、產生測試案例、加速重複性修改;對資安團隊而言,真正困難的問題是「在進入 pull request 之前,有多少 AI 寫出來的程式碼已經混進 codebase」。這條訊號值得 AppSec 主管反覆閱讀,因為它指出傳統「在 PR 階段把關」的防線已經來不及,AI 程式碼可能在 commit、甚至本地端 IDE 階段就已經產生,把關點必須往左移。原文:[https://ift.tt/q9adEtQ]
觀察一:強傳染性授權專案的閉源風險如何納入供應鏈評估
Cal.com 從 AGPL-3.0 轉為閉源這件事,對採購方資安主管的啟示是:選用開源元件時,只看「目前的授權條款」是不夠的,還要評估「授權方未來轉向的風險」。建議在 SBOM 與供應鏈風險評估流程中加入幾項補強:第一,標註元件的「授權穩定度」——是被基金會持有、社群多人維護,還是單一商業實體掌控;第二,對於關鍵元件,事前確認 fork 條款與社群 fork 的可行性;第三,對於 AGPL/GPL 系列的核心相依,維護一份「替代方案」清單,避免單一供應商授權變動導致整條服務必須緊急重寫。原文:[https://ift.tt/HhSTX2a]
觀察二:AI 程式碼把關點要從 PR 往左移到 IDE 與 commit
當 AI 工具直接在開發者本機產生大量程式碼,傳統「PR 觸發 SAST」的防線會看到的是「最終版本」,看不到 AI 的原始輸出與後續人為修改軌跡。建議 AppSec 團隊評估三個層次的補強:第一,在 IDE 層整合即時的 secret 偵測與授權條款掃描,避免 AI 把外部範例的金鑰或不相容授權片段直接貼進 codebase;第二,在 pre-commit hook 增加對「明顯機器產生樣式」(如 placeholder import、hallucinated 函式名)的偵測;第三,把 SAST 規則調整為對「成熟度低、覆蓋率不全的測試」更嚴格,因為 AI 程式碼的測試常常只覆蓋 happy path。原文:[https://ift.tt/q9adEtQ]
觀察三:AI 不會殺死開源程式碼安全——前提是治理跟得上
原文標題明確表達一個觀點:AI 並不會殺死開源程式碼安全。這個論點背後的邏輯是,開源安全本來就靠「眾人之眼」與「自動化工具」雙軌支撐,AI 帶來的不是新的攻擊面而是新的程式碼產出量,只要把關自動化跟得上,治理框架就不會崩潰。對台灣資安主管的意義是,不要把 AI 寫程式視為「無法管理的怪獸」進而禁用,反而應該擴充既有 SCA、SAST、SBOM 工具的吞吐量與規則覆蓋,讓自動化把關速度跟上 AI 產出速度。禁用通常只會讓開發者繞道,而不是真的停止使用。原文:[https://ift.tt/HhSTX2a]
觀察四:AI 程式碼的「品質尾端」風險與測試覆蓋盲點
原文點名 AI 工具被開發者廣泛用來「起草函式、解釋陌生程式碼、產生測試、加速重複性修改」。後三項對既有 codebase 尤其敏感:解釋陌生程式碼可能導致開發者依賴 AI 的「自信但錯誤」描述去修改既有邏輯;產生測試容易只覆蓋 happy path 而漏掉邊界條件;加速重複性修改則可能在批次操作中放大原本只是個案的安全瑕疵。AppSec 團隊建議在 PR 模板中明確要求標註「本次變更是否包含 AI 協助」,並把 AI 輔助的 PR 在 review 階段加上額外的測試覆蓋率與安全規則檢查。原文:[https://ift.tt/q9adEtQ]
觀察五:單一商業實體掌控的開源專案在治理上的脆弱性
Cal.com 案例的另一個治理層面意義是,當一個開源專案的 IP 與決策權集中在單一商業實體時,授權變動只是時間問題。對企業資安與採購主管而言,這帶出一個過去較少被列入供應鏈風險評估的維度:「治理結構」。建議在重要相依元件的選型時,把幾個治理指標納入評估表:核心 maintainer 是否分散、是否有獨立基金會持有商標、CLA(Contributor License Agreement)的轉授權條款是否寬鬆到足以單方面變更授權、社群討論是否公開可追溯。這些指標雖然不影響當下技術評估,卻會在三五年後決定企業要不要被迫重寫。原文:[https://ift.tt/HhSTX2a]
台灣視角:中型企業 AppSec 主管面對 AI 程式碼洪流的三道防線
把今天兩條訊號收斂回台灣中型企業現況,給 AppSec 主管三道現實可行的防線。第一道是「進入點管控」:在 IDE 與 pre-commit 階段加上 secret 與授權片段偵測,把多數低品質 AI 輸出擋在進入 codebase 之前。第二道是「批次擴大鏡」:對於同一支 PR 內出現大量結構相似的修改,觸發更嚴格的 SAST 規則與 review 要求,因為這往往是 AI 重複性操作的特徵,而重複性操作會放大原本只是單點的瑕疵。第三道是「相依信任分級」:把核心相依元件按治理結構分為「基金會持有」「多 maintainer 社群」「單一商業實體」三級,對第三級加上替代方案盤點與遷移路徑準備,避免下一個 Cal.com 出現時措手不及。原文:[https://ift.tt/HhSTX2a] 與 [https://ift.tt/q9adEtQ]
今日行動清單:給 AppSec 與供應鏈安全主管
彙整今天兩條訊號,建議 AppSec 與供應鏈安全主管在本季可以採取以下五項具體動作:(1) 盤點公司內部 SBOM,標註每個關鍵相依元件的授權方治理結構,把單一商業實體掌控的元件列為高風險;(2) 對開發團隊更新 PR 模板,加入「本次變更是否包含 AI 協助」欄位,作為後續安全規則調整的數據基礎;(3) 評估在 IDE 層導入 secret 與授權片段即時偵測工具,把把關點從 PR 往左移到開發者本機;(4) 對於使用 AGPL/GPL 系列強傳染性授權的關鍵元件,建立替代方案清單與遷移評估文件,避免授權方政策變動時無路可退;(5) 在既有 SAST/SCA 規則中,新增對「結構相似的批次修改」的特殊處理規則,把 AI 重複性操作可能放大的安全瑕疵納入既有把關流程。