🔐

GitHub サプライチェーン攻撃が怖すぎるので Socket.dev を試してみた

に公開
GitHub
npm
Security
socket
tech

はじめに

GitHub 周辺のサプライチェーン攻撃への対策として Socket.dev を導入してみました。

試した結果、Free プランでも個人開発ならそこそこ使えそうだったので、しばらく使ってみることにしました。

背景

最近、GitHub 周辺のサプライチェーン攻撃について、かなり暗澹とした気持ちで過ごしています。

手口が巧妙で、しかもかなりメジャーなパッケージやツールまで侵害されていて「こんなんどうすりゃいいんだ、、」と思っています。

直近の代表的なものだけでも、以下のようなものがありました。

  • 2026年3月の Axios npm パッケージ侵害
  • TeamPCP 系の攻撃による Trivy、LiteLLM、Checkmarx、Telnyx などの侵害
  • 2026年5月の TanStack 関連 npm パッケージ侵害
  • 悪意ある VS Code 拡張機能をきっかけにした、GitHub 内部リポジトリへの不正アクセス

GitHub内部リポジトリへの侵害は「いよいよここに極まれり」感がありました。。。

一応、クールダウンの設定や install script の制御などはとりあえずやっていますが、特にクールダウンは「新しすぎる package」を避ける代わりに脆弱性修正の取り込みも遅らせるので、方針として少し違和感があります。

正直、リスクの置き場所を変えているだけで、セキュリティ全体のレベルが上がっている感じがあまりしません。

そこで今回は、たまたま X の以下のポストで見かけた Socket.dev を試してみることにしました。

https://x.com/etharp5/status/2057242969527214435?s=20

https://socket.dev/

Socket の概要

調べてみたところ、Socket は依存パッケージの振る舞いやリスクシグナルを見て、OSS サプライチェーン攻撃を検知・ブロックするためのサービスのようです。

Socket が見ているシグナルは、サプライチェーン攻撃向けにかなり寄っています。

  • install script: postinstall など、インストール時にコードを実行する仕組みが入っていないか。
  • 権限の強い挙動: shell 実行、ネットワークアクセス、ファイルシステムアクセス、環境変数アクセスなどがないか。
  • パッケージの素性: typosquat、既知 malware、最近公開されたパッケージ、HTTP/GitHub/Git 依存などではないか。
  • メンテナンス状況: deprecated、長期間更新されていない、所有者が不安定といった兆候がないか。
  • コードの不審さ: 難読化、minify されたコード、怪しい文字列、telemetry、protestware 的な挙動がないか。

このあたりを見るなら、cooldown のように「何日待つか」だけで守るよりも、依存関係の中身を見て判断できそうなのが気になりました。単に「新しいから待つ」よりは納得感があります。

ざっくり見ると、主な機能は以下のような感じです。

  • Socket for GitHub: GitHub App として入れて、PR 上の依存関係変更をチェックする。
  • Socket Firewall: パッケージのインストール時にリクエストを検査し、危険な依存関係をブロックする。
  • Socket CLI: ターミナルや CI から Socket のスキャンやポリシーチェックを実行する。

今回はこのうち、Socket Firewall と GitHub 連携を試してみます。

Socket Firewall を試す

Socket Firewall は、package manager の install command の前に sfw を付けて使います。

Free 版は API key や設定ファイルなしで使えるので、まず試すだけならかなり導入しやすいです。

手順は公式 docs の Socket Firewall Free にあります。

https://docs.socket.dev/docs/socket-firewall-free

まず sfw をインストールします。

今回は WSL 上で試すので、Linux x86_64 向けの binary を入れます。

curl -L -o sfw https://github.com/SocketDev/sfw-free/releases/latest/download/sfw-free-linux-x86_64
chmod +x sfw
sudo mv sfw /usr/local/bin/

pnpm で試す

インストール後は、普段の package manager command の前に sfw を付けます。たとえば pnpm なら、以下のような形です。

sfw pnpm install

最初に既存プロジェクトでそのまま実行したところ、以下のようになりました。

Protected by Socket Firewall
Lockfile is up to date, resolution step is skipped
Already up to date
Done in 873ms using pnpm v10.32.1

=== Socket Firewall ===

Warning: Socket Firewall did not detect any package fetch attempts

Already up to date なので package の取得がなく、Socket Firewall 側でも fetch attempt が検出されていないようです。

次に node_modules を削除して、実際に package の取得が発生する状態でもう一度インストールしてみると、以下のように表示されました。

Protected by Socket Firewall
Downloading @biomejs/cli-linux-x64@2.4.15: 19.63 MB/19.63 MB, done
Downloading @rolldown/binding-linux-x64-gnu@1.0.2: 8.82 MB/8.82 MB, done
Packages: +197
Progress: resolved 284, reused 165, downloaded 38, added 197, done

Done in 6.5s using pnpm v10.32.1

=== Socket Firewall ===

 - 38 packages fetched successfully

今回は downloaded 38 になり、Socket Firewall 側でも 38 packages fetched successfully と出ました。これを見る限り、sfw 経由で pnpm の package fetch を検出できていそうです。

Dockerfile と CI に入れる

ちなみに、本番デプロイ時にも sfw を通したいので、Dockerfile 側にも以下のように入れておきました。

