【ITニュース解説】Deno 2.6's minimum dependency age flag ignores year and month durations

Denoは、JavaScriptやTypeScriptを安全に実行するために開発された新しいランタイムである。これはNode.jsの作者によって作られ、セキュリティと開発者の使いやすさの向上を目指している。現代のソフトウェア開発において、「サプライチェーン攻撃」という脅威が深刻化している。これは、開発中のプロジェクトが利用する外部のソフトウェア部品（ライブラリやパッケージ）に悪意のあるコードが紛れ込み、気づかないうちにプロジェクト全体に被害を及ぼす攻撃である。Deno 2.6では、このような攻撃から身を守るためのいくつかの新機能が導入されたが、その中でも特に注目されたのが、依存関係（利用する外部パッケージ）の最小経過時間を指定する機能である。

Deno 2.6で追加された--min-dep-ageというコマンドライン引数は、deno installやdeno addといったコマンドで外部パッケージをインストールする際に、指定した期間よりも新しく公開されたパッケージの利用を拒否する機能を提供する。この機能の目的は、悪意のあるパッケージが公開されても、通常は数時間から数日のうちに発見され、報告または削除されることが多いという性質を利用することにある。つまり、あえて一定期間（例えば30日間）が経過したパッケージのみをインストールするように設定することで、この種のサプライチェーン攻撃のリスクを大幅に軽減できるという考え方だ。

このフラグには、パッケージの公開からの経過時間を分単位で指定する方法や、「P2D」（2日間）のようなISO-8601形式で期間を指定する方法、「2025-09-16」のような絶対的な日付を指定する方法など、柔軟な設定が可能である。実際に、よく利用される20種類のJavaScriptパッケージに対して、--min-dep-age=P30D（30日間）という条件を設定してインストールを試したところ、そのうちの12種類が最新バージョンではなく、30日以上前に公開された古いバージョンに解決された。例えば、vitestというパッケージでは、最新バージョンが数日前に公開されていたにもかかわらず、30日以上の条件を満たすために、それよりも前のメジャーバージョンである4.1.10がインストールされた。このとき、Denoは新しいメジャーバージョンが存在することを示すエラーや警告を一切表示しないため、ユーザーは新しいバージョンが利用できないと誤解する可能性があった。一方で、このフィルタリング機能によるインストール速度への影響はごくわずかで、処理のオーバーヘッドはほとんどなかった。これは、フィルタリングがパッケージの公開日などのメタデータ情報を比較するだけで完了するため、処理コストが低いことを示している。

しかし、この--min-dep-ageフラグには、重大な問題が発見された。CLIのヘルプでは日単位の例が示されているものの、ISO-8601形式の期間指定では「月」や「年」といった単位も使用できる。そこで、期間を月単位や年単位（例: P1M: 1ヶ月、P2Y: 2年）で指定してテストしたところ、これらの月や年を含む期間指定は完全に無視され、常にパッケージの最新バージョンがインストールされてしまうことが判明したのだ。たとえば、--min-dep-age=P1Mと設定しても、最新バージョンが数日前に公開されたものであれば、それがそのままインストールされた。この問題は、指定する期間に月や年の要素が含まれていると発生し、たとえそれらの値がゼロであっても同様だった。Denoはエラーメッセージや警告を一切表示せず、処理も正常終了するため、ユーザーはこの年齢制限が正しく適用されていないことに気づくことが非常に困難である。もし企業やプロジェクトのセキュリティポリシーが「6ヶ月より新しい依存関係は許可しない」といった月単位で定められ、それをdeno.jsonファイルに"minimumDependencyAge": "P6M"と記述した場合、実際には何のリスク軽減効果も得られないにもかかわらず、セキュリティ対策が機能していると思い込んでしまう危険性があった。

さらに、この機能に関連して、CLIでのフラグ名と設定ファイルでのキー名に不整合があることもわかった。コマンドラインで利用する際のフラグ名は--min-dep-ageだが、設定ファイルであるdeno.jsonで同じ設定を行う場合のキー名は、minDepAgeではなく、フルスペルの"minimumDependencyAge"と記述する必要がある。もし誤って"minDepAge"と記述した場合、Denoはその設定を無言で無視し、結果として依存関係の年齢制限は適用されない。これもまた、ユーザーが意図しない挙動に気づきにくい原因となる。

