Faraday徹底解説：6.5kスターの脆弱性管理プラットフォームOSS、80+セキュリティツール統合

ペンテスト・脆弱性スキャン・SOC運用の現場では、「Nmap・Burp・Nessus・OWASP ZAP・Metasploit・SonarQube…と多数のツールを使うが、結果がバラバラで集約できていない」という慢性的な課題がある。infobyte/faraday は、この「ツール群の出力を1つのワークスペースに集約・正規化する」ことに特化したOSSプラットフォームだ。執筆時点でGitHub Stars 6,500、Forks 1,100、GPL-3.0、Python 97.4%。80+のセキュリティツールがプラグインで統合されており、ペンテスター・AppSecエンジニア・SOCアナリストが同じデータを触れる。

この記事ではFaradayによる脆弱性管理ワークフローを解説します。サプライチェーン全体のセキュリティ戦略はサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストをご覧ください。

Source: infobyte/faraday — Faradayの脆弱性管理画面。複数のセキュリティツール出力が同じワークスペースに集約される。

Faradayとは：80+のセキュリティツールを1つのワークスペースに集約

Faradayは2026年現在、OSSの脆弱性管理プラットフォーム（VMP）として最も広く使われているプロジェクトの一つだ。Python 97.4%という構成で、Argentinaのセキュリティ企業Infobyte（現Faraday Security）が開発・メンテナンスしている。コミュニティ版は完全無料・GPL-3.0で、商用版（Pro/Enterprise）が別途提供されている。

「1つの脆弱性管理プラットフォームが80+のツールに対応している」というのは控えめに言って驚異的で、これが「ペンテスター3人チーム・OSS無料」で使えるのが2026年現在のセキュリティ業界の追い風になっている。

主要機能：データ集約・可視化・コラボレーション

Faradayの提供価値は3層に整理できる。

1. データ集約（Aggregation）

複数のセキュリティツールの出力（XML、JSON、独自フォーマット）をFaradayの内部スキーマに正規化して統合する。同じ脆弱性が複数ツールで検出された場合、重複排除（deduplication）を行う。

これがあれば、Nmapで見つけたOpen Portと、Nessusで見つけたVuln、OWASP ZAPで見つけたWebアプリ穴を、同じワークスペース内で串刺しレビューできる。「スキャン結果のExcelをマージする時間」が消える。

2. 可視化（Visualization）

ダッシュボードはマネージャー向けと分析者向けの2系統で提供される。

「経営層の説明資料」と「現場の作業画面」が同じデータから生成される設計になっており、報告作業の手間を大きく減らせる。

Source: infobyte/faraday — Manager Dashboard。脆弱性のリスクトレンド・修復進捗・SLA達成率を可視化。

3. コラボレーション（Collaboration）

複数ユーザー・複数ロール（admin / pentester / asset_owner / client）でワークスペースを共有でき、コメント・ステータス変更・担当者割り当てが可能。「ペンテスト中のチャット」を別ツール（Slack等）でやらず、Faradayの脆弱性レコード上でコメントする運用が組める。

インストール：Docker Compose一発が王道

Faradayの導入はDocker Composeが最も摩擦が少ない。

wget https://raw.githubusercontent.com/infobyte/faraday/master/docker-compose.yaml
docker-compose up -d

これで以下が立ち上がる：

• Faraday本体（Pythonアプリ）
• PostgreSQL（メタデータ・脆弱性情報の永続化）
• Redis（セッション・キャッシュ）

ブラウザで http://localhost:5985 にアクセスし、デフォルト認証情報（username: faraday）でログインすると、UIが表示される。

# docker-compose.yaml の主要部分（概念）
services:
  faraday:
    image: faradaysec/faraday:latest
    ports:
      - "5985:5985"
    depends_on:
      - postgres
      - redis
    environment:
      - PGSQL_USER=faraday
      - PGSQL_PASSWD=changeme
      - PGSQL_HOST=postgres
      - PGSQL_DBNAME=faraday

  postgres:
    image: postgres:14
    environment:
      - POSTGRES_USER=faraday
      - POSTGRES_PASSWORD=changeme
      - POSTGRES_DB=faraday
    volumes:
      - postgres-data:/var/lib/postgresql/data

  redis:
    image: redis:7

