npm・PyPIで4連続の供給網攻撃（GitGuardian 7/22総括）｜自社の製品が『開発会社のnpm install』経由で汚染される時代の発注側チェック

このガイドが役立つ方：システム開発やアプリ開発を外部の開発会社に委託している、年商1〜100億円規模の中堅企業の経営者・事業責任者。社内に専任のセキュリティ担当がおらず、情シスは0〜1名、あるいは他業務との兼任という体制で、「うちのシステムは外注だから、セキュリティも先方が見てくれているはず」と考えている方を想定しています。

2026年7月22日、認証情報漏えい検知を手がけるGitGuardianが、6月上旬から7月中旬にかけてnpmとPyPIで相次いだソフトウェア供給網（サプライチェーン）攻撃を1本の総括レポートにまとめて公開しました。個別の攻撃はそれぞれ別の日に起きていましたが、こうして並べて見ると、いずれも「開発者が普段何気なく実行しているパッケージのインストール」を突破口にしている点で共通しています（ベンダー調査による報告のため、本記事では準一次情報として扱います）。

結論から言えば、これは「開発会社の話」であって自社には関係ない、という問題ではありません。あなたの会社の製品やサービスが外注で作られているなら、その製品のビルド環境は、開発会社のエンジニアが打つ npm install（依存パッケージの取得）というコマンド1つで、外部の汚染されたコードを取り込みうる状態にあります。汚染されたパッケージは、ビルドを通じて最終的にあなたの会社の名前で世に出る製品の中に紛れ込む可能性がある。本記事は、この構図を発注側の言葉で解きほぐし、「開発を任せている会社に、何を・どの順で確認すればよいか」を判断できる状態にすることを目的としています。

結論：外注していても、供給網の汚染リスクは発注側に返ってくる

今回の4件は、いずれも「正規のパッケージ配布の仕組み」を悪用しています。悪意あるコードは、開発会社が自社サーバーに侵入されて仕込まれたのではなく、世界中の開発者が使う公開レジストリ（npm・PyPI）に置かれた「一見まともなパッケージ」の中に潜んでいました。開発会社がそれを取り込めば、開発会社のPC・CI（自動ビルド）サーバー・そして最終的な成果物が汚染されます。

発注側が押さえるべき要点は3つです。第一に、契約書に「セキュリティは受託者が責任を負う」と書いてあっても、被害は自社の製品・顧客・ブランドに直接及ぶこと。第二に、丸投げでは守れない領域があり、発注側が最低限の確認を入れないと、汚染が起きたことすら気づけないこと。第三に、確認すべき項目は技術用語こそ多いが、経営者が「やっているか／いないか」を問うだけで防御の水準が大きく変わること。以下、まず4件の中身を発注側の視点で押さえ、その上でベンダーへの確認リストへ進みます。

4件の供給網攻撃の概要（GitGuardian 7/22総括より）

数値・固有名詞はGitGuardianの総括レポートに記載された範囲で記しています。ベンダー調査由来のため、以降の判断も「確定した公式発表」ではなく「準一次情報として妥当な整理」として扱ってください。

なぜ「開発会社の話」で終わらないのか

多くの経営者は、システム開発を外注した時点で、「作る責任も守る責任も先方に移った」と感じます。しかし供給網攻撃は、その感覚の死角を正確に突いてきます。順に見ていきます。

「自社製品」の中身は、他人が書いたコードでできている

現代のシステム開発では、機能の大半を外部のオープンソースパッケージに依存します。ログイン、決済連携、日付処理、暗号化——こうした部品を毎回ゼロから書く開発会社はほぼ存在せず、npm（JavaScript／TypeScript）やPyPI（Python）といった公開レジストリから取り込むのが標準です。1つのアプリが数百から数千のパッケージに依存することも珍しくありません。つまり、あなたの会社の名前で公開される製品の中身の相当部分は、顔も知らない世界中の開発者が書いたコードでできています。今回汚染されたパッケージ群は、まさにその「部品」の位置にあるものでした。

汚染は「ビルドの一瞬」で成果物に混入する

偽決済SDKやAsyncAPIの事例が示すのは、汚染されたパッケージがインストールやビルドのタイミングで自動実行されるという点です。開発者がコマンドを1回打つだけで、環境変数（KEY・SECRET・TOKEN・AUTHなど、まさに認証情報が入る名前）が外部へ送信される。AsyncAPIに至っては、正規の電子署名（Sigstore・SLSA）が付いていたにもかかわらず発火しました。「署名があるから安全」という素朴な安心が通用しないことを、この事例は突きつけています。開発会社のCIサーバーに保管されたあなたの会社のクラウド認証情報が抜かれれば、被害はあなたの本番環境へ直結します。

