npm audit fix --force 可以直接交給 AI agent 跑嗎？

不建議直接在主分支執行。這個指令會改動 dependency tree，應先在獨立 branch 執行、檢查 lockfile diff，再跑專案原有的 build 與 test；若牽涉 major version，留給人做相容性判斷。

side project 需要做到 SBOM 或 SLSA 嗎？

小型單一 repo 可以先把可靠的 dependency inventory、PR gate、已知漏洞掃描與固定 triage 做好。等客戶要求交付、出現合規或多 repo 治理需求，再評估正式 SBOM 或更完整的供應鏈框架。

免費依賴安全工具夠用嗎？

對單一 side project，免費工具通常足以建立基本閉環，但功能可用性仍要依當下 GitHub 方案核對。當你需要跨 repo policy、reachability 分析、多人協作或合規報告時，再評估付費 SCA 平台。

AI 做完 App 別急著上線：indie maker 的依賴監控與供應鏈安全指南

AI agent 幫你把登入、付款、資料庫一次接好，畫面也跑得動。你準備 deploy 時才發現 package.json 多了一排沒看過的套件，lockfile 更是幾千行。哪個真的進了 production？上週那次 PR 又換掉了什麼？很可能沒人說得清楚。

先別把問題想成「AI 寫的 code 天生危險」。目前沒有足夠的一級來源能證明 AI-assisted 專案比手寫專案有更高的供應鏈事件率。能確定的是，AI coding loop 讓加套件、改 workflow、貼 install command 變得很快，review 卻沒有跟著加速。風險就藏在這段時間差裡。

依賴一旦跑在 server、付款流程或 GitHub Actions，問題就不只是「網站 build 失敗」。它可能碰到環境變數、使用者資料或部署權限。本文寫給已用 AI 做出 Node.js／Next.js App，而且能操作 GitHub 與終端機的 indie maker；如果你還不熟這些工具，可以先完成 30 分鐘版本，不必一次做到 CI gate。

這篇給你一張「生產部署地雷圖」。不用先買平台，也不用把自己變成資安工程師。你要做的是讓每個 dependency 有跡可循、每次變更過 PR gate、已知漏洞有人收到、更新後真的跑過測試。

快速結論：先 commit lockfile，確認 GitHub dependency graph 讀得到資料；接著把 dependency change 放進 PR review，再開 alerts 與修補 PR。npm audit 或 OSV-Scanner 顯示零告警，只表示目前沒有命中已知漏洞資料，不能替新套件背書。

先畫地雷圖：AI-built app 最壞會在哪裡出事？

side project 規模小，不代表 dependency 出事時影響一定小。套件可能跑在 server、build pipeline 或 GitHub Actions 裡，能碰到的資料與權限完全不同。比起背攻擊名詞，先拿你的 repo 對照五格地雷圖：

地雷	你會看到的症狀	最低成本 gate
看不見	不知道直接與間接依賴有哪些	commit lockfile，建立 dependency graph
未審查	AI 在 PR 裡順手加了 package	dependency diff 加人工引入理由
未告警	漏洞公開後沒人收到通知	Dependabot alerts／security updates
誤修補	bot PR 或 `audit fix` 合併後 App 壞掉	原有 build、test 與 production path 檢查
掃描盲點	零告警就當成安全	套件來源、install scripts、project-health review

GitHub dependency graph 會根據 repo 內的 manifest、lockfile，以及透過 API 提交的資料整理依賴。這讓「production 裡到底有什麼」開始可回答。CISA 的 OSS 與 SBOM 指南也把 inventory 放在風險管理脈絡中，但那是組織實務指南，不是要求每個小專案照表抄完的法規。

先圈出你完全沒控制的格子。若五格都空白，別一次裝五套工具，從「看不見」開始補。

地雷一「看不見」：用 lockfile 與 dependency graph 建 inventory

dependency inventory 是什麼？ 它是一份可持續更新的直接與間接依賴清單，至少能指出套件、版本與來源檔案。間接依賴（transitive dependency）是你沒有直接安裝、而是被其他套件帶進來的套件。沒有 inventory，告警與 PR review 都缺少可靠的比對基準。

打開 repo，先做三件事：