また、--min-dep-age機能は、既存のロックファイル（deno.lock）には適用されない点も重要である。この年齢チェックは、新しい依存関係を追加したり、既存のロックファイルを更新したりする際に、どのバージョンのパッケージを選ぶかを決定する段階でのみ実行される。一度ロックファイルに特定のパッケージバージョンが記録されてしまえば、その後deno install --min-dep-age=P30Dを実行しても、ロックファイルに記載されたバージョンがそのままインストールされる。これは、ビルドの再現性を保証する上では合理的な設計であるが、CI/CD環境でロックファイルがすでにコミットされている場合、CIのインストールステップでこのフラグを設定しても、サプライチェーン攻撃からの保護は得られないことを意味する。この保護機能は、パッケージのバージョンが最初に選択される瞬間にのみ機能すると理解すべきである。

Deno 2.6では、npmパッケージに含まれるライフサイクルスクリプト（例えば、パッケージがインストールされた後に自動実行されるpostinstallスクリプトなど）の実行方法も改善された。以前はdeno install --allow-scriptsでまとめて許可していたが、新たにdeno approve-scriptsコマンドが導入され、個々のパッケージのスクリプトに対して、より細かく実行を承認できるようになった。この機能は期待通りに動作し、デフォルトではスクリプトの実行はブロックされ、明示的に承認することで実行される。承認されたパッケージとそのスクリプトはdeno.jsonに記録されるため、どのスクリプトが許可されているかを明確に把握でき、セキュリティ管理の観点から非常に有用な機能と言える。

しかし、Deno 2.6のもう一つの主要機能であるdeno audit（利用している依存関係に既知のセキュリティ脆弱性がないかをnpmのデータベースと照合する機能）にも問題が確認された。筆者の環境は、TLS（通信の暗号化）を検査するプロキシを経由していたため、deno auditコマンドを実行すると、「invalid peer certificate: UnknownIssuer」（無効なピア証明書：不明な発行者）というエラーが発生し、処理が失敗した。興味深いことに、同じ環境で、Denoスクリプト内で同じURLに対してfetch()関数を実行した場合や、通常のnpmインストーラーを使用した場合では、問題なくパッケージレジストリと通信できた。このことは、deno auditが、他のDenoコマンドや機能とは異なるHTTPクライアントを使用しており、システムの証明書信頼設定を適切に引き継げていない可能性を示唆している。企業やCI環境で、通信を監視するためにTLSを復号化・再暗号化するプロキシが利用されている場合、この問題はdeno audit機能の導入を妨げる要因となる。

これらの新機能は、Deno自身も「不安定版」と位置づけているため、一部に未熟な点があることは開発の途中段階であることを考慮すれば理解できる。しかし、もしこれらの問題を知らずに組織のセキュリティポリシーに組み込んだ場合、意図しないセキュリティリスクを抱え続けることになる可能性があった。

したがって、もし現在--min-dep-ageやminimumDependencyAgeといった依存関係の年齢制限機能の導入を検討している場合、期間の指定は「日」または「週」のみに限定すべきである。また、deno addコマンドを実行した後には、必ず生成されたdeno.jsonやdeno.lockファイルを確認し、意図した古いバージョンのパッケージが実際にインストールされていることを手動で検証することが不可欠である。この機能は、依存関係が初めて解決されるときにのみ機能し、既存のロックファイルに基づいてインストールされる場合には適用されないため、ロックファイルの管理方法にも十分に注意する必要がある。さらに、TLS検査プロキシのような特殊なネットワーク環境を利用している場合は、deno audit機能が期待通りに動作するかどうかを、事前に十分にテストしておくべきである。これらの点を理解し、適切な対策を講じることで、Denoが提供するセキュリティ機能を最大限に活用し、プロジェクトを安全に保つことができるだろう。