気づけるのは「確認の仕組みを入れていた会社」だけ

偽決済SDKは公開から約6分、AsyncAPIは約4時間で検知・対処されました。これは「監視していた人がいた」から成立した時間です。逆に言えば、依存パッケージの取り込みを何も監視していない開発現場では、汚染が起きても誰も気づかないまま成果物が納品され得る。発注側が「そちらの監視体制はどうなっていますか」と一度も問わなければ、この差は永久に見えません。丸投げの本質的な危うさはここにあります——守れているかどうかを確認する回路そのものが存在しないのです。

丸投げでは守れない領域を可視化する

供給網攻撃に対して、発注側が「自分では手を動かせないが、確認はできる」領域は明確です。次の4つは、開発会社に任せきりでも、発注側が問い方さえ知っていれば水準を引き上げられます。

• 依存関係の管理：どのパッケージを、どのバージョンで使っているか。新しく公開されたばかりのパッケージを無防備に取り込んでいないか。
• CIの秘密情報管理：自動ビルド環境に置かれた自社のクラウド認証情報・APIキーが、必要最小限の権限に絞られ、外部へ持ち出されにくい構成になっているか。
• SBOM（ソフトウェア部品表）：製品が「どの部品でできているか」の一覧を、納品物として受け取れるか。汚染パッケージ名が公表されたとき、自社製品が影響を受けるか即座に照合できるか。
• ロックファイルの運用：依存パッケージのバージョンを固定する仕組み（package-lock.json / poetry.lock 等）を使い、勝手に最新版へ更新されない運用になっているか。

これらは開発会社が「やっている」と言えば1分で終わる話ですが、やっていない現場では、聞かれて初めて不在に気づきます。以下、それぞれの確認軸を発注者の言葉に落とします。

依存関係の管理：新着パッケージへの「間合い」があるか

供給網攻撃の多くは、公開直後の数時間〜数日が最も危険です。偽決済SDKが約6分、AsyncAPIが約4時間で検知・対処されたことは、裏を返せば「公開直後に取り込んでしまえば汚染版をつかむ」ことを意味します。近年は、新しく公開されたパッケージを一定期間（例：数日）は自動取り込みしない「待機期間（クールダウン）」を設ける運用が広がっています。発注側としては、「新着パッケージや新バージョンを即座に取り込んでいないか、待機期間を設けているか」を問えば十分です。

CIの秘密情報管理：抜かれても被害を最小化できるか

今回の攻撃はいずれも「環境変数や認証情報の窃取」を狙いました。ここで効くのは、そもそもCI環境に強すぎる権限の認証情報を置かないという設計です。ビルドに必要な最小限の権限に絞る、本番環境への書き込み権限はビルド用トークンから外す、トークンには短い有効期限を設ける——こうした「抜かれても被害が限定される」構成になっているかが分かれ目です。発注側は「CIに置いている認証情報の権限は最小化されていますか。抜かれた場合、本番環境まで到達しますか」と問えます。

SBOM：汚染が公表された翌朝に照合できるか

SBOM（Software Bill of Materials）は、製品を構成するパッケージの一覧です。これが納品物にあると、「Hadesで◯◯というパッケージが汚染された」という発表が出た朝、自社製品がその部品を含むかを数分で照合できます。SBOMがなければ、開発会社に問い合わせ、先方が調べ、回答が返るまで——汚染が広がる時間の中で自社が影響下にあるかすら分からない状態が続きます。発注側は「納品時にSBOMを提供してもらえますか。既知の汚染パッケージとの照合はどう運用しますか」と問えます。

ロックファイルの運用：昨日動いたものが今日も同じか

ロックファイルは、依存パッケージのバージョンを厳密に固定する仕組みです。これがないと、同じソースコードでも、ビルドする日によって取り込むパッケージのバージョンが変わり、「昨日は安全だったが今日は汚染版を引いた」という事故が起こり得ます。ロックファイルを使い、バージョンを固定した上で、更新は人の目を通してから反映する——この運用があるかで、汚染版を無自覚に取り込む確率が大きく変わります。発注側は「ロックファイルでバージョンを固定していますか。依存の更新は誰がレビューしますか」と問えます。

発注前・棚卸しチェックリスト（発注側が確認する項目）

すでに開発を委託している場合も、これから発注する場合も、次の項目を確認してください。技術用語が並びますが、開発会社にそのまま渡して「該当しますか」と聞けば機能します。

