AIエージェントがログイン、決済、データベースをまとめて実装し、画面も動いています。ところがdeploy直前、package.jsonには見覚えのないpackageが並び、lockfileは数千行。どれがproductionで動き、先週のPRで何が変わったのか、誰も説明できないかもしれません。

問題を「AIが書いたcodeは危険」と単純化する必要はありません。AI-assistedな開発の方が手作業よりサプライチェーン事故が多いと断言できる一次情報は、現時点では十分ではありません。確かなのは、package追加やworkflow変更は速くなったのに、reviewの速度が追いついていないことです。

依存関係がserver、決済処理、GitHub Actionsで動けば、影響はbuild失敗だけでは済みません。本記事は、AIでNode.js／Next.jsアプリを作り、GitHubとterminalを扱えるindie maker向けです。まだ不慣れなら、いきなりCI gateまで進めず、まず30分版から始めてください。

先に結論です。 lockfileをcommitし、GitHub dependency graphが読めることを確認します。次にdependency変更をPR reviewに通し、alertsと修正PRを有効にします。npm auditやOSV-Scannerがゼロ件でも、既知の脆弱性データに一致しなかっただけで、新しいpackageの安全証明にはなりません。

ツールを選ぶ前に、被害範囲を地図にする

小さなside projectでも、依存関係はserver、build pipeline、secret、deploy権限に触れます。攻撃名を覚えるより、まず5つの穴を確認しましょう。

穴	症状	最低コストのgate
見えない	直接・間接依存を一覧にできない	lockfileをcommitしdependency graphを作る
未review	AIがPRでpackageを追加する	導入理由とdependency diffを人が確認する
未通知	脆弱性公開後も誰も気づかない	Dependabot alerts／security updatesを有効化する
誤修正	botの更新でアプリが壊れる	既存のbuild、test、production pathを確認する
scanの盲点	ゼロ件を安全証明と誤解する	配布元、install scripts、project healthを見る

GitHub dependency graphはmanifest、lockfile、APIから送られた情報を基にinventoryを作ります。CISAもOSS inventoryとSBOMをリスク管理に位置づけていますが、すべての小規模プロジェクトに全項目を義務づける法律ではありません。

lockfileとdependency graphでinventoryを作る

dependency inventoryとは、直接・間接依存のpackage、version、参照元ファイルを継続的に更新する一覧です。 transitive dependencyは、自分が直接installせず、別のpackage経由で入る依存関係です。inventoryがなければ、alertもPR reviewも信頼できる比較基準を持てません。

最初に3つ実行します。

1. lockfileをcommitします。npmなら通常はpackage-lock.jsonで、package.jsonだけでは不十分です。
2. GitHub repoの Insights → Dependency graph → Dependencies を開き、package名、version、参照元manifest／lockfileが見えるか確認します。
3. 最初の脆弱性スナップショットを作ります。

npm audit

npm公式ドキュメントによると、auditはdependency tree情報を設定済みregistryへ送り、既知の脆弱性レポートを受け取ります。便利ですが、code reviewでもpackageの信頼性評価でもありません。

AIによる無言の依存追加をPRで止める

AIが「このlibraryで解決できます」と答えても、導入審査が完了したわけではありません。manifest、lockfile、workflowの変更ごとに、必要な理由、既存codeで代替できない理由、直接・間接依存の変更内容を確認します。

GitHub Dependency ReviewはPR内の追加・削除・更新された依存関係と既知の脆弱性を表示します。Dependency Review actionとrequired checkを組み合わせれば、policy違反時にmergeを止められます。

## Dependency change
- 目的：
- 既存codeでは足りない理由：
- manifest／lockfileの差分確認：はい／いいえ
- buildとtestの結果：

ツールはdiffを見せます。productionに入れる判断は人の仕事です。

npm audit、OSV-Scanner、Dependabotの役割を分ける

scannerを全部CIに入れると、同じ既知脆弱性が3回届くことがあります。守る時点で分けると迷いません。

時点	ツール	答える問い	答えない問い
local	npm audit	npm dependency treeが既知脆弱性に一致するか	新しいpackageを信頼できるか
PR	Dependency Review	今回のPRで何が変わり、脆弱性が入ったか	runtime互換性があるか
CI	OSV-Scanner	source、lockfile、containerがOSVデータに一致するか	未知の悪意が存在しないか
hosted alerts	Dependabot	graph内のどの依存に既知脆弱性があるか	修正PRを安全にmergeできるか
修正PR	Dependabot security updates	patch済み最低versionへ更新できるか	buildとtestを代行できるか

OSV-ScannerはCIでlockfile、source、containerのscan場所が不足している時に向きます。公式のGitHub ActionはSARIFも出力できます。GitHub標準機能で十分なら、ツール数を増やすためだけに重ねないでください。

構成	向いている人	PR gate	継続alert	主な盲点
lockfile + npm audit	GitHub gate未導入のローカル運用	なし	なし	人が実行と追跡を忘れる
GitHub標準構成	単一GitHub repoでPRとalertを守りたい	planと設定に応じたDependency Review	Dependabot alerts	repo種別、plan、platformの制約
GitHub + OSV-Scanner	CI、lockfile、containerにscanの穴がある	workflow次第	重複alertの可能性	workflowとtriageの負担が増える

単一GitHub repoなら標準構成から始め、scan場所の穴を説明できる時だけOSV-Scannerを足します。GitHub外のrepoでは、利用するplatformやCIでinventory、PR gate、継続alert、修正updateの4機能を再現してください。

