【資安日報】5月25日，GitHub內部儲存庫的程式碼外流，確認遭供應鏈攻擊事故波及

來源：https://www.ithome.com.tw/news/176094

駭客團體TeamPCP兜售GitHub近4千個儲存庫資料，底價為5萬美元

駭客團體TeamPCP近日聲稱竊得GitHub近4千個內部儲存庫的程式碼，資安新聞網站Bleeping Computer報導指出，該駭客組織以5萬美元底價公開競標，並聲稱只會有一位買家得標，一旦買賣成立，他們就會提供資料並銷毀手上的備份。若無買家出價競標，將直接公布這批檔案。對此，GitHub表示他們著手調查此事，後續公布結果指出，起因是有員工不慎安裝惡意延伸套件，導致這些內部儲存庫遭入侵。

Nx Console的VS Code延伸套件被植入竊資軟體

Nx Console的VS Code延伸套件傳出遭遇供應鏈攻擊，資安公司StepSecurity透露，若是開發者不小心安裝惡意套件，該套件就會在開發環境搜刮多種憑證與權杖資料。Nx開發團隊發布資安公告證實此事，並說明事故原因是團隊中一名開發者遭遇TanStack供應鏈攻擊，導致GitHub憑證外流，攻擊者得以冒充開發者的身分執行該團隊GitHub儲存庫的工作流程。該團隊將這起事故登記為CVE-2026-48027，並將危險程度評為重大等級。

針對內部儲存庫遭駭事故，GitHub證實為受到Nx Console的供應鏈攻擊波及

關於日前GitHub透露近3,800個內部儲存庫遭駭的消息，GitHub在部落格揭露更多細節，指出該名員工安裝的惡意套件就是18.95.0版Nx Console，該公司是在2日前偵測到這名員工的裝置被入侵，當時他們就移除套件，將端點隔離，然後展開事件回應流程。由於Nx Console事故源於開發者受到TanStack攻擊活動波及，換言之，GitHub此次事故同樣可追溯至TanStack遭受攻擊。

CISA警示Drupal的SQL注入漏洞已被用於實際攻擊

日前內容管理系統Drupal開發團隊修補SQL注入漏洞CVE-2026-9082，該團隊不僅破例為已停止支援版本發布更新，並先行預告修補釋出時間，希望網站管理員保留時間盡速更新，以防攻擊者不久後就開發出漏洞利用工具，顯示其嚴重程度。相隔兩日後，美國網路安全暨基礎設施安全局（CISA）掌握遭到利用的跡象，將其加入已遭利用漏洞清單（KEV），顯現攻擊者已鎖定此漏洞發動攻擊。

cPanel外掛程式LiteSpeed存在滿分漏洞，已有駭客用於以root執行指令碼

網頁伺服器系統開發商LiteSpeed於5月21日指出，他們提供cPanel用戶的外掛程式存在權限提升漏洞CVE-2026-48172，只要攻擊者取得任意的cPanel使用者帳號，就能藉此以root權限執行任意指令碼，這個外掛程式的2.3至2.4.4版均會受到影響，CVSS v4.0風險達到滿分10分，對此LiteSpeed已發布2.4.5版進行修補。值得留意的是，他們強調漏洞已遭積極利用，呼籲用戶儘速升級新版之餘，也應清查伺服器是否遭到入侵。

為AI與量子運算做好準備，全面強化資安治理已成當務之急

2026年的資安面臨多項重大挑戰，絕大多數都與AI有關，量子安全議題也快速升溫，出席2026臺灣資安大會的Palo Alto Networks日本暨亞太地區政策與政府事務副總裁Nicole Quinn認為，攻擊是可以預防的，資安問題是能夠解決的，關鍵在於能否充分運用AI進行防禦，她指出，我們必須掌握三大策略：提升事件偵測與遏制的速度、降低基於身分與AI代理而導致的風險暴露，以及建立涵蓋整個網路環境的運作狀態觀測分析視野，改善雲端服務、端點與第三方系統整合的能見度。

