socket.devとは？npm/PyPIのサプライチェーン攻撃を防ぐ仕組みと料金

socket.dev（ソケット）は、npmやPyPIに公開された第三者パッケージの「振る舞い」を解析し、マルウェア化した依存をインストール前に止めるサプライチェーンセキュリティのツールです。既知の脆弱性（CVE）を後から知らせる従来型スキャナとは検知の起点が異なり、2025年9月に発生した自己増殖ワームShai-Huludのような未知の攻撃にも、パッケージ公開直後のPR段階で反応します。この記事では、socket.devの仕組みと検知できるリスク、DependabotやSnykとの役割分担、GitHub App・CLI・Socket Firewallの導入形態、4プランの料金、そして導入が向く組織と過剰になる場面までを、公式情報と実際の攻撃事例に基づいて整理します。

socket.devの仕組み・料金・他ツール併用の要点整理

socket.devの核心は、CVEデータベースとの照合ではなく、パッケージのコードと公開状況そのものを見て「悪意ある振る舞い」を見つける点にあります。難読化されたコード、インストール時に走るスクリプト、ファイルシステムや外部通信への不審なアクセスなど70種類超のシグナルを評価し、危険な依存はPRやインストールの時点でブロックします。これにより、CVEがまだ採番されていない攻撃にも対応できます。

料金はFree（無料）からEnterprise（要問い合わせ）まで4段階で、無料プランでも悪性パッケージの自動ブロックとAI解析が使えます。実務上の結論はシンプルです。DependabotやSnykのようなCVE型ツールを置き換えるのではなく、それらが取りこぼす「未知のマルウェア」を塞ぐ補完層として併用するのが現実的な使い方です。まずは無料プランかOSS向けの無料枠で導入し、月1,000スキャンの上限に当たる規模になったら有料プランを検討する——この順序で十分です。

socket.devとはnpm/PyPIの依存を狙う攻撃を防ぐ防御ツール

現代のアプリは、コードの大半を第三者のオープンソースパッケージに頼っています。socket.devは、その第三者依存に的を絞って安全性を判定するツールです。2020年に、Stanfordでウェブセキュリティを教えていたOSSメンテナのFeross Aboukhadijeh氏が創業し、2026年にはSeries Cで6,000万ドルを調達、評価額は10億ドルに達しました（累計調達額は1.25億ドル）。SOC 2 Type IIにも準拠しています。

自分のコードではなく第三者依存の挙動を解析するsocketの設計思想

一般的な静的解析ツールが自社コードの欠陥を探すのに対し、socket.devが見るのはpackage.jsonやpackage-lock.jsonに並ぶ第三者パッケージの中身です。socketに送られるのは依存リスト（マニフェスト）だけで、利用者のソースコードは端末やCI環境から外に出ません。攻撃者が狙うのは、自分たちが書いたコードよりも、無防備に取り込まれる依存ツリーの奥です。だからこそ「他人の書いたコードを読む」という設計が効きます。

install scriptや特権API呼び出しを含む70種類超のリスク検知

socketが評価するシグナルは70種類を超えます。代表例は、インストール時に自動実行されるpreinstallやpostinstallスクリプト、難読化されたコード、外部サーバーへのデータ送信、そしてchild_processやeval()といった特権的なAPI呼び出しの突然の追加です。マイナーバージョンやパッチ更新でこれらが紛れ込むと、CVEベースのスキャナはまず見逃します。socketは更新のたびに差分を解析し、不審な挙動が増えていれば警告を出します。

Supply Chainなど5カテゴリ100点満点のパッケージスコア

各パッケージは、Supply Chain Security・Vulnerability・Quality・Maintenance・Licenseの5カテゴリで100点満点採点されます。たとえばReactのパッケージページではSupply Chain SecurityとVulnerabilityがいずれも100点と表示され、未知のパッケージでも導入前にリスクの全体像をつかめます。npm公式のパッケージページにも「Analyze security with Socket」のリンクが追加されており、ブラウザ上で依存の健全性を確認できます。

