Codexで依存インシデントを調べる前に決めること

3行まとめ

Advisory

情報源。

Package

対象。

Path

利用経路。

Exposure

露出。

dependency incidentは、まず影響調査として扱います。

• dependency incidentは、upgrade前にadvisory、package、利用経路、runtime exposureを分けて見ます。
• Codexには、repo-audit plan、evidence table、next actionを作らせると判断しやすくなります。
• 修正へ進むのは、影響経路、owner、検証方法、rollbackが揃ってからにします。

公開アドバイザリが出ると、すぐ依存関係を上げたくなります。もちろん、急ぐべきincidentはあります。ただ、すべてを「とにかく更新」で扱うと、影響のないrepoに時間を使ったり、重要なruntime pathを見落としたりします。

Codexに任せるなら、まず影響調査です。advisoryを読み、lockfileを見て、import pathを探し、実行時に外へ露出するかを確認する。ここまでをrepo-audit planとして残します。

この記事では、OpenAI公式のCodex Use Casesにある「Audit dependency incidents」をもとに、2026年6月1日時点の情報として整理します。Codexのuse casesやsecurity関連機能は更新され得るため、導入時は最新docsと自社security運用を確認してください。

この記事でわかること

Lockfile

version。

Import

利用箇所。

Runtime

動く場所。

Owner

担当。

影響あり/なしを決める前に、確認すべき証拠を揃えます。

• public package advisoryを見た後にCodexへ任せる範囲
• advisory、package、path、exposureの分け方
• lockfile、import path、runtime contextを入力として整える方法
• repo-audit plan、evidence table、next actionの作り方
• urgentとnormalの分け方
• 修正へ進む条件と、false positiveの残し方

この記事は、依存更新そのものの手順ではありません。依存更新をAIに任せる権限やテストゲートは、公開済み記事のClaude Codeに依存更新を任せる前にが近いです。ここでは、更新前の影響調査に絞ります。

前提知識

項目	内容	見方
Use Cases		incident audit。
Features		作業入口。
Permissions		権限。
Worktrees		修正分離。
AGENTS.md		repo手順。

advisory確認とrepo読み取りは、修正作業とは分けます。

OpenAI公式のCodex Use Casesでは、public package advisoryからsafe repo-audit planを作る用途が紹介されています。これは、security scanやvulnerability remediationとは少し違います。すでに外部で報告されたadvisoryを起点に、自社repoのどこが関係するかを調べる作業です。

Codex app featuresは、projectやthread、worktreeなどの作業単位に関係します。Permissions docsは、advisory確認のためのnetwork、repo読み取り、修正時のwriteを分ける時に使います。Worktrees docsは、修正へ進む場合に調査とpatchを分ける時に関係します。AGENTS.md docsは、repo固有のpackage manager、test command、報告形式を渡す土台です。

公式情報で見る範囲

公式情報	この記事で見ること
Codex Use Cases	dependency incident audit
Codex app features	project、thread、worktree
Codex Permissions	network、read、writeの境界
Codex Worktrees	修正作業の分離
AGENTS.md	repo固有の調査手順

dependency updateとの違い

dependency updateは、versionを上げる作業です。dependency incident auditは、その前に「自社repoが本当に影響を受けるか」「どこで使っているか」「外部に露出するか」を調べる作業です。

影響なしと判断する場合も、証拠が必要です。lockfileに入っていない、transitiveだがruntime pathに乗らない、devDependencyだけでproduction artifactに入らない、該当APIを使っていない。こうした根拠を残します。

incidentを4層に分ける

1. 1Advisory

   何が問題か。

2. 2Package

   入っているか。

3. 3Path

   使っているか。

4. 4Exposure

   外へ出るか。

packageがあるだけで影響ありとは扱いません。

dependency incidentは、advisory、package、path、exposureの4層に分けます。これを混ぜると、判断が荒くなります。

advisoryは、何が問題かです。packageは、自社repoに対象versionがあるかです。pathは、そのpackageをどこから使っているかです。exposureは、その経路が外部入力、顧客data、本番runtimeに触れるかです。

advisory