衛福部發表FHIR Box醫療作業系統，同時說明其資安配置

衛福部5月20日在國科會第21次委員會議會後記者會中，揭露名為FHIR Box的醫療資料交換作業系統，以解決國內醫院資訊系統（HIS）長年碎片化的痛點，進而推動全國病歷互通、醫療資料標準化，以及AI應用基礎建設。在資安方面，衛福部資訊處表示，目前由計畫團隊定期進行弱點掃描與SBOM軟體成分檢查，並採用OAuth 2.0身分驗證機制，限制不同系統與使用者的資料存取權限，降低資料交換過程中的資安風險。

我國政府機關7月前完成AI風險評估，一年內建立內控規範

根據AI基本法施行規畫，各級政府機關必須在今年7月前完成公務使用AI的風險評估，並在1年內建立AI內部控制與管理規範。另外，由數發部研擬的AI風險分類框架及驗證工具，未來會由各目的事業主管機關，針對所轄產業的AI應用風險，訂定管理規範與產業指引，同時完成相關法規調適與修正。國科會前瞻及應用科技處處長蔡妙慈表示，國科會除了負責AI發展綱領統籌，也肩負跨部會推動與追蹤角色，確保AI基本法通過後，不論在法規調適或實際執行上，各部會都能有一致步調。

CIS專家看Mythos AI風險：漏洞發掘加速考驗企業資安基本功

關於Claude Mythos、GPT-5.5-Cyber等先進AI模型投入資安研究場景後的變化，美國非營利資安組織網際網路安全中心（CIS）資深副總裁Tony Sager指出，零時差漏洞並不是新問題。Mythos這類AI工具真正改變的，是漏洞被發現與揭露的速度，以及漏洞研究可能涵蓋的技術領域；這將使企業資安團隊面臨更多漏洞通報與更緊迫的應變壓力，但並不代表既有防禦策略已經失效。他並針對企業領導者給出建議，應從資安治理的五項基本問題出發。

外界擔憂Mythos恐助長網路攻擊，部分資安專家認為風險被高估

先進AI模型在漏洞挖掘利用的能力已引發全球矚目，但有部分資安專家認為，AI輔助漏洞研究並非新現象，外界擔心Mythos將大幅推升駭客攻擊能力的看法，可能被高估。但許多專家同樣也提醒，提升攻擊方能力是一回事，企業應對是另一回事，企業真正面臨的挑戰，仍是如何驗證、排序並修補大量新發現的弱點。

舊款SonicWall SSL-VPN設備多因素驗證漏洞未補全，被駭客破解植入後門

資安業者ReliaQuest發現，部分SonicWall SSL-VPN設備雖已安裝CVE-2024-12802修補更新，但若企業未依安全公告完成額外LDAP設定，仍可能留下MFA繞過風險。ReliaQuest在今年2至3月間發現數起相關攻擊行動，攻擊者以暴力破解SonicWall Gen 6設備的SSL VPN帳號後，繞過MFA而得以VPN存取受害組織內部檔案伺服器，並且整個過程不到30分鐘，比多數SOC手動發送單一警告時間都短。

駭客濫用微軟IE時代舊工具MSHTA發動無檔案攻擊

微軟雖已結束IE瀏覽器產品生命週期，但相關舊工具MSHTA仍存在於Windows，並持續遭駭客濫用。資安業者Bitdefender指出，今年以來，針對MSHTA的惡意攻擊活動顯著增加，駭客主要透過兩種方式將惡意HTA散布至受害者電腦。其一是假冒破解軟體，將改名的MSHTA執行檔藏在壓縮包內，第二種是用於ClickFix手法，誘騙受害者開啟Win+R並將預先植入剪貼簿、用以呼叫MSHTA的惡意指令貼上送出。

Anthropic悄悄修補已存在近半年的Claude Code沙箱漏洞，未公開揭露引發研究人員批評

