# secator turns dozens of security tools into one workflow runner > secator is a Python task and workflow runner for security assessments that wraps dozens of well known tools behind unified input options and a unified output schema, and can distribute those tasks over Celery workers. It is published under the BSL 1.1 for non-commercial use, and the last push was on 2026-10-15. **freelabz/secator** — secator - the pentester's swiss knife - Repository: https://github.com/freelabz/secator - Website: https://docs.freelabz.com - Stars: 1,323 · Forks: 138 - Language: Python - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/freelabz-secator ## A runner over tools you already have to install secator describes itself as a task and workflow runner used for security assessments, supporting dozens of well known security tools and designed to improve productivity for pentesters and security researchers. The tagline in the repository header calls it the pentester's swiss knife. The first thing to understand is that secator does not implement scanning itself. It is a front end to a curated list of commands, and the README's supported tools table makes that concrete: arjun for HTTP parameter discovery, arp-scan for CIDR host discovery, bbot as a multipurpose scanner, cariddi for crawling endpoints and secrets, dalfox for XSS scanning, dirsearch and ffuf and feroxbuster for content discovery, dnsx for DNS work, gau for fetching known URLs from public archives, gf as a grep wrapper, gitleaks for detecting secrets in git repositories, gospider and katana for crawling, grype for scanning container images and filesystems, h8mail for email lookups, httpx for HTTP probing, jswhois for WHOIS data in JSON, and more. Each entry is tagged with a category such as url/fuzz, ip/recon, vuln/scan, secret/scan or pattern/scan. That categorisation is the interesting part of the table, because the categories are secator's own vocabulary rather than each tool's. A tool belongs to a category, and a category maps to a kind of task, which is what makes it possible to build a workflow that chains a crawler into a secret scanner without the workflow author knowing which binary does what. The practical consequence is that secator is an orchestration layer, not a replacement. The tools it drives still have to be present on the system, and secator's own Docker image installs a set of them as part of the build. ## Unified input options and a unified output schema The feature list names two ideas that do most of the work: unified input options and a unified output schema. Together they are what turn a pile of tools into a workflow system. Unified input options means that the way you specify a target or an option does not change when you switch tools. The README's feature list also includes CLI and library usage, so the same commands are available as an importable Python API, and complexity from simple tasks to complex workflows, which describes the range between running one command and chaining many with dependencies. The unified output schema is the part that pays off over time. Every tool's findings come back in one shape, so a workflow can take the output of a crawl, pass it into a scanner, and write the result in one format without a bespoke parser per tool. The dependency list supports that: orjson for fast serialisation, pydantic for validation, and rich for terminal output, with rich-click providing the command line interface. jinja2 is there for templating, so reports and output formats can be generated rather than hand written. The rest of the feature list covers the operational side. Distributed options with Celery means a workflow can be split across workers, Customizable means the tool set, the categories and the output can be extended, and the whole thing is usable both from the command line and as a library. The data model is also worth noting. The pyproject.toml declares a bundled CISA KEV mirror as a build artifact, with a comment explaining that hatchling excludes VCS-ignored files by default and the mirror has to be shipped explicitly. That file is the offline fallback for the kev vulnerability tagging, so a known exploited vulnerability catalogue is available without a network call. ## Celery, Redis and MongoDB are how the work leaves your laptop The distributed mode is not a side feature, and the deployment files show what it takes. The docker-compose.yml defines three services, with the client and worker built on freelabz/secator:latest. The secator service is the client, started with an empty entrypoint and a tail -F /dev/null command so the container stays alive, and the worker service runs the command 'worker'. Both point at a redis service for the Celery broker and result backend, using SECATOR_CELERY_BROKER_URL=redis://redis:6379/0 and SECATOR_CELERY_RESULT_BACKEND=redis://redis:6379/0. The package.json in the repository root drives the same arrangement from the host for development. The solo script creates a virtual environment, installs the package with the gcs, redis, worker, dev and mongodb extras, and runs a worker. The dev script adds SECATOR_CELERY_BROKER_URL and SECATOR_CELERY_RESULT_BACKEND pointing at redis://localhost:6379 and turns on SECATOR_ADDONS_MONGODB_ENABLED=1. There are npm scripts for starting and stopping redis and mongodb containers, and docker:start-all to bring the whole stack up. The Dockerfile is where the interesting engineering shows. It is a two stage Alpine build, with an alpine:3.21 builder where pipx installs the package and a set of addons are installed, including worker, gdrive, gcs, mongodb, redis, ai and dev. The runtime stage is python:3.12-alpine3.23 and copies the installed environment across. It then configures sudoers so the secator user can run nmap, arp-scan and arp with NOPASSWD, explicitly so that privileged scans work, and it allows the user to install commands and to symlink libpcap. That sudoers configuration is the detail that matters most for a security tool in a container: it grants passwordless root for a specific set of binaries, which is a deliberate and bounded privilege grant rather than a blanket one. The image also sets the flavour with an ARG and supports building from source. ## Addons are how the tool set extends The addon mechanism appears in the Docker build, in the environment variable SECATOR_ADDONS_MONGODB_ENABLED, and in the repository layout, and the Dockerfile shows the categories the project itself ships: worker, gdrive, gcs, mongodb, redis, ai and dev. What an addon does is not spelled out in the README, so the honest statement is that the mechanism is first class and the project's own addons cover the distributed execution stack, cloud storage integrations, database backends and an AI integration. The CONFIG.md file at the top of the repository, along with the docs/ directory and the documentation site at docs.freelabz.com, is where the configuration surface is described. The repository also has a SECURITY.md, a CONTRIBUTING.md, a CHANGELOG.md and a CLAUDE.md, plus a .coderabbit.yaml and a .claude/ directory, which indicates the project has put the same tooling conventions in place as the other projects in this set. The helm/ directory and cloudbuild.yaml suggest the container image is built and published through Google Cloud Build and then deployed with Helm, and the Dockerfile has a separate Dockerfile.dev alongside the main one. The security posture of the project itself deserves a mention given what it does. There is a SECURITY.md, the maintainers publish a Discord server, a Twitter account and a YouTube channel under the freelabz name, and the package metadata lists FreeLabz with a sales email. The project is a company product with an open source core, which is relevant to the licensing question below. ## The licence is the constraint to read first The licence situation is unusual and it is the first thing to check if you plan to use secator at work. The README badge points at the LICENSE file and labels it BSL 1.1. The package classifiers in pyproject.toml say License:: Free for non-commercial use, and the project is published on PyPI as secator at version 0.49.2. The GitHub listing records the licence as a custom one GitHub cannot classify, which is consistent with the BSL being a source-available licence rather than one of the OSI approved ones GitHub recognises. The BSL is a middle position. It is designed so that a project can be used freely for non-commercial purposes and becomes available under an open source licence after a set period. Before you rely on that, read the LICENSE file in the repository, because the terms that apply to you depend on the specific version of the licence text and on how you use the software, and this is not legal advice. The other metadata tells you the maturity. The development status classifier is 3 - Alpha, the supported Python versions run from 3.8 to 3.11, and the operating system classifier is Unix. The requires-python is >=3.8, and the dependency pins are all upper bounded, with an unusual pair of constraints on validators, one of which carries a comment explaining that 0.34 or newer is needed for domain lookups with underscore hostnames. The release cadence is fast. v0.49.0 came on 2026-10-04, v0.49.1 on 2026-10-05 and v0.49.2 on 2026-10-09, with the last push on 2026-10-15. A patch release every day or two is normal for a project that tracks dozens of upstream tools, and it also means pinning a version matters. ## Where secator is the wrong choice The first limitation is the one the project is most candid about. It is an alpha, it is classified for non-commercial use, and its interface is a thin abstraction over tools that have to be installed separately. If your goal is to scan one host for one class of issue, the direct tool will be simpler, better documented by its own author, and one less layer to debug when something does not behave as expected. The second is the abstraction tax. Unified options and a unified output schema are exactly what you give up to get portability between tools. A workflow that needs a behaviour specific to one scanner, an unusual flag combination or a tool's own output format will find those things hidden behind the common shape. The richer your workflow, the more you are working around the abstraction rather than with it. The third is the operational weight. Running the distributed mode means Redis, Celery workers and optionally MongoDB, and the Docker image grants passwordless sudo for a set of binaries so that privileged scans work. That is a real security decision for any environment that runs the worker near anything sensitive, and the README does not discuss how to lock that down for a shared deployment. The fourth is that a workflow runner multiplies the blast radius of a mistake. A single scan against one target is one tool's behaviour. A chained workflow that enumerates, then fuzzes, then tests bypasses against what it found will do all of that as part of one run, and the person who wrote the workflow is the one who chose the chain. ## Conclusion secator suits a pentester or security researcher who already knows the individual tools and wants one interface, one output format and repeatable workflows instead of a shell history, and it is the wrong tool for someone who wants a single scanner with a good interface. Before adopting it commercially, read the LICENSE file, because the repository is licensed under the BSL 1.1 and the package classifiers say free for non-commercial use, which is a real constraint on company use. Verify first that the tools you need are in the supported list and installed, since secator orchestrates external binaries rather than replacing them. ## FAQ ### What is secator? secator is a task and workflow runner used for security assessments. It integrates dozens of well known security tools and gives them unified input options and a unified output schema, and it can be used from the command line or as a Python library. ### Which tools does secator integrate? The supported tools table lists tools such as arjun, arp-scan, bbot, cariddi, dalfox, dirsearch, dnsx, feroxbuster, ffuf, gau, gf, gitleaks, gospider, grype, h8mail, httpx, jswhois and katana, each tagged with a secator category such as url/fuzz, ip/recon, vuln/scan or secret/scan. ### How does secator run tasks in distributed mode? Distributed runs use Celery with Redis as the broker and result backend. The docker-compose file defines a client container, a worker container and a redis container, with the client and worker on freelabz/secator:latest and redis on redis:latest, configured through SECATOR_CELERY_BROKER_URL and SECATOR_CELERY_RESULT_BACKEND. ### What licence is secator released under? The README badge points at the BSL 1.1, and the package classifiers say free for non-commercial use, with the project also marked as alpha status. The repository licence is a custom one GitHub cannot classify, so the LICENSE file should be read directly. ### Does secator need the underlying security tools installed? Yes. secator is a runner over external commands rather than a scanner in its own right. Its Docker image installs a set of tools during the build and configures sudoers so nmap, arp-scan and arp can run with elevated privileges for privileged scans. ## Sources - [freelabz/secator on GitHub](https://github.com/freelabz/secator) - [Issues](https://github.com/freelabz/secator/issues) - [Project website](https://docs.freelabz.com) - [README](https://github.com/freelabz/secator/blob/main/README.md) - [Releases](https://github.com/freelabz/secator/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/freelabz-secator