advisoryでは、対象package、affected versions、fixed versions、attack condition、severity、workaroundを見ます。

Codexには、advisory本文を短く要約させます。ただし、外部advisoryを読む場合は、許可されたsourceに限定します。公式advisory、package registry、GitHub Security Advisory、vendor docsなど、根拠を残せるsourceを使います。

package

packageでは、自社repoに対象versionがあるかを見ます。package.jsonだけでは足りません。lockfile、workspace、monorepo package、container image、serverless bundleも見る場合があります。

Codexには、direct dependencyとtransitive dependencyを分けて出させます。directなら更新判断がしやすいですが、transitiveでは親packageやlockfile更新の影響を見ます。

path

pathでは、実際に使っているかを見ます。import、require、dynamic import、CLI、build tool、test tool、runtime bundleなどです。

packageが入っていても、該当機能を使っていない場合があります。反対に、薄く見えるutilityが重要pathに入っていることもあります。

exposure

exposureでは、外部入力や顧客dataに触れるかを見ます。server route、background job、admin tool、build-time only、test-onlyでriskは違います。

Codexには、利用箇所ごとにruntime contextを出させます。production runtime、build time、dev only、test onlyを分けます。

Codexに渡す入力

項目	内容	見方
URL		advisory。
Lockfile		version。
Imports		利用箇所。
Runtime		実行経路。

長い情報を丸投げせず、調査に必要な範囲へ絞ります。

Codexへ渡す入力は、advisory URL、lockfile、import path、runtime contextです。長い情報を丸投げせず、調査に必要な範囲へ絞ります。

入力が曖昧だと、Codexはもっともらしい一般論を返します。必要なのは、自社repoでの影響です。

advisory URL

advisory URLは、根拠の起点です。対象package、affected version、fixed version、条件、回避策が読めるsourceにします。

Codexには、advisoryの主張と、自社repoで確認すべき点を分けさせます。

lockfile

lockfileは、実際に入っているversionを見るために必要です。npmならpackage-lock、pnpm-lock、yarn.lock。ほかのecosystemでも同じです。

Codexには、対象packageのversion、親package、workspaceごとの差分を出させます。

import path

import pathは、利用箇所を見ます。該当packageを直接importしているか、framework経由か、CLIだけか、bundleに入るか。

単純検索だけでは足りない場合があります。wrapperやplugin経由で使っていることもあるため、関連fileや設定も見ます。

runtime context

runtime contextは、どこで動くかです。server、browser、worker、build、test、admin、script。ここがriskを大きく変えます。

Codexには、利用箇所ごとにruntime contextを表にさせます。

成果物を固定する

Plan

調査手順。

Evidence

証拠。

Action

次の一手。

Question

不足情報。

成果物を固定すると、security ownerが判断しやすくなります。

Codexに作らせる成果物は、repo-audit plan、evidence table、next actionです。

repo-audit planは、何をどの順番で調べるかです。evidence tableは、確認結果と根拠です。next actionは、更新、追加調査、watch、false positive、owner確認などです。

repo-audit plan

repo-audit planには、対象package、対象repo、対象workspace、確認するlockfile、検索するimport path、見るruntime、実行するtestを入れます。

調査計画があると、security ownerやcode ownerがレビューしやすくなります。

evidence table

evidence tableには、package version、dependency type、parent package、利用箇所、runtime context、exposure、根拠file、判断を入れます。

「影響なし」と書く場合も、根拠fileや確認方法を残します。

next action

next actionは、更新、pin、workaround、追加調査、owner確認、false positive、watchに分けます。

すべてを更新へ回さないことが大事です。影響経路がないならfalse positive候補です。影響経路があるが回避策があるなら、短期対応と恒久対応を分けます。

修正へ進める条件

項目	内容	見方
Path		影響経路。
Owner		担当。
Test		検証。
Rollback		戻し方。

条件が足りない場合は、追加調査へ戻します。

修正へ進む条件は、影響経路、owner、test、rollbackです。これがないままpatchへ進むと、incident対応が雑になります。

影響経路

影響経路は、対象packageがどこから入り、どこで使われ、どの入力に触れるかです。