npm・PyPIを軸にGo/Ruby等へ広がる対応エコシステムの差

振る舞い解析が最も深いのはnpm（JavaScript／TypeScript）とPyPI（Python）の2つです。Go、Ruby、Maven、Cargo、NuGetなど10以上の言語にも対応しますが、こちらは脆弱性とサプライチェーンの広めのカバレッジが中心で、npm／PyPIほどの深さはありません。判断の目安として、依存の中心がnpmかPyPIならsocketの強みを最大限に引き出せます。逆に主戦場がGoやRubyだけなら、効果は限定的になります。

CVE型スキャナでは防げない攻撃をsocketが検知する仕組み

従来のSCA（ソフトウェア構成解析）ツールの多くは、公表済みのCVEと依存バージョンを突き合わせます。この方式の弱点は明確です。攻撃者が悪意あるコードを仕込んだ「まだ誰も脆弱性として報告していないパッケージ」には反応できません。socketはここを別のアプローチで埋めます。

既知CVEの事後通知と未知マルウェアの即時検知という根本的な違い

CVEは、脆弱性が発見・報告・採番されて初めて世に出ます。つまり通知は常に「事後」です。一方、サプライチェーン攻撃の多くは、正規パッケージが乗っ取られて悪性版が公開された瞬間から被害が始まります。socketは公開されたコードの振る舞いを直接見るため、CVEの採番を待たずに「このパッケージは情報を盗み出そうとしている」と判定できます。検知の起点が「報告」ではなく「挙動」である点が、両者を分ける本質です。

1〜2文字違いを捉えるtyposquatting等の検知判定基準

typosquatting（タイポスクワッティング）は、人気パッケージと紛らわしい名前を登録して誤インストールを狙う手口です。socketはこれを機械的な基準で判定します。パッケージ名が人気パッケージと1〜2文字違いで、かつ正規版の月間ダウンロード数が1,000倍以上多い場合に、タイポスクワットとして扱います。たとえばbrowserifyに対するbowserifyのような偽パッケージが該当します。dependency confusion（依存混同）も同じく検知対象です。

新規メンテナや公開順の異常を捉えるサイドチャネル検知の中身

悪用の兆候は、コードの外側にも現れます。socketは「unstable ownership」、つまり既存パッケージに新しいメンテナが公開権限を与えられた状態を検知します。アカウント乗っ取りの直後に起きやすい変化だからです。さらに、公開順序の異常——攻撃者がいまだ利用の多い古いメジャーバージョンに新しいパッチを後出しする——も捉えます。コードだけを見ていては気づけない、運用上のシグナルを拾う設計です。

パッケージ公開直後にPR上で疑わしい依存を遮断する検知速度

socketは依存を追加・更新するPRごとにセキュリティレポートを自動で残し、危険と判断した依存はマージ前にブロックします。公開から数分単位で新しいパッケージを解析するため、攻撃者が悪性版を投入してから開発者が気づくまでの空白を縮められます。後述するShai-Hulud 2.0では実際に、socketが影響パッケージの一覧を継続更新し、被害の封じ込めに使われました。

Shai-Hulud等2025〜2026年のnpm攻撃事例とsocketの検知実績

socketが「なぜ必要か」は、抽象論よりも実際の事件で語るほうが早く伝わります。2025年から2026年にかけてnpmを襲った一連の攻撃は、CVE型スキャナの限界と、振る舞い検知の意義を同時に示しました。

自己増殖ワームShai-Hulud（2025年9月）が500超を汚染した手口

