uvの`audit`コマンドとは？依存関係の脆弱性スキャンを実際に試してみた

Pythonのパッケージ・プロジェクト管理ツール「uv」は、このブログの過去記事（Serenaの検証など）でもインストール手段として何度か登場しています。そのuvに、依存関係の脆弱性を調べる実験的（preview）なサブコマンドuv auditが追加されていることに気づき、実際に動かして検証しました。

\n

先に結論を書きます。このクラウド環境のネットワークポリシーは、uv auditが既定で問い合わせる脆弱性データベースAPI（api.osv.dev）への接続を許可していません。そのため、実際の脆弱性スキャン結果そのものは確認できませんでした。一方で、コマンドの実在・オプション構成・既定の挙動・エラーメッセージの内容・GitHub上での開発経緯までは、公式リポジトリと実際の実行結果の両方から確認できています。本文では、どこまでが公式ドキュメント／コードの記述で、どこからが実際にこの環境で動かして得た結果かを区別して書きます。

\n

uvとは：pipやpoetryをまとめて置き換えるRust製ツール

\n

公式リポジトリ（astral-sh/uv）のREADMEは、uvを「An extremely fast Python package and project manager, written in Rust」と説明しています。開発元はRuffやty（型チェッカー）と同じAstral社です。README本文によると、pip・pip-tools・pipx・poetry・pyenv・twine・virtualenvなど複数のツールを単一のバイナリで置き換えることを目指しており、pip比で10〜100倍速いと述べられています。プロジェクト管理用のユニバーサルなロックファイル、Cargo風のワークスペース、PEP 723のインラインメタデータを使ったスクリプト実行、Pythonバージョン自体の管理、uvxによるツール実行など、カバー範囲は広めです。ライセンスはApache License 2.0とMITのデュアルライセンスでした。

\n

このクラウド環境にはすでにuvが入っており、uv --versionを実行するとuv 0.11.32が返りました。GitHub Releasesを確認すると、本稿を書いている時点の最新版は2026年11月3日公開の0.13.7で、この環境のuvは0.13系からは少し離れたバージョンです。コマンド自体は後述のとおり問題なく動きましたが、挙動を確認する際は自分の環境のバージョンがどのくらい新しいかも合わせて見ておいたほうが安全そうです。

\n

`uv audit`とは：依存関係の「脆弱性」と「非推奨・検疫」を調べるコマンド

\n

手元でuv help auditを実行すると、次のような説明が返ってきます（実際の出力そのまま）。

\n

Audit the project's dependencies.\n\nDependencies are audited for known vulnerabilities, as well as 'adverse' statuses such as\ndeprecation and quarantine.

\n

つまりpip-auditやcargo audit、npm auditに近い位置づけのコマンドで、プロジェクトの依存関係（既定では全エクストラ・全グループが対象）に既知の脆弱性がないか、あるいはパッケージが「非推奨」や「検疫（quarantine）」といった状態になっていないかを調べます。「quarantine」はPyPI側が2024年8月から運用している機能で、疑わしいと判断されたプロジェクトをPyPIのSimple Indexから一時的に見えなくする仕組みです（PyPI公式ブログ）。uv auditがこの状態もチェック対象に含めている、というのがuv help auditの記述から読み取れる設計です。

\n

uv audit --helpを実行すると、--no-extra・--no-dev・--no-group・--only-groupといった対象の絞り込みオプション、CI向けの--locked・--frozen、結果の出力形式を切り替える--output-format <text|json|sarif>、特定の脆弱性IDを無視する--ignore・--ignore-until-fixed、そしてPEP 723のインラインメタデータ付きスクリプトを直接対象にできる--scriptが確認できました。--service-format（既定はosv）と--service-urlが用意されている点から、問い合わせ先のサービス自体を差し替えられる設計になっているようです。

\n

GitHub上の開発経緯：3月に「非表示」が解除され、11月もまだ変更が続く実験的機能

\n