資安研究人員Aonan Guan揭露Anthropic旗下AI開發工具Claude Code的網路沙箱（Network Sandbox）機制存在漏洞，恐導致原始碼與憑證洩漏。他在2026年4月透過HackerOne通報時指出，該漏洞影響期長達5個半月；然而，Anthropic以該漏洞已由內部發現並修補為由，將其列為重複案件。研究人員後續分析版本差異，發現4月發布的2.1.90版確實已完成此漏洞的修補，但Anthropic在版本更新說明中並未提及相關安全性問題，引發研究人員批評。

Google傳出不慎洩露Chrome尚未修補的資安漏洞

Google於5月20日公布Chromium專案程式碼庫時，意外公開未修補漏洞的概念驗證程式碼（PoC），恐導致Chrome、Edge、Brave、Vivaldi、Arc等瀏覽器用戶曝險。後續資安研究員Lyra Rebane指出，Google公開內容為她4年前通報的漏洞細節，原以為已修補才公開，測試後卻發現問題仍存且可被利用。Google隨後向媒體表示，已獲悉程式碼外洩並著手修復。

美加聯手逮捕KimWolf殭屍網路23歲管理者

美國司法部在今年3月已聯手打擊Aisuru、KimWolf、JackSkid與Mossad等大型殭屍網路，如今有後續消息是，加拿大警方已於5月20日在渥太華逮捕涉嫌管理KimWolf殭屍網路的23歲男子Jacob Butler，該嫌涉及以DDoS即服務模式出售殭屍網路的操控權，讓其客戶利用這些受感染設備發動攻擊，受害者包括全球的電腦與伺服器。

NPM新增套件暫存發布機制，降低惡意版本散布風險

因應軟體供應鏈攻擊，Node.js套件管理平臺NPM導入套件暫存發布機制，在套件正式公開前加入人工審查關卡，降低自動化發布流程遭濫用的風險，避免攻擊者在入侵CI/CD環境或竊取權杖後，直接將惡意版本發布到NPM登錄庫。此外，套件暫存發布也可搭配NPM既有的可信任發布（trusted publishing）功能。

Discord全面啟用預設全程加密功能，語音與視訊通話都受專屬DAVE加密協定保護

Discord宣布，平臺所有語音與視訊通話服務（含私訊、群組通話、語音頻道及Go Live串流）已正式預設啟用全程加密（E2EE）。事實上，Discord自2023年9月即展開相關測試，並於2024年9月推出自行開發且開源的加密協定DAVE（Discord Audio & Video Encryption），如今完成全面部署。不過Discord也說明，全程加密目前僅限語音與視訊，並未規畫擴及文字訊息的溝通。

Claude託管代理現可連企業內網並在自有環境執行工具

Anthropic Claude平臺更新，為Claude Managed Agents加入兩項企業導入代理應用所需的基礎能力，包括可連接私有網路MCP伺服器的MCP通道（MCP Tunnels）研究預覽版，以及可在客戶自有環境執行工具與程式碼的自架沙箱（Self-hosted Sandboxes）。該日更新未涉及新模型，重點放在代理的內部系統連線、工具執行位置與資料流向控管。

微軟新版Edge for Business支援Purview管控機制，可防範影子AI

微軟新版商務版Edge（Edge for Business）不僅新增及擴增原有的AI功能，同時更深度整合Microsoft Purview，以防範企業內的影子AI（Shadow AI）風險。根據微軟說明，所有Copilot行為都在IT管控及使用者監督下進行，例如，IT管理員可設定Copilot專門的管理政策，也可利用Microsoft Purview為生成的資料加敏感度標籤、紀錄敏感資料的複製/貼上，或限制Copilot存取未授權資料；面臨稽核或法務調查時，也可利用Purview快速搜尋並導出Copilot的歷史對話紀錄。

1Password整合OpenAI Codex，讓AI代理使用憑證但又不取得秘密值

為了降低AI代理在開發與部署時的憑證外洩風險，1Password宣布與OpenAI展開深度整合，這項整合的最大亮點在於，當Codex在協助開發者執行程式開發任務時，可透過1Password授權使用必要憑證，但不直接取得密碼、金鑰等秘密值，降低AI程式開發代理操作資料庫、API與部署流程後，將憑證寫進程式碼、檔案或提供給AI的提示詞（prompt）而外洩的風險。

