本期 Tempest Security Daily 彙整 2026 年 6 月 19 日的資安動向。今日 security_filtered.json 僅收錄 3 篇文章,因此本報實質上整理 3 條獨立訊號,未做任何補充或推測。主題卻意外集中且互相呼應:第一條是澳洲訊號局(ASD)正式把「不具備安全技能的開發者」寫進國家層級資訊安全手冊,把開發者本身視為一道風險閘門;第二條是回到開放原始碼授權的基本盤,重新檢視 MIT License 的合規邊界與企業攻防;第三條則是 AppSec 廠商討論 AI 生成程式碼大量湧入時,傳統安全工作流程崩解的徵兆。對台灣的工程與資安主管,這三條訊號連起來其實是同一個命題:在 AI Coding Agent 時代,「誰負責安全」這個問題已經從一個流程節點,變成跨越採購、人事、合規與工程的系統性議題。
1. ASD 對「缺乏安全技能的開發者」劃下硬底線,更新 ISM 直接點名能力義務
把「開發者能力」寫進國家級資訊安全手冊,等同於把人視為控制點—— 報導指出,澳洲訊號局(Australian Signals Directorate, ASD)更新了 Information Security Manual(ISM),向組織傳達一條明確且直白的訊息:不應該把軟體專案交給「沒有能力安全地處理它們」的開發者。對台灣的工程與資安團隊,這條訊號的判斷意義有三:第一,它把「人」正式納入控制目錄——過去 ISM 等手冊多半針對流程與技術控制,但這次明確把開發者能力寫進條文,意味著未來在合規檢查、稽核訪談時,「這個 PR 是誰寫的、他有沒有受過安全訓練」會成為可被問到的具體證據;第二,對台灣多數採用承攬、外包或 SI 模式的金融、政府專案而言,這代表 RFP 階段就需要重新檢視承包商工程師的安全資格、培訓紀錄,以及內部的程式碼審查機制,不能只把責任丟到驗收測試階段;第三,這條訊號和今天另外兩條(MIT 授權合規、AI 生成程式碼)合起來看,可以視為「軟體供應鏈的人因風險」被正式納管的開端——程式碼從哪裡來、是誰寫的、那個人(或 AI)是否受信任,都會成為新一輪安全治理的問項。原文:https://ift.tt/N5ZOTja
2. 重新檢視 MIT License:寬鬆背後的合規地雷與企業實務取捨
越寬鬆的授權,通常代表企業端內部紀律要越強—— 這篇文章重新整理 MIT License 的核心定位:它是一個寬鬆型(permissive)的開放原始碼授權,允許使用、修改與散布,條件只有保留原始版權聲明與免責聲明(disclaimer)。文章同時強調,即便授權本身條件極少,法務與工程團隊在實務上仍需建立三項紀律:歸屬聲明的維護、相依套件可視性,以及軟體成分管理。對台灣的工程與資安主管,這條訊號的價值在於三層提醒:第一,MIT 雖被廣泛視為「最自由的選項」,但「自由」不等於「沒義務」——版權聲明保留與免責聲明的散布要求,若在企業產品打包、Docker Image、SaaS 前端、行動 App 內遺漏,仍構成實質違約;第二,在當前 LLM 大量生成程式碼、人類工程師大量從 GitHub 直接 copy snippet 的時代,SBOM(Software Bill of Materials)與授權清點工具的角色變得不可妥協,授權與相依清單必須由工具自動產生而非仰賴開發者自報;第三,把這條訊號放回今天的整體脈絡,可以看出 ASD 強調「人」、AppSec 強調「AI 生成程式碼」、本篇強調「授權與相依」其實在拼同一張圖:供應鏈安全已從「相依套件本身有沒有漏洞」擴大成「相依套件來源、人員、授權三個維度同時驗證」。原文:https://ift.tt/6LstyUa
3. AI 程式碼安全:AppSec 為何必須在「AI 生成程式碼時代」重新被設計
當生成速度遠遠超過審查速度,傳統 AppSec 工作流會自然崩盤—— 這是一場由 Apiiro 贊助的網路研討會宣傳(WC #1),主題鎖定「AI 編碼助理正在加速開發,但同時也淹沒 AppSec 團隊」。文中提到三個關鍵命題:AI 生成的程式碼如何增加風險、為什麼傳統安全工作流會崩潰,以及如何透過 guardrails、context 與 autofix 重塑安全交付流程。對台灣的工程與資安主管,這條訊號值得切成三個層面理解:第一,當 IDE 內 AI 補全已成為常態,單一工程師每日提交的程式碼量級可能比一年前高出數倍,但 AppSec / SAST 團隊的人力與檢查能力並沒有同步擴張,這意味著「審查」會自然變成瓶頸——若不導入工具側的 guardrails(在 IDE / PR 階段就攔下),漏洞會在比過去更短的時間內入庫;第二,context(也就是「這段 AI 程式碼是在什麼資料、什麼權限、什麼模組情境下生成」)在 AI 環境下變得至關重要——同一段看似無害的 SQL 字串拼接,在報表頁面與在登入頁面的風險權重完全不同,新世代 AppSec 工具必須能讀懂這層脈絡;第三,autofix 不只是「掃描出 → 開 ticket」,而是「掃描出 → 立刻生成修補 PR」,把修補閉環縮短到開發者一個按鍵內完成,否則永遠追不上 AI 的生成速度。把今天三條訊號連起來看,ASD 強調人、MIT 強調授權、本條強調 AI 生成程式碼,其實共同指向:AppSec 已不能只是 SDLC 末端的 gate,而必須轉型為跨人因、跨授權、跨 AI 的全鏈控制平面。原文:https://ift.tt/iDnTNPx
結語
今日雖然只有 3 條獨立訊號,但主題彼此呼應得相當清楚:ASD 點名「人」、MIT 文章點名「授權」、AppSec 文章點名「AI 生成程式碼」,三條合起來指向同一個觀察——軟體供應鏈安全的邊界,正從「程式碼本身有沒有漏洞」延伸到「寫程式碼的人是誰、用了誰的程式碼、是用什麼工具寫的」。對台灣團隊,今天最值得帶走的判斷是:在 RFP、PR review、SAST 工具選型這三個本來分屬不同部門的決策點上,應該開始用同一個治理框架來檢視彼此的接點;尤其在 AI Coding Agent 已普遍進入日常開發流程的此刻,「安全責任歸屬」這個老問題,值得用今天 3 條訊號重新拉一次內部對話。