uv auditは最初から公開のコマンドだったわけではないようです。GitHubのプルリクエスト#18540「Unhide `uv audit`」（2026年3月18日にopen・同日にmain へマージ）には、「ほぼ全てのMVPロードマップが完了したので、`uv audit`を非表示から解除する」と書かれています。このPRにはpreviewラベルが付いており、現在もCHANGELOG上は「Preview features」のカテゴリに分類され続けています。実際に手元で実行しても、毎回次の警告が表示されます（実際の出力）。

\n

warning: `uv audit` is experimental and may change without warning. Pass `--preview-features audit-command` to disable this warning.

\n

開発は本稿執筆時点でも活発に続いています。CHANGELOG.mdの直近エントリ（CHANGELOG.md）には、2026年11月3日公開の0.13.7で「エイリアスされたOSVレコードを`uv audit`上で1件にまとめて報告する」変更（#22990）が入ったと記載されています。また、GitHubのPR一覧を見ると、#23120「Support `--python` and `UV_PYTHON` in `uv audit`」という、2026年11月5日付け（本稿執筆のわずか数日前）のPRも見つかりました。このPRは、AIによって自動生成されたものだったためメンテナーの方針（AIがメンテナーとやり取りすることを認めない方針）に反するとして、ボットにクローズされています。コミュニティからの改善提案が今も活発に出ていること、そしてメンテナー側がAI生成PRの扱いに明確なポリシーを持っていることの両方がうかがえる一幕でした。

\n

なお、非表示を解除したPR #18540の作者であるGitHubアカウントwoodruffwは、本ブログで以前取り上げたGitHub Actions向け静的解析ツール「zizmor」のメンテナーでもあります（本人のGitHubプロフィールにmaintainer @zizmorcoreと明記され、所属organizationに@astral-shも含まれています）。サプライチェーン・セキュリティ系のツールを複数の立場で手がけている人物が、uv側の脆弱性チェック機能にも関わっているようです。

\n

実際に動かしてみる：脆弱性が既知の古いパッケージを依存関係に入れて試す

\n

このクラウド環境で、検証用の小さなプロジェクトを作りました。

\n

uv init --no-readme uv-audit-test\ncd uv-audit-test\nuv add "urllib3==1.25.8"

\n

urllib3 1.25.8は複数の既知の脆弱性（CVE）が報告されている古いバージョンで、脆弱性チェックの動作確認によく使われます。uv addは問題なく完了し、生成されたuv.lockにもurllib3 1.25.8が1パッケージとして記録されました。ここまでは通常のuvの挙動どおりです。続けてuv auditを実行します。

\n

uv audit

\n