近期資安日報

【5月22日】微軟修補防毒軟體零時差漏洞

【5月21日】近兩個月研究人員公布的零時差漏洞已能串成攻擊鏈

【5月20日】CISA驚傳暴露AWS GovCloud金鑰與內部系統憑證

'

VS Code 1.121內建Mermaid圖表與本機HTML預覽，強化AI代理終端機行為

來源：https://www.ithome.com.tw/news/176063

微軟發布VS Code 1.121，這次更新加入Mermaid圖表預覽與本機HTML檔案預覽，並改善AI代理使用終端機時的顯示、資源清理與安全處理方式。新版也繼續強化Agents Window預覽版，加入遠端代理功能，讓使用者可透過SSH或開發通道（Dev Tunnels）連到自己可存取的遠端機器，監看與控制AI代理工作階段。

VS Code 1.121將Mermaid圖表支援納入內建功能，Mermaid是一種用簡單文字語法產生流程圖與架構圖的開源工具，開發者在Markdown預覽、筆記本的Markdown儲存格與聊天內容中，可直接算繪Mermaid圖表，不必另外安裝擴充套件。

新版也讓本機HTML檔案可直接在VS Code的整合式瀏覽器中開啟預覽，過去開發者若要在編輯器內快速查看本機HTML頁面，通常需要安裝額外擴充套件，現在則可直接使用內建瀏覽器查看結果。

AI代理相關更新則集中在終端機行為，微軟說明，過去命令列工具無法判斷終端機指令是由使用者手動執行，還是由VS Code的AI代理流程啟動，因此可能出現進度動畫、互動提示或過多輸出，影響代理持續執行任務。VS Code 1.121會在AI代理啟動終端機指令時設定專用環境變數，讓命令列工具可辨識這類指令來源，改用較適合機器讀取的輸出格式，並減少可能阻塞流程的提示。

針對長時間執行的終端機指令，VS Code現在會在聊天介面顯示指令仍在背景執行，並提供查看按鈕，讓使用者回到對應終端機確認狀態。新版也擴大終端機工具輸出的壓縮範圍，VS Code 1.121會在傳回模型前修整重複內容，讓AI代理更容易取得真正重要的錯誤訊息或執行結果，也可減少不必要的模型處理成本。

在安全處理方面，當終端機指令要求輸入密碼、通行片語、PIN碼或驗證碼時，VS Code會讓使用者直接在終端機中輸入，避免這些敏感資訊進入聊天內容。

此外，VS Code 1.121也加入遠端AI代理預覽功能。使用者可透過SSH或開發通道連接自己擁有的遠端機器，讓AI代理工作階段在運作，即使本機端暫時中斷連線，遠端代理仍可繼續處理任務。

'

【AI Coding實戰】AI開始寫程式後，工程師下一步是什麼？LINE臺灣：不只寫規格，更要懂得帶AI做事

來源：https://www.ithome.com.tw/news/175833

一開始，LINE臺灣工程師們並非用AI來開發正式產品，而先來解決一些上班時的小麻煩。

比如，有人寫了一個小工具，請AI幫忙操作公司販賣機；也有人用AI自動搜尋會議室空檔、幫忙搶會議室；還有人把一些重複性的內部流程，自動化成小程式，省去每天手動處理的麻煩。

這些原本只是工程師之間的自發性小專案，卻讓LINE臺灣企業解決方案事業部技術總監林建辰慢慢發現一件事：團隊裡幾乎每個人，都開始用AI解決工作問題。他笑說：「既然大家都在用，不如我們就找一些公司裡的小型專案來試試，看有沒有辦法用AI幫我們做出產品。」

第一步：Mini Home有7成程式碼來自AI

林建辰所帶領的LINE臺灣企業解決方案事業部技術團隊，成立於去年4月，源自LINE內部的一次組織重整。這支新團隊的工程師來自LINE內部不同技術單位，主要負責企業客戶相關的產品與解決方案。