volumes:
  postgres-data:

別の経路では、PyPI経由のインストールも可能。

pip3 install faradaysec
faraday-server --start

軽量PoCなら pip、本格運用なら Docker Compose、というのが定石だ。

80+の統合プラグイン：Nmap・Burp・Nessus・ZAPの典型ワークフロー

Source: infobyte/faraday — 統合される代表的なセキュリティツール群。

Faradayが「他の脆弱性管理OSS」と差別化される最大の理由が、80+のプラグインによる広範な統合だ。代表的なツールをカテゴリ別に整理する。

各プラグインの使い方は単純で、ツールが出力したファイルをFaradayにアップロードするだけ。CLIで一気にやる場合：

# Nmapスキャン → Faradayへ取り込み
nmap -oX scan.xml 192.168.1.0/24
faraday-cli tool report scan.xml --plugin nmap

# OWASP ZAP → Faradayへ
zap-cli quick-scan --self-contained -o '-r report.xml' http://example.com
faraday-cli tool report report.xml --plugin zap

# Burp Suite → Faradayへ
# Burpから XML エクスポート
faraday-cli tool report burp-export.xml --plugin burp

「毎週金曜にCronで全環境スキャン → 結果をFaradayに集約 → 月曜の朝にCISOがダッシュボードで状況確認」のフローが、Cron数行で組める。

ワークフロー：脆弱性発見→トリアージ→修正→検証

Faradayは脆弱性管理のライフサイクル全体をカバーする設計だ。

各フェーズの詳細：

「1つの脆弱性のライフサイクルが、すべてFaraday内のレコードとして履歴に残る」のが大きい。後から監査されたとき、「いつ誰がどう判断して、どう修正したか」が時系列で追える。これは外資系・上場企業・規制業種では必須の能力だ。

Faraday-CLI：自動化を支える司令塔

Source: infobyte/faraday — faraday-cliの動作デモ。CLIから直接ワークスペース・脆弱性・レポートを操作できる。

Faradayの自動化は faraday-cli で行う。CI/CDに組み込むのも、ローカルからスキャンを実行するのも、CLIが中心。

# faraday-cliのインストール
pip install faraday-cli

# 認証（一度だけ）
faraday-cli auth -u username

# ワークスペース作成
faraday-cli workspace create my-pentest-2026

# ツール結果を取り込み
faraday-cli tool report nmap-scan.xml -w my-pentest-2026 --plugin nmap

# 脆弱性のリスト
faraday-cli vuln list -w my-pentest-2026

# レポート生成
faraday-cli report -w my-pentest-2026 -o report.html

これがあれば、「セキュリティテストの一連の作業をシェルスクリプト化」できる。

#!/bin/bash
# weekly-scan.sh
WORKSPACE="weekly-$(date +%Y-W%V)"
faraday-cli workspace create $WORKSPACE

# ネットワークスキャン
nmap -oX nmap.xml ${TARGETS}
faraday-cli tool report nmap.xml -w $WORKSPACE --plugin nmap

# Webアプリスキャン
zap-cli quick-scan -o '-r zap.xml' ${WEB_TARGETS}
faraday-cli tool report zap.xml -w $WORKSPACE --plugin zap

# レポート生成
faraday-cli report -w $WORKSPACE -o weekly-report.html
slack-send weekly-report.html

毎週これをCronで動かせば、「自動週次セキュリティレポート」が成立する。手作業がほぼなくなる。

Faraday Agents Dispatcher：リモートスキャンを束ねる

「ペンテスター複数人・拠点が分散・スキャン対象が大量」という大規模運用では、Faraday Agents Dispatcherが効く。エージェントを各ネットワークに配置し、中央のFaradayから命令を出してリモート実行できる。