warning: `uv audit` is experimental and may change without warning. Pass `--preview-features audit-command` to disable this warning.\nResolved 2 packages in 1ms\nerror: Request failed after 3 retries\n  Caused by: error sending request for url (https://api.osv.dev/v1/querybatch)\n  Caused by: client error (Connect)\n  Caused by: tunnel error: unsuccessful

\n

ロックファイルの解決自体は成功しており、そのあとにapi.osv.dev/v1/querybatchへの接続が失敗しています。このクラウド環境のネットワークプロキシのステータスを確認したところ、許可リストにはpypi.orgやfiles.pythonhosted.orgは含まれていますが、api.osv.devは含まれていませんでした。つまり、この結果はuv audit自体の不具合ではなく、検証環境側のネットワークポリシーによる制限です。

\n

--offlineフラグを付けた場合は、エラーメッセージが変わりました（実際の出力）。

\n

error: Network connectivity is disabled, but the requested data wasn't found in the cache for: `https://api.osv.dev/v1/querybatch`

\n

このメッセージから分かるのは、uv auditはcargo auditのようにローカルへ脆弱性データベース全体を同梱する方式ではなく、問い合わせ結果をキャッシュしつつ、基本的には毎回OSV（Open Source Vulnerabilities）のAPIへ問い合わせにいく設計だということです。ネットワークに接続できない環境で結果を得るには、事前に一度オンラインでuv auditを実行してキャッシュを作っておくか、--service-urlで到達可能な別のOSV互換サービスを指定する必要がありそうです（後者は今回未検証です）。

\n

PEP 723スクリプト単体も対象にできる`--script`

\n

uv audit --scriptを使うと、プロジェクト全体ではなく、インライン依存メタデータ（PEP 723）を持つ単一ファイルのPythonスクリプトを対象に監査できます。次のような、依存関係をスクリプト先頭のコメントで宣言したファイルを用意しました。

\n

# /// script\n# requires-python = ">=3.11"\n# dependencies = [\n#     "urllib3==1.25.8",\n# ]\n# ///\nimport urllib3\nprint(urllib3.__version__)

\n

uv audit --script script.py

\n

実行結果は、依存関係の解決（Resolved 1 package in 3ms）まではプロジェクト向けと同様に進み、そのあとで同じapi.osv.devへの接続エラーで止まりました。uv runがプロジェクトと単体スクリプトの両方を同じように実行できるのと同じ発想で、uv audit側も単体スクリプトを第一級の対象として扱っていることが確認できました。

\n

向いている場面・まだ注意が必要な場面

\n

• 向いている：すでにuvでプロジェクトやスクリプトの依存関係を管理していて、CIに依存関係の脆弱性チェックを足したい場合。--output-format jsonや--output-format sarif、--locked・--frozenが用意されているため、既存のCIパイプラインに組み込みやすい設計です
• まだ注意が必要：preview機能であり、CHANGELOGにも書かれているとおり挙動が予告なく変わる可能性があります。また既定では外部APIへのオンライン接続が前提で、ローカルの脆弱性データベースを完全な代替として同梱してはいないため、社内ネットワークやエアギャップ環境で使う場合は、事前に接続先ホストと挙動を確認したほうがよさそうです

\n

この記事で確認できなかったこと

\n

繰り返しになりますが、このクラウド環境のネットワークポリシー上、api.osv.devへの接続自体がブロックされているため、実際に脆弱性が検出された場合の出力例（JSON形式やSARIF形式を含む）、--ignore・--ignore-until-fixedで検出結果を抑制する際の実際の挙動、--service-urlで別のOSV互換サービスを指定した場合の動作は、いずれも今回確認できていません。これらはいずれも公式の--help出力から存在が確認できるオプションですが、実際の出力例は今回のクラウド環境の制約により試せなかった点として明記します。

\n

まとめ

\n

uvには、依存関係の既知の脆弱性と「非推奨・検疫」ステータスを調べるpreview機能uv auditが追加されています。2026年3月に非表示が解除されたばかりの新しいコマンドで、11月に入ってもOSVレコードの重複排除やPythonインタプリタ指定への対応など、活発に変更が加えられ続けています。実際にこのクラウド環境で動かしてみたところ、コマンド自体・オプション構成・ロックファイルの解決までは問題なく動作しましたが、既定の問い合わせ先であるapi.osv.devへの接続がこの環境のネットワークポリシーで遮断されており、実際の脆弱性検出結果そのものは確認できませんでした。ローカルDBを持たない設計であることや、preview機能ゆえに挙動が変わる可能性がある点は、導入前に把握しておいたほうがよいポイントです。

\n

参考にした一次情報

\n

• GitHub公式リポジトリ：astral-sh/uv（README、ライセンス）
• CHANGELOG.md（0.13.7などのリリースノート）
• GitHub Releases（バージョン履歴）
• PR #18540「Unhide `uv audit`」（非表示解除の経緯）
• PR #22990（エイリアスされたOSVレコードの統合）
• PR #23120（`--python`/`UV_PYTHON`対応、AIポリシーによりクローズ）
• PyPI公式ブログ：Project Quarantine機能について
• 本文中のuv --version・uv help audit・uv audit --help・uv audit・uv audit --script・uv audit --offlineの実行結果は、この記事の検証時点で実際にこのクラウド環境でuv 0.11.32を使って得たものです。