RUN apt-get update \
    && apt-get install -y --no-install-recommends ca-certificates curl \
    && curl -fsSL -o /usr/local/bin/sfw \
        https://github.com/SocketDev/sfw-free/releases/latest/download/sfw-free-linux-x86_64 \
    && chmod +x /usr/local/bin/sfw \
    && rm -rf /var/lib/apt/lists/*

RUN sfw pnpm install --frozen-lockfile

また、CI でも依存関係の install をしているので、GitHub Actions 側にも sfw を入れておきました。

- uses: socketdev/action@v1
  with:
    mode: firewall

- run: sfw pnpm install --frozen-lockfile

セキュリティ対策として入れているものなので、実運用では socketdev/action@v1 のようなタグ指定だけでなく、commit SHA で pin することも検討した方がよさそうです。

uv で試す

ちなみに、Python の uv でも sfw uv sync --frozen を試したところ、一度 CI が落ちました。

最初は Python package がブロックされたのかと思ったのですが、原因は別でした。CI が node:20-bookworm コンテナ上で動いていて Python 3.13 が入っていなかったため、uv sync が Python 本体を python-build-standalone の GitHub Releases から取得しようとしていました。その通信も sfw 経由になり、以下のような証明書エラーになっていました。

Failed to download https://github.com/astral-sh/python-build-standalone/...
invalid peer certificate: UnknownIssuer

対応として、uv に Python のインストールまで任せるのをやめました。CI の最初に actions/setup-python で Python 3.13 を用意し、その状態で sfw uv sync --frozen を実行するようにしたところ、CI は通りました。

uv で指定した Python version まで用意できるのはかなり便利なので少しもったいないのですが、現時点では CI 側で Python を先に入れておく方が安定しそうです。

uv と組み合わせる場合は、依存 package だけでなく Python runtime の自動取得まで sfw 配下に入ることがあるので、CI では Python を先に明示的に入れておく方が挙動が読みやすそうです。

GitHub 連携を試す

Socket for GitHub は、GitHub App としてリポジトリに入れるだけで使えます。

設定では、おおまかに以下をやります。

  • Socket Security App を GitHub にインストールする
  • 対象の organization / repository を選ぶ
  • PR や default branch の scan 結果を確認する

SocketのGitHub連携
Socket の GitHub 連携画面

実際には、GitHub に Socket Security App をインストールして対象リポジトリを選んだあと、Socket 側の Organization 作成画面に遷移しました。

SocketのOrganization設定
Socket の Organization 設定画面

この設定を済ませると、Socket のダッシュボードのような画面が開きました。

設定後は、依存関係を変更した PR に Socket のチェックが出るようになります。

GitHub PR 上の Socket チェック
GitHub PR 上の Socket チェック

公式 docs を見る限り、Project Report は commit に対して生成されるプロジェクト単位のレポートで、Pull Request Alerts は PR の変更内容に対して依存関係のリスクを通知するレポートのようです。

Free プランでできること

とりあえず触ってみるだけなら、Free プランでもかなり試せそうです。

公式の Pricing を見ると、Free プランは $0 で、以下が含まれています。

  • 無制限の developers / repositories
  • 月 1,000 scans
  • malware、vulnerability、license など 70+ risk types の検出
  • 悪意ある依存関係の自動ブロック
  • 隠れた依存関係の挙動を flag する AI analysis
  • GitHub 連携
  • Socket Firewall

ただし、Free プランには月 1,000 scans、3 members、1 repository label といった制限があります。

Socket Firewall Free も別途用意されていて、API key や設定ファイルなしで使えるようです。sfw を package manager command の前につけるだけで、インストール時に malicious package をブロックできます。

https://docs.socket.dev/docs/socket-firewall-free

Firewall Free の対象は、JavaScript / TypeScript では npm、yarn、pnpm、Python では pip、uv、Rust では cargo です。

ただし Free の Firewall にはいくつか制限があります。public registry 向け、wrapper mode のみ、dashboard 連携なし、未知の package はブロックしない、といったものです。また、AI が検出した未確認の malware は warning 表示にとどまり、human review 済みの confirmed malware だけがブロック対象になるようです。

使ってみた所感

ここまで試した限りでは、導入自体はかなり簡単で、個人開発でも使いやすそうに感じました。

一方で、気になったのは誤検知された場合にどうなるのかです。私が試した範囲では誤検知には遭遇していませんが、運用するならここは気になります。

ただ、前述したように Socket Firewall Free では AI が検出しただけの malware は warning にとどまり、human review 済みの confirmed malware だけが block されるようなので、ここはかなり安心感がありました。

GitHub 連携の PR alert については、PR コメントで @SocketSecurity ignore package-name@version のように書くことで、特定の dependency alert を ignore できるようです。

ただし、この bot command は PR コメントの先頭に書く必要があり、repository contributor による main pull request thread のコメントでのみ有効なようです。

まとめ

Socket.dev を試してみて、「好き!!」って感じでした。

Socket Firewall Free は API key や設定ファイルなしで使えます。GitHub App もリポジトリにインストールするだけなので、どちらもかなり簡単に試せました。それでいて、install 時や PR 時に怪しい依存関係を見てくれるのはかなり安心感がありました。

また、Socket のダッシュボードで複数リポジトリを横断して見られるのもよかったです。最近はバイブコーディングで複数のアプリを並行して作ることも増えているので、個人開発でもこういう横断的な可視化はかなり助かる気がします。

まずは 1 つのプロジェクトに入れて様子を見ていますが、よさそうであれば他のプロジェクトにも広げていきたいです。公式を見ると MCP server、VS Code 拡張、Chrome 拡張など周辺機能もいろいろありそうなので、そのあたりも引き続き調べてみたいと思います。

以上です。ありがとうございました。

Discussion