Shai-Hulud（シャイ・フルード、Dune由来の砂虫の名）は、npmエコシステム史上初の自己増殖ワームとして2025年9月に出現しました。週200万ダウンロードを超える@ctrl/tinycolorを含む500以上のパッケージが汚染されています。手口はこうです。npmのセキュリティ警告を装ったフィッシングメールでメンテナの認証情報を奪い、そのトークンで同じメンテナの他パッケージへ悪性コードを注入して公開する。さらにTruffleHogでAWS・GCP・Azureの認証情報を探し、被害者アカウント配下に「Shai-Hulud」という公開リポジトリを作って窃取した秘密情報をさらします。米CISAは2025年9月23日に注意喚起を出しました。

preinstall実行で被害が拡大したShai-Hulud 2.0（2025年11月）

2025年11月、Shai-Hulud 2.0と呼ばれる再来が観測されました。トロイの木馬化したパッケージは11月21〜23日にかけてnpmへ投入されています。最大の変化は実行タイミングで、従来のpostinstallからpreinstallへ移ったことです。これにより、開発者の端末だけでなくCI/CDパイプラインまで被害範囲が一気に広がりました。Wizの調査では、認証情報が25,000を超えるリポジトリに露出したと報告されています。Node.jsエコシステムを基盤とする開発現場にとって、依存の更新が即リスクになる構図が改めて浮き彫りになりました。Node.jsの脆弱性と同様に、影響の早期把握と認証情報のローテーションが対応の起点になります。

ソース流出後に派生したMiasma・Hades等2026年の亜種

事態は2026年に入っても収束していません。2026年5月、Shai-Huludを操っていたとされるグループがワームのソースコードを公開し、まもなくクローンが現れました。6月1日以降はMiasmaやHadesと名付けられた亜種が、npmとPyPIをまたいで連鎖的に使われています。2026年2月には「SANDWORM_MODE」と名付けられた別系統のnpmワームも確認され、socketの研究チームがDune由来の命名を引き継いだ系譜だと指摘しました。ソース流出によって攻撃の参入障壁が下がった以上、単発の対処ではなく継続的な監視が前提になります。

影響パッケージ一覧の公開などsocketが攻撃追跡で担った役割

これら一連の攻撃で、socketは影響を受けたパッケージの一覧を継続的に公開し、対応の指針を提供してきました。Shai-Hulud初動の2025年9月16日には、CrowdStrike関連のnpmパッケージへの攻撃をいち早く報告しています。2026年3月にはPyPIのlitellmに混入したマルウェアを解析し、危険性を警告しました。こうした「脅威インテリジェンスを自前で出し、製品の検知に即反映する」サイクルが、Shai-Huludのような前例なき攻撃への反応速度を支えています。なお、2021年のLog4ShellのようなCVE型の脆弱性は依然として重要ですが、性質が異なります（詳細はLog4Shell（Log4j2の脆弱性）を参照）。

DependabotやSnykなど既存ツールとsocketの役割分担

socketを検討する際に最初に整理すべきは、「既存のDependabotやSnykを置き換えるのか」という点です。結論を先に言えば、置き換えではなく併用が妥当です。守備範囲が重ならないからです。

Dependabotの既知CVE通知とsocketの振る舞い遮断の違い

GitHub標準のDependabotは、既知CVEに該当する依存を検出し、更新用のPRを自動で出してくれます。あくまで「公表済みの脆弱性」が対象です。対してsocketは、CVEになる前のマルウェア的な振る舞いをPR時点で遮断します。両者は時間軸が違い、Dependabotは「報告済みの穴をふさぐ」、socketは「これから穴になりそうな依存を入れない」役割を担います。Dependabotの基本動作を整理したい場合はDependabotとGitHub Actionsの基本もあわせて確認すると、両者の補完関係が理解しやすくなります。

GitHub Advanced Securityやコードスキャンとの守備範囲の差

GitHub Advanced Security（GHAS）は、シークレットスキャン、依存関係レビュー、コードスキャン（SAST）を束ねたGitHub純正のセキュリティ機能群です。これらは主に自社コードと、既知の依存リスクを対象にします。socketが見るのは、その依存パッケージ「中身の悪性挙動」という別レイヤーです。GitHub Advanced Securityの機能やGitHub Code Scanningを導入済みの組織でも、サプライチェーン攻撃の検知だけはsocketで補う、という構成が成り立ちます。

