Laravel 端出「Moat」——一行指令掃完你所有 GitHub 帳號的 Rust 護城河工具

2026 年 5 月 25 日，Nuno Maduro 在 Laravel 官方部落格發了一篇短短的文章，宣告 Moat——一個開源、用 Rust 寫的、單一執行檔 CLI——可以掃描任何 GitHub 使用者、組織或 repository，產生硬化分數加上 PASS/FAIL 清單。程式碼行數不多，但訊號很重：它放在官方的 laravel/ GitHub 組織下，是用 Rust 而不是 PHP 寫的，發布時間恰好是 laravel-lang Composer 套件遭入侵後第三天。

這個時間點絕對不是巧合。Moat 是 Laravel 對「整個禮拜每家 PHP 公司都在被客戶問」的問題的官方回答：「如果攻擊者 15 分鐘就能在一個看起來像官方的 Composer 命名空間下改寫 700 個歷史標籤，那我們有什麼防護？」Moat 沒有用產品宣傳去回答這個問題，它用一張清單回答。

一、Moat 到底在做什麼

Moat 是純唯讀的。它不會修改設定、不會裝 hook、不會寫進你的 repo。你給它一個 GitHub token（它會自動讀 GITHUB_TOKEN、GH_TOKEN，或 gh auth token 快取的 token），指定一個使用者、組織或 repo，它就會針對大約十二項控制產出分數：

組織層級強制啟用雙因素驗證
預設分支上鎖（branch protection）
強制簽署 commit
啟用 secret scanning + push protection
Dependabot 警告與安全更新已開
不可變動發行版（immutable releases，讓歷史標籤不能被默默改寫）
fork 的 PR 必須過審才能執行 workflow
workflow 權限收緊（沒有默許的 contents: write）
GitHub Actions 用 SHA 鎖死，不用 tag
標出 pull_request_target 的使用
盤點 webhook 與直接協作者清單
啟用 private vulnerability reporting，並有 SECURITY.md

輸出是一份簡單的 pass/fail 清單。沒有 dashboard、沒有 SaaS 帳號、沒有用量配額。執行檔透過 Homebrew（brew install laravel/moat/moat）發布，也可以直接到 GitHub Releases 下載。每個 repo 可以用一份 moat.toml（checkin 在 repo 內）做客製化，對有「合法歷史例外」的舊 repo 很實用。

二、為什麼用 Rust 寫

這是 Laravel 第一個有份量的官方工具不是用 PHP 寫的。Laravel 團隊講得很白：Moat 要能在任何地方跑——開發者的 MacBook、GitHub Actions job、Windows CI runner、Alpine 容器——不需要拖著 PHP runtime、Composer 或框架依賴。一個靜態連結的單一執行檔，讓你連從沒裝過 PHP 的機器都能第一天就跑起來。

策略意涵也值得記一下：在 laravel/ 組織下發布一個 Rust 執行檔，等於官方表態「該用什麼語言就用什麼，不會把 PHP 當宗教」。對長期跟客戶說「我們會挑最適合的工具」的接案團隊來說，這是個小但有用的社交證據。

三、Moat 不是什麼

Moat 不是供應鏈掃描器。它不會告訴你某個 Composer 依賴是否被植入後門，也不會比對 composer.lock 與漏洞資料庫。這部分還是要交給 Composer Audit、Socket、Snyk、GitHub 自己的 Dependabot 或 StepSecurity 的 harden-runner。

Moat 檢查的是再上一層：你的 GitHub 帳號與維護的 repos 上的控制項，這些控制項本來就能阻止 laravel-lang 攻擊者所做的事。Immutable releases 會擋掉「改寫歷史標籤」這一招；2FA 加簽署 commit 會把「偷 PAT」這個前置動作的成本拉高；Pinned actions 會阻止 CI 內的橫向移動。laravel-lang 的受害維護者，這幾項都沒做。Moat 會告訴你，你「也沒做」哪幾項。

四、接案團隊本週的五分鐘演練

如果你的團隊有在發 Composer 套件、Flutter 套件、npm 套件，或任何「客戶會下載」的產物，這週的標準演練很簡單：

一、裝 Moat，跑 moat scan <your-org>。看 PASS/FAIL 清單。所有紅色項目 24 小時內修掉——每一項都是設定開關，沒有一個是寫程式。

二、對每一個你有 admin 權限的客戶 GitHub 組織跑 moat scan，順手把自己的個人帳號也掃一遍。個人帳號才是 PAT 最常外流的地方。

三、把 moat scan 排成 GitHub Action，每週對前 20 個重要 repo 跑一次。失敗就推 Slack。把新的 fail 當成壞掉的單元測試處理。

四、所有對外公開發布的套件，把 immutable releases 打開（2026 年 repo 層級是一個 checkbox，組織層級是一個 server-side flag）。這是單一槓桿最高的控制項——laravel-lang 攻擊者最致命的一招「改寫歷史標籤」，在 immutable releases 開啟後就直接做不到。

五、這對 Laravel 自己代表什麼

這次釋出透露了 Laravel 對自己責任邊界的看法。Composer 生態的安全長期以來被當作「社群問題」——Packagist 負責發布、Composer 團隊負責 client，剩下的維護者自生自滅。laravel-lang 事件暴露這個模式在規模化後有多脆弱：一個帶有 Laravel 品牌的命名空間（即使不是 Laravel 團隊直接維護的）一旦淪陷，責任就是 Laravel 在揹。

Moat 等於 Laravel 在說：「我們會出免費工具拉高每位維護者的安全底線，包含我們沒有直接管的維護者。」可以預期今年稍晚 Laravel 13.2 會把 Moat 結果整合進 Forge 與 Envoyer，讓接案團隊在一個 dashboard 看到所有客戶環境的安全姿態。

我的觀點

2026 年沒人想承認、但很真的事實是：絕大多數對 PHP 公司的供應鏈攻擊不會很高明。會是外洩的 PAT、沒上鎖的分支、權限過大的 CI、或是從來沒設成 immutable 的 tag。Moat 並不想裝聰明，它只想「會數」。這正是每個接案團隊最需要多一些的工具。三年後我預期會看到每個主流框架都跟進這個模式——「官方出品、單一執行檔、唯讀、對著 checklist 打分」。今天 Laravel 先做了，跑一次的成本是十五秒。如果你的團隊這禮拜還沒對所有自家帳號跑過 moat scan，你正在選擇比較貴的那一條路。