SpiderFootとは｜OSINT自動化ツールの現在地——本家は2023年で停止、自社ドメインで実測

「SpiderFoot」は、ドメイン名やIPアドレスを1つ入力するだけで、多数の公開情報源に自動で問い合わせて結果を1か所に集約するOSINT（オープンソースインテリジェンス）自動化ツールだ。GitHubスター21,520・MITライセンス・Python 3製で、Kali Linux にも標準パッケージとして入っている。ただし日本語の解説記事はKali 2021年前後で時計が止まっており、このツールが今どういう状態にあるのか——本家の開発が動いているのか、どのバージョンのPythonなら入るのか、APIキーを1つも持っていない人が実際に何を得られるのか——に答えているものが見当たらない。そこで本日、公式リポジトリの実データをGitHub APIで取り、手元のmacOSに入れて当サイトが管理する自社ドメイン1本に対して実際に走らせた結果をまとめる。

外から見えている資産の棚卸しは、依存パッケージ側の点検とセットで初めて意味を持つ。取り込む側の経路についてはサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説で扱っている。本記事は「外に出ている自分の情報を、自分で見に行く」側の話だ。

SpiderFootとは——230モジュールが公開情報源を手分けして叩く仕組み

SpiderFootの情報収集の設計は素直だ。利用者が「調べる起点」を1つ与えると、それがイベントとしてモジュール群に配信される。あるモジュールが「ドメイン名」を受け取ってIPアドレスを吐き出すと、そのIPアドレスが新しいイベントとして別のモジュールに配られ、そこからさらに別の事実が出てくる。README はこれを publisher/subscriber モデルと表現している。

起点として指定できるのは、ドメイン／サブドメイン名、ホスト名、IPアドレス、ネットワークサブネット（CIDR）、ASN、メールアドレス、電話番号、ユーザー名、人名、Bitcoinアドレスだ。

READMEは「Over 200 modules」と書く。実際に数えると modules/sfp_*.py は233ファイルあるが、sf.py -M が一覧に出すのは230個だった。差の3個は内訳がはっきりしている——sfp__stor_db と sfp__stor_stdout は結果を保存・出力するための内部モジュール、sfp_template は自作モジュールを書くときの雛形だ。つまり「200を超える」という公称値は正しく、実数は230である。

同様に相関エンジンのルールは README が「37 pre-defined rules」と書いているが、correlations/ 配下の YAML は実測で38本あった。1本ぶんの差は README の更新漏れとみられる。

APIキー無しで動く範囲はどこまでか

外部サービス依存のモジュール（Shodan、HaveIBeenPwned、GreyNoise、SecurityTrails など）はAPIキーが要る。設定項目にAPIキーを持つモジュールを機械的に数えると、230個のうち83個だった。残る147個はキー無しで動作する。

本記事の検証ではキーを1つも新規取得していない。それでもDNSレコードの解決、IPv4／IPv6アドレスの特定、WHOIS情報の取得、証明書透明性ログの照会、逆引き、国名の解決といった基礎的な事実は取れた。「キーを揃えないと何もできないツール」ではないというのが実測の結論だ。

メンテナンス状況——masterは2023年11月で止まり、会社はIntel 471の傘下にある

ここが本記事のいちばん伝えたい部分だ。SpiderFootはスター21,520・フォーク3,471という規模のプロジェクトで、Kali Linux にも入っているため「現役の定番ツール」に見える。しかし公式リポジトリの実データはそう言っていない。

2026年8月30日時点でGitHub APIから取った値は次のとおり。

pushed_at が2026年4月になっている点に注意したい。 リポジトリ一覧やダッシュボードで「4か月前に更新」と表示されるのはこの値だが、実際に押されたのは Dependabot が作った依存更新ブランチであって、master は2023年11月5日から1コミットも動いていない。star数や「最終更新」表示だけを見て現役と判断すると、ここを取り違える。

会社側の動き