確認 lockfile 已 commit：npm 專案通常是 package-lock.json，不要只留下 package.json。
確認 dependency graph 有資料：在 GitHub repo 的 Insights → Dependency graph → Dependencies 查看。能看到套件名稱、版本與來源 manifest／lockfile，就代表 GitHub 已辨識這批依賴。GitHub 文件指出，graph 也能顯示 license、已知漏洞，以及支援 ecosystem 的部分 transitive path。
建立第一張漏洞快照：在現有 Node.js 專案執行：

npm audit

npm 官方文件說明，audit 會把 dependency tree 的資訊送到設定的 registry，取得已知漏洞報告。它很好用，但範圍很清楚：它不是 code review，也不會回答某個新 package 是否值得信任。

這一步最常踩的坑，是看到 direct dependencies 不多就安心。真正讓你卡住的常是 transitive dependency，也就是你沒直接安裝、卻被上層套件帶進來的東西。lockfile 與 dependency graph 的價值，就在於讓這條路徑浮出來。

地雷二「未審查」：在 PR 階段攔住 AI 悄悄加套件

AI 回答「這個 library 可以幫你處理日期」，不等於它已完成引入審查。任何 manifest、lockfile 或 workflow 變更，都應在 PR 裡回答三個問題：為什麼需要它、現有 code 能不能完成、這次實際新增或更新了哪些依賴。

GitHub Dependency Review 會在 PR 顯示新增、移除、更新的 dependencies，也包含 lockfile 裡的間接依賴與已知漏洞。搭配 dependency review action 與 required check，發現符合設定條件的脆弱版本時可以擋住 merge。

你的 PR template 可以很短：

## Dependency change
- 用途：
- 不使用現有 code 的理由：
- manifest／lockfile diff 已檢查：是／否
- build 與 test 結果：

工具負責把 diff 攤開，人負責問「真的有必要嗎」。若 AI 連用途都講不清楚，這個 package 就不該靠一句「可能會用到」進 production。

別重複掃描：npm audit、OSV-Scanner、Dependabot 各守哪一站

把工具全塞進 CI，看起來很安心，結果可能只是同一批已知漏洞被報三次。用時間點分工會清楚很多。

時點	工具	它回答的問題	它不替你做的事
local	`npm audit`	目前 npm dependency tree 命中哪些已知漏洞	判斷新套件可信度
PR	Dependency Review	這次 PR 改了哪些依賴，有沒有帶入已知漏洞	驗證 App runtime 相容性
CI	OSV-Scanner	source、lockfile 或 container 抽出的套件是否命中 OSV 資料	保證未知惡意行為不存在
hosted alerts	Dependabot	dependency graph 中哪些依賴有已知漏洞	證明修補 PR 可以安全合併
修補 PR	Dependabot security updates	有 patch 時嘗試升到含修補的最低版本	取代你的 build 與 test

OSV-Scanner 適合你想在 CI 裡多一個 lockfile 或 container 掃描位置時使用；官方也提供 GitHub Action 與 SARIF 輸出。若 GitHub 原生流程已覆蓋你的需求，不必為了工具數量再疊一層。先問「哪個時間點沒人守」，再補那一格。

如果你正在選最低配置，可以先這樣判斷：

配置	適合誰	PR 攔截	持續告警	主要盲點
lockfile + `npm audit`	本機維護、還沒建立 GitHub gate	無	無	要靠人記得執行與追蹤
GitHub 原生組合	單一 GitHub repo，想補 PR 與 hosted alerts	Dependency Review 可依方案與設定擋 PR	Dependabot alerts	受 repo 類型、方案與 GitHub 平台限制
GitHub 原生 + OSV-Scanner	還有 CI、其他 lockfile 或 container 掃描缺口	依 workflow 設定	兩套來源可能產生重複告警	多一套 workflow 與 triage 成本

單一 GitHub repo 可以先從原生組合開始；只有確認掃描位置仍有缺口時，再加 OSV-Scanner。repo 不在 GitHub，則要用託管平台或 CI 支援的替代工具補上 inventory、PR gate、持續告警與更新 PR，不能直接照搬 GitHub 的設定。

30 分鐘、2 小時、半天：按時間建立最低防線

這些時間是規劃層級，不是實測保證。舊 repo、monorepo 或幾乎沒有測試的專案，一定會更久。

