Faraday: Turning 80+ Security Scanners Into a Unified Vulnerability Intelligence System
Hook
Security teams run an average of 8-12 different vulnerability scanners, each producing incompatible reports stored in isolation. Faraday solves the aggregation problem that spreadsheets can’t.
Context
Modern security operations face a tooling fragmentation crisis. Network security teams run Nmap and Nessus. Application security uses Burp Suite and OWASP ZAP. DevSecOps pipelines integrate Bandit, SonarQube, and container scanners. Each tool generates proprietary output formats—XML from Nmap, JSON from modern APIs, custom formats from commercial products. Analysts waste hours manually copying findings into tracking systems, losing context in translation.
Faraday emerged from this chaos as an open-source vulnerability management platform designed specifically for multi-tool environments. Unlike commercial solutions that lock you into vendor ecosystems, Faraday positions itself as tool-agnostic middleware. It doesn’t replace your scanners—it orchestrates them. The 6,304 GitHub stars signal adoption by teams tired of duct-taping scripts together to correlate findings across tools. At its core, Faraday solves one problem exceptionally well: normalizing heterogeneous security data into a unified schema that enables collaboration, trend analysis, and automated remediation tracking.
Technical Insight
Faraday’s architecture splits into components that work independently or together. The core is faraday-server, a Python web application running on port 5985 with PostgreSQL as the persistence layer. This isn’t a lightweight SQLite setup—the PostgreSQL requirement signals Faraday’s design for team-scale deployments with concurrent users.
The plugin system is where architectural elegance meets practical utility. Faraday supports 80+ tools through two plugin types: console plugins that intercept live command output, and report plugins that parse pre-generated files. Console plugins work through the faraday-cli wrapper. Instead of running nmap www.example.com directly, you execute:
$ faraday-cli tool run "nmap www.example.com"
💻 Processing Nmap command
Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-22 14:13 -03
Nmap scan report for www.example.com (10.196.205.130)
Host is up (0.17s latency).
PORT STATE SERVICE
80/tcp open http
443/tcp open https
2222/tcp open EtherNetIP-1
3306/tcp closed mysql
Nmap done: 1 IP address (1 host up) scanned in 11.12 seconds
⬆ Sending data to workspace: test
✔ DoneBehind the scenes, faraday-cli captures stdout, routes it through the Nmap plugin parser, extracts structured data (hosts, ports, services, vulnerabilities), and sends normalized data to the server API. The normalization layer maps tool-specific concepts to Faraday’s data model—Nmap’s “open ports,” Burp Suite’s “vulnerabilities,” and Nessus’s “findings” all become standardized entries.
Report plugins handle the batch import use case. If you’ve already run a Burp scan and have the XML, you skip the CLI wrapper:
$ faraday-cli tool report burp.xmlThis simplicity masks sophisticated XML/JSON parsing logic that handles version differences across tool releases. The plugin architecture is extensible—creating a new plugin appears to involve implementing a parser class, though the specific API details would require consulting the plugin documentation.
For DevSecOps workflows, Faraday Agents Dispatcher (a separate tool) adds remote execution capabilities. Deploy agents on CI runners or bastion hosts to execute scanners in isolated environments and push results back. This enables scenarios like scanning internal networks from Jenkins without exposing Faraday credentials to every pipeline.
The workspace model organizes findings by project or engagement, enabling multi-tenancy where a single Faraday instance serves multiple teams or clients. Workspaces become the unit of collaboration—analysts share a workspace, see real-time updates as scans complete, and use built-in features to discuss remediation strategies.
Deployment flexibility ranges from pip install for quick tests to Docker Compose for production. The Docker setup bundles PostgreSQL, handling the infrastructure complexity:
$ wget https://raw.githubusercontent.com/infobyte/faraday/master/docker-compose.yaml
$ docker-compose upThis launches the necessary containers, exposing Faraday on localhost:5985. The default credentials are username “faraday” with a password generated during installation. For production deployments, the Debian/RPM packages integrate with systemd.
Gotcha
Faraday’s PostgreSQL dependency is non-negotiable, which immediately excludes lightweight use cases. If you want to quickly triage a single penetration test on your laptop without infrastructure setup, Faraday’s architecture fights you. The Docker Compose option helps, but you’re still running a database server to track a dozen findings—significant overhead compared to opening an HTML report.
Plugin quality likely varies across the 80+ supported tools. Core plugins for Nmap, Burp, and Nessus presumably receive active maintenance, but niche tools may have parsers that lag behind tool updates. When a plugin fails to parse output, debugging requires diving into the faraday_plugins repository code.
The workspace model, while powerful for teams, adds friction for solo practitioners. Every scan must target a workspace. You can’t casually import reports without first creating organizational structures that make sense for multi-user collaboration but feel bureaucratic when working alone. The web UI serves the “manager dashboard” use case but may feel less streamlined for rapid analyst workflows compared to native desktop tools.
Performance under continuous scanning loads is undocumented. The README mentions CI/CD integration extensively but provides no benchmarks for scan result ingestion rates or database scaling guidance. If your pipeline generates hundreds of scan reports per hour, you’re architecting without concrete performance data.
Verdict
Use Faraday if you’re managing security for multiple applications with heterogeneous tooling, especially in DevSecOps environments where CI/CD pipelines already generate scanner outputs that currently rot in build artifacts. It excels when you need centralized vulnerability tracking across teams, historical trend analysis that spans tools, or want to stop manually correlating Nmap and Nessus findings in spreadsheets. The Docker Compose deployment makes proof-of-concept evaluation relatively straightforward despite the PostgreSQL requirement.
Skip Faraday if you’re a solo penetration tester who values speed over collaboration, work exclusively with a single commercial scanner that has adequate built-in reporting, or need a lightweight solution for occasional security audits. The infrastructure requirements and workspace-centric design are overkill when native tool reports suffice. Also consider alternatives if you require documented performance guarantees for high-volume continuous scanning—Faraday lacks published scalability data for demanding throughput scenarios.