林建辰觀察，去年5、6月，AI輔助開發和AI Agent開始在產業界快速發酵，團隊也明顯感受到，相較前年，大型語言模型（LLM）的表現和可靠度進步很多。

於是，他們決定從一個真正的小型產品開始試水溫。

這個產品，就是LINE Mini App生態系中的入口頁面「Mini Home」。Mini Home整合在LINE錢包頁面中，扮演各種Mini App的服務入口，使用者不必額外下載獨立App，就能直接在LINE應用程式內完成品牌會員、點餐、訂位等操作，甚至還能把常用服務釘選到手機桌面，就像使用原生App一樣快速存取。

這個產品去年10月正式上線，團隊從7、8月開始規畫，採用時下最直覺的Vibe Coding模式，來輔助開發。所謂Vibe Coding，是指工程師直接透過指令（Prompt）描述需求，再由AI產生程式碼，邊寫邊修正。

林建辰透露，Mini Home約70%的程式碼由AI生成，剩下30%由工程師負責調整、補強和後續測試，整體開發時間約2到3周。「如果用傳統方式做，我估計至少還要多一個月。」

這次成功讓團隊建立信心，但也很快暴露出另一個問題：Vibe Coding雖然快，卻不夠可控。

第二步：改用Spec Kit，工程師白天寫規格，晚上讓AI寫程式

林建辰形容，Vibe Coding最大的問題，就像你請一位工匠幫你做椅子，他可能第一次做出木椅；第二次你告訴他要一張人體工學椅，請他重做，結果他只在木椅加上輪子；第三次又換成別的版本。

「AI不是不會做，而是如果規格不夠明確，它很容易已讀亂回。」林建辰表示，為解決這個問題，團隊後來導入GitHub開源的Spec Kit框架，正式從Vibe Coding轉向規格驅動開發。

進一步來說，Spec Kit的核心，把開發流程拆解成4個明確的階段，先定義完整規格，再讓AI根據這些規格工作。例如，在最前面的Constitution階段，團隊會先定義技術堆疊、命名規則、程式撰寫風格，以及依賴策略；接著在Specify階段，團隊要定義功能範圍、使用流程與驗收條件；再來是Plan階段，要決定資料庫設計、API結構與系統元件；最後是Tasks階段，將規格拆成可執行任務，交由AI逐步實作與測試。

換句話說，工程師不再花大量時間告訴AI「怎麼寫」，轉而先定義「要做什麼」、「不能做什麼」、「做到什麼程度才算完成」。「以前我們白天寫code，現在變成白天寫spec，下班後讓AI寫code。」林建辰說：「因為AI不用休息，隔天白天我們就可以審查AI寫好的程式碼，加速完成專案。」

這套方法第一次大規模實戰，是應用在LINE官方帳號生態系產品OA Plus幫手市集中的一個功能元件。雖然OA Plus本身是經營多年的大型產品，不可能整個重寫，但團隊選擇其中一個中小型元件，作為Spec Kit試點專案。

（OA Plus幫手市集示意圖）

結果，一個比Mini Home規模更大的元件，只花3天就完成了。「第一天、第二天讓AI跑，第三天我們收尾、確認沒問題，專案就完成了。」林建辰說。

擁抱SDD不能一路複製，專案規模變大就得要切分規格

不過，規格驅動開發模式，並不是導入後就能一路複製。

林建辰坦言，在他的團隊裡，SDD目前仍用於中小型元件或功能模組，還沒有直接套用到真正的大型核心系統。

最大的原因，在於當專案規模越來越大，如何切分規格本身，就是一門新學問。「規格切得太大，AI一次吃不下；切得太碎，規格之間的相依性又會很難管理。」尤其當系統牽涉多個服務、資料庫與外部API串接時，團隊不只要定義單一功能的規格，還要進一步思考系統邊界、模組依賴關係，以及不同規格之間如何協作。

林建辰表示，這已經不是單純的指令工程，而更接近架構治理。「以前我們寫程式，現在更像是設計AI怎麼工作。」