只有 30 分鐘

commit 並檢查 lockfile
確認 dependency graph 能辨識套件
跑一次 npm audit，把結果存進 issue 或維護紀錄
指定誰會看後續 security alerts，只有你也沒關係

能留 2 小時

補上 Dependabot alerts 與 security updates
建立 dependency change 的 PR 說明規則
在方案與 repo 類型支援的前提下，加入 Dependency Review required check
拿一個真實更新 PR 走過 dependency diff、build 與 test

Dependency Review 的可用範圍會隨 public／private repo 與 GitHub 方案不同。官方目前明列 public repo，以及啟用 GitHub Code Security 的部分 organization-owned repo；設定前直接看當下文件，別照兩年前的教學影片找選單。

這裡有三個不同功能，不是開一個總開關就全部完成：Dependabot alerts 負責通知 dependency graph 命中的已知漏洞；Dependabot security updates 在有可用修補時嘗試開 PR；Dependency Review 則檢查某一次 PR 帶來的依賴變更，還要另外搭配 action 與 required check 才能形成 merge gate。設定入口與方案支援可能調整，實作時以各段連結的當下官方文件為準。

有半天

將 OSV-Scanner 放進 CI 的缺口位置
設定 branch protection 或 ruleset，讓必要檢查不能被跳過
演練一次「收到漏洞告警到合併修補」
用 OpenSSF Scorecard 補看上游 project-health signals

做到這裡就先停。每一個 detector 都要有 owner 與處理節奏，沒人看的 dashboard 只是比較漂亮的焦慮。

告警爆量怎麼排：自動修補、手動升級、暫時 ignore 決策樹

Dependabot 一次開出很多東西時，先把 security updates 與一般 version updates 分開。GitHub 官方也把兩者定義為不同目的：前者處理已知漏洞，後者維持版本更新。混成同一個佇列，只會讓真正該看的 PR 被淹掉。

照這棵決策樹走：

它有進 production scope 嗎？ production scope 指真正會進入正式環境、build 或部署流程的依賴範圍。沒有也要記錄判斷依據，但優先級可以往後；有就繼續。
有可用的修補版本嗎？ 有，檢查 dependency diff；沒有，先評估停用功能、替換套件或限制暴露面。
修補是否牽動父依賴或大版本？ 小而清楚的變更進正常 PR；範圍大就放獨立 branch 手動升級。
現有測試能覆蓋使用路徑嗎？ 能，跑完再 review；不能，補一個針對 production path 的人工檢查。
要暫緩嗎？ 記下理由、影響範圍、owner 與下次重看日期。不要按下 ignore 後當它消失。

Dependabot security updates 會在有 patch 時嘗試開 PR，目標是升到包含修補的最低版本。npm ecosystem 對部分 transitive dependency 能連父依賴一起處理，其他 ecosystem 可能受限。這也解釋了為什麼「bot 沒開 PR」不能直接推導成「問題不用修」。

安全更新也要測：什麼時候才可以 auto-merge

Dependabot PR 可以 auto-merge 嗎？ 只有 dependency diff 範圍清楚、branch protection 生效、必要檢查通過，而且現有測試真的覆蓋使用路徑時，才適合考慮低風險 auto-merge。

安全更新描述的是修補目的，不是相容性保證。GitHub 會嘗試在不破壞 dependency graph 的前提下提出最低修補版本，某些 PR 也可能顯示來自其他 public repo CI 的 compatibility score；那仍然不是你的 App 測試結果。

合併前至少確認：

dependency diff 沒有帶進預期外套件
repo 原本的 build、lint、type check、test 依實際存在的項目跑完
登入、付款、資料寫入等真正的 production path 有覆蓋
required checks 與 branch protection 沒被 PR 同時改掉

如果專案根本沒有測試，先別開 auto-merge。手動點過首頁不叫完整驗證，但至少誠實承認 test confidence 很低，會比讓 bot 自動一路進 production 好。

地雷三「掃描盲點」：零告警後仍要檢查套件可信度

npm audit 與 OSV-Scanner 都很擅長回答「這個版本是否命中目前已知漏洞」。它們不會替你保證套件名稱沒有拼錯、install script 沒做多餘的事、maintainer 沒換人，或剛發布的新版本完全可信。