[Faraday Server]
   ↓ (REST API + WebSocket)
[Agent Dispatcher]
   ├ Agent 1 (Tokyo office network)
   ├ Agent 2 (Singapore VPC)
   ├ Agent 3 (US-East subsidiary)
   └ Agent 4 (Customer environment)

各エージェントは自分のネットワークでツールを実行し、結果を中央のFaradayにアップロードする。地理的・ネットワーク的に分散した環境を一元管理できる。

これはMSSP（マネージドセキュリティサービスプロバイダ）や社内CISO組織のグローバル運用で特に効く。「東京オフィスから米国子会社の脆弱性まで把握」がFaraday1台で回る。

REST API：自前ツールとの統合

FaradayはREST APIをドキュメント化しており、自前のセキュリティツール・SIEM・チケットシステムとの統合が可能。

import requests

# 認証
session = requests.Session()
session.auth = ("username", "password")

# 脆弱性をプログラムから登録
session.post(
    "http://localhost:5985/_api/v3/ws/my-workspace/vulns/",
    json={
        "name": "Custom Vulnerability",
        "description": "Detected by our internal tool",
        "severity": "high",
        "type": "Vulnerability",
        "host_id": 12,
    }
)

# 全脆弱性を取得
vulns = session.get("http://localhost:5985/_api/v3/ws/my-workspace/vulns/").json()

# JIRAに連携（外部システムとの統合例）
for v in vulns["data"]:
    if v["severity"] in ("critical", "high"):
        jira_create_ticket(v)

「自前のセキュリティ自動化スクリプトの結果をFaradayに集約」「Faradayの脆弱性をJIRA/GitHubに自動チケット化」のような統合が、APIで自由に組める。

Community vs Pro vs Enterprise の機能差

Faradayにはコミュニティ版（OSS）・Pro版・Enterprise版の3階層がある。実用上の機能差を整理する。

「コミュニティ版でほぼ全機能が動く」のがFaradayの誇るべき点。Proで上乗せされるのは「企業向けの追加機能」であって、コア機能はOSSで揃っている。「PoCはCommunity、本番がスケールしたらPro/Enterpriseに移行」という現実的な進め方ができる。

競合比較：DefectDojo・ThreadFix・Security Operations系

脆弱性管理プラットフォームの選択肢は、Faraday以外にも複数ある。

「ペンテスト系の作業に強い + AppSecもカバー」という両刀がFaradayの位置取り。DefectDojoはAppSec専用色が強いため、ペンテストレポート作成や手動の脆弱性記録には Faraday の方が向く。

ServiceNow / Tenable.io 等の商用SaaSとの比較では、「ライセンスフリーで自社内で完結」という Faraday の強みが効く。データ主権を気にする日本企業や、「ペンテスト結果を社外に置けない」業種では、Faraday一択になるケースが少なくない。

AIエージェント時代の脆弱性管理：Faradayがハマる場面

ここまでが事実と分析だった。最後に独自視点を1つ。AIエージェント時代の脆弱性管理で、Faradayが特に価値を発揮する、というのが私見。

理由は3つ。

1. AIエージェントが大量に脆弱性を見つける時代になった

BISSA Scanner や OWASP APTS（自律ペンテスト標準） のようなAI主導のスキャンが現実化している。人間がスキャンしていた時代より検出件数が桁違いに多くなる——その大量データを集約・正規化・トリアージするプラットフォームが必要だ。

2. AIエージェントの結果を「人間が判断する」UIが必要

AIが見つけた「これは本当に脆弱性か、誤検知か」の判断は、最終的に人間が行う必要がある。Faradayのワークスペース＋コメント機能は、AIが大量に投げてきた候補を人間がトリアージするUIとしてそのまま機能する。

# AIエージェントがFaradayに脆弱性候補を投入する例
import requests

ai_findings = [
    {"title": "SSRF candidate", "severity": "high", "confidence": 0.9},
    {"title": "Possible XSS", "severity": "medium", "confidence": 0.6},
]

