ペンテスト・脆弱性スキャン・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による脆弱性管理ワークフローを解説します。サプライチェーン全体のセキュリティ戦略はサプライチェーン攻撃とは|手口・防御ツール比較・npm 12の新機構まで実践解説をご覧ください。

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

この記事のポイント

  • 80+のセキュリティツール(Nmap・Burp・Nessus・OWASP ZAP・SonarQube等)の出力を自動正規化してワークスペースに集約。
  • コミュニティ版は完全無料(GPL-3.0)。Pro/Enterprise はクラウド・SSO・高度なレポート機能が追加。
  • CLI・REST API・Agents Dispatcherで自動化対応。CIに組み込んでPRごとに脆弱性スキャンを動かせる。
  • 「Vulnerability Management as Code」 を支えるOSSとして、エージェント時代のセキュリティ運用にハマる。

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

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

観点 中身
提供元 Infobyte(Faraday Security)
ライセンス GPL-3.0(コミュニティ版)
主要言語 Python 97.4%
統合ツール数 80+(プラグイン経由)
主な対象ユーザー ペンテスター / AppSecエンジニア / SOCアナリスト
インストール Docker Compose / Docker / pip / Debian/RPM / Source
CLIツール faraday-cli
API REST API完備

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

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

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

1. データ集約(Aggregation)

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

ツール 出力形式 Faradayでの扱い
Nmap XML ホスト・ポート・サービスとして取り込み
Burp Suite XML リクエスト/レスポンスとともに脆弱性化
Nessus .nessus CVE情報とCVSSスコアで取り込み
OWASP ZAP XML/JSON Webアプリ脆弱性として登録
SonarQube API コード品質を脆弱性カテゴリに変換
Bandit JSON Pythonコード脆弱性として登録
Metasploit DB export エクスプロイト試行を記録
Nuclei JSON カスタムテンプレート検出を脆弱性として登録

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

2. 可視化(Visualization)

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

ビュー 主な利用者 内容
Manager Dashboard CISO / セキュリティマネージャー 全体統計、リスクトレンド、修復進捗、SLA達成率
Analyst View ペンテスター / AppSecエンジニア 脆弱性詳細、エビデンス、再現手順、関連ツール出力
Asset View SOCアナリスト ホスト/サービス単位での脆弱性集約

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

Faraday Dashboard 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の典型ワークフロー

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

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

カテゴリ 統合ツール
ネットワークスキャナ Nmap / Masscan / Zmap
Web脆弱性スキャナ Burp Suite / OWASP ZAP / Acunetix / w3af / Nikto / Wapiti
商用Vulnスキャナ Nessus / Qualys / Rapid7 InsightVM / OpenVAS
Code Scanner(SAST) Bandit / SonarQube / Brakeman / Checkmarx
Container Scanner Trivy / Anchore / Clair
Cloud Security ScoutSuite / Prowler / CloudSploit
ペンテストフレームワーク Metasploit / Empire / Cobalt Strike(公式統合の有無は要確認)
API・モダン Nuclei / Zap2docker / Postman vulnerabilities
その他 Faraday-CLI、faraday-agents(リモート実行)

各プラグインの使い方は単純で、ツールが出力したファイルを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は脆弱性管理のライフサイクル全体をカバーする設計だ。

未修正

修正済

ツール実行
Nmap/Burp/Nessus等

Faraday取込み
正規化・重複排除

トリアージ
重要度判定

担当者割り当て
修正計画

修正実装
開発側

再スキャン
検証

クローズ
レポート化

CISO/監査用
Manager Dashboard

各フェーズの詳細:

フェーズ 担当 Faradayでの操作
ツール実行 ペンテスター/SOC CLI経由 or Agents Dispatcher
取込み・正規化 自動 プラグインが内部スキーマに変換
トリアージ AppSecリード 重要度・影響範囲を判定、フラグ付け
担当者割り当て マネージャー アサイン、SLA設定
修正 開発チーム コメント・ステータス更新
検証 ペンテスター 再スキャン・確認
クローズ・レポート マネージャー レポート出力(HTML/PDF/CSV)

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

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

Faraday CLI demo 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階層がある。実用上の機能差を整理する。

機能 Community Pro Enterprise
80+プラグイン統合 ✓ ✓ ✓
基本ダッシュボード ✓ ✓ ✓
Faraday-CLI ✓ ✓ ✓
REST API ✓ ✓ ✓
Agents Dispatcher ✓ ✓ ✓
HTMLレポート ✓ ✓ ✓
執行サマリレポート - ✓ ✓
チケット連携(JIRA/ServiceNow) - ✓ ✓
SSO(SAML/OIDC) - - ✓
クラウドSaaS版 - ✓ ✓
24/7サポート - - ✓
コンプライアンスレポート - - ✓

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

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

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

プラットフォーム ライセンス 主言語 統合ツール数 主戦場
Faraday GPL-3.0 Python 80+ ペンテスト + AppSec
DefectDojo BSD-3 Python 100+ AppSec中心
ThreadFix MPL Java 中 AppSec中心、Denimでメンテ
Dradis GPL/Pro Ruby 10+ ペンテスト報告書中心
ServiceNow Security Operations 商用 - 多数 エンタープライズ統合
Tenable.io 商用 - Tenable製品中心 スキャナ統合プラットフォーム

「ペンテスト系の作業に強い + 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に送らずローカルで処理できる。データ主権の観点で、これが効く。

対策:配布の docker-compose をそのまま本番に出さない

Faraday は脆弱性情報そのものを溜める箱なので、ここが抜かれると調査結果が丸ごと持っていかれる。2026-10-12 に git clone --depth 1 して配布物を読み直したところ、本番前に必ず直すべき既定値があった。

# ① 配布 compose の既定クレデンシャルと公開設定を確認する
git clone --depth 1 https://github.com/infobyte/faraday
grep -n "POSTGRES_PASSWORD\|image: postgres\|ports:" faraday/docker-compose.yaml

出てくるのは次の3点。

既定値(2026-10-12 時点) 本番での対策
POSTGRES_PASSWORD=postgres 必ず変更。compose に直書きせず環境変数か secrets へ出す
POSTGRES_USER=postgres / POSTGRES_DB=faraday DBユーザーを分け、最小権限にする
image: postgres:12.7-alpine PostgreSQL 12 は既にサポート終了世代。更新系列へ上げる

DBのパスワードが postgres のまま、というのは開発用 compose にはよくある形だが、Faraday の場合そこに入るのが脆弱性スキャンの生データである点が違う。ports: はホスト側ポートを指定しない書き方('5432' / '6379')になっていて外部に直接は出ないが、同一ホスト上の他コンテナからは到達できるので、パスワードを既定のままにしておく理由はない。

# ② 管理者パスワードの変更は専用サービスが用意されている
docker compose --profile manual run --rm change-password

change-password は profiles: ["manual"] 付きで定義されており、通常の up では起動しない。初期化は faraday-manage initdb が担当し、固定の初期パスワードは配布物に含まれていなかった(initdb が都度生成する形)。この点は良い設計で、緩和策として追加でやることは少ない。

公式の Hardening ガイドがリポジトリに同梱されている

見落とされがちだが、SECURITY.md は脆弱性報告の窓口案内ではなく、冒頭からこう書かれている。

The Faraday development team is aware that the information stored in the platform is of the highest criticality. With this in mind, we have developed this guide to perform Faraday Hardening.

最初の節が SSL で、「Nginx をリバースプロキシに置いてクライアント〜サーバー間を SSL 化せよ」と指示している。配布の compose には TLS 終端が入っていないので、これは利用者側で足す前提だと明示されていることになる。導入時はこのファイルを先に読むのが近道だ。

なおライセンスは GPL-3.0-only(pyproject.toml の license と LICENSE の実体が一致)、直近コミットは 2026-10-06、追跡ファイルは895本だった。

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

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

論点 状況 取れる対応
個人情報保護法 脆弱性データに個人情報が混入する可能性 プロジェクト/ワークスペース単位でアクセス制御
ISMS監査 脆弱性管理プロセスの文書化が必須 Faradayのライフサイクル機能でほぼ満たす
Pマーク 脆弱性発見〜修正の証跡 コメント・ステータス変更履歴で対応
データ主権 海外SaaSにデータを送れない 完全自己ホスト・GPL-3.0で安心
GPL-3.0の社内利用 利用は問題ない 社内利用に限定すれば配布義務なし
既存JIRA/Backlogとの統合 チケット運用との整合性 Pro版で標準対応、CommunityでもAPIで自前統合可
エンタープライズサポート 商用契約が必要な場合 Pro/Enterpriseで提供

「日本の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にも流す設計が現実的。

連携先 用途 連携方法
Splunk セキュリティイベント集約 Webhook / REST API Pull
Datadog 統合可観測性 Custom Metrics / Logs
ELK / OpenSearch ログ分析 Logstash経由
Microsoft Sentinel エンタープライズSOC Logic App経由
logbull 軽量ログ集約 logbullへ転送するスクリプトを書く

「脆弱性データを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 DefectDojo
出自 Infobyte(商用企業) OWASP公式
ライセンス GPL-3.0 + 商用 BSD-3
主言語 Python 97% Python(Django)
主戦場 ペンテスト + AppSec AppSec専門
プラグイン数 80+ 100+(パーサ)
UI モダン(独自実装) やや古い(Django Admin風)
API REST完備 REST + GraphQL
ペンテストレポート 強い 弱い
AppSec統計 中 強い
商用版 Pro / Enterprise なし(純OSS)
メンテナンス 商用企業主導で活発 コミュニティ主導
ドキュメント 充実 公式ドキュメントが薄い

「ペンテスト寄りなら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のようなプラットフォームを早期導入しておく価値は高い。

参照ソース