2022年11月2日、脅威インテリジェンス企業の Intel 471 が SpiderFoot を買収したと発表している。創業者の Steve Micallef 氏は Intel 471 の Vice President of Attack Surface Technology として合流した。発表文はオープンソース版がGitHubで公開されていることに触れているが、その後の開発・保守を継続するとは書いていない。

現在の状況はURLにも表れている。READMEのバナーやリンク先である公式サイト spiderfoot.net は、本日 curl で確認したところ 301で intel471.com へリダイレクトする。README中の「SpiderFoot HX」（商用SaaS版）へのリンクも、open-source-vs-hx の比較ページも、同じく企業サイトのトップへ吸収されている。

# 実行して確認したリダイレクト（2026-08-30）
curl -sIL -A "Mozilla/5.0" http://www.spiderfoot.net | grep -Ei '^(HTTP|location)'
# HTTP/1.0 308 Permanent Redirect
# Location: https://www.spiderfoot.net/
# HTTP/2 301
# location: https://www.intel471.com/
# HTTP/2 200

SpiderFootのインストールと起動——Python 3.14では入らない、3.12なら22秒（実測）

開発が止まっているプロジェクトで最初に壊れるのは依存関係だ。SpiderFootの requirements.txt は26行あり、そのほとんどに上限ピンが付いている（lxml>=4.9.2,<5、cryptography>=3.4.8,<4、networkx>=2.6.3,<2.7、PyPDF2>=1.28.6,<2 など）。この上限は2022〜2023年時点の最新版で切られているため、新しいPythonでは事前ビルド済みのホイールが存在しない。

Python 3.14 で試した結果：失敗する

手元の既定である Python 3.14.4 で仮想環境を作り、そのまま入れると lxml のホイールビルドで落ちた。ソースからのコンパイルに進み、CPython 3.13 以降で _PyLong_AsByteArray の引数が5個から6個に変わった影響で15件のコンパイルエラーになる。

src/lxml/etree.c:270440:70: error: too few arguments to function call, expected 6, have 5
ERROR: Failed building wheel for lxml
× Failed to build installable wheels for some pyproject.toml based projects
╰─> lxml

lxml は5系以降でこの変更に追随済みだが、requirements.txt が <5 で上限を切っているため、その修正版は選ばれない。この上限ピンこそが、開発停止の実害が最初に出る場所である。

Python 3.12 で試した結果：通る

同じマシンで Python 3.12 に切り替えると、26パッケージすべてがホイールで解決し、約22秒で完了した。ビルドは1件も発生していない。

# 実際に成功した手順（macOS 14 / Apple Silicon / 2026-08-30）
git clone --depth 1 https://github.com/smicallef/spiderfoot.git
python3.12 -m venv venv
./venv/bin/pip install --no-cache-dir -r spiderfoot/requirements.txt
cd spiderfoot && ../venv/bin/python sf.py -V
# => SpiderFoot 4.0.0: Open Source Intelligence Automation.

入った cryptography は 3.4.8、lxml は 4.9.4、networkx は 2.6.3 だった。いずれも上限ピンの直下に張り付いた古い版で、cryptography 3.4.8 は2021年8月のリリースだ。依存が古いまま固定されることは、このツール自体を長期運用の基盤に据えるうえでの実務的なリスクになる。

Web UIの起動と、そこで見つかるもう1つの停止の痕跡

SpiderFootはコマンドラインだけでなく、内蔵のWebサーバーからも操作できる。-l にバインド先を渡すだけで起動する。

# Web UI を localhost だけに公開して起動
python sf.py -l 127.0.0.1:5001
# ブラウザで http://127.0.0.1:5001/ を開く

実際に起動して curl で叩くと HTTP 200 が返り、ページタイトルは SpiderFoot v4.0.0 だった。CLIで走らせたスキャン結果もそのまま同じ画面から参照できる。

ただし起動時のログに、開発停止の影響がもう1つ現れる。

Warning: passwd file contains no passwords. Authentication disabled.
Please consider adding authentication to protect this instance!
Refer to https://www.spiderfoot.net/documentation/#security.