for finding in ai_findings:
    requests.post(
        "http://faraday/_api/v3/ws/ai-pentest/vulns/",
        json={
            **finding,
            "tags": ["ai-detected", f"confidence-{int(finding['confidence']*100)}"],
            "status": "open" if finding["confidence"] > 0.8 else "needs-review",
        },
        auth=("api-user", "api-token"),
    )

confidence < 0.8 のものは「needs-review」ステータスで人間が確認、0.8以上は即「open」で対応進行、というワークフローが組める。

3. ローカルで完結する

AIエージェントが脆弱性候補を吐く処理は、機密データを含む場合が多い。Faradayは完全自己ホストで動くため、AIが吐いた候補を外部SaaSに送らずローカルで処理できる。データ主権の観点で、これが効く。

日本企業導入時の論点：規制・データ主権・既存運用

日本企業でFaradayを導入する場合の現実的な論点を整理する。

「日本のCSIRT・PSIRT・SOCの標準ツール」としての地位は、まだDeloitte等の大手コンサルが入っているServiceNowが優勢だが、「中小企業のSOC構築・社内ペンテストチームの基盤」としては、Faradayがじわじわ浸透している。

CI/CDへの組み込み：PRごとにスキャンする運用

DevSecOps文化が広がる中、「PRをマージする前に脆弱性スキャンを必ず実行する」という運用が標準になりつつある。FaradayはCI/CDの集約点として機能する。

# .github/workflows/security-scan.yml
name: Security Scan
on: [pull_request]

jobs:
  faraday-scan:
    runs-on: ubuntu-latest
    services:
      faraday:
        image: faradaysec/faraday:latest
        ports:
          - 5985:5985

    steps:
      - uses: actions/checkout@v4

      - name: Run Bandit (Python SAST)
        run: |
          pip install bandit
          bandit -r src/ -f json -o bandit-report.json || true

      - name: Run Trivy (Container Scan)
        run: trivy image --format json -o trivy-report.json myimage:latest

      - name: Run Nuclei
        run: nuclei -target https://staging.example.com -j > nuclei-report.json

      - name: Upload to Faraday
        run: |
          pip install faraday-cli
          faraday-cli auth -t $
          faraday-cli workspace create pr-$
          faraday-cli tool report bandit-report.json --plugin bandit -w pr-$
          faraday-cli tool report trivy-report.json --plugin trivy -w pr-$
          faraday-cli tool report nuclei-report.json --plugin nuclei -w pr-$

      - name: Block PR if Critical Found
        run: |
          CRITICAL=$(faraday-cli vuln list -w pr-$ --severity critical --output count)
          if [ "$CRITICAL" -gt 0 ]; then
            echo "::error::$CRITICAL critical vulnerabilities found"
            exit 1
          fi

「PRごとに3つのツールでスキャン → Faradayに集約 → クリティカルがあればCIで止める」というワークフローが、これだけで組める。脆弱性管理が「セキュリティチームの作業」から「開発フローの一部」に組み込まれる。

既存のSIEMとの統合：Splunk・Datadog・ELKへ

エンタープライズで運用するなら、FaradayのデータをSIEMにも流す設計が現実的。

「脆弱性データをSIEM側にも複製しておくと、ネットワーク異常検知やインシデントレスポンスとの相関分析」が可能になる。Faradayは脆弱性管理のシステム・オブ・レコード、SIEMは運用の中央集約、と役割分担するのが定石だ。

ペンテスト案件のワークフロー：受注から納品まで

実際のペンテスト案件で、Faradayがどう機能するかを業務フロー寄りに展開する。

[Day 1: 受注]
  → Faradayでクライアント専用ワークスペース作成
  → ロール: pentester (内部) + client (顧客閲覧)
  → ターゲットスコープを Asset で登録

[Day 2-7: 偵察フェーズ]
  → Nmapスキャン → Faraday取込
  → サブドメイン列挙（Amass等） → Faraday取込
  → Webクローリング（OWASP ZAP） → Faraday取込

