AI 開發時代，資安不能只等工具跳警報

Cisco Talos 這週的 Threat Source 來自 Cisco Live U.S.。現場討論的主軸很明顯：AI 不只是產品功能，而是正在改變企業的資料流、基礎設施與防禦方式。

對 vibe coding 開發者來說，這篇文章最值得注意的不是單一漏洞，而是整體趨勢：AI agent、雲端 IDE、套件管理器、OAuth token、瀏覽器內開發環境，都正在變成攻擊者會盯上的入口。

這對用 AI 寫 code 的開發者代表什麼？

Talos 提到，攻擊者越來越會刻意避開傳統偵測門檻。很多安全工具仍然依賴「看到已知壞東西才跳警報」的模式，但如果攻擊行為只留下很弱、很分散的訊號，就可能不會被單一工具抓到。

這點和 AI coding 工作流很有關係。

現在開發者常常會：

• 把 repo 開在 GitHub.dev、VS Code Web 或遠端開發環境
• 安裝 AI、lint、formatter、preview、deploy 相關 extension
• 把 GitHub、AWS、Okta、Microsoft 365 等帳號接進工具鏈
• 讓 AI agent 讀檔、改檔、跑測試、執行 shell command
• 在本機或 VPS 上開 development server、MCP server、agent server

這些都讓「開發環境」本身變成高價值目標。攻擊者不一定要打 production server；偷到你的 token、extension 權限或開發機憑證，也可能足夠造成嚴重後果。

本週幾個和開發者特別相關的風險

GitHub.dev / VS Code extension 攻擊

文章引用一則新聞：有一個 one-click GitHub.dev 攻擊，可以讓攻擊者安裝惡意 VS Code extension，並在 GitHub OAuth token 傳給 GitHub.dev 時，利用主 VS Code 視窗與 webview 之間的 message-passing 機制竊取 token。

這對 AI coding 開發者很重要，因為 extension 生態系常常被視為「只是開發工具」。但一旦 extension 可以接觸 OAuth token、repo、終端機或工作區檔案，它就不是普通外掛，而是供應鏈風險的一部分。

開發者該注意：

• 不要隨便安裝不熟悉的 VS Code / GitHub.dev extension
• 對會要求 GitHub 權限、讀取 workspace、執行 command 的 extension 特別小心
• 定期檢查 GitHub OAuth apps、Personal access tokens、授權過的第三方工具
• 如果懷疑 token 外洩，直接撤銷並重新產生，不要只改密碼

Red Hat 官方 NPM channel 被植入後門

文章也提到：Red Hat 官方 NPM 帳號遭入侵，被用來發布會在機器間擴散的惡意 worm，目標是竊取敏感憑證。

這對依賴 npm 的開發者是非常直接的提醒：就算套件來源看起來「官方」，也不代表永遠安全。AI agent 幫你加套件、更新依賴、跑 install 時，如果你沒有看清楚變更，就可能把惡意依賴帶進環境。

開發者該注意：

• 不要讓 AI 自動加入新 dependency 而不審查
• PR 裡如果出現 package.json、lockfile 大量變更，要特別看
• 對新加入的 npm package 檢查來源、維護者、版本歷史
• CI/CD、開發機、VPS 上的 npm token、cloud credential 不要放在容易被讀取的位置
• 盡量使用 least privilege token，不要把高權限憑證放進一般開發流程

Kali365 phishing kit 擴大目標

文章提到 FBI 曾標記的 phishing kit「Kali365」原本針對 Microsoft 365，現在擴大到 AWS、Okta 和俄羅斯平台，並使用 device code phishing。

這代表攻擊者不只想偷信箱，也想拿到雲端與身份系統入口。對開發者來說，AWS、Okta、Microsoft 365 都可能是部署、登入、CI/CD、內部工具的核心。

開發者該注意：

• 對 device code login 保持警覺，不要在不明來源要求下輸入 code
• AWS / Okta / Microsoft 365 帳號開 MFA
• 檢查登入通知與異常裝置
• 不要把一次性登入流程交給不可信的頁面或聊天訊息

HTTP/2 Bomb 可能讓網站快速離線

文章引用一則「HTTP/2 Bomb」攻擊，指出它可能影響超過 880,000 個支援 HTTP/2、且使用預設 NGINX、Apache HTTPD、Microsoft IIS、Envoy 或 Cloudflare Pingora 設定的網站。

這對開發者的意義是：即使你的 app code 沒有明顯漏洞，web server 或 proxy 的預設設定仍可能成為風險。對 vibe coding 專案尤其常見：功能很快做出來，但部署層、反向代理、rate limit、HTTP/2 設定常被忽略。

開發者該注意：

• 不要只測 app route，也要注意 NGINX / Apache / proxy 設定
• 追蹤你實際使用的 web server 安全公告
• 避免長期使用預設設定裸跑服務
• 對公開服務加上基本 rate limiting 與資源限制

Talos 的重點：只靠自動警報不夠

Cisco Talos 這次強調他們正在擴大 Threat Hunting program，用 AI-driven telemetry analysis 加上人工專家驗證，在 endpoint、network、identity data 中主動找出隱藏威脅。

他們提到一個例子：透過這種 hypothesis-driven hunting，在正式偵測規則出現前，就發現了 KongTuke command-and-control（C2）相關活動。

換成開發者語言：不要只期待工具告訴你「這是惡意」。很多時候，你要看的是弱訊號組合，例如：

• 某個 extension 突然要求更多權限
• lockfile 出現大量不明套件變更
• GitHub OAuth app 多了一個陌生授權
• 開發機或 VPS 出現不認得的對外連線
• CI log 裡出現奇怪的 install script
• agent / dev server 被開到不該公開的網路介面

這些單獨看可能都不像重大事件，但合起來就可能是入侵線索。

開發者現在可以做的事

• 審查 VS Code / GitHub.dev extension，移除不必要或來源不明的外掛
• 定期檢查 GitHub OAuth apps、tokens、SSH keys
• 不讓 AI 在未確認前新增 dependency 或改 lockfile
• 對 npm、cloud、CI/CD token 使用最小權限
• 不把能執行指令的 agent server、dev server、MCP server 無認證公開到網路
• 關注 NGINX、Apache、IIS、Envoy、Cloudflare Pingora 等基礎設施更新
• 對 device code phishing 保持警覺，尤其是 Microsoft 365、AWS、Okta 登入流程
• 把「開發環境」當成正式資產保護，不要只保護 production

原文連結：https://blog.talosintelligence.com/reporting-from-vegas-networking-ai-and-good-boys/