Trickest's inventory repository publishes continuously generated DNS and web server asset data for over 800 public bug bounty programs, usable for authorized recon and defensive visibility.
| Tool | trickest/inventory — scheduled attack surface inventory of 800+ public bug bounty programs, MIT licensed, ~1.6k stars, Shell |
| Category | Attack surface management / automated OSINT reconnaissance |
| Primary Use | Pulling pre-computed subdomain, DNS, and web server results (dns-report.csv, server-report.csv, targets.json) to accelerate authorized bug bounty and asset-discovery work |
| Safe Use | Intended for authorized security assessments, sanctioned bug bounty programs, labs, and blue-team asset visibility; all covered programs are public and in-scope by their own policies |
| Telemetry Note | The project deliberately centralizes automated scanning so defenders see consolidated, scheduled enumeration rather than ad-hoc noise; new hostnames are flagged with [x] via anew |
inventory from trickest is less a traditional tool you install and more a living dataset generated by scheduled workflow automation. The repository's tagline is attack surface management of public bug bounty programs, and the data it accumulates includes DNS records and web server information for more than 800 companies, all of which maintain public, sanctioned vulnerability disclosure or bug bounty programs. Everything you see in the repo — the per-program hostnames.txt archives, the consolidated targets.json, the CSV reports — is produced automatically by two Trickest workflows, refreshed on a schedule, and pushed back to GitHub. For an authorized researcher, this means the noisy, expensive first phase of reconnaissance has already been done for you.
The project states four explicit goals in its README, and they are worth reading closely because they reveal the philosophy. First, monitor the 800+ companies in targets.json for new assets. Second, help bug bounty hunters get productive on new programs quickly, since onboarding onto an unfamiliar scope is one of the biggest time sinks in the field. Third, give security teams better visibility into their own assets — a notable defensive framing, since internal asset inventories are notoriously incomplete. Fourth, and perhaps most interesting, reduce the load that bug bounty programs face from uncoordinated automated tooling: rather than thousands of hunters independently hammering the same domains, the workflows run once on schedule and share the results with everyone.
Architecturally, the system is split into two pipelines. The first, Inventory 3.0 - Targets, is a data consolidation layer. It ingests bug bounty program definitions from two well-known community sources: arkadiyt/bounty-targets-data and projectdiscovery/public-bugbounty-programs. Python scripts transform that heterogeneous input into a consistent format, merge programs sharing the same URL to eliminate duplication, and layer in additional programs contributed via community.json. The output is targets.json, a single deduplicated catalog of programs and their domains. This file alone is valuable as a machine-readable index of the public bug bounty landscape.
The second pipeline, Inventory 3.0, does the actual enumeration, and the README documents it in commendable detail. It starts by extracting the program list from targets.json and passing it through a file-splitter node so the workflow fans out in parallel, one branch per program. This per-program distribution is what makes the whole effort tractable at 800-plus targets, and it mirrors how a senior operator would structure a large-scope engagement: shard, parallelize, and standardize the per-target pipeline.
The enumeration itself is a textbook passive-then-active progression. The passive stage combines three subdomain discovery engines — subfinder and findomain from the projectdiscovery and Findomain ecosystems, plus vita — and supplements them with mksub, Trickest's own subdomain generator, to synthesize candidate names. Resolution is handled by puredns using the trickest/resolvers list, and a custom bash script mines the passive results to build custom wordlists tuned to the naming conventions each organization actually uses. That last detail is the mark of a mature pipeline: derived wordlists almost always outperform generic ones.
Active enumeration then takes the passive findings, builds a fresh brute-force wordlist, and uses dsieve to enumerate environments per subdomain level — separating, for example, staging from production naming tiers. New candidate subdomains come from mksub again, this time seeded with the derived wordlist plus a curated level2.txt list from the trickest/wordlists repository, and everything is re-resolved with puredns. A permutation stage follows: active and passive results are merged, environments re-extracted with dsieve, and alterx generates permutation candidates that are resolved once more. The result is a much widerhostname corpus than any single technique would produce.
Reporting is where the dataset becomes directly consumable. A Python script collects the per-program hostnames.txt files from prior runs, and anew — TomNomNom's append-new utility — diffs the current run against history, so genuinely new hostnames are marked with [x]. This new-asset flag is the single most operationally useful feature of the repo: watching for [x] entries on a program you research is effectively a free new-asset alerting service. Final resolution uses dnsx for a dns-report.csv and httpx for a server-report.csv, both pushed to the repository alongside zipped per-program archives of active, passive, and permutation results.
The tooling choices throughout are worth studying even if you never consume the dataset. Every component is best-in-class open source: subfinder, findomain, vita, mksub, puredns, dsieve, alterx, dnsx, httpx, anew. The workflows effectively serve as a reference architecture for building your own ASM pipeline, whether on Trickest's commercial platform — which the README markets, unsurprisingly — or reimplemented in cron jobs, CI runners, or a homegrown orchestrator. The sequencing of passive collection, custom wordlist derivation, environment-tiered active enumeration, permutation expansion, and historical diffing is a pattern you can lift wholesale into internal tooling.
There is a defensive angle that the README itself calls out. Security teams can point their own monitoring at this dataset (or replicate the workflow internally) to get continuous external asset visibility — the same data an attacker's recon phase would surface, delivered on a schedule. Because the enumeration is centralized and published rather than run ad hoc by hundreds of separate hunters, program owners also see less redundant automated traffic. From a blue-team telemetry perspective, activity originating from this project is structured, scheduled, and observable, which is far preferable to distributed scan noise.
Consumption is straightforward and entirely passive from your side: clone the repository with git clone https://github.com/trickest/inventory and work from the checked-in JSON and CSV files, or fetch specific artifacts like targets.json or a program's archive directly. There is nothing to install beyond git, and you contribute new programs via pull requests against community.json. Contributions, ideas, and target suggestions are explicitly welcomed through PRs, Twitter, or the project's Discord.
Caveats are few but real. The repository is a marketing surface for the Trickest platform, so the workflow screenshots and sign-up links are part of the pitch; the data, however, stands on its own under an MIT license. As with any third-party dataset, verify that specific hostnames fall within a program's declared scope before touching anything beyond passive DNS lookups — targets.json is a starting point for scope research, not a substitute for reading each program's policy. Used within those boundaries, inventory is one of the highest-leverage free resources in public bug bounty reconnaissance, and a genuinely instructive example of automated attack surface management done thoughtfully.
trickest/inventory.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.