Look, the world doesn't need another wrapper script. reconFTW and BBOT already exist, they're both mature, and thousands of hunters use them every day without complaint. But after hitting dependency hell with Python virtualenvs one too many times, and after a near miss where a manually managed scope list almost let a scan touch a subdomain that wasn't in a program's bounds, I built my own single binary recon pipeline anyway. It's called BBPTS.
This isn't a "top 10 tools" post. It's the story of why I built it, and an honest look at how a six week old passion project actually stacks up against the tools that inspired it including the places where it just doesn't hold a candle to them yet.
TL;DR: reconFTW and BBOT are more mature, more battle tested, and probably the right call for most people reading this. I built BBPTS anyway because I wanted scope enforcement and severity scoring baked into the pipeline itself, not bolted on afterward. Full story and comparison below.
The problem that started this
Every recon workflow I'd cobbled together looked the same: subfinder | httpx | nuclei, plus half a dozen other tools chained by hand, re-typed for every new program. Two specific frustrations pushed me from "annoyed" to "building something":
Dependency hell. Python-based tooling means a virtualenv per project, version conflicts between tools that both want a different version of the same library, and setup breaking on a fresh machine right when you need to start hunting. Bash-based tooling avoids the venv problem but trades it for "does this box have all fourteen CLI tools installed and on PATH."
Scope discipline was entirely on me. Bug bounty programs define scope precisely for a reason testing outside it isn't a gray area, it's the fastest way to get banned from a program or worse. Managing that scope by hand, cross-referencing a downloaded scope file against every subdomain a tool spits out, is exactly the kind of manual bookkeeping that's easy to get wrong under time pressure.
Neither problem is a knock on reconFTW or BBOT specifically they weren't built to solve either of these, and that's a fair scope decision on their part. I just wanted a tool where dependency management and scope enforcement weren't things I had to bolt on myself.
What I built
BBPTS ships as a single Go binary no virtualenv, no bash dependency chain to debug. It integrates 49+ tools across subdomain discovery, HTTP probing, and vulnerability scanning (nuclei, dalfox, ffuf, trufflehog, plus checks for JWT misconfiguration, CORS issues, mass assignment, and subdomain takeover), and it loads HackerOne/Bugcrowd scope files directly, enforcing them before any active scan runs rather than trusting me to filter results afterward. It also does CVSS 3.1 scoring on findings and keeps a differential baseline between scans, so re-running against the same target only surfaces what's new.
That's the pitch. Now the honest part.
How it actually stacks up including where it loses
Before anything else: BBPTS is six weeks old. reconFTW has years of real world use behind it. BBOT is a mature, actively developed project with a real community. Neither of those things is true for BBPTS yet, and if you need a tool you can trust today against a high stakes target, that track record gap is a completely legitimate reason to pick one of them instead.
| Tool | Language | Primary Strength | Built in Scope Check | Maturity / Track Record |
|---|---|---|---|---|
| reconFTW | Bash | Massive tool coverage & community | Manual | 5+ years, battle tested |
| BBOT | Python | Modular plugin architecture, asset graphing | Manual | Mature, active community |
| BBPTS | Go | Single binary, scope enforcement, CVSS scoring built in | Yes (H1/Bugcrowd native) | 6 weeks, experimental |
Where reconFTW wins outright: breadth. It chains more tools, has more edge cases handled from years of community bug reports, and if something breaks, there's a much larger pool of people who've hit the same issue before you.
Where BBOT wins outright: extensibility. Its plugin architecture means if it doesn't do something you need, you can write a module rather than waiting on the maintainer (me, in BBPTS's case) to get to it. The asset graphing approach also surfaces relationships between findings that a flat pipeline like BBPTS doesn't currently show.
Where BBPTS is different, for better or worse: it's the only one of the three with scope enforcement and severity scoring built into the pipeline rather than left to the hunter, and it's the only one that's a single dependency free binary. Whether that's worth trading years of maturity for is a genuinely open question I'd lean toward "try it on a low stakes target first, don't make it your only tool yet."
Two other tools worth knowing about if you're building out a recon stack: Sn1per, which goes beyond recon into scanning and exploitation and has a free Community Edition plus a paid Pro/Enterprise tier; and Osmedeus, a Go based orchestration engine built for running recon across large target lists. Neither was a direct inspiration for BBPTS the way reconFTW and BBOT were, but both are solid options depending on what you need.
Try it, or don't yet
If you want a tool with years of proof behind it, use reconFTW or BBOT that's not false modesty, it's the honest answer for most people. If you're curious about a newer, smaller, single binary alternative with scope enforcement baked in, and you're comfortable running something experimental on non critical targets while it matures:
git clone https://github.com/Developer-Army/BBPTS.git
cd BBPTS
./setup.sh
It's Apache-2.0, open source, and I'm actively using it on my own hunts which means bug reports from real usage are the thing that actually gets it out of "experimental."
FAQ
What's the difference between recon and vulnerability scanning in bug bounty hunting?
Recon is the discovery phase finding subdomains, live hosts, and exposed services that make up a target's attack surface. Vulnerability scanning comes after, testing those discovered assets for actual security issues. Most automated pipelines, BBPTS included, chain both stages together.
How do I avoid accidentally testing out of scope targets during recon?
Read a program's scope definition carefully before starting, keep the scope file as your single source of truth rather than a mental note, and where possible use tooling that checks discovered assets against that scope file automatically rather than filtering results by hand afterward.
Is reconFTW or BBOT better for beginners?
reconFTW's bash based setup is more widely documented with more existing tutorials and community threads to reference. BBOT's plugin model has a steeper initial learning curve but pays off if you want to customize your recon flow later.
Do I need to know Go or Python to use any of these tools?
No all of them are usable as CLI tools without touching the underlying code. Knowing the language only matters if you want to extend or modify one yourself.
Where can I find BBPTS if I want to try it?
github.com/Developer-Army/BBPTS — Apache-2.0, issues and PRs open.
I built and maintain BBPTS, and I'm actively using it in my own bug bounty hunting. If you try it and something breaks, that's useful information for a six week old tool open an issue on the repo.