用 Claude Code 檢查 GitHub 專案有沒有惡意程式：我埋了九個雷實測

從 GitHub 裝一個陌生套件，clone 之後、install 之前該做什麼？我做了一個埋九個雷的測試 repo 實測：grep 漏掉肉眼看不見的 Unicode 隱藏字元、secret 掃描器對假憑證回報 0、npm audit 對新投毒套件完全無感。附陌生 repo 的七步審查流程與工具清單，AI 創作者裝 Skill 和 MCP 前必看。

你在 GitHub 看到一個很想用的工具，git clone 下來，正要 npm install 或 ./install.sh。等一下 ── 那一秒鐘，你就把這個陌生人寫的程式碼，放進了你有 SSH 金鑰、有 .env、有瀏覽器 cookie 的這台電腦。

2025 年是開源供應鏈攻擊工業化的一年。光是這一年，新增的惡意開源套件就超過 45 萬個，九成九集中在 npm。有一種自我複製的蠕蟲，會在你安裝的瞬間掃你機器上的憑證，再自動把自己塞進你能發布的套件裡繼續傳播。

這篇不講理論。我親手做了一個埋了九個雷的測試 repo，然後當作第一次看到它，實際跑一次審查，看哪些抓得到、哪些會漏。全部有實測輸出。

我埋的九個雷，和它們怎麼被抓到

我做了一個假的 npm 套件，取名 cute-progress-bar，看起來人畜無害，但埋了九個真實攻擊手法的無害樣本（全部指向 example.com、載荷解開只是 echo、不讀不傳任何真實檔案，原理跟防毒界的測試檔一樣）。然後我用三種方法檢查它：

grep 抓到六個，漏掉三個。這三個漏洞，就是這篇的重點。

教訓一：grep 只抓得到你想搜的字

那個 Unicode 雷，是我在一行正常程式碼裡塞了一個 U+202E（從右到左覆寫字元）。它在編輯器裡肉眼完全看不到，git diff 只會顯示一個奇怪的 U+202E，大多數人會直接滑過去。grep 也搜不到，因為你根本不知道要搜什麼。

要抓它，得專門偵測那些「屬於 Unicode 規範但不產生任何視覺輸出」的控制字元。2025 年真的有一款自我傳播的編輯器擴充蠕蟲，就是用這種隱形字元把惡意碼藏在擴充裡，受害擴充被下載了三萬多次都沒人發現。

教訓二：「掃出 0 個」不等於乾淨

我裝了專業的 secret 掃描器去掃那些硬編碼的假 AWS 跟 GitHub token，結果它回報 0 個。

我一度以為工具壞了。追下去才發現：我當初挑的假憑證，剛好用了 AWS 官方文件裡的 AKIAIOSFODNN7EXAMPLE 這種範例值，而掃描器內建白名單專門排除它們（不然會對所有教學文件狂誤報）。我換成一般格式的假 token，它立刻抓到三個。

這件事的意義很重：掃描器有盲區、有白名單，「掃出 0 個」可能只是規則沒命中，不是真的乾淨。一個工具不夠，要交叉比對。

而且還有個更常見的誤會：npm audit、pip-audit、Dependabot 這些，查的全是「已知漏洞資料庫」。一個剛被投毒、postinstall 正在偷你 token 的新套件，它們完全無感 ── 因為還沒人通報。要抓「惡意行為」得另外用會做行為分析的工具。

教訓三：掃描器負責圈可疑，人負責做判決

我自己寫的掃描規則，對一支完全乾淨的 install.sh 誤報了「有可疑」。它命中的是這行：

if command -v "$candidate" >/dev/null 2>&1; then

我的規則想抓「把輸出導去 /dev/null 藏證據」，結果撞到 >/dev/null 2>&1 ── 那是每支 shell 腳本都在用的「安靜執行」寫法，無害。同類的假警報還有：字串裡的 eval、.env.example 裡的假值、註解裡的指令。

所以掃描器亮紅燈，意思是「這裡值得看一眼」，不是「有罪」。最終判斷一定要人來做。這也正是你可以把 Claude Code 用上的地方 ── 讓它把可疑點一條條圈出來、解釋每一條在做什麼，然後你來決定要不要信任。相關的護欄思路我在WP-CLI 那篇也寫過。

AI 創作者要多擔心一件事：Skill 與 MCP 的安全

如果你會裝 AI Skill、MCP server、或編輯器擴充，你的風險比一般人更高。因為套件只是「被安裝」，但這些東西是會被 AI 讀進 context 並自動執行的。

數字很嚇人：有人掃了近四千個 AI Agent Skill，三成六有安全缺陷、七十幾個確認帶惡意 payload。第一個被記錄的惡意 MCP server，前十五個版本都乾淨、累積信任，第十六版才偷加一行，把經手的信件副本轉走。還有一種手法更陰：把 prompt injection 藏在 README 或程式碼註解裡，誘導你的 AI 去執行惡意行為 ── 這不是能 patch 的 bug，是架構性問題。

甚至連 Claude Code 本身都出過一個（已修的）漏洞：惡意 repo 的 .claude/settings.json 會在你點「信任」對話框之前就自動執行，等於 clone 加開啟就中招。所以裝 Skill這件事，來源比方便更重要。

我的想法 — 九黎月怎麼看這件事

我做這個實驗的時候，一直想到「請神」這件事。

民間信仰裡，請一尊來路不明的神像回家供，是大忌。老一輩會說，你不知道那裡面住的是什麼。它可能是神，也可能是借著神像的殼、等你上香餵養的東西。所以要看來歷、看開光、看是誰經手的 ── 不是不信，是「信任要有依據」。

裝一個 GitHub 上的陌生套件，是一模一樣的事。你把它請進這台有你所有金鑰的機器，postinstall 那一炷香一點下去，它就開始跑了。九成九的套件是好的，就像九成九的神像只是木頭。但那要命的百分之一，你分辨得出來嗎？

AI 在這件事上，是很好的乩身。它讀得比你快、記得住那些你會滑過去的隱形字元、能把一段混淆的程式碼還原給你看。但它不是判官 ── 它會把可疑處圈給你，最後那一下「信，還是不信」，得你自己落。

工具會過時，攻擊手法會翻新，但「請進門之前先看清楚」這個規矩，不會。

結論：檢查 GitHub 惡意程式的七步審查

做完這七步，你不會百分之百安全 ── 沒有人能保證這個。但你會從「閉著眼睛請神」，變成「至少看過來歷再決定」。這中間的差距，可能就是你那台機器裡所有金鑰的距離。