• 使用しているオープンソースパッケージの一覧（SBOM）を、納品物として受け取れるか
• 新着パッケージ・新バージョンを、公開直後に無条件で取り込んでいないか（待機期間の有無）
• ロックファイル（package-lock.json / pnpm-lock.yaml / poetry.lock 等）でバージョンを固定しているか
• 依存パッケージの更新は、自動反映ではなく人のレビューを経ているか
• CIサーバーに置く自社の認証情報は、最小権限・短期有効期限になっているか
• CIで使うトークンから、本番環境への直接の書き込み権限を外しているか
• パッケージのインストール時に自動実行されるスクリプトを制御しているか（無効化や検査の仕組み）
• 汚染パッケージが公表された際に、自社製品が影響を受けるか照合する手順が決まっているか
• 万一汚染が判明した場合の、連絡・切り分け・切り戻しの初動が契約や運用で決まっているか
• これらの確認に、開発会社が具体的に答えられるか（「大丈夫です」で終わらないか）

最後の項目が最も重要です。上記に対して具体的な運用で答えられる開発会社は、供給網リスクを日常的に意識しています。逆に、抽象的な安心の言葉しか返ってこない場合、確認の回路そのものが現場に存在しない可能性を疑うべきです。

開発ベンダーへの質問テンプレート

そのまま送れる形にまとめます。回答の「粒度」を見れば、相手の成熟度が判断できます。

1. 「当社向けの成果物について、依存しているオープンソースパッケージの一覧（SBOM）をいただけますか。更新時にも差分を提供いただけますか。」
2. 「依存パッケージのバージョンはロックファイルで固定されていますか。新しいバージョンへの更新は、どなたがどうレビューして反映していますか。」
3. 「新しく公開されたパッケージや新バージョンを、公開直後にそのまま取り込まない運用（待機期間など）はありますか。」
4. 「CI／ビルド環境に保管している当社のクラウド認証情報やAPIキーは、どの範囲の権限に絞られていますか。仮に窃取された場合、当社の本番環境までは到達しない構成になっていますか。」
5. 「パッケージのインストール時に自動実行されるスクリプトについて、無効化や検査の仕組みはありますか。」
6. 「特定のパッケージが汚染されたと公表された場合、当社製品が影響を受けるかを、どのくらいの時間で判断できますか。その手順は決まっていますか。」

回答が「はい／いいえ」で終わらず、誰が・どのツールで・どの頻度でと具体的に返ってくるかを見てください。供給網攻撃は運用の細部で防ぐものであり、細部を語れることが信頼の根拠になります。

見積もり・契約の読み方：セキュリティは「明記されているか」で見る

供給網対策の多くは、見積書の表面には現れません。「セキュリティ対策一式」とだけ書かれていて、中身が依存管理やCI保護まで含むのかが読み取れないことがよくあります。ここで発注側が確認したいのは、「セキュリティが安いか高いか」ではなく、上記の運用が見積もりの前提として組み込まれているか、それとも別料金の追加提案として初めて出てくるのかです。

依存管理・CI保護・SBOM提供が「標準の開発プロセスに含まれる」と明言できる会社と、「必要ならオプションで」と切り出す会社では、供給網リスクへの日常的な向き合い方が異なります。契約段階では、①汚染が判明した場合の連絡・初動の責任分界、②SBOMなど成果物の範囲、③依存更新の運用主体——この3点が文書に落ちているかを確認してください。あいまいなまま進めると、事故が起きてから「それは契約外です」というやり取りに時間を奪われます。契約書の文言に不安があるなら、着手前に第三者へ見積もりのセカンドオピニオンを取るのが安全です。GXOでは、開発会社への発注前チェックや見積もりの読み解きを支援しており、供給網まで含めた要件の整理をお手伝いできます。

誰が読むべきか

• 外注でシステム・アプリを作らせている経営者・事業責任者：自社製品のビルドが第三者のコード経由で汚染される構図と、発注側にできる確認を把握したい方。
• 情シス0〜1名・兼任情シスの体制で発注を管理している方：技術の細部までは踏み込めないが、開発会社への問い方で防御水準を上げたい方。
• これから開発会社を選定する方：相見積もりの各社に同じ質問を投げ、供給網リスクへの成熟度で比較したい方。
• すでに稼働中のシステムを持つ方：棚卸しとして、いま任せている会社の運用を点検し直したい方。

技術者が自ら防御を設計する記事は多く出ています。本記事はあえて、自分では手を動かさない立場の人が、任せている相手に何を問えばよいかに焦点を当てています。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、発注側の立場でリスクを棚卸しする価値があります。