CVE修正のSnykとマルウェア遮断のsocketを併用する理由

SnykのOpen Source製品は、CVE中心のSCAに自動修正PRを組み合わせた構成です。socketは挙動ベースのサプライチェーン攻撃検知に特化しています。多くのチームは両方を使います。既知の脆弱性はSnykで修正ワークフローに乗せ、未知の悪性パッケージはsocketがマージ前に止める——この分担なら、片方では埋まらない穴がふさがります。「どちらか一方で十分」と考えると、必ずどちらかの死角が残ります。

CVE型ツールと振る舞い型socketの違いを整理する比較表

両者の性格の違いを表に整理します。検知の起点・タイミング・苦手分野が対照的で、競合というより役割分担の関係にあることが見て取れます。

表のとおり、両者は埋める穴が違います。既存のCVE型ツールを残したまま、socketを「サプライチェーン攻撃の最後の関所」として足すのが、実務で破綻しにくい構成です。

GitHub App・CLI・Socket Firewallの導入形態と選び方

socketには複数の入り口があり、開発ライフサイクルのどこを守りたいかで選び分けます。PRで止めたいのか、開発者の端末で止めたいのか、AIエージェントが追加する依存まで見たいのか——目的を先に決めると迷いません。

PRへ自動でレポートを返すSocket for GitHubの最短導入

最短の導入は、GitHub MarketplaceからSocket for GitHubアプリを追加し、監視対象のリポジトリを選ぶだけです。依存を変更するPRが立つたびに、socketが自動でパッケージを解析し、リスクがあればコメントとしてレポートを残します。組織レベルでセキュリティポリシーを設定できるため、リポジトリごとに設定ファイルを置く必要はありません。まずPR段階のガードを固めたいなら、この経路が最も負担の少ない選択です。

npm/yarn/pnpm/pipをラップしCIを止めるSocket CLI

ローカル開発やCIでの遮断には、Socket CLIを使います。npmならnpm install -g @socketsecurity/cliで導入し、socket scan createでスキャンを実行できます。CLIはnpm・yarn・pnpm・pipといったパッケージマネージャをラップし、危険な依存を検知するとパイプラインのステップを非ゼロ終了で失敗させます。GitHub以外のCI環境やマージ前チェックを止めたいケースで効きます。pnpmを使ったプロジェクト構成についてはpnpmでのバージョン管理もあわせて参考になります。

プロキシでインストール時に依存を遮断するSocket Firewall

Socket Firewallは、パッケージマネージャの前段にHTTP/HTTPSプロキシとして座り、ネットワーク通信を傍受して悪性依存をインストール時に遮断する仕組みです。出力をスクレイピングするのではなく、通信そのものを止める点が特徴で、開発者の端末やビルドシステムに悪性パッケージが届く前に防げます。4つのエコシステムに対応し、self-hostedやクライアント／サーバー構成での運用も選べます。PRより手前、依存が降りてくる経路そのものを塞ぎたい組織向けです。

MCPサーバ経由でAIエージェントが追加する依存を検証する連携

AIによるコード生成が増えると、人間がレビューしないまま依存が追加されるリスクが上がります。socketはMCPサーバ（depscoreツール）を提供し、mcp.socket.devの公開エンドポイント経由でClaude、VS Code Copilot、Cursorなどから依存スコアを問い合わせられます。AIアシスタントに「新しい依存を追加する前に必ずスコアを確認し、低ければ代替を検討する」というルールを持たせれば、生成AI時代の依存追加にもガードをかけられます。

socket.devの4プラン料金と無料枠で始める際の判断基準

socketの料金は機能と規模で段階化されています。無料でも実用的なため、まず使ってから判断できます。価格は変動するため、予算化の前に公式のpricingページで最新の数値を確認してください。

Free $0からEnterprise要問合せまで4プランの料金実額と年払い