這也是團隊目前還不敢直接把Spec Kit套用在超大型專案的原因，而先從元件、模組開始驗證，再逐步往更大的系統擴展。

第一次送資安審查就被打槍，LINE開始用AI監督AI

AI加速開發後，新問題也隨之浮現。

林建辰透露，團隊第一次把Spec Kit那套方法產出的程式，送交內部資安團隊審查時，原本大家都很興奮，沒想到結果卻是「不審查還好，一查一堆問題」，資安團隊甚至開出好幾張修正單。

這讓他們意識到，AI輔助開發要真正落地，資安要更早結合到開發流程中。

於是，他們先把公司內部的資安規範，直接寫進規格裡。例如，如果產品涉及個人資料，規格就必須明確定義資料加密；如果系統需要引入第三方函式庫，也必須符合公司內部審核規範，而不是讓AI自行決定。

這還不夠，LINE後來更進一步，在CI/CD pipeline中導入AI Agent，專門監督AI產出的程式碼。

林建辰透露，這個AI agent除了掃描常見漏洞外，還會透過MCP連接公司內部Wiki系統，來即時抓取最新版本的安全指引，再比對這次PR是否符合最新規範。

「因為公司的安全指引一直在更新，十幾頁、甚至更多，不可能每次都人工從頭看完。」林建辰說：「但AI可以。」這讓資安從過去的最後一道關卡，逐漸往前移到規格撰寫和CI階段。

「現在不只用AI幫忙寫程式，我們還用另一個AI，監督AI寫出來的程式碼。」但他也強調，最後負責的人，仍然是工程師。

AI輔助開發，也進入軟體開發的生命周期

從程式碼審查、系統設計，到規格驅動與資安治理，林建辰觀察到，AI真正開始改變的，不只是單一的開發環節，而是整個軟體開發生命周期。

以林建辰團隊這一年導入AI的經驗來看，軟體開發大致可拆成需求釐清、定規格、實作、測試上線，以及後續維護等5個階段，而AI幾乎每一段都開始介入。

比如，在需求階段，工程師可先用AI協助搜尋類似案例、整理市場資訊，甚至提出不同技術解法，協助團隊更快釐清問題本身。

進入定規格階段後，AI則扮演「資訊整理者」的角色。過去，產品需求可能散落在會議紀錄、郵件、即時通訊，甚至不同國家的團隊文件中，但現在，AI可以協助把不同來源的資訊整合成較完整的規格初稿，甚至主動點出邏輯不一致或驗收條件不夠明確的地方。

到了真正寫程式的階段，變化就更明顯了。

林建辰表示，過去工程師拿到需求後，不只要熟技術，也得懂產品，才能一步一步把需求變成程式，人力門檻和學習成本都不低。但現在，AI已經能先協助產出第一版程式，甚至補上一些重複性高的基礎內容，讓工程師不用再從零開始。

工程師真正花時間的地方，也從「怎麼把程式寫出來」，慢慢轉向「這樣寫對不對」、有沒有符合產品需求，以及整體架構是否合理。「現在，工程師更像審核者。」林建辰說。

至於測試階段，LINE團隊現在也開始讓AI協助生成測試案例、自動化測試腳本，甚至由QA工程師透過AI快速建立瀏覽器自動化測試流程。

而在系統上線後的維運階段，AI也開始協助整理變更日誌（Change Log）、追蹤系統異動，甚至產生架構決策記錄（ADR），記錄每次重大技術變更背後的原因，好傳承背景知識。

「以前AI只是加速寫程式，但現在，它開始深入整個開發生命周期。」林建辰強調。

從寫程式到設計AI，LINE要重新定義工程師的角色

AI不只改變開發流程，也開始重新定義工程師在團隊裡的角色。

林建辰表示，目前團隊人數並沒有因AI導入而縮減，但角色邊界開始變得模糊。比如，原本負責手動測試的QA工程師，現在開始用AI生成自動化測試腳本，甚至透過Playwright建立瀏覽器自動化測試。這讓原本需要2周才能完成的大型迴歸測試，縮短到2、3天。

