Agent 寫完 code,GitHub 要你先別急著 commit
MCP Server 的 secret scanning 已 GA,dependency scanning 進入測試。這不是資安工具多兩個按鈕,而是 AppSec 開始搬到 AI 寫程式的現場。
GitHub 在 2026 年 5 月 5 日讓 GitHub MCP Server 的 secret scanning 進入 GA,並推出 dependency scanning public preview。本文拆解 AI 寫程式流程裡的 AppSec 控制點如何改變。
AI coding agent 最讓人緊張的時刻,不是它開始寫 code,而是它寫完之後。螢幕上看起來一切順利:測試可能過了,diff 也有條理,agent 還貼心地整理了變更摘要。下一步通常就是 commit。
也正是在這一刻,風險開始變快。工程師自己改一段程式,PR、CI、code review 還能當主要防線;agent 一次改多個檔案、補依賴、調設定,安全檢查如果只等到 PR 之後才出現,團隊其實已經把問題送進流程裡。
GitHub 5 月 5 日的兩則 changelog,應該放在這個瞬間讀。GitHub MCP Server 的 secret scanning 已經 generally available;dependency scanning through GitHub MCP Server 還在 public preview。產品名很工程,但方向很清楚:把部分 AppSec 檢查推到 commit 前,推到 agent 還在對話和 IDE 裡的地方。
這不是「agent 可以取代資安」。比較準確的說法是:當 AI 寫程式變成日常開發環境的一部分,安全政策也不能只站在後面的關卡等它。
第一個新關卡:改完先掃 secrets
Secret scanning 這次進入 GA,最有用的不是「多支援一種掃描」,而是它出現在 MCP-compatible coding agent 或 IDE 裡。GitHub 官方列的情境包含 GitHub Copilot CLI 和 Visual Studio Code。開發者準備提交變更前,可以透過 GitHub MCP Server 掃目前 code changes,找出可能暴露的密鑰。
這會改變工程師和 AppSec 的默契。
以前 secret scanning 很像 PR 或 push 之後亮起的紅燈。現在它更像 commit 前的一句工作指令:這批 agent 變更先掃過 secrets,再送出去。
更重要的是,GitHub 說這個 GA 能力會尊重 existing push protection customization。企業原本在 repository 或 organization 層設定的偵測和 bypass 邏輯,不必完全重做一套給 AI 工具。這讓 MCP 不只是工具接頭,而是把既有安全政策帶進 agent 可以呼叫的工作現場。
第二個新關卡還在測試:依賴套件要先試跑
另一則公告不能寫得太滿。Dependency scanning through GitHub MCP Server 仍是 public preview。
它走 dependabot toolset,會用 GitHub Advisory Database 檢查依賴資訊,回傳受影響套件、嚴重度和建議修補版本。更深的檢查可以在本機跑 Dependabot CLI,比對變更前後的 dependency graph。
這很有用,但 preview 就是 preview。覆蓋率、誤報、速度、開發者是否真的會用,都還要靠團隊自己驗證。把它當成「AI coding agent 的供應鏈安全已經解決」會太快。
比較務實的做法,是把兩個能力放在不同成熟度的流程裡。Secret scanning 可以先進入 commit 前 checklist;dependency scanning preview 可以放在試點或高風險 repository;CI、Dependabot alerts、code review 和 AppSec review 仍然是後面的防線。
AppSec 要插進 prompt,而不是只守住 PR
MCP 最容易被看成「讓模型接工具」的協議。但在企業開發裡,它也會變成治理通道。當 agent 能透過 MCP 呼叫 GitHub 工具,問題就不只是「它能做什麼」,而是「它做事時受哪套規則約束」。
Secret scanning 接 push protection customization,dependency scanning 接 GitHub Advisory Database 和 Dependabot。這些連接點在說同一件事:agent 不應該繞過平台安全系統,而應該被接回平台安全系統。
AppSec 團隊因此要多看一層流程。未來的安全基準不只問 CI 有沒有跑,也要問 agent 工作流裡有沒有最基本的 commit 前檢查:
- agent 改完後是否掃過密鑰?
- 新增或更新依賴時是否檢查 advisory?
- 哪些檢查可以由 agent 觸發,哪些仍必須在 CI 強制?
- bypass 是否留下原因和紀錄?
- 人類 reviewer 是否知道哪些檢查已經跑過,哪些還沒?
這是煞車,不是安全終點
GitHub 這次更新值得跟進,但不能被神化。
Secret scanning 不是所有安全問題;dependency scanning 也不是完整 code security。它們不會替你判斷架構風險,不會理解所有 business logic,也不會保證 AI 產生的變更沒有授權、資料處理或部署風險。
它們比較像早一點出現的煞車。AI coding agent 把開發速度往前推,GitHub 正把安全檢查也往前推。這一步如果做得好,工程師會在更早的時間看到錯誤,AppSec 也比較不用只在 PR 後面追。
最後的責任沒有消失。agent 可以先踩煞車,CI 可以再踩一次,人類 reviewer 仍然要看方向盤握在誰手上。
SOURCES
- A Secret scanning with GitHub MCP Server is now generally available
- A Dependency scanning with GitHub MCP Server is in public preview
- A Secret scanning in AI coding agents via the GitHub MCP Server
來源分級:A = 一手公告/論文/官方文件 · B = 可信媒體 · C = 可參考但需脈絡 · D = 觀察用,不可當事實。
MACHINE-READABLE SUMMARY
- Topic
- 工作現場
- Key claims
-
- GitHub MCP Server 的 secret scanning 已在 2026 年 5 月 5 日進入 generally available。
- Dependency scanning through GitHub MCP Server 仍是 public preview,不能與 secret scanning 當成同等成熟能力。
- MCP 正變成 AI coding agent 工作流裡承接企業安全政策與檢查的控制通道。
- Entities
- GitHub · GitHub MCP Server · Dependabot
- Taiwan relevance
- medium
- Confidence
- high
- Last updated
- 2026-05-07
- Canonical URL
- https://signals.tw/articles/github-mcp-security-scanning/
SUGGESTED CITATION
如果 AI agent / 研究 / 報導要引用本文,建議格式如下:
林子睿(編輯:廖玄同),《Agent 寫完 code,GitHub 要你先別急著 commit》,矽基前沿 [Si]gnals,2026-05-07。https://signals.tw/articles/github-mcp-security-scanning/
AI agents / search engines may quote, summarize, and cite with attribution and a link back to the canonical URL above. See /for-ai-agents for full policy.