プランはFree・Team・Business・Enterpriseの4段階です。Freeは月額0ドルで、開発者数とリポジトリ数は無制限、ただしスキャンは月1,000回・メンバー3名までという制限があります。Teamは開発者1人あたり月25ドルで、スキャンが月5,000回に増え、reachability解析やSlack通知が付きます。Businessは1人あたり月50ドルで、スキャンとAPIが無制限になり、SBOMの入出力・SSO/SAML・GitHub ActionsやAIモデルのスキャンが加わります。Enterpriseは要問い合わせで、関数レベルのreachabilityやGitLab・Bitbucket・Azure DevOps連携、SCIMなどが含まれます。年払いなら最大20%割引です。なお、オープンソースプロジェクトは恒久的に無料で、申請すれば無料のTeam枠も利用できます。

過去90日にコミットした人を数える「developer」課金の仕組み

課金の単位となる「developer」は、socketがスキャンする組織リポジトリに過去90日以内にコミットした人を指します。在籍人数ではなく実際にコードを触った人数で数えるため、見積もりの際はアクティブなコミッター数を基準にします。支払いはStripe経由のクレジット／デビットカード（EnterpriseはほかにACH/Wireも可）で、価格は税込表示です。前述のとおりソースコードは送信されず、課金対象はあくまで依存の解析範囲です。

1,000スキャン/月の無料枠で足りる規模と超える規模の線引き

無料枠の1,000スキャン/月で足りるかどうかが、最初の分岐点です。依存の更新頻度が低い個人開発や小規模チームなら、Freeのままで運用できます。一方、複数パッケージを抱えるモノレポや、依存を頻繁に更新する高頻度のCI/CDでは、月1,000回はすぐに使い切ります。この場合はTeamへの引き上げが必要になります。判断基準は人数ではなく、CIが回す月間スキャン回数だと考えてください。

関数レベルreachabilityでCVEを最大90%削減する上位プラン

socketは2025年4月にCoanaを買収し、reachability解析を取り込みました。これは「脆弱性が存在するか」だけでなく「自分のコードからその脆弱性に実際に到達するか」まで判定する技術です。socketの公称値では、TeamのreachabilityでCVEの誤検知を約60%、Enterpriseの関数レベルreachabilityでは最大90%削減できるとされています。アラート疲れに悩むチームほど、上位プランの恩恵が大きくなります。これらは公称値のため、自社環境での効果は試用で確かめるのが安全です。

socket.devの導入効果が高い組織と過剰になりやすい場面

socketは万能ではありません。効果が大きい組織と、導入しても持て余す組織がはっきり分かれます。ここは曖昧にせず、条件で線を引きます。

OSS依存とnpm/PyPIのCI利用が多い組織で効果が高い理由

効果が最も高いのは、npmやPyPIのパッケージを大量に抱え、依存を頻繁に更新する組織です。依存ツリーが深いほど攻撃面は広がり、人手のレビューでは追いつきません。PRの数が多く、CI/CDで日常的にパッケージを取り込むチームでは、socketのPR時遮断とFirewallが目に見えて効きます。Shai-Hulud 2.0がCI/CDを直撃した事実を踏まえれば、自動化が進んだ現場ほど守る価値があります。

依存が少なく主言語がGo/Ruby中心の構成で過剰になる理由

逆に、外部依存がごく少ない小規模アプリや、主言語がGoやRuby中心の構成では、socketは過剰になりがちです。深い振る舞い解析が効くのはnpmとPyPIであり、それ以外のエコシステムは広めのカバレッジにとどまるためです。依存の数が限られていて手動レビューで回せる規模なら、有料プランの費用に見合うリターンは得にくいでしょう。この場合は無料プランで様子を見るか、導入を見送る判断も妥当です。

モノレポで月1,000スキャンを超え無料枠が破綻する失敗例