Codexには、package -> import -> runtime -> exposureの流れで書かせます。流れが書けない場合は、まだ追加調査です。

owner

ownerは、security owner、code owner、release ownerに分けます。dependency incidentは、単なるpackage updateではなく、risk判断です。

Codexはowner候補を出せますが、採用判断は人間が持ちます。

test

testは、更新やworkaround後に何を確認するかです。unit、integration、E2E、security regression、manual QAのどれを見るかを決めます。

テスト失敗の扱いは、公開済み記事のCodexでテスト失敗を切り分ける前にともつながります。

false positiveを残す

影響なしと判断したものは、消さずにfalse positiveとして残します。なぜ影響なしなのか、どのversionを見たのか、どのpathに乗らないのかを記録します。

同じadvisoryが再度話題になった時、判断を再利用できます。

urgentとnormalを分ける

項目	内容	見方
Exploit		悪用可能性。
Public		外部露出。
Data		data影響。
Workaround		回避策。

severityだけでなく、自社での露出と回避策を合わせて見ます。

urgentとnormalは、severityだけで決めません。exploitability、public exposure、data impact、workaround、patch availabilityを合わせて見ます。

exploitability

exploitabilityは、実際に悪用できる条件です。特定APIを呼ぶ必要があるのか、外部入力が必要なのか、認証が必要なのか、local onlyなのか。

Codexには、advisory上の条件と、自社repoでの条件を分けて出させます。

public exposure

public exposureは、外部から到達できるかです。public web route、API endpoint、file upload、admin only、internal job、build toolでriskは変わります。

外部から到達できるpathなら、対応優先度は上がります。

workaround

workaroundがある場合は、短期対応と恒久対応を分けます。feature flag、config変更、route制限、input validation、package pin、WAF ruleなどです。

workaroundを入れる場合も、ownerと解除条件を残します。

よくある失敗

Upgrade first

先に更新。

Version only

versionだけ判断。

No owner

担当なし。

No evidence

根拠なし。

早く動くほど、証拠とownerを短く残します。

よくある失敗は、先にupgradeする、versionだけで判断する、transitiveを見落とす、ownerなしで止まる、根拠なしで影響なしにする、です。

先にupgradeする

急ぐ場面はありますが、何が影響しているかを見ないままupgradeすると、検証範囲が読めません。

まず影響経路を短く出し、必要なら緊急patchへ進みます。

versionだけで判断する

対象versionが入っているだけでは、必ずしも影響ありではありません。逆に、直接入っていなくてもtransitiveで入る場合があります。

version、path、exposureを合わせて見ます。

根拠なしで影響なしにする

「使っていなさそう」は判断ではありません。検索したpath、確認したlockfile、runtime context、owner確認を残します。

Codexには、判断と根拠を必ず分けさせます。

FAQ

項目	内容	見方
Transitive		経路確認。
No import		証拠化。
Auto fix		条件後。

Codexの出力は、修正命令ではなく判断材料として扱います。

transitive dependencyはどう見ますか？

lockfileで親packageを見ます。どのpackage経由で入っているか、production dependencyかdev onlyか、runtime bundleに入るかを確認します。

importがなければ影響なしですか？

必ずしもそうではありません。framework、plugin、CLI、config経由で使う場合があります。importがないことは根拠の一部ですが、runtime contextも見ます。

Codexに自動修正まで任せてよいですか？

影響経路、owner、test、rollbackが揃った小さな修正なら可能です。揃っていない場合は、repo-audit planとevidence tableまでにします。

外部advisoryを読ませてよいですか？

必要な場合は、許可されたsourceに限定します。取得した内容は根拠として残し、未知の外部サイトや認証情報を含むlogを雑に渡さないようにします。

参照した主な情報源

• Codex Use Cases
• Codex app features
• Codex Permissions
• Codex Worktrees
• AGENTS.md in Codex

次に読むなら

更新履歴

1. 2026.06.01

   初版。

Codexのuse casesやsecurity運用は、導入時に公式docsで見直します。

• 2026年6月1日: 初版公開。