[Day 8-14: エクスプロイトフェーズ]
  → 手動ペンテスト → 脆弱性をFaradayに直接登録
  → Burp Suiteで深掘り → 取込
  → Metasploit試行 → エビデンス添付

[Day 15-16: トリアージ]
  → 重複排除、重要度判定
  → False Positiveをマーク
  → クライアントへ修正提案を Comment 機能で記載

[Day 17-18: 納品]
  → Executive SummaryをHTML/PDF生成
  → 詳細レポートをCSVエクスポート
  → クライアントにワークスペースアクセスを発行

[Day 30: 再テスト]
  → 同じワークスペースで再スキャン
  → ステータス更新（Fixed/Reopened）
  → 最終レポート発行

「ペンテスト案件の事務作業がFaraday1つで回る」。Excelでマスタを管理したり、レポートをWordで手書きしたりする作業がほぼ消える。これはペンテスト企業の競争力に直結する効率化だ。

Faraday vs DefectDojo：AppSec領域の細部比較

DefectDojoはOWASPプロジェクトの公式OSSで、Faradayと並ぶ脆弱性管理プラットフォームの選択肢だ。両者の細部の違いを整理する。

「ペンテスト寄りならFaraday、CI/CD統合のAppSec専業ならDefectDojo」というのが、2026年現在の使い分けの定石。両方使うチームも珍しくなく、Faradayをペンテスト用ワークスペース、DefectDojoをCI統合の自動スキャン集約に、という分業が成立する。

1年後の予想：Faradayが「脆弱性管理のGitHub」になる可能性

最後に、独自視点で1年後の予想を3つ。

予想1：「ワークスペースの共有」がコラボ標準に

ペンテスト案件の納品が、「PDFレポートを送付」から「Faradayワークスペースのアクセス権を提供」に置き換わる。クライアントがワークスペースに直接ログインして脆弱性を確認するのが標準体験になる。

予想2：「AIエージェント駆動の脆弱性発見」がFaraday前提になる

OWASP APTS のような自律ペンテスト規格が広がるにつれ、「AIが見つけた脆弱性をどこに集約するか」の標準が必要になる。Faradayはプラグイン文化と REST APIでこの標準ポジションを取りやすい。

予想3：「監査・コンプライアンスのコモディティ化」

Faradayの脆弱性管理ライフサイクルが標準化することで、ISMS・SOC2・PCI-DSSの監査における「脆弱性管理証跡」の作成コストが大きく下がる。「Faradayから自動で監査レポートが出る」機能がEnterpriseで強化されれば、監査コンサルの一部業務がOSSに置き換わる。

まとめ：「ペンテスト・AppSec・SOCの統合プラットフォーム」として

Faradayは、「複数のセキュリティツールの結果を一元管理する」という地味だが本質的な機能を、OSS・GPL-3.0・80+プラグイン統合で提供しているプラットフォームだ。

• 個人ペンテスター：レポート作成の手間が桁違いに減る、コミュニティ版で十分。
• 小〜中規模事業者：CISO・SOC・開発チームが同じデータを触れる基盤。
• エンタープライズ：Pro/Enterprise版でSSO・コンプライアンスレポート・JIRA連携が揃う。
• MSSP（マネージドサービス）：Agents Dispatcherで複数顧客環境を一元管理。
• AIエージェント運用：自律スキャンの結果を集約・トリアージする受け皿として機能する。

サプライチェーン攻撃、AI駆動の自律ペンテスト、エンタープライズの脆弱性増加——「セキュリティの作業量が増える未来」に備える上で、Faradayのようなプラットフォームを早期導入しておく価値は高い。

FAQ

Q. コミュニティ版だけで十分ですか？

A. 個人〜小チームのペンテスト・AppSec業務なら十分です。Pro版が必要になるのは、JIRAチケット連携・SSO・実行サマリレポートが業務上必須の場合に限られます。最初はコミュニティ版で運用し、必要に応じてPro/Enterpriseへ移行するのが王道です。