導入でつまずく典型は、無料枠のまま大規模モノレポに適用してしまうケースです。依存更新のたびにスキャンが消費され、月1,000回の上限を月の途中で使い切り、肝心のPRで解析が止まる——これが起こると、入れたつもりのガードが穴になります。もう一つの失敗は、組織レベルのセキュリティポリシーを設定せずにアラートを放置するパターンです。検知できても運用が伴わなければ意味がありません。規模に応じたプラン選定と、ブロックか警告かのポリシー設計を最初に決めておくべきです。

socket.devに関するよくある質問

socket.devの導入検討でよく挙がる疑問を、5つにまとめて回答します。

socket.devは無料で使えますか？

はい、無料で使えます。オープンソースプロジェクトは恒久的に無料で、申請すれば無料のTeam枠も利用できます。一般のFreeプランは月額0ドルで、開発者数とリポジトリ数は無制限ですが、スキャンは月1,000回・メンバー3名までという上限があります。私的リポジトリで本格運用する場合や、月1,000スキャンを超える規模では、開発者1人あたり月25ドルのTeam以上が必要です。料金は変動するため、最終的な数値は公式pricingページで確認してください。

socket.devとsocket.ioは同じものですか？

まったくの別物です。socket.ioは、ブラウザとサーバー間のリアルタイム双方向通信を実現するJavaScriptライブラリで、チャットや通知などの機能に使われます。一方socket.devは、npmやPyPIの依存を解析するサプライチェーンセキュリティのサービスです。名前が似ているうえ「socket」という語が通信プログラミングやSSL（secure socket layer）でも使われるため混同されやすいですが、用途も提供形態も異なります。本記事で扱うのは後者のsocket.devです。

socket.devは日本語に対応していますか？

2026年6月時点で、socket.devの管理画面やドキュメント、アラートの種別表記は英語が中心です。日本語の公式UIは限定的で、リスク名やスコアのカテゴリ（Supply Chain Securityなど）も英語で表示されます。実運用上は、検知されたアラートの種別を社内で読み解ける体制があれば支障は小さいものの、日本語UIを前提とする現場では事前に確認しておくと安心です。最新の対応状況は公式情報で確認してください。

自社のソースコードはsocketに送信されますか？

いいえ、送信されません。socketが受け取るのは、package.jsonなどのマニフェスト、つまり依存パッケージのリストだけです。利用者が書いたソースコード自体は、端末やCI環境から外に出ない設計になっています。socketが解析するのは公開されているオープンソースの第三者パッケージであり、利用者の独自コードや顧客の個人情報（PII）は扱いません。秘匿性の高いコードベースでも導入しやすい点が特徴です。

DependabotやSnykを使っていればsocket.devは不要ですか？

役割が異なるため、不要とは言えません。DependabotやSnykは公表済みのCVE（既知の脆弱性）を対象とし、修正PRや更新を支援します。これに対しsocketは、CVEになる前のマルウェア的な振る舞いや、メンテナアカウントの乗っ取りといった未知のサプライチェーン攻撃を検知します。Shai-Huludのように報告前から被害が広がる攻撃には、CVE型ツールだけでは反応できません。既知の脆弱性はDependabot／Snyk、未知の悪性パッケージはsocket、という併用が現実的な構成です。

関連記事

• DependabotとGitHub Actionsの基本概念：既知CVEを通知するDependabotの仕組みを押さえると、socketとの役割分担が理解しやすくなります。
• GitHub Advanced Securityの主要機能：GitHub純正のセキュリティ機能群と、socketが補うサプライチェーン領域の違いがわかります。
• GitHub Code Scanningとは：自社コードを対象とするSASTの位置づけを知ると、依存解析との守備範囲の差が明確になります。
• Node.jsの高深刻度脆弱性：npmエコシステムの土台であるNode.js側の脆弱性対応の考え方を補完できます。
• Log4Shell（Log4j2の脆弱性）：CVE型の代表的なサプライチェーン関連事例として、振る舞い検知との違いを比較できます。