新套件引入時，把下面四項獨立於漏洞掃描檢查：

核對 package 名稱、registry 頁面與官方 repo 是否互相指向
看 release、maintainer 與 repository 活動是否有異常變化
檢查 scripts，特別是安裝期間會執行的內容
若沒有非升不可的理由，別在 production 第一時間追剛發布的版本

OpenSSF Scorecard 可以提供 branch protection、dependency update tooling、危險 workflow 等 project-health heuristics。把它當訊號，不要把分數當安全證書。零漏洞加上高分，依然無法證明某個新版本沒有惡意行為。

地雷四「防線本身」：更新 bot 與 GitHub Action 也要被 review

你加進 .github/workflows 的 scanner，本身也會取得權限、拉取 action 並執行 code。若 AI 可以一邊新增 dependency，一邊悄悄放寬 workflow 權限，再多 scanner 也救不了那次沒人看的變更。

把 workflow change 視為 production dependency change：要求人工 review、把 permissions 收到工作所需的最低範圍，並依團隊政策固定 action reference。更新安全工具的 PR 也要走同一套 required checks，不能因為標題寫著 security 就免審。

這裡不硬塞一套「萬用 pinning 策略」。不同 action 與更新方式的取捨不同，文章來源也不足以支持單一答案。先確保 workflow 變更不會和一般 code 一樣被快速滑過去，已經能堵住最大的流程洞。

每週 20 分鐘維護節奏：讓防線不會裝完就荒廢

20 分鐘是一個 timebox，不保證清空所有告警。它的好處是讓你每週真的會打開一次，而不是收到通知就關掉、累積三個月後整批忽略。

可以這樣排：

前 5 分鐘：先看 security alerts，確認 production scope 與有沒有 fix。
中間 8 分鐘：review 已通過 CI 的低風險修補，檢查 dependency diff。
接著 5 分鐘：挑一個較大的更新，決定手動升級、替換或暫緩。
最後 2 分鐘：替暫緩項目寫理由與下次日期，關掉純通知雜訊。

如果每週都超時，不要先關 Dependabot。先檢查是不是把一般版本更新和安全修補混在一起、是不是開了重複 scanner、是不是缺少能讓低風險 PR 快速通過的測試。告警疲勞常常是流程塞車，不是 detector 太認真。

什麼時候免費最小流程不夠，才升級 SBOM 或付費 SCA

side project 需要 SBOM 嗎？ 單一小 repo 先維持可用的 dependency inventory 就夠務實；當客戶要求交付機器可讀清單、出現合規稽核或跨 repo 治理需求，再升級正式 SBOM。

GitHub dependency graph 本身就能匯出 SBOM。CISA 指南則把 SBOM 放在更完整的 OSS inventory 與風險管理流程裡。清單能提升可見性，卻不代表清單裡的每個版本都安全。

繼續用最小流程	開始評估完整平台／正式 SBOM
單一或少量 repo	多 repo 需要統一 policy
你能手動完成每週 triage	告警需要分派、稽核與追蹤責任
dependency diff 與 CI 足以判斷	需要 reachability 或跨專案分析
沒有外部交付格式	客戶、合規或採購要求報告
現有託管平台與方案能提供所需 gate	非 GitHub repo，或現有方案缺少必要整合
每週告警量能在固定 timebox 內處理	告警量長期超出可投入的維護工時

不要因為「企業都在做」就替 side project 買一套維護不起的系統。反過來，若客戶已經問你用了哪些 OSS、誰負責處理漏洞，只靠偶爾跑一次 npm audit 也確實撐不住了。

今天就讓一個 dependency PR 走完閉環

AI-assisted shipping 的速度不會慢下來，你也不需要為了安全把每個 package 都研究一週。今天先 commit lockfile、確認 dependency graph 有資料，再挑一個真實 dependency PR，完整走過引入理由、diff、漏洞檢查、build、test 與人工 merge。

只有一晚，做到 inventory 與第一張漏洞快照就停。已經有 CI 與測試，就把 Dependency Review 和更新演練補起來。工具會繼續換名字，但那條沒有被速度跳過的 review 路徑，才是你的 App 上線後還能放心維護的底氣。