前端與後端工程師的界線，也不像過去那麼明確。林建辰坦言，以前做這種自發性小專案時，工程師可能還需要找其他同事協助補前端或後端；現在，在AI的輔助下，每個人都越來越像全端工程師。

在他看來，未來工程師不會消失，但角色一定會升級。「以前工程師比較像工匠，專注把自己那一塊做好；未來更像工頭，帶著一群AI Agent一起做事。」他甚至認為，未來每位工程師，都會像一位小型產品經理，底下帶著不同功能的AI Agent，分別負責前端、後端、測試與外部系統串接。

工程師真正的價值，不在是撰寫多少程式碼，而是能不能定義問題、寫出好的規格，並對AI產出的結果負責。

寫好規格只是開始，下一步要學的是怎麼帶AI做事

對LINE團隊來說，導入Spec Kit並不是終點，而更像下一階段的起點。

林建辰透露，團隊接下來除了持續深化SDD，把更多專案從需求階段就開始規格化，也希望進一步培養自主開發AI Agent的能力。

但他坦言，真正困難的地方，從來不是把大型語言模型串接起來，而是如何讓AI Agent在企業環境中，變成一套可管理、可監控，也值得信任的系統。

舉例來說，當使用者對AI Agent下指令時，系統要不要先快取這些指令？如果要，是要做語法（Syntax）層級的快取，還是進一步理解使用者真正的意圖，做更深層的語意（Semantic）快取？這本身就是一門技術。

除此之外，當使用者與AI Agent互動時，系統是否要保留完整的稽核紀錄（Audit Log）；當後端的大型語言模型異常時，是否具備自動切換能力；甚至，如何即時監控Token用量，避免成本失控，也都是團隊接下來必須面對的新課題。

「我剛講的每一件事，其實都是一門學問。」林建辰說：「這些能力都很重要，只是過去大家都沒有真的實作，整個業界也都還在摸索。」

也因此，目前像系統部署、環境升級等高風險操作，團隊仍堅持由工程師人工把關。

「誰寫程式碼不重要，最後負責的，還是工程師。」這也是LINE團隊過去一年最大的體悟：當AI開始自己寫程式，工程師真正被放大的，不是開發能力，而是規格思維、架構視野，以及治理AI的能力。

'

法國監管機構調查：資料中心耗電3年暴增38%，大型AI資料中心成能源與碳排新壓力

來源：https://www.ithome.com.tw/news/176092

法國電子通訊與郵政監管局（Arcep）近日公布第五版數位永續調查報告，持續追蹤法國ICT產業的能源消耗與環境影響。該報告指出，儘管資料中心設備能效持續改善，但整體能源需求仍快速成長，過去3年間資料中心用電量累計增加38%。

報告指出，2024年新增啟用的資料中心數量雖然有限，但整體運算能力仍持續大幅提升，反映新建設施規模不斷擴大。若以電力容量觀察，2023年啟用的新資料中心平均容量已達9MW，遠高於既有資料中心平均3MW的規模，而2024年新投入營運的資料中心平均容量更進一步提高至20MW。

這項趨勢顯示，隨著AI訓練、大規模雲端服務及高效能運算需求增加，資料中心產業正由傳統機房逐步轉向高密度、大容量的超大型設施，也使得總體能源消耗持續攀升，即使單位運算效率改善，仍無法完全抵銷運算需求成長帶來的能源負擔。

能源效率提升仍難抵消AI運算需求，碳排持續增加

報告指出，資料中心技術持續進步，包括伺服器效能提升、散熱系統優化與能源管理改善，都有助於提高能源使用效率。然而，由於整體運算規模成長速度更快，資料中心的能源消耗與溫室氣體排放量仍呈現上升趨勢。

