インストールの成功から分かること

コードの変更が一行でも、依存関係のグラフ全体は変わり得ます。一つのパッケージが間接依存を追加し、実行ファイルをダウンロードし、開発端末やCIの権限で動くことがあります。インストールに失敗する名前を見つける作業と、インストールできる配布物の信頼性を確認する作業はそれぞれ行います。

AIが生成したコードにパッケージ名があれば、使用予定のレジストリで検索します。登録がなければその経路では導入できません。見つかった場合は、使おうとしたAPIがそのリリースに存在するか、別のエコシステムで同じ綴りを持つ別プロジェクトか、配布されたバージョンが公式ソースに結びつくかを確認します。READMEとレジストリのリンクは同じ公開者が管理できるため、公式サイトや承認済み社内カタログなど、独立した参照先に照らします。

SpracklenらはUSENIX Security 2025で、コード生成に使う16モデルと二つのプロンプトデータセットを用いた研究を発表しました。調べたのはPythonとJavaScriptのコード576,000件に含まれるパッケージの幻覚です。結果が示すのは研究時点のモデル、プロンプト、レジストリの条件です。実際の配布経路と照合する根拠になります。自社で誤った提案がどれくらい出るかは、PRの記録を使って確認します。USENIX Security 2025の原論文[1]

検討する単位を次の情報で固定します。

  • 導入対象。エコシステム、正規化した名前、スコープ、レジストリ、バージョンを記録します。社内と公開のレジストリに同じ名前がある場合に備え、実際に選ばれた取得先を残します。モノレポでは適用されるワークスペース設定とロックファイルを確認します。
  • 信頼の根拠。公開者、ソースリポジトリ、リリースタグまたはコミット、成果物の識別値を記録します。公式リリース情報などでも配布名を照合し、公開者やビルド経路が変わったら前回の承認根拠と突き合わせます。
  • 必要な機能。import名、呼び出すAPI、対応ランタイム、失敗時の動作を記録します。提案されたコードが対象バージョンの文書とソースに適合するか確認します。似た名前に置き換える修正も新規依存として検討します。

レジストリの利用規則があるリポジトリでは、開発端末、PR用ビルド、リリース用ビルドで実際に使われる設定を確認します。CIでは想定した配布物を取得していても、開発端末では設定の優先順位が異なることがあります。実行結果を比べる前に、配布経路の違いを解消します。

依存関係の追加レビューに残す五つの項目

下の表をPRのレビュー票に使えます。新しく入るコードの影響を確認するため、アプリの修正とロックファイルの差分を同時に見ます。セキュリティ承認や例外判断を行う担当も決めておきます。

項目PRに残す証拠保留条件
必要性要求事項、呼び出し箇所、標準ライブラリや既存コードとの比較、保守担当呼び出す箇所がない、または既存の共通コードで対応できる
配布元正確な名前と版、承認済みレジストリ、公開者、ソースとコミット、成果物ハッシュまたは検証可能な来歴名前やスコープが異なる、配布元変更の説明がない、証明と導入物が異なる
依存関係マニフェストとロックファイルの差分、直接・間接依存、新規レジストリ、ライセンス、ランタイム、環境差無関係な大量更新、ロックファイル欠落、取得先変更の説明がない
実行動作インストール・ビルド・実行時のスクリプトやバイナリ、アクセス先、権限、隔離試験の結果本番の認証情報がないと再現できない、取得する実行ファイルが未確認、外部通信の記録がない
保守対象コミット、検査範囲、未実行・タイムアウト、担当者、削除・切り替えの条件検査範囲が見えない、例外の担当・期限がない、導入を再現できない

外部コンポーネント管理の参考としてNISTのSSDFがあります。誰が何を確認して決めるかを合わせます。保守担当は機能の適合、ビルド担当はグラフと動作の再現、セキュリティ担当は配布元と権限例外を確認します。一人が複数の役割を担うチームでも、確認対象、再現できるコマンドやログを残せます。NIST SP 800-218 SSDF v1.1[2]

ロックファイルで版と取得経路を確認する

依存関係の宣言にはバージョン範囲があり、ロックファイルには管理ツールが解決した依存関係が記録されます。共有ロックファイルを変えると他のワークスペースに影響することがあります。追加された間接依存、除外された版、同一パッケージの複数バージョンを確認します。行の順序が大きく変わったときは、ツールの版による表示差か、解決結果が変わったかを調べます。

固定された版、取得先、整合性の情報を確認します。GitのURL、ローカルパス、ミラー、別のレジストリが入る場合は、実際のビルドで想定した経路を使うかを照合します。整合性の値が一致すれば、取得したバイト列が記録された内容と一致します。動作や配布経路の信頼性は個別に調べます。

npmではマニフェストと既存ロックファイルが一致しないと npm ci がエラーになり、ロックファイルの書き換えは行われません。依存関係の形を変えるオプションでロックファイルを作った場合は同じ設定をCIで使います。他の管理ツールでは採用版のロックファイルと実行スクリプトの制御を確認します。レビューにはインストールツール、ランタイム、レジストリ設定、PRのコミットを記録します。npm ciの公式文書[3]

間接依存を変更する理由も残します。たとえば異なるバージョンのパーサーが共存する場合に、それぞれの利用経路を調べます。依存関係の一覧から消えたコードが配布バンドルに残る場合があります。依存コードをバンドルに含める構成では、導入一覧、配布物、実行環境のどれを確認したかを明記します。