• システムを外注しているが、開発会社のセキュリティ運用を一度も確認したことがない。
• 見積書に「セキュリティ対策」とあるが、依存管理やCI保護まで含むのか読み取れない。
• 汚染パッケージのニュースが出るたびに不安になるが、自社が影響を受けるか判断できない。
• 開発会社の回答が抽象的で、具体的な運用として信頼してよいか判断がつかない。
• これから開発を発注するにあたり、供給網まで含めた要件を整理してから相見積もりを取りたい。

GXOは、AI・システム開発のDX・システム開発支援を軸に、発注前の要件整理から開発会社の選定、稼働後の運用点検までを、発注者の立場に立って支援します。供給網を含むセキュリティの観点はセキュリティの取り組みとして整理しており、AIを組み込んだシステムを内製・外注する際の依存リスクについてはAI導入・活用支援の文脈でもご相談いただけます。「守れているかを確認する回路」を自社に持つための第一歩として、お問い合わせからご相談ください。丸投げの不安を、確認できる状態へ変えることが目的です。

よくある質問（FAQ）

Q1. 自社は開発を外注しているだけです。それでも供給網攻撃の被害を受けるのですか。 A. 受け得ます。あなたの会社の製品は、開発会社が取り込んだ外部パッケージで構成されています。そのパッケージが汚染されれば、汚染は成果物を通じて自社製品・顧客・本番環境に及びます。契約上の責任が受託者にあっても、実被害とブランドへの影響は発注側に返ってきます。

Q2. 開発会社に「セキュリティは大丈夫ですか」と聞けば十分ですか。 A. 不十分です。抽象的な問いには抽象的な安心が返るだけです。本記事の質問テンプレートのように、SBOM・ロックファイル・CIの権限・自動実行スクリプトといった具体項目を問い、運用として答えられるかを確認してください。

Q3. SBOMとは何ですか。なぜ必要なのですか。 A. SBOMは製品を構成するパッケージの一覧（部品表）です。特定のパッケージが汚染されたと公表されたとき、自社製品がその部品を含むかを即座に照合できます。SBOMがないと、影響を受けるかどうかの判断そのものに時間がかかります。

Q4. 「正規の電子署名が付いていれば安全」ではないのですか。 A. AsyncAPIの事例では、Sigstore・SLSAという正規の署名が付いていたにもかかわらず、悪性コードが発火したと報告されています。署名は「配布元が本物か」を示すものであり、「中身に悪意がないか」を保証するものではないと理解してください。

Q5. 待機期間（クールダウン）を設けると開発が遅くなりませんか。 A. 新着パッケージを数日置いてから取り込む運用は、緊急のセキュリティ修正を除けば、通常の開発速度にほとんど影響しません。むしろ公開直後の最も危険な時間帯に汚染版を引くリスクを下げられます。緊急更新の例外運用を併せて決めておくのが実務的です。

Q6. すでに稼働しているシステムがあります。今から何をすべきですか。 A. まず開発会社にSBOMの提供を求め、既知の汚染パッケージとの照合手順を確認してください。同時に、CIに置いている自社認証情報の権限が最小化されているか、汚染判明時の初動が決まっているかを点検します。これらは新規開発でなくても着手できます。

Q7. 社内に技術者がいなくても、これらの確認はできますか。 A. できます。本記事の質問テンプレートを開発会社に渡し、回答の具体性を見るだけで、相手の成熟度は判断できます。回答の技術的な妥当性に不安があれば、第三者に発注前チェックやセカンドオピニオンを依頼するのが確実です。

まとめ

GitGuardianが7月22日に総括した4件の供給網攻撃（Hades・偽決済SDK・jscrambler・AsyncAPI）は、いずれも「開発者が普段行うパッケージの取り込み」を突破口にしていました。外注していても、その汚染は自社製品を通じて発注側に返ってきます。守れているかを確認する回路が自社になければ、汚染が起きたことにすら気づけません。依存管理・CI秘密情報・SBOM・ロックファイルという4つの軸で、任せている開発会社に「やっているか」を問う——それが、手を動かさない立場の経営者にできる最も費用対効果の高い防御です。

参考文献

• GitGuardian「Shai-Hulud, npm & PyPI Supply Chain Attacks（総括レポート、2026年7月22日公開）」 https://blog.gitguardian.com/shai-hulud-npm-pypi-supply-chain-attacks/ （ベンダー調査による準一次情報。個別攻撃の時期・件数・ダウンロード数は同レポート記載の範囲に基づく）