從區域分布來看，法國的資料中心發展高度集中。2024年受調查資料中心中，超過90%的運算能力與能源消耗集中於上法蘭西（Hauts-de-France）、普羅旺斯－蔚藍海岸（Provence-Alpes-Côte d’Azur）及法蘭西島（Île-de-France）三大區域。其中，法蘭西島地區單獨就占受調查資料中心數量的56%，並貢獻超過70%的總運算能力與能源使用量。

這種高度集中化現象，也代表電力供應、電網容量與再生能源配置將面臨更大壓力。近年歐洲各國陸續將資料中心納入能源轉型與碳排放管理政策範圍，原因正是大型AI資料中心帶來的用電需求已逐漸成為區域能源規畫的重要變數。

光纖基礎建設同樣存在隱含碳排與能源成本

除了資料中心本身，Arcep今年也首次納入光纖纜線供應鏈的環境影響評估。調查顯示，2024年法國市場銷售的光纖纜線在生產過程中總共消耗約170GWh能源，其中大部分為電力，相當於法國固定網路全年耗電量的26%。

此外，光纖製造過程亦消耗約6.6萬立方公尺用水，平均每公里光纖約需200公升水資源。若以產品全生命週期計算，2024年銷售光纖纜線的隱含碳排放量（Embodied Emissions）達10.8萬噸二氧化碳當量。

報告特別指出，光纖纜線的碳足跡與纖芯數量高度相關。僅有1至4芯的光纖纜線，每公里約產生100公斤CO₂e，而超過288芯的大容量骨幹光纖，每公里碳排放量可達2,500公斤CO₂e，兩者相差超過25倍。

下一步將納入雲端服務商環境影響調查

Arcep表示，隨著AI與雲端運算快速成長，現有資料已不足以完整呈現數位產業的環境衝擊。因此，下一版調查將首次納入雲端服務供應商的能源與碳排放數據，希望建立更完整的數位基礎設施環境影響資料庫。

這反映出監管機關開始關注焦點從電信網路延伸至雲端平臺與AI基礎設施，隨著大型AI模型訓練與推論需求持續增加，資料中心的能源效率、再生能源採用率、用水管理以及隱含碳排放，逐漸成為數位產業永續發展的重要評估指標。

'

Ubiquiti修補UniFi OS平臺三項滿分重大漏洞，未更新可能導致執行任意指令與洩露敏感資訊

來源：https://www.ithome.com.tw/news/176091

主打中小企業與個人專業用戶的網通設備商Ubiquiti，近日發布資安公告，修補旗下UniFi OS管理平臺的重大漏洞，包含3項CVSS嚴重性評分10.0滿分的漏洞，可能導致攻擊者執行任意指令、存取系統底層敏感資訊等問題。

Ubiquiti這次更新，是繼3月份修補UniFi Network Application滿分重大漏洞後，再次修補旗下網路設備管理軟體的滿分重大漏洞，但此次受影響的是更底層的系統平臺UniFi OS，一共包含5項漏洞，其中風險最高的是3項CVSS嚴重性滿分的重大漏洞：

首先是CVE-2026-34908，為UniFi OS的存取控制不當問題，可能導致攻擊者對系統進行未經授權的更改。其次是CVE-2026-34909，屬於路徑遍歷問題，可能導致攻擊者藉此存取底層系統檔案，進而存取底層帳戶。第3項是CVE-2026-34910，屬於輸入驗證不當問題，可能造成指令注入攻擊。

除前述3個滿分漏洞外，這次Ubiquiti還修補另2個UniFi OS漏洞CVE-2026-33000與CVE-2026-34911，其中CVE-2026-33000的CVSS嚴重性評分達9.1分，為可能造成指令注入攻擊的輸入驗證不當問題。CVE-2026-34911的CVSS嚴重性評分則為7.1分，屬於可能導致存取底層敏感檔案的路徑遍歷問題。

前述漏洞會影響UniFi OS 5.0.6以前版本，以及配套的Ubiquiti各式網路周邊設備的系統韌體，如UCG-Industrial、UDM、UDR、UNAS、UNVR等系列。解決方法是將UniFi OS升級到5.0.8以後版本，並依照公告指示，將網路周邊設備韌體升級到已修補版本。

'