Q. GPL-3.0で社内利用に制限はありますか？

A. 社内利用に限定すれば配布義務は発生しません。ただし、Faradayを改変して社外に提供する場合（SaaS化、納品物に含めて顧客に渡す等）は、改変部分のソース提供義務が発生します。社内ツールとしての利用には実質制約なしと理解してOKです。

Q. 80+のプラグインは公式で全部メンテされていますか？

A. 大半は公式リポジトリで管理されていますが、ツール側のフォーマット変更でプラグインが古くなることがあります。利用前に直近のメンテ状況を確認するのが安全です。コミュニティ貢献も活発で、新しいツール対応のPRが頻繁にマージされています。

Q. 既存のJIRA運用と統合できますか？

A. Pro版で公式統合が提供されます。Community版でも、REST APIから自前で双方向同期スクリプトを書けば対応できます。脆弱性のステータス変更時にJIRAチケットも更新する、などの自動化はAPIベースで実装可能です。

Q. 大規模環境（数千ホスト）でも動きますか？

A. PostgreSQLのチューニングと、Faraday本体のリソース割り当て次第で数千ホスト規模まで対応可能です。それ以上の規模ではワークスペースを分割するか、Pro/Enterprise版のスケーリング機能を活用する必要があります。

Q. ペンテスト報告書の自動生成は可能ですか？

A. はい。HTMLレポートはCommunity版で生成可能。カスタムテンプレートで会社ロゴ・フォーマットを反映できます。Pro/Enterprise版ではExecutive Summary形式や規制対応レポート（PCI-DSS / HIPAA等）も提供されます。

Q. 既存のNessus/Burp結果を一括取り込みできますか？

A. 過去のスキャン結果ファイルをまとめて取り込むことが可能です。faraday-cli tool report をループさせるバッチを書けば、過去N年分の脆弱性を一気にFaradayに集約できます。過去資産の可視化にも使えるユースケースです。

Q. AIエージェントとの統合のおすすめは？

A. REST APIに脆弱性候補を投入するのが最もシンプルです。Claude Codeにスキルを追加して「スキャン結果をFaradayにアップロードする」フローを書けば、自然言語の指示から脆弱性管理が動きます。confidence値で人間レビュー要否を分けるワークフローが現実的です。

Q. コンプライアンス監査（ISMS/SOC2）に直接使えますか？

A. 脆弱性管理ライフサイクルの証跡として使えます。各脆弱性の検出日時・対応者・修正日時・再検証結果がFaraday内で時系列に残るため、監査人への提示資料として機能します。Enterprise版では監査用エクスポート機能が追加されます。

Q. 学習コストはどれくらいですか？

A. UI自体は直感的で、ペンテスター/AppSecエンジニアなら数日で慣れるレベルです。CLI・APIの活用で本領を発揮するため、1〜2週間で自動化ワークフローを組めるようになるのが標準的な習熟ペースです。

Q. オンプレで完全エアギャップ環境でも動きますか？

A. 動きます。 Docker Compose で立ち上げる構成自体が外部依存ゼロ（PostgreSQL + Redis のみ）で、インターネット非接続環境でも問題なく稼働します。プラグインや脆弱性データベース（CVEなど）のアップデートだけは、定期的にネットワーク接続環境でビルドし直したコンテナイメージを社内に持ち込む形で運用するチームが多いです。

Q. 大量のFalse Positiveを効率的に処理する方法は？

A. タグとフィルタの組み合わせが王道です。「特定パターンのFalse Positive」をルール化して一括ステータス変更するスクリプトをCLI/APIで書けば、トリアージの作業時間が桁違いに減ります。AIエージェントに「過去のFalse Positive判定を学習させ、新規脆弱性を自動分類する」運用も2026年現在は現実的になってきています。

参照ソース

• infobyte/faraday — GitHub
• Faraday 公式ドキュメント
• faraday-cli ドキュメント
• Faraday REST API ドキュメント