テストより先に実行されるコードを調べる

パッケージのコードはインストール、ビルド、テスト、配布、実際の要求処理で動くことがあります。npmは npm ci、npm install のライフサイクルイベントを説明しています。テスト結果から先行して動いたスクリプトは分からないため、対象版の宣言と配布物の実ファイルを先に調べます。npmのライフサイクルスクリプト[4]

スクリプトが必要な理由を具体化します。たとえばネイティブモジュールの実行ファイルを用意する場合は、取得先と整合性の確認方法、読み込む環境変数、書き込むファイル、通信先を調べます。URLが固定でも後日内容が変わることがあります。承認後の初回実行は顧客データや本番の認証情報がない隔離環境で再現し、ビルドに必要な最小権限で実行できるかを確認します。

管理ツールでスクリプト実行を抑制できる場合は、初期確認に使い、抑制した範囲を記録します。実デプロイで必要なスクリプトは承認済み条件で再現し、生成物と外部通信を確認します。無関係な依存まで実行可能になることを避けるため、例外は承認したバージョンに絞ります。

来歴を確認し、動作も調べる

ソフトウェアの来歴を示すprovenanceは、成果物の配布元と生成経路を確認できる証拠です。SLSAは成果物の由来と生成方法を追える情報を説明しています。npmでは登録パッケージとソース、ビルド手順が結びつきます。署名が有効か、今回の版と取得した実体を対象にしているか、ビルドの主体と経路がチームの基準を満たすかを調べます。SLSA v1.2のProvenance[5]、npmのprovenance文書[6]

来歴が一致しても、ソースの変更や配布物だけに含まれるコードを確認します。証明のないパッケージを検討する場合は、許容する代替証拠と承認者を確認します。成果物と監査可能なソースを照合したり、社内レジストリで確認した版のみ配布したりできます。公開者の素性を確かめられないときは、似た名前のパッケージを導入する前に要求事項を見直します。

サービスの仕組み

正常系の先にある例外も検証 — 実装された動作から要件を復元し、入力、権限、外部呼出しの例外経路を実行して確認します。

仮想の配送アプリで判断する

架空の配送管理アプリで、連携先APIに渡す短い照会キーを検証します。AIが作ったPRにはユーティリティが追加され、説明には文字列変換とだけありました。チームは利用できる文字と長さを確認し、連携先が大文字・小文字を区別することを確かめました。一律に小文字へ変更すると、別の顧客のキーと解釈される可能性があります。

比較案入力と確認内容採用の判断材料
既存の検証関数空文字、最大長、許可しない文字、大文字・小文字要求を満たせば既存の保守経路を利用できる
標準ライブラリと小さな判定最小・最大長、改行、空白、文字の混在、大文字・小文字の保持規則が小さく安定し、機能試験で判定できる
提案された外部ライブラリ対象版での正常・境界入力、間接依存、ライフサイクルUnicodeの正規化など追加の必要性が生じたときに再検討

チームは入力値の検証で対応できると確認し、既存関数を再利用しました。マニフェストとロックファイルから追加を外したコミットで試験を再実行しました。正常なキーは元の値を保ち、不正なキーは外部への送信前に拒否されます。承認記録には既存試験で扱わなかった空白や大文字・小文字の境界も残しました。正規化が必要になれば、必要性、版、配布元を改めて調べます。

複雑な形式を長期間支えるパーサーなら、ライブラリを導入する場合と実装を保守する場合の負担を調べます。どの入力を処理でき、失敗がどこに隔離されるかを試験します。メンテナンス終了、修正版の不足、配布元変更の際に止める機能や代替手段を決めておくと、同じ版を無期限に固定する状況を避けやすくなります。

スキャン結果を承認に結びつける

対象のコミットとロックファイル、確認したエコシステム、版、検査の出所を記録します。検出ゼロの意味は検査範囲で決まります。リポジトリの依存関係アラートが無効でも、別のロックファイル照会が行われている場合があります。どの検査をやり直すか判断できるよう、実施範囲と結果を個別に記録します。

Qoretixの公開文書には、接続したGitHubリポジトリのセキュリティアラートとロックファイルによるサプライチェーン情報の照会が記載されています。リポジトリで無効な検査は不明と表示し、外部スキャナーとの連携はプレビューとしています。ツール、アカウント、リポジトリごとの適用範囲は導入時に確認します。来歴の判定、スクリプトの承認、通信制限にはチームのビルド・セキュリティ方針を適用します。IXCのQoretix紹介、Qoretixのセキュリティ詳細[8]

未確認の点がどこに影響するかを明確にします。本番アプリの依存コードがインストール時に未確認の送信先を使うなら、導入を保留できます。開発用の依存もビルドランナーで動けば本番の成果物に影響します。すでに実行された場合は環境とアクセス可能だった認証情報を調べます。鍵が露出した可能性がある場合は、リポジトリのシークレット流出対応を参照できます。

マージの根拠を提出する前に、承認したロックファイルとスキャンを実行したコミットが一致するか確認します。後続コミットで版が変わった場合や、スキャナーとレジストリの設定により導入範囲が変わった場合は必要な検査をやり直します。保護ブランチと必須検査の関係は、AIエージェントが作ったPRのマージ基準で扱っています。