Philosophy & design

... or the core concepts behind the pillars of secator.

---

Why do we need another tool ?

Traditional pentesting sessions can be a pain:

• Use of dozens of commands (each very good at what it does)

• Each command has different options

• Each command outputs results in a different format

Here is for instance a basic host scan that we run day-to-day on many targets:

Standard

naabu -Pn -silent -host example.com -json -rate 10 -c 50 > open_ports.txt
nuclei -silent -sj -si 20 -hm -u example.com -jsonl -tags network,ssl -proxy socks5://tor-privoxy:9050 -rate-limit 10 -c 50
httpx -silent -td -asn -cdn -l open_ports.txt -json -proxy socks5://tor-privoxy:9050 -rate-limit 10 -threads 50 -match-code 200,204,301,302,307,401,403,405,500
katana -silent -jc -js-crawl -known-files all -u example.com -json -proxy socks5://tor-privoxy:9050 -rate-limit 10 -concurrency 50
echo https://example.com | cariddi -info -s -err -e -ext 1 -json -proxy socks5://tor-privoxy:9050 -c 50

Secator

With secator the goal is to unify all these awesome tools by creating an abstract layer for input and output, such that all tools "speak" the same language and we can mutualize options that will apply to all tools, unlocking the ability to run complex workflows.

---

Who is it made for ?

• Bug-bounty hunters

• Pentesters

• Security researchers

• Companies of any size

---

Why is the license BSL ?

We believe in open-source 100%.

Freelabz founders have written code for open-source for as long as they started working in the tech industry. secator is and will remain free-to-use, forkable and open to community contributions forever, and we believe in the collective to make it one of the de-facto tools in the security world.

However, Freelabz is a young company that is seeking to make a living and pay its workers correctly. We are working on a paid product derived from secator and BSL allows us to restrict commercial uses of secator by big tech actors who could profit from its success. All standard OSS rules still apply, which means you can still read / fork / modify it, use it in other OSS projects, and even use it in production as long as you don't sell a service based on it.

Feel free to reach out to us if you want to use secator in a commercial tool, and we will review your request on a case-by-case basis.

---

Design principles

Curated list of tools

Tools integrated to secator MUST be fast, efficient, well-maintained, and have structured output (either JSON, JSON lines, CSV, or XML).

We do make exceptions for really awesome tools and write custom parsers (e.g: nmap).

Unified input options

secator tools belonging to the same category (eg: fuzzers) MUST end up with mutualized input options, while still retaining the capability to use unique options for each command.

Unified output schema

Tools belonging to the same category MUST have unified output types, allowing you to run multiple commands and aggregate results quickly.

CLI and library usage

When secator is called as a library from other Python code, the output MUST be structured (list of dicts). Results MUST also be yielded in realtime.

When secator is called as a CLI, various Exporters MUST be available, such as csv, json, txt, or table.

Distributed options

secator MUST work in both synchronous mode (default) and distributed mode.

Switch from synchronous to distributed when you want to increase the scanning speed MUST be easy, by simply configuring Celery worker with your broker and results backend of choice.

From simple tasks to complex workflows

secator MUST be useful for running simple tasks like in CTFs, bug-bounties or hackathon, or to automate entire workflows.

Customizable

secator MUST be customizable, so that the community can contribute tasks, workflows, and scans to the repo if they can serve the greater good.

---