npm公開時スキャン、dual-use要件とCI待機設計

GitHub は 2026年7月28日、npm に publish-time malware scanning と dual-use metadata を導入すると発表した。新しく公開された package は、install 可能になる前に自動スキャンを受ける。内容によっては通常公開、手動レビュー、ブロックに分かれ、公開直後にすぐ取得できる前提の自動化は見直しが必要になる。

この更新は、5月に扱った npm Staged Publishing、公開前検証を標準化 の続きとして読むべきだ。staged publishing が「公開前に人間とCIが見る時間」を作る更新だったのに対し、今回の publish-time scanning は「公開操作後、利用者へ届く前に npm 側が止める時間」を作る。どちらも、npm の速さを少し犠牲にして、供給網の説明可能性を上げる設計である。

日本の JavaScript / TypeScript チームにとって重要なのは、これは npm maintainer だけの話ではないという点だ。社内 SDK、design system、frontend platform、CLI、AI エージェント用の社内 package を npm または互換 registry で配る組織では、release workflow、GitHub Actions、Dependabot、package install policy を一体で見直すタイミングになる。

事実: npm公開後に短い待機時間が入る

GitHub Changelog によると、新規公開 package は install 可能になる前に自動でマルウェアスキャンされる。スキャン結果に応じて、そのまま公開される場合もあれば、手動レビューへ回る場合、またはブロックされる場合がある。多くの publish では、利用者側が特別な操作をする必要はない。ただし、公開から利用可能になるまで通常数分程度の遅延があり、ピーク時や package の内容・サイズによってはさらに長くなる可能性がある。

実務上は、この「数分の遅延」が一番大きい。これまで release workflow の中には、npm publish の直後に npm install <package>@<version> を実行して smoke test を走らせたり、別 repository の CI を即時に起動したり、documentation site のサンプルを同じ version で検証したりするものがあった。今後は、publish 成功と install 可能を同じ状態として扱えない。

GitHub は、スキャン待ちの間も npm dist-tag は動く一方、公開済み version に依存する npm deprecate や npm unpublish は package が利用可能になるまで動かないと説明している。つまり、release automation は「publish コマンドが成功したか」だけでなく、「registry から実際に解決できるか」を別の状態として扱う必要がある。

この点は、OpenAI TanStack対応、CI/CD防御を再点検 で扱った supply chain incident ともつながる。trusted publishing や provenance は重要だが、正規の公開経路が悪用される場合には、公開直後の検知・保留・利用側の取り込み遅延も防御層になる。

事実: dual-use packageには宣言が求められる

同じ発表で、npm は dual-use content 向けの metadata 要件も示した。dual-use content とは、penetration testing、security research、obfuscation など、正当な用途がある一方で自動スキャンからは malware に見え得る security-relevant な機能を含む package を指す。

npm Docs の Dual-Use Content Policy では、maintainer は package.json に contentPolicy を追加し、published tarball の root に DISCLOSURE file を含める必要がある。DISCLOSURE は自由形式の text で、package が提供する dual-use 機能と正当な利用目的を説明するために使われる。

ここで誤解してはいけないのは、宣言すれば自動的に許可されるわけではないことだ。npm は、dual-use metadata が追加スキャンや Trust & Safety review に使われる可能性を示している。さらに、一度 dual-use metadata 付きで公開した package は、新 version で contentPolicy や DISCLOSURE を外せない。外した publish は拒否され得る。

公開方法にも制約がある。dual-use package は 2FA が強制される方法で公開する必要がある。interactive publish、または staged publishing の promotion step は許される。一方、2FA を bypass する granular access token での direct publish や、staging を挟まない trusted publishing direct publish は許されない。これは、security tool の公開ほど「誰が本当に公開したのか」を強く求める設計だ。

分析: 日本チームは即時install前提を直す必要がある

ここからは分析である。

日本の開発現場では、npm publish は小さな release job として扱われがちだ。tag を切る、build する、publish する、Slack に通知する、別 repository を更新する。これ自体は自然だが、publish-time scanning が入ると、release job は「公開したら終わり」ではなく「公開、registry availability 確認、利用側 smoke test、通知」の段階へ分ける必要がある。

まず直すべきは CI の待機設計だ。npm view <pkg>@<version> version のような registry 解決確認を retry 付きで入れ、数分の pending を failure と誤判定しないようにする。時間を置けば解決する pending と、malware 判定や policy violation でブロックされた状態は、運用上の意味がまったく違う。release job はそこを区別できるようにしたい。

次に、社内利用者への通知を変える。publish command が成功した時点で「利用可能」と通知すると、下流チームが install できず混乱する。通知は「publish submitted」「available」「blocked/review required」に分けるほうがよい。特に社内 package を多数の product team が使う企業では、この状態分離だけで incident 対応が楽になる。