既定では認証が無効という警告自体は正しい挙動だが、その対処法として案内されている spiderfoot.net/documentation/ を実際に開くと、301で intel471.com/documentation へ飛ばされたうえで404になる。つまりツールが自分で指し示している安全設定の手引きが、もう存在しない。

バインド先は -l に書いた値がそのまま使われる（sf.py はソース上 sfWebUiConfig['host'] = '127.0.0.1' を持つが、-l を渡さないとそもそもWebサーバーが起動しないので、実質は指定した値で決まる）。問題はリポジトリ同梱の Dockerfile が CMD ["sf.py", "-l", "0.0.0.0:5001"] になっている点で、コンテナで動かすと既定で全インターフェースに待ち受ける。認証が無効なまま到達可能なネットワークへ出せば、誰でもスキャンを起動・閲覧できる。

対策は2点。①手元で使うだけなら -l 127.0.0.1:5001 と明示する、②コンテナや共有環境で使うなら passwd ファイルに認証情報を置いたうえで、公開範囲をリバースプロキシやセキュリティグループで絞る。

影響を受ける範囲

ここまでの導入上の問題が誰に当たるのかを整理しておく。

配布経路ごとの差

なおDocker Hubには dtagdevsec/spiderfoot（220万プル）などサードパーティのイメージが複数ある。公式が用意したものではないため、使うなら中身を自分で確認する必要がある。

自社ドメインで実際に回した結果——数分では終わらず、大半が「隣の家」の情報だった

ここからが本題だ。当サイトが管理する ai-heartland.com を対象に、既定の passive（受動的）ユースケースでスキャンを実行した。APIキーは1つも設定していない。

# 実際に流したコマンド（対象は自分が管理するドメインのみ）
python sf.py -s ai-heartland.com -u passive -q -o csv > scan.csv

分かったこと1：既定のpassiveスキャンは「数分で終わる」ものではない

このスキャンで有効化されたモジュールは200個だった（スキャン設定 _modulesenabled に記録された実数）。そのうち大半はAPIキーが必要で、キーが無い場合は何も返さないまま待機・タイムアウトする。結果として、ドメイン1本の受動スキャンに874.7秒（14分35秒）かかった。スキャンのSQLiteに記録された開始・終了時刻から計算した値である。

そして実際にイベントを1件でも返したモジュールは22個だけだった。200個のうち178個は、まるまる待ち時間だけを消費して何も返していない。「とりあえず回してコーヒーを淹れて戻ってくる」という感覚だと合わない。実務では後述のようにモジュールを絞るのが前提になる。

分かったこと2：自社ドメインを指定しても、出てくる事実の大半は第三者のもの

これが最も注意すべき挙動だ。ai-heartland.com は Cloudflare の背後にあり、共有IP（104.21.2.214 / 172.67.129.182）で配信されている。SpiderFootはこのIPを解決したあと、同じIPに同居している他サイトの列挙に進む。

実測の内訳は次のとおり。生成された全632イベントのうち、種別名が「Co-Hosted（同居）」または「Affiliate（関連先）」で始まるもの——すなわち当社の資産ではない第三者に関する事実——が508件（80%）を占めた。逆に、明確に自社の資産そのものを指すイベント（ドメイン名・IPv4／IPv6アドレス・WHOIS・ネームサーバ等）はわずか16件である。

重複を除いた同居ドメイン／ホストは110件。SpiderFootはそのうち73件についてWHOIS照会を実行し、そこから「Affiliate - Email Address」として延べ83件・重複を除いて47件のメールアドレスを収集していた。さらに12件は「Blacklisted Co-Hosted Site」、3件は「Malicious Co-Hosted Site」として記録されている——これらは当社と関係のない他社のドメインである。

つまり 「自分のドメインを入れた」＝「自分の範囲だけを調べている」ではない。これは悪用の話ではなく、意図しない範囲へ手が伸びるという運用上の事実であり、対策としてモジュールを明示的に限定する必要がある。

分かったこと3：モジュールを絞れば速く、範囲も自分の資産に収まる

