XiliuxSomeone hands you a security tool with 4000 GitHub stars and the question seems obvious: do we use it? The better question is another one: what here fits, and what is debt we would inherit without noticing?
We actually did it. We cloned a popular offensive recon tool, read its 1561 lines of source —not the README, the code— and classified every capability against a single criterion: that it be keyless and sovereign. Meaning it works without depending on a keyed API, a paid service, or a third-party scrape someone can take down tomorrow.
Almost all of it was debt
- Subdomain enumeration via Google dork: blocked by a CAPTCHA. Via a third-party scrape: fragile, and not sovereign.
- Wrappers for
nmap,openssl,whois: external binaries that must be installed on every machine. Our engine is a single binary that runs on its own; adding system dependencies is going backwards. - Obsolete TLS checks: Heartbleed died in 2014. A cipher grade is not a finding anyone pays for.
- The flagship "OWASP" module: empty stubs since 2018. Never implemented.
We also looked at the rest of the author's profile —twelve more repos. The only other adjacent one was a bypass of CloudFlare's anti-bot challenges... from 2019, already dead (CloudFlare moved to opaque challenges years ago). And a scraper that solves CAPTCHAs by OCR, which also crosses our charter: we do not evade bot-detection, period. Of thirteen repositories, exactly one had anything alive for us.
We kept one vein
The genuinely payable thing was one: cloud storage data exposure. An S3 or Google Cloud Storage bucket set to public-readable or listable leaks its contents —database dumps, backups, internal files— to anyone with a browser, no credentials. It is a classic data leak (CWE-200), and it keeps showing up.
The original's discovery was weak (it only looked at the page's <img src> tags). We reimplemented it in Rust, keyless, no SDK: candidates are generated by permuting the target's name (acme, acme-backup, assets-acme…), each is probed with an anonymous GET against S3 and GCS, and the response is classified by its unmistakable signal: a ListBucketResult in the body is listable; an AccessDenied is "exists but closed"; a NoSuchBucket does not exist. With its anti-false-positive control: a 200 that is NOT a ListBucketResult —a website served from the bucket— does not count as listable.
Two things that are non-negotiable, because we are a responsible-disclosure tool, not a looter:
- Read-only. Anonymous
GETonly, with a read ceiling so we never download gigabytes. It never writes, mass-lists, or exfiltrates. - Ownership unconfirmed. The S3 namespace is global:
acme-backupsmay not be your target's. Every finding is flagged so a human confirms ownership and scope before reporting. Nothing is auto-submitted.
The lesson
A star is not a fit. What you adopt from someone else's tool is a technique, not a file; and the technique gets reimplemented under your own rules —in our case, in Rust, keyless, with tests that discriminate. The rest is discarded with its reason written down, so you don't re-evaluate it in six months. Evaluating a dependency well means, most of the time, saying no.