3つ目は、AI エージェントによる依存追加との接続である。AI が package を追加する PR を作る場合、公開直後の package をそのまま取り込むと、スキャン pending や後続ブロックの影響を受けやすい。以前の GitHub DependabotのAIエージェント修復 で見たように、依存更新は AI が扱いやすい領域になっている。だからこそ、AI が選んだ package を CI がどう待ち、どう検知し、どう人間へ説明するかが重要になる。

分析: 同日のDependabotとActions更新も同じ方向を向く

7月28日の GitHub 更新は npm だけではない。Dependabot は OpenSSF malicious-packages repository の advisory を GitHub Advisory Database へ取り込み、npm や PyPI など複数 ecosystem で malware alert coverage を広げた。malware alerting が有効なら、新しい malicious package advisory が公開されたときに Dependabot alerts として検知できる。

同じ日に GitHub Actions も、潜在的に悪意ある workflow run を実行前に hold し、write access を持つ collaborator の承認を要求する保護を発表した。対象は github.com の public repositories で、GitHub Enterprise Server には現時点で適用されない。供給網攻撃が GitHub credential を奪い、悪意ある workflow を push して CI/CD credential を盗む流れを意識した保護である。

この二つは、npm publish-time scanning と合わせて見ると意味がはっきりする。npm 側は package が利用者に届く前に止める。Dependabot は利用側で既知 malware advisory と dependency を照合する。Actions は workflow 自体が credential 収集の入口になる場合に実行前承認を挟む。つまり、公開、利用、CI 実行の三点で同時に「即時実行」を弱めている。

日本企業が見るべきなのは、個別機能のオン/オフではなく、この方向性だ。AI エージェントが依存を追加し、CI が自動で build し、package が数分で世界へ流れる環境では、速さだけを最適化すると防御点が消える。npm、Dependabot、Actions の更新は、速い供給網にあえて保留・検知・承認を入れる流れとして整理できる。

導入時のチェックリスト

まず、release workflow が publish 直後の install 成功を前提にしていないか確認する。npm publish の直後に別 package の integration test を走らせるなら、registry availability の retry と timeout を入れる。pending が数分で解消しない場合は、人間に通知して release manager が npm の通知や appeal 状況を確認できるようにする。

次に、dual-use に該当する package を棚卸しする。security scanner、pentest helper、proxy、crawler、obfuscation、credential inspection、malware analysis helper のような機能を持つ社内・OSS package は、contentPolicy と DISCLOSURE の要否を確認する。日本企業では、セキュリティ部門が作った内部ツールを公開 npm と同じ workflow で配ることがある。そこは早めに分類しておきたい。

3つ目は、2FA と staged publishing の整理である。trusted publishing は強力だが、dual-use package の direct publish には使えない。staging を挟む、promotion に 2FA を求める、granular token の権限と bypass-2FA の扱いを分ける、といった運用が必要になる。これは GitHub MCP Serverで秘密情報と依存関係を事前検査 で扱ったような、エージェント前段の権限境界とも相性がよい。

最後に、利用側の検知を Dependabot と OSV-Scanner へ寄せる。OpenSSF は malicious package records を OSV 形式で扱い、lockfile や SBOM を CI でスキャンする導線を示している。npm 側のスキャンだけに依存せず、下流 repository でも package-lock、SBOM、Dependabot malware alerts を確認するほうが現実的だ。

まとめ

npm publish-time malware scanning と dual-use metadata は、npm registry の運用変更であると同時に、日本の開発チームへ CI/CD 設計の変更を迫る更新である。公開直後にすぐ install できる、security tool も通常 package と同じ token で direct publish できる、CI が新しい依存を即時に取り込める。そうした前提は弱くなる。

これは悪いことではない。AI エージェントが依存追加や release 作業へ入るほど、公開と利用の間に短い検査時間を置き、dual-use package の意図を明文化し、Dependabot と Actions で利用側の検知・承認を重ねる価値は上がる。日本企業は、npm の新機能を「待ち時間が増えた」とだけ見ず、供給網を説明可能にするための設計変更として扱うべきだ。

出典

• npm publish-time malware scanning and dual-use metadata - GitHub Changelog, 2026-07-28
• npm Dual-Use Content Policy - npm Docs, last updated 2026-07-28
• Dependabot alerts on malicious packages across more ecosystems - GitHub Changelog, 2026-07-28
• GitHub Actions holds potentially malicious workflows for approval - GitHub Changelog, 2026-07-28
• OpenSSF Malicious Packages - OpenSSF, accessed 2026-07-29