-m でモジュールを明示すると、挙動は一変する。DNS解決・SSL証明書・証明書透明性ログの3つに限定した実行を4回繰り返したところ、所要時間は2.7〜11.9秒、イベントは各回8件で、第三者に関するイベントは0件だった。結果は自社ドメインとそのIPv4／IPv6アドレスだけである。冒頭のFV動画がその実行の録画にあたる。

# 範囲を自分の資産に閉じる書き方
python sf.py -s ai-heartland.com \
  -m sfp_dnsresolve,sfp_sslcert,sfp_crt -q -o csv

使う前に押さえる前提——対象は自分の資産に限る

SpiderFootは README 自身が「攻撃的にも防御的にも使える」と書いているツールだ。本記事は防御側の用途、すなわち「自社が外部に何を露出しているかを自分で確認する」用途だけを扱っている。

対象範囲

・自分が管理する資産だけを対象にする。 所有しているドメイン、契約しているIPレンジ、自社の公開ホストに限る
・共有IP上の同居サイトは自分の資産ではない。 前節のとおり既定の挙動でここに手が伸びるため、モジュール選択で明示的に避ける
・個人に紐づく起点（人名・メールアドレス・電話番号・ユーザー名）は、本人の同意が無い限り使わない。 SpiderFootはこれらも起点にできるが、他人を対象にした時点で用途が変わる

法令上の位置づけ

許可のない対象に対する調査は、目的・手段によっては日本の不正アクセス禁止法（アクセス制御を回避する行為）、個人情報保護法（目的外の個人データ取得）、状況によってはストーカー規制法などに関わり得る。公開情報を見ること自体が直ちに違法になるわけではないが、「公開されているから何をしてもよい」ということにはならない。

同種のツールカタログを防御側の視点から読む話はawesome-osint-arsenal 解説｜OSINTツール集約OSSをブルーチーム視点で読む防御ガイドとRedTeam-Tools（A-poc）とは｜攻撃ツール集約OSSをブルーチーム視点で読む防御ガイドで扱っている。

SpiderFootの後継と代替——開発が続いているのはフォーク側

本家が止まっている以上、「では今から使うなら何を選ぶか」が現実的な論点になる。GitHub上のフォーク3,471本を star 順に洗ったところ、実質的に開発が継続しているものが1本あった。

poppopjmp/spiderfoot は2025年2月に作られたフォークで、スター192・フォーク31、MITライセンス。バージョンは v6.1.0（2026年6月2日）まで進んでおり、モジュール309個・相関ルール95本と本家を上回る。compare APIで確認すると本家 master より1,902コミット先行・遅れ0コミットで、本家の内容を丸ごと含んだうえで独自に伸びている。Python は 3.11+ を公称し、Docker Compose 構成・GraphQL API・Go製CLIなど本家に無い要素が加わっている。

他のツールとの比較

用途で選び分けるのが現実的だ。 「外部に出ているサブドメインや証明書を継続的に洗い出したい」なら BBOT や Amass のほうが目的に合う。「1つの起点から広く浅く、多様な情報源をまとめて当てたい」という SpiderFoot 固有の性格が必要なら、本家の状態を承知のうえで使うか、フォークを自己責任で検証して使うことになる。

まとめ

対象は自分が管理する資産に限る。この1点だけは、どのツールを選ぶかに関わらず変わらない。

参照ソース

・smicallef/spiderfoot（公式リポジトリ・README） — モジュール構成・機能一覧・v4.0の公称値。star/fork/最終コミット/ブランチ一覧はGitHub REST APIで本日取得
・Intel 471 Acquires SpiderFoot（2022-11-02 公式発表） — 買収日・Steve Micallef氏の役職・オープンソース版の位置づけ
・poppopjmp/spiderfoot — 開発継続中のフォーク。モジュール309個・相関95本・v6.1.0、本家比1,902コミット先行
・spiderfoot | Kali Linux Tools — Kali配布版。パッケージ版数 4.0-0kali5 は pkg.kali.org で確認
・PyPI: spiderfoot 0.0.1 — 「Reserved name placeholder」と自称する1,302バイトのプレースホルダーパッケージ