30分、2時間、半日で最低防線を作る

これは計画用の目安で、実測保証ではありません。古いrepo、monorepo、testが少ないプロジェクトは長くかかります。

30分だけなら

• lockfileをcommitして確認する
• dependency graphがpackageを認識するか見る
• npm auditを1回実行し、issueか維持記録に残す
• 今後security alertを見る担当者を決める

2時間取れるなら

• Dependabot alertsとsecurity updatesを有効にする
• PRにdependency変更の説明欄を追加する
• repoとplanが対応していればDependency Review required checkを追加する
• 実際のupdate PRをdiff、build、testまで通す

Dependency Reviewの対応範囲はpublic／private repoとGitHub planで異なります。alerts、security updates、Dependency Reviewは別機能で、一つのswitchではありません。実装時はリンク先の最新公式ドキュメントを確認してください。

半日使えるなら

• CIの不足箇所だけにOSV-Scannerを置く
• branch protectionまたはrulesetでrequired checksを必須にする
• alert受信から修正mergeまでを一度演習する
• OpenSSF Scorecardで上流project-health signalを補う

ここで一度止めます。すべてのdetectorに担当者と処理周期が必要です。誰も見ないdashboardは、見た目のいい不安にすぎません。

alert過多を決定木で整理する

security updatesと通常のversion updatesを分け、次の順で判断します。

1. production、build、deployに入る依存か。判断根拠も記録します。
2. patch済みversionがあるか。なければ機能停止、package交換、露出低減を検討します。
3. 親依存やmajor versionまで変わるか。広い変更は別branchで手動reviewします。
4. 既存testがproduction pathを覆うか。足りなければ対象を絞った手動確認を追加します。
5. 保留するか。理由、影響範囲、owner、次回確認日を残します。

Dependabot security updatesはpatchを含む最低versionへのPR作成を試みます。npmでは一部のtransitive dependency修正で親依存も更新できますが、ecosystemごとに制約は異なります。bot PRがないことは、問題を無視できる理由になりません。

testが信頼できる時だけauto-mergeする

Dependabot PRをauto-merge候補にできるのは、dependency diffが明確で、branch protectionが有効、required checksが通り、testが対象production pathを覆う時だけです。 security目的でもruntime互換性は保証されません。

予想外のpackageがないか、実在するbuild、lint、type check、testが通るか、必要ならログイン・決済・data writeを覆うか、PRがrequired checksを弱めていないかを確認します。testがないプロジェクトではauto-mergeを有効にしないでください。

scanゼロ件はpackageの信頼評価ではない

npm auditとOSV-Scannerは、versionが現在の既知脆弱性に一致するかを答えます。package名のtypo、install script、maintainer交代、新releaseの信頼性までは保証しません。

• registry、公式repo、package名が相互に対応するか確認する
• release、maintainer、repository活動の不自然な変化を見る
• scripts、特にinstall中に動く処理を確認する
• 明確な理由がなければ、新releaseをproductionですぐ採用しない

OpenSSF Scorecardはbranch protection、dependency update、危険なworkflowなどのproject-health signalを補います。scoreは手掛かりであり、安全証明書ではありません。

防線そのものもreviewする

.github/workflowsのscannerは権限を持ち、actionを取得してcodeを実行します。workflow変更もproduction dependency変更として扱い、人のreviewを要求し、permissionsを必要最小限にし、チームpolicyに沿ってaction referenceを固定します。security toolの更新もrequired checksを通してください。

毎週20分のtimeboxで運用を止めない

20分は習慣の枠であり、全alertを消す保証ではありません。最初の5分でsecurity alertとproduction scopeを確認し、次の8分でCI通過済みの低risk修正をreviewします。5分で大きめのupdateを一つ判断し、最後の2分で保留理由と次回日付を残します。

毎週超過するなら、通常updateとsecurity修正が同じqueueにないか、scannerが重複していないか、test不足で小さなPRまで重くなっていないかを確認します。alert fatigueはdetectorよりworkflowの渋滞で起きることがあります。

必要になってから正式なSBOMや有料SCAへ進む

小規模な単一repoなら、まず使えるdependency inventoryを維持するのが現実的です。 顧客が機械可読の一覧を求める、コンプライアンス対応が始まる、複数repoを統一管理する、といった段階で正式なSBOMを検討します。

最小構成を続ける	platform／正式SBOMを検討する
単一または少数repo	多数repoに共通policyが必要
毎週の手動triageで回る	担当割当や監査履歴が必要
dependency diffとCIで判断できる	reachabilityや横断分析が必要
外部提出形式がない	顧客、調達、監査がreportを求める
現在のhostingとplanでgateが足りる	GitHub外、またはplanに連携がない

大企業が使っているという理由だけで、維持できないsystemを買わないでください。一方、顧客から利用OSSと脆弱性対応責任者を聞かれているなら、たまにnpm auditを実行するだけでは足りません。

今日、一つのdependency PRを最後まで通す

AI-assisted開発の速度は落ちませんが、すべてのpackageを一週間調査する必要もありません。今日、lockfileをcommitし、dependency graphを確認し、一つの本物のdependency PRを導入理由、diff、脆弱性確認、build、test、人の承認まで通してください。

一晩しかないならinventoryと最初の脆弱性スナップショットで止めます。すでにCIとtestがあるならDependency Reviewとupdate演習を追加します。ツール名は変わり続けても、速度で飛ばせないreview経路が、公開後もアプリを安心して維持できる土台になります。