Project Overview
Faraday is an open-source vulnerability management platform built for security teams running collaborative penetration testing engagements and continuous security assessments. The core idea: instead of every tester on your team running tools independently and emailing CSVs around, Faraday gives you a central place to collect, correlate, and track vulnerabilities from dozens of scanning tools.
The project is maintained by Infobyte Security Research and ships in two tiers: a community open-source edition and commercial tiers (Professional and Corporate). The community edition gives you the workspace, import pipeline, and REST API. The commercial tiers add advanced reporting, role-based access controls, and enterprise integrations. Know this distinction before you commit—some features shown in the docs or marketing materials are paywalled, and discovering that mid-engagement is frustrating.
Faraday's 82.6% star growth over the last ~6 months tracks with broader demand for team-based vulnerability aggregation tools that aren't fully proprietary.
Key Challenges Addressed
Running a security assessment with multiple tools—Nessus, Burp Suite, Metasploit, Nikto—generates scattered, overlapping, and duplicate findings. Without a central aggregator, you end up with:
- Duplicate vulnerabilities reported across tools with no deduplication
- No unified status tracking (open, confirmed, risk-accepted, fixed)
- No shared context across team members working simultaneously
- No audit trail linking a finding to who confirmed it and when
Faraday addresses these by acting as a collecting layer. Each tool's output passes through a plugin that normalizes the format and lands in a shared PostgreSQL-backed vulnerability database. Your team then works from a single source of truth rather than individual tool exports.
Getting Started
Faraday runs as a server process with a web UI. The fastest path is Docker:
git clone https://github.com/infobyte/faraday.git
cd faraday
docker-compose up
The web interface becomes available at http://localhost:5985. On first launch, you create an admin account and then create a workspace for your engagement.
For a non-Docker install on Ubuntu/Debian:
pip install faradaysec faraday-plugins
faraday-manage migrate
faraday-manage createsuperuser
faraday-server
Sharp edges you'll hit immediately:
- Python version sensitivity: Faraday requires Python 3.8+ and has version-specific dependency pins. Installing into a system Python with conflicting packages causes cryptic import errors at startup. Use a virtual environment or Docker from the start.
- PostgreSQL is a hard requirement: If
DATABASE_URLis not set before running migrations,faraday-manage migratefails with a database connection error rather than a useful configuration message. ExportDATABASE_URLpointing at a running Postgres instance before running any management commands. - Plugin installation is separate: Running
pip install faradaysecalone gives you the server but not the tool parsers. You won't see import options for any scanner until you also installfaraday-plugins. Install both in the same command to avoid this. - Version pinning is not optional: Mismatched versions between
faradaysecandfaraday-pluginscause silent import failures where tool output is accepted by the CLI but no vulnerabilities appear in the workspace. Pin both to the same release in your requirements file.
Features and Use Cases
Collaborative workspaces: Every pentest engagement maps to a workspace. Multiple team members connect to the same workspace and see each other's findings in real time. This is the primary value proposition for team-based assessments.
Automated tool ingestion: Faraday ships with plugins for over 80 security tools. You pipe tool output through faraday-cli or the REST API and findings appear in the workspace. This works for Nessus XML exports, Burp Suite XML, Metasploit, Nikto, OpenVAS, and many others.
Vulnerability deduplication: When two tools both report the same host/port/CVE combination, Faraday merges them rather than creating duplicates. The merge heuristics work reliably for standard CVE-labeled findings; edge cases with custom vulnerability names may still create duplicates you need to manually resolve.
Status tracking and workflow: You can move a vulnerability through states—open, re-opened, closed, risk-accepted—and attach comments, evidence, and screenshots. This makes Faraday usable as a lightweight ticketing layer for security findings without requiring a separate issue tracker.
REST API: Every action available in the UI is also available via the REST API, which is documented with Swagger. If you're building an automated pipeline—nightly scans feeding into a tracking dashboard—you can POST findings directly without going through the CLI.
Reporting: The community edition generates basic PDF reports. The commercial tiers add customizable templates and scheduled delivery.
Ecosystem and Dependencies
Faraday's main integration surface is its plugin ecosystem. The faraday-plugins package is a separate repo and package that handles parsing for individual tools. If your preferred scanner isn't supported, writing a custom plugin is straightforward—the base class expects a parseOutputString method that returns normalized finding objects.
For CI/CD integration, faraday-cli supports piping scanner output from automated build pipelines. A common pattern is running a scanner as a build step and piping output through faraday-cli fplugin <tool_name> to populate a workspace automatically.
Faraday's Swagger-documented REST API makes it connectable to external dashboards, SIEM systems, and ticketing tools. Community integrations for Jira exist, though they're not maintained as part of the core project.
Architectural Overview
Faraday is a Flask-based Python application backed by PostgreSQL. The main components:
- faraday-server: The Flask API server. Handles authentication, workspace management, and vulnerability CRUD operations.
- faraday-plugins: The parser layer. Takes raw tool output and converts it into normalized vulnerability objects before database insertion.
- Web UI: A React frontend that connects to the REST API. Standard single-page application.
- PostgreSQL: The only supported database. Vulnerability data, workspace metadata, and user accounts all live here.
- faraday-client (legacy GTK desktop): Effectively deprecated in favor of the web UI. Ignore it—the docs referencing it are stale.
The plugin architecture is the key design choice. By keeping parsers as a separate package, the core server stays tool-agnostic and you can update a parser without redeploying the server. The downside is that two packages must stay version-synchronized, and mismatches produce confusing failures.
The Flask API follows a fairly standard REST design. Authentication uses JWT tokens. Workspaces are the top-level organizational unit—all vulnerability data, hosts, and services live inside a workspace.
Pros and Cons
Pros
- Solves a real team coordination problem that spreadsheets and email don't handle well for multi-tool assessments.
- Plugin coverage for 80+ tools means you probably won't need custom parsers for common scanners.
- The REST API is well-documented and stable, enabling automation without fighting undocumented internals.
- Active development with regular releases and responsive issue tracking.
- The web UI is cleaner and more functional than most open-source security tools.
Cons
- PostgreSQL is a hard dependency. No lightweight option for solo assessors evaluating the tool before committing to infrastructure.
- The community vs. commercial feature boundary is not always clearly documented. You may hit a paywall mid-engagement on a feature you assumed was free.
faraday-pluginsversion drift is a recurring source of breakage. Two packages requiring synchronized versions is an ongoing maintenance burden.- Self-hosting requires real infrastructure: PostgreSQL, a persistent server process, and enough RAM for Flask. Not a tool you spin up quickly for a one-off assessment.
- The legacy GTK client still appears in older docs and tutorials, creating confusion about which client is current.
Comparison and Alternatives
GitHub stars
Weekly star gains
Full metrics details
GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.
Faraday
GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
DefectDojo
GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.
175 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Nuclei
GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Issues opened
Weekly total
Full metrics details
GitHub API observation. Historical values render only when the source provides a real observation for that day.
Faraday
GitHub API observation. Historical values render only when the source provides a real observation for that day.
149 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
DefectDojo
GitHub API observation. Historical values render only when the source provides a real observation for that day.
143 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Nuclei
GitHub API observation. Historical values render only when the source provides a real observation for that day.
178 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Issues closed
Weekly total
Full metrics details
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
Faraday
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
149 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
DefectDojo
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
143 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Nuclei
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
178 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Pull requests opened
Weekly total
Full metrics details
GitHub API observation. Historical values render only when the source provides a real observation for that day.
Faraday
GitHub API observation. Historical values render only when the source provides a real observation for that day.
149 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
DefectDojo
GitHub API observation. Historical values render only when the source provides a real observation for that day.
143 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Nuclei
GitHub API observation. Historical values render only when the source provides a real observation for that day.
178 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Pull requests closed
Weekly total
Full metrics details
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
Faraday
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
149 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
DefectDojo
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
143 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Nuclei
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
178 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Pull requests merged
Weekly total
Full metrics details
GitHub API observation. Historical values render only when the source provides a real observation for that day.
Faraday
GitHub API observation. Historical values render only when the source provides a real observation for that day.
149 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
DefectDojo
GitHub API observation. Historical values render only when the source provides a real observation for that day.
143 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Nuclei
GitHub API observation. Historical values render only when the source provides a real observation for that day.
178 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Open/closed pull request ratio
Weekly average
Full metrics details
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
Faraday
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
DefectDojo
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
175 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Nuclei
GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Open/closed issues ratio
Weekly average
Full metrics details
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
Faraday
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
DefectDojo
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
175 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Nuclei
GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Releases
Weekly total
Full metrics details
GitHub release published_at events bucketed by UTC day; drafts are excluded.
Faraday
GitHub release published_at events bucketed by UTC day; drafts are excluded.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
DefectDojo
GitHub release published_at events bucketed by UTC day; drafts are excluded.
175 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Nuclei
GitHub release published_at events bucketed by UTC day; drafts are excluded.
180 observed daily rows. Missing days are not fabricated.
| Date | Value |
|---|
Hotness score
Weekly average
Full metrics details
Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.
Faraday
Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.
180 observed daily rows. Missing days are not fabricated.
Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.
- Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
- Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
- Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
- Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
- Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
- Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
| Date | Stars | Stars 1d | Stars 7d | Stars 14d | Stars 30d | Stars 90d | Same-day multiplier | Weekly multiplier | Fortnight multiplier | Hot today | Hot week | Breakout | Stored score |
|---|
DefectDojo
Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.
175 observed daily rows. Missing days are not fabricated.
Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.
- Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
- Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
- Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
- Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
- Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
- Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
| Date | Stars | Stars 1d | Stars 7d | Stars 14d | Stars 30d | Stars 90d | Same-day multiplier | Weekly multiplier | Fortnight multiplier | Hot today | Hot week | Breakout | Stored score |
|---|
Nuclei
Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.
180 observed daily rows. Missing days are not fabricated.
Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.
- Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
- Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
- Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
- Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
- Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
- Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
| Date | Stars | Stars 1d | Stars 7d | Stars 14d | Stars 30d | Stars 90d | Same-day multiplier | Weekly multiplier | Fortnight multiplier | Hot today | Hot week | Breakout | Stored score |
|---|
Reliability score
Weekly average
Full metrics details
Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.
Faraday
Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.
180 observed daily rows. Missing days are not fabricated.
Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.
- Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
- Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
- Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
- Support burden = 100 − 2 × open issues per 1,000 stars
- Liveness = 100 × exp(−pushed days ago ÷ 120)
Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.
| Date | Issues opened | Issues closed | PRs opened | PRs merged | Releases | Stars | Open issues | Pushed days ago | Continuity | Closure | Shipping | Liveness | Support burden | License | Observed days | Missing days | Needs healing | Stored score |
|---|
DefectDojo
Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.
175 observed daily rows. Missing days are not fabricated.
Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.
- Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
- Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
- Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
- Support burden = 100 − 2 × open issues per 1,000 stars
- Liveness = 100 × exp(−pushed days ago ÷ 120)
Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.
| Date | Issues opened | Issues closed | PRs opened | PRs merged | Releases | Stars | Open issues | Pushed days ago | Continuity | Closure | Shipping | Liveness | Support burden | License | Observed days | Missing days | Needs healing | Stored score |
|---|
Nuclei
Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.
180 observed daily rows. Missing days are not fabricated.
Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.
- Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
- Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
- Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
- Support burden = 100 − 2 × open issues per 1,000 stars
- Liveness = 100 × exp(−pushed days ago ÷ 120)
Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.
| Date | Issues opened | Issues closed | PRs opened | PRs merged | Releases | Stars | Open issues | Pushed days ago | Continuity | Closure | Shipping | Liveness | Support burden | License | Observed days | Missing days | Needs healing | Stored score |
|---|
Several open-source tools occupy adjacent space in vulnerability management and security collaboration:
| Project | Repo | Hotness (~6mo) | PRs merged (~6mo) | Star growth (~6mo) |
|---|---|---|---|---|
| Faraday | https://github.com/infobyte/faraday | 7.57 | 0 | 2947 |
| DefectDojo | https://github.com/DefectDojo/django-DefectDojo | metrics pending | 0 | 62 |
| Nuclei | https://github.com/projectdiscovery/nuclei | 65.05 | 61 | 4874 |
DefectDojo is the strongest open-source alternative for vulnerability management. It has deeper CI/CD integration documentation, stronger support for DevSecOps workflows where findings flow from automated scanners into a continuous tracking system, and a larger contributor base. If your use case is continuous vulnerability tracking in a development pipeline rather than episodic pentest engagements, DefectDojo is the better choice.
Conclusion
Penetration testing teams running multi-tool engagements will get immediate, concrete value from Faraday's workspace and plugin aggregation layer—it eliminates the cross-tool deduplication and status-tracking work that otherwise falls to spreadsheets. Start with the official community documentation to understand the workspace model before you deploy, so you know what the community edition actually gives you versus what requires a commercial license.
Do not run pip install faradaysec without also pinning faraday-plugins to the matching version—mismatched packages cause silent import failures where tool output appears to be accepted but no vulnerabilities land in the workspace. Before anything else, run faraday-manage check to validate that your PostgreSQL connection and plugin installation are correctly configured.