設備效能莫名變差、GPU 使用率怪怪的，你會想到是被拿去挖礦了嗎？這篇帶你完整復盤一次真實入侵，再把資安做法搬進 AI Coding 的每個開發階段！
一開始只是表象：物件偵測的效能變差，GPU 使用率不對勁，接著客戶也回報了異常。
我們順著查下去，才發現 GPU 被人拿去挖礦了。
先交代背景。我們部門做的是工廠裡的邊緣運算設備，用物件偵測做人因工程分析，屬於工控設備。它的設計前提是部署在廠內、跑在封閉網路裡，不對外連線。
我不是資安出身。這次是和 DevOps 的同事一起把事情從頭查到尾，才學到很多原本不知道的事。這篇是那次的復盤，也是我後來重新想「上線」這兩個字的起點。
快速回答 一台設計在封閉網路裡的工廠邊緣運算設備，在客戶端被接上外網，攻擊者從對外暴露的 Docker 容器服務進來，用寫在設定檔裡的密鑰拿到資料庫最高權限，把 GPU 拿去挖礦。四個根因都是「反正在內網」的捷徑，網路上卻有程式 24 小時自動掃描這類破口：資安沒拼上，產品就不完整。用 AI 寫程式的團隊，把資安規則寫進 AI 每次都會讀的規則檔，再讓工具在 commit 前、PR、映像檔和上線後各擋一關。
封閉網路只是舒服的假設：設備到了客戶現場，網路上隨時有程式在掃描破口
封閉網路是一個很舒服的假設。設備不連外網，外面的人就進不來；進不來，裡面有些事就可以先將就。
這個假設在自家工廠成立。到了外部客戶那裡就不一定了。有些客戶的 IT 管理沒那麼嚴謹，設備實際上被接到了能從外網連進來的位置。我們設計時預設的那道牆，在客戶的現場並不存在。
而外面一直有人在找這樣的設備。網路上有程式 24 小時自動掃描，看哪些主機開著不該開的門。第一次真正意識到這件事時，我的感覺很奇妙：原來世界上有這麼多人，日夜不停地在找破口。
真實入侵路徑：攻擊者從暴露的容器服務長驅直入，靠設定檔密鑰拿下資料庫並盜用 GPU 挖礦
事後拼回來的入侵經過，大致是這樣的：
- 攻擊者從設備上對外暴露的容器服務進來。
- 進來之後，在設定檔裡找到直接寫在檔案中的密鑰。
- 循著這些密鑰找到資料庫後台，拿到最高權限。
- 植入挖礦程式和監控，偽裝成看起來無害的正常程式，開始吃設備的 GPU。
這個模式在業界並不罕見。Kaspersky 在 2025 年 5 月揭露過一波類似的攻擊：從不安全地對外公開的 Docker API 進入，挖礦程式和擴散工具都用 Go 寫成，擴散工具直接取名為「nginx」，看起來就像一個正常的網頁伺服器；它們不需要指揮伺服器，會自己在暴露的容器環境之間散播。趨勢科技也追蹤過另一波名為 Commando Cat 的攻擊，同樣是濫用對外暴露的 Docker 介面來部署挖礦程式。
Kaspersky 在報告裡用這張圖說明整條攻擊是怎麼自動擴散的：入口、植入、再往外找下一個受害者，三步都不需要人手。
程式碼量不小，靠人一行一行讀很慢。我們用 AI coding 工具，搭配網路上公開的資安掃描提示詞，讓 AI 先把可疑的地方掃出來，再由人逐一確認。這次能比較快找到問題，AI 幫了很大的忙。
四個致命根因：密鑰寫死、內網全通、容器繞過防火牆與最高權限，全來自「反正在內網」的捷徑
復盤下來，真正讓攻擊者一路走到資料庫的，是四個「反正在內網」的捷徑。
密鑰寫在檔案裡。封閉網路讓人覺得檔案不會外流，於是密鑰、密碼直接寫在設定檔裡。攻擊者一旦進來，這些檔案就是現成的地圖。
內網全部互相開放。設備內部的服務之間沒有限制，彼此都能連。進到一個點，就等於進到全部。
防火牆有設，容器卻繞過它。這是我學到最意外的一課。主機上的 Linux 防火牆規則我們有設，但容器對外公開的連接埠，流量在進到那些規則之前就被轉走了。Docker 的官方文件寫得很直接：封包會在防火牆規則套用之前就被路由出去，等於忽略了你的防火牆設定。我們以為關上的門，對容器來說一直開著。
資料庫用最高權限連線。應用程式用最高權限的帳號連資料庫，所以攻擊者拿到一組密鑰，就拿到了整個資料庫。
這四件事單獨看都像小疏忽。放在一起，就成了一條從外網直通 GPU 的路。
事後止血的五項處置：重置設備、輪換密鑰、補上容器防火牆、切分內網與降級權限
事後我們做了五件事：
- 受感染的設備重置、重新部署。只刪掉木馬不夠，無法確定還留了什麼。
- 密鑰全部移出程式碼，並且輪換。舊的密鑰一律視為已外洩。
- 處理容器繞過防火牆的問題，讓對外的規則在容器那一層也生效。
- 內網切分、最小開放。只留下服務之間真正需要的連線。
- 資料庫權限降級。應用程式改用只拿得到它需要的權限的帳號。
仍待解決的兩大盲點：客戶端網路邊界不由我們掌控，且團隊尚缺固定的上線前資安流程
有兩件事，到現在還沒有好答案。
第一，客戶端的 IT 我們控制不了。設備裝在客戶的網路裡，要不要對外開放，最後是客戶決定。我們能做的是讓設備本身在「被接上外網」時也撐得住，但牆在哪裡，不由我們決定。
第二，團隊還沒有固定的上線前資安檢查流程。這次是出事之後補救。如果下次的修補仍然靠某個人剛好想起來，同樣的事遲早會再發生。
AI Coding 放大資安風險：AI 協作 commit 洩漏密鑰率達 2 倍，45% 生成程式碼含漏洞
這次出事的設備，問題出在「封閉網路」的假設。但我後來越想越覺得，用 AI 寫程式的團隊，更需要把這一課放在心上。
寫程式變快了，攻擊也是。攻擊端已經是自動化的：掃描、入侵、擴散，都不需要人在旁邊。開發端也變快了，但快的同時，有些風險跟著放大。GitGuardian 統計，2025 年公開 GitHub 上新增約 2,865 萬組寫死的密鑰，比前一年多 34%；有 AI 協作的 commit，密鑰外洩的比例大約是一般 commit 的兩倍。內部 repo 更有 32.2% 含有寫死的密鑰，公開 repo 只有 5.6%：越覺得安全的地方，越容易鬆懈。這跟我們當初面對封閉網路的心態完全一樣。
程式碼本身也一樣。Veracode 2025 年拿 80 個寫程式任務測了一百多個模型，45% 的情況下，模型寫出的程式含有 OWASP Top 10 列出的漏洞，而且模型變大並沒有明顯改善。
Vibe Coding 讓一個人也能很快做出能跑的產品。能跑，和能放到一個 24 小時有人在掃的網路上，是兩件事。
把資安防線前移到 AI 協作：用精簡規則檔、RCI 自檢與攻擊面提問防堵漏洞
我們那次是事後補救。回頭看，那四個根因，傳統資安其實都有對應的做法：安全編碼規範、程式碼審查、密鑰管理、供應鏈管理、最小權限。這些做法在 AI 時代沒有過時，只是執行的位置換了。以前寫在團隊規範和審查清單裡，現在有很大一部分，要寫進你跟 AI 協作的過程。
具體怎麼做，我整理成五個技巧。
一、把資安規則寫進規則檔，而且寫短。Claude Code 的 CLAUDE.md、通用的 AGENTS.md、GitHub Copilot 的 instructions，都是 AI 每次開工會先讀的檔案。開源安全基金會 OpenSSF 在 2025 年 8 月發布了一份專門的指引，建議規則要「簡潔、具體、可執行」，目的是影響 AI 的行為，同時不把它淹沒；只挑和你的專案有關的規則放進去，貼一大堆無關的範例反而會讓 AI 寫出多餘或錯誤的程式。對照我們踩到的坑，一份最小可用的規則大概長這樣：
## 資安規則
- 不要把 API key、密碼或任何密鑰寫進程式碼、設定檔或輸出；改用環境變數或密鑰管理服務。
- 資料庫查詢一律使用參數化查詢；所有外部輸入都要檢查格式與長度。
- 新增套件前，先說明它是什麼、由誰維護；不要引入不存在或來路不明的套件。
- 容器公開的連接埠預設只綁 127.0.0.1；需要對外時，先說明原因。
- 應用程式連資料庫使用最小權限帳號，不要使用管理員帳號。
規則檔的寫法，可以直接參考 OpenSSF 的原文，裡面有各語言、各平台的範例規則可以挑：
二、寫完之後，叫它自己挑毛病。這個做法叫「遞迴批評與改進」（Recursive Criticism and Improvement，RCI）。一篇 2024 年的研究系統性比較了各種提示技巧對程式碼安全的影響，在 GPT-3、GPT-3.5、GPT-4 上，RCI 降低資安弱點的效果最明顯；OpenSSF 的指引也建議這樣做。提示詞很簡單：
請檢查你剛才寫的程式，列出可能的資安問題（密鑰、輸入驗證、權限、對外暴露的介面），再依這些問題修改程式。
三、寫功能之前，先問攻擊面。動手前多問一句：「這個功能會對外開哪些介面？誰可以呼叫？最壞會被拿來做什麼？」我們的設備如果在設計時問過「被接上外網會怎樣」，答案會很不一樣。
四、不要叫它「扮演資安專家」。OpenSSF 的指引特別說明，目前不建議一般情況下要求 AI 以特定身分回答，有些實驗發現「專家角色」的提示表現反而不好。具體的規則，比一個身分有用。
五、規則檔本身也要審。規則檔會影響之後每一次產出，所以它也是攻擊目標。資安公司 Pillar Security 在 2025 年 3 月揭露「Rules File Backdoor」：攻擊者把人眼看不見的字元藏進看似正常的規則檔，AI 讀得到、人看不到，就會在之後產出的程式裡偷偷加料。從網路上複製來的規則檔，進 repo 之前要像程式碼一樣審查。
這五個技巧有一個共同的邊界：提示詞能降低出錯的機率，不能保證不出錯。研究測的是特定模型和特定任務，最後一關仍然要交給工具和人。
資安防線不能只靠人記住：從寫程式、commit 到上線五階段導入自動化工具攔截
提示詞靠人記得下。真正可靠的，是把檢查放進流程，讓它每次都自動發生。市面上每個階段都有現成的工具，很多是開源或有免費方案：
下面這五個，我用介紹朋友的方式講：它從哪裡來、解決什麼問題、好在哪裡、要小心什麼。都是舉例，沒有排名。
寫程式時：Claude Code 的 /security-review
Anthropic 在 2025 年 8 月推出，有兩種用法：在終端機裡打 /security-review，commit 之前先跑一次資安審查；或裝上它開源的 GitHub Action（MIT 授權），每個 PR 自動審查並留言。它解決的是「每次改動都找人審太慢」：只看這次改動的檔案，用模型去理解程式在做什麼，比固定規則多看一層，還會過濾掉一部分誤報。
好處是它懂上下文，抓得到規則式工具看不出來的邏輯問題，設定也簡單。要小心的是，它本身也是 AI，會漏、也會誤判，同一段程式兩次的結果不一定一樣；每次掃描都要花 API 費用。Anthropic 自己也寫得很清楚：這是補充，不能取代既有的資安做法和人工審查。
commit 前：Gitleaks
2018 年開源，用 Go 寫成，MIT 授權。它解決的就是我們的第一個根因：密鑰還沒進 repo 就先攔下來。掛在 git 的 pre-commit 上，每次提交前自動掃；也能回頭掃整段 git 歷史，把很久以前就埋在裡面的舊密鑰找出來。原理是用正規表示式比對已知的密鑰格式，再加上字串的亂度判斷。
好處是免費、在本機跑、速度快，規則看得懂也改得動。要小心兩件事：規則式比對會有誤報，剛導入時要花點時間調設定；另外，維護者已經在官方 README 寫明 Gitleaks「功能已完成」，之後只發資安修補，心力轉到新專案 Betterleaks。現在拿來用沒問題，但長期要留意後續。
PR／CI：Semgrep
它的前身是 Facebook 開源程式分析工具 pfff 裡的 sgrep，後來由 r2c（現在的 Semgrep 公司）接手，2020 年改名為 Semgrep。它解決的是「不安全的寫法一直重複出現」：把一種寫法寫成規則，合併前自動把符合的程式碼標出來。
好處是規則長得很像程式碼本身，團隊看得懂、也能自己寫，社群累積的現成規則很多。要小心的是，免費的社群版（Community Edition，LGPL 2.1 授權）以單一檔案的模式比對為主，跨檔案追蹤資料流這類深入分析在付費版；官方維護的規則近年改了授權，限制部分商業用途，也因此有廠商另外分支出 Opengrep。導入前先看清楚你要用的是引擎還是規則、各自什麼授權。GitHub 的 CodeQL 是同一類工具，公開 repo 可以免費用。
建置與映像檔：Trivy
日本工程師福田鉄平（Teppei Fukuda）在 2019 年以個人專案開源，同年由 Aqua Security 接手並延攬他，專案維持開源（Apache 2.0）。它解決的是「容器裡到底裝了什麼、有沒有已知漏洞」：一個工具就能掃容器映像檔、相依套件的已知漏洞，以及設定檔的錯誤設定。
好處是一支執行檔就能跑，涵蓋面很廣，很適合當第一個導入的掃描器。要小心的是，它比對的是已知漏洞資料庫，報告常常列出一長串，其中很多在你的使用情境下碰不到，需要人排優先順序；它也判斷不了「這台設備會不會被接上外網」這種部署情境。我們的設備跑在容器裡，這一關最貼近我們的情境，但它補不了封閉網路假設被打破的那一塊。
上線後：Falco
2016 年由 Sysdig 開源，2018 年捐給雲原生運算基金會 CNCF，2024 年 2 月成為 CNCF 的畢業專案。前面四關都是「上線前」的靜態檢查，Falco 補的是上線之後：它在執行期間監看主機和容器裡發生的事，出現異常行為就即時告警。
好處是它看得到「已經在發生」的事，是前面所有檢查的最後一道網。設備裝在客戶端，牆在哪裡不由我們決定，那至少要在異常發生時知道。要小心的是，規則不調會警報疲勞，最後沒人看；它需要在主機上裝核心層的驅動或 eBPF 探針，邊緣設備的資源和核心版本要先確認撐不撐得住。
AI Coding 時代的上線前檢核清單：密鑰隔離、權限限縮與「被接上外網」的必測情境
我把這次的教訓整理成一份上線前檢查。每一條都對應一個我們實際踩到的坑，再加上 AI coding 特有的一條：
- 密鑰不進檔案、不進 repo、不進給 AI 的上下文。用環境變數或密鑰管理服務；commit 前用工具自動掃描；一旦外洩就輪換。GitGuardian 發現，2022 年就已驗證有效的密鑰，四年後還有 64% 能用，外洩過的密鑰不會自己失效。
- 盤點每一個對外的連接埠，從外面掃一次自己。特別檢查容器公開的連接埠，不要假設主機防火牆管得到它；不需要對外的服務，只綁在本機位址。
- 內網預設不通。服務之間只開必要的連線。工控現場可以參考 IEC 62443 的分區做法，把網路切成區域，區域之間只留受控的通道。
- 每個帳號只給它需要的權限。應用程式連資料庫不用最高權限，管理用的帳號另外分開。
- AI 寫的程式，合併前要過資安掃描。也可以反過來讓 AI 幫忙找問題，我們就是這樣找到的，但掃出來的結果，最後要有人看過、確認。
- 為異常設警示。GPU 使用率、對外連線數這類指標，平常就要有基準線，偏離了要有人知道。我的判斷是，這次如果有警示，我們有機會比客戶更早發現。
最後一條是給自己的：部署環境的假設要寫下來。產品預設在封閉網路裡跑，就把「如果被接上外網會怎樣」當成必測的情境。
結論：封閉網路只是假設，上線前落實資安檢查才是唯一的證明
那台被拿去挖礦的設備，後來重置、重新部署了。
它教我的事很簡單：我們以為的牆，攻擊者看不到；他們只看得到門有沒有關。
封閉網路是假設，上線前的資安檢查才是證明。
如果想知道接上 AI 工具時交出了哪些權限，可以接著讀〈MCP server 該不該裝？安裝前一定要做的權限檢查（2026 資安懶人包）〉；想把「AI 說完成了」變成可驗證的結果，可以讀〈AI 寫的測試全過，為什麼功能還是錯的？驗證閉環完整懶人包（2026）〉。
常見問題
為什麼宣稱封閉內網的設備，還是會被植入挖礦程式？
「封閉網路」多半只是紙面上的假設。在現場維護、遠端除錯或設備交接時，常有人臨時插上 4G 網卡、連上公共 Wi-Fi 或打開未經管制的路由。攻擊者的自動化掃描器 24 小時在公網探測，只要設備稍微露出一瞬間的漏洞，就會立即淪陷。
Docker 容器預設公開連接埠時，為什麼主機防火牆可能管不到？
Docker 啟動時預設會自動操作 Linux 系統底層的 iptables 規則，直接將容器連接埠暴露給外部網路。許多工程師以為在主機端開啟了 ufw 防火牆就萬無一失，卻不知道 Docker 的規則優先權高於 ufw，直接繞過了本地防護。
部署在客戶現場的邊緣設備，最基本的資安防線有哪三道？
一、所有服務預設只監聽本地迴路（127.0.0.1），絕不對外開放未經驗證的連接埠；二、金鑰與帳密禁止寫死在程式碼或設定檔中，全面採用環境變數隔離；三、建立核心指標監控，當 GPU 或 CPU 出現異常飆高、對外連線暴增時立即發出警報。
開發階段用 AI 生成的組態與程式碼，在上線前如何做資安防護？
AI 產出往往以「能跑通」為第一優先，經常便宜行事給予 0.0.0.0 綁定、預設高權限帳號或寬鬆的 CORS 設定。上線前必須使用靜態安全分析工具（SAST）進行自動化掃描，並由資安或資深工程師依據檢核清單逐項驗證權限邊界。
延伸閱讀
- AI Demo 很成功，為什麼一上線就出事？五條失敗路徑一次看懂（2026）
- Claude Code 權限要怎麼設？一直按「允許」真的安全嗎？（2026 完整懶人包）
- AGENTS.md 怎麼寫？規則寫越多，Agent 反而越貴？（2026 完整教學＋範例）
參考資料
- Docker Docs. Packet filtering and firewalls.
- Kaspersky Securelist (2025-05). Dero miner zombies biting through Docker APIs.
- 趨勢科技 (2024). Commando Cat：新型加密挖礦攻擊.
- GitGuardian (2026). The State of Secrets Sprawl 2026.
- SD Times (2025). AI-generated code poses major security risks in nearly half of all development tasks, Veracode research reveals（Veracode《2025 GenAI Code Security Report》，經二手來源確認）.
- OpenSSF Best Practices and AI/ML Working Groups (2025-08-01). Security-Focused Guide for AI Code Assistant Instructions.
- Catherine Tony et al. (2024; ACM TOSEM 2025). Prompting Techniques for Secure Code Generation: A Systematic Investigation.
- Anthropic (2025-08-06). Automate security reviews with Claude Code.
- Pillar Security (2025-03). New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents.
- Anthropic. claude-code-security-review（GitHub，MIT 授權）.
- 工具官方頁面：Gitleaks、Semgrep、Trivy、Falco（2026-10-13 檢視）.
- CNCF (2024-02-29). Cloud Native Computing Foundation Announces Falco Graduation.
- Aqua Security. Trivy Vulnerability Scanner Joins the Aqua Family.
- Semgrep Docs. What is Semgrep Community Edition?
留言0
登入後就能留言。
登入