Sn1per: inside the Community Edition of 1N3's pentest orchestration framework

The problem Sn1per exists to solve

A manual reconnaissance pass is a sequence of unrelated programs. Subdomain enumeration feeds a resolver, the resolver feeds a port scanner, the scanner feeds a fingerprinting step, and each hop needs its own flags, its own output format and its own retry logic. Sn1per's stated purpose is to collapse that sequence into one orchestrated workflow. The README describes it as a platform that "consolidates reconnaissance, vulnerability scanning, exploitation, and reporting into a single workspace," and lists four jobs it covers: external attack surface management, continuous attack surface management, automated penetration testing, and reconnaissance and attack surface discovery.

The audience is narrow and explicit. This is a tool for penetration testers and security teams running authorized engagements. The README frames it around offensive security teams that would otherwise "stitch together" the same work from a dozen tools. It is not a developer security scanner you point at your own repository, and it is not a substitute for a vulnerability management program that tracks remediation. The value proposition is orchestration and active verification, the README's claim that the platform's "active verification" cuts the false positives that "version-only scanners ship as 'critical.'"

How the orchestration actually works

The repository layout tells you more about the architecture than the marketing copy does. The top level holds a single executable named sniper, a configuration file sniper.conf, and three directories that map onto the pipeline: modes/, conf/ and templates/. Modes are the scan profiles, configuration holds the per-tool settings, and templates hold the reporting output. Work products land in loot/, which is the engagement's working directory.

The engine is Shell. That matters for two reasons. First, the orchestration model is process spawning: Sn1per calls out to third-party binaries and parses what they return, which is why the integration count is a meaningful number rather than a feature list. Second, the failure modes are the failure modes of shell pipelines. A missing binary, a changed output format, or a tool that hangs without a timeout all surface as a broken stage rather than a clean error. The README does not document per-stage timeouts or a rollback path, so a partial run is something you diagnose from loot/ rather than from the tool's own reporting.

The editions share this core. The README states that the Community, Professional and Enterprise editions are "all backed by the same core scanning engine," with the paid tiers adding a web interface, commercial integrations and email support. The pro/ directory in the repository is the visible seam between the free engine and the paid surface.

Installing Sn1per Community Edition on Kali Linux

The README's Install section points at install.sh in the repository root. The Dockerfile shows the sequence the maintainers use themselves: clone the repository, change into it, run install.sh, then run sniper with the -u flag to update.

git clone https://github.com/1N3/Sn1per.git
cd Sn1per
./install.sh
sniper -u force

The reason this is a Kali story is dependency depth. The Dockerfile starts from kalilinux/kali-rolling, runs apt full-upgrade, installs metasploit-framework, and reinitialises the Metasploit database with msfdb reinit before Sn1per is even cloned. On a non-Kali distribution you are supplying that package base yourself, and the README does not provide a per-distribution dependency list. The install.sh script is the only supported path the documentation gives.

There is a desktop entry at sn1per.desktop and an uninstall.sh beside install.sh, so the install is meant to be reversible from the repository rather than from a package manager.

Running Sn1per in Docker instead of on the host

For a tool that installs Metasploit and a PostgreSQL-backed database, the container path is the cleaner one. The repository ships docker-compose.yml with a single service named kali-linux that builds from the root Dockerfile, and a second compose file, docker-compose-blackarch.yml, paired with Dockerfile.blackarch for the BlackArch base.

docker compose up -d

The Dockerfile's own build steps run git clone, ./install.sh and sniper -u force inside the image, and the container's default command is sniper, so the image is self-contained rather than a base you finish configuring by hand. The README's 2026 release notes describe this direction as "Docker-first deployment, same image, every distro," which is the strongest argument for the container route: the distribution differences that make the host install fragile are the image's problem, not yours.

The compose file sets json-file logging with a 40 MB per-file cap and ten files retained, which is a deliberate answer to the log growth that long scans produce. What the compose file does not define is any volume mount, so the README does not document how loot/ survives container removal. Treat that as something to verify against your own compose overrides before you rely on it for an engagement.

Where the Community Edition stops

The honest limitation is the edition boundary, and it is drawn through the middle of the product rather than around its edges. The web UI, the Workspace Navigator, the CSV, Excel and PDF reporting exports, the JSON API v1.0, and the expanded modules for ReverseAPK, MassPwn, Threat Intel, Nessus and Burp Suite are all described in the README as part of the 2026 Professional release. If your workflow depends on pushing findings into a SOAR or SIEM pipeline through the JSON API, the free edition in this repository is not the thing that does it.

The second limitation is licensing, and it is easy to miss because the repository is public. The README calls the Community Edition "source-available, custom EULA" and points at LICENSE.md; the repository's licence field reports NOASSERTION, which means GitHub could not match it to a standard identifier. Source-available is not the same as open source, and the difference affects redistribution, internal tooling and anything you build on top. Read LICENSE.md before you plan around it.

The third is release cadence. The repository's releases list shows v9.2 from 2023-07-29, v9.1 from 2022-12-12 and v9.0 from 2021-01-09, while the README's headline release is the paid 2026 edition. The last push to master is 2026-07-04, so the repository is not dormant, but the tagged Community Edition releases are not where the recent work is announced. If you need the features the README advertises, check whether they are in the free tree or behind the pro/ boundary before you commit to the Community Edition.

Sn1per against a plain Nmap and Nuclei pipeline

The most direct alternative is not another platform but a short shell script of your own: Nmap for discovery, a subdomain enumeration tool, and a template-based scanner for checks. The difference in approach is real. A hand-rolled pipeline gives you a small surface you can read end to end, exact control over flags and output formats, and no dependency on a third party's integration maintenance. It also means you own the parsing, the retries and the reporting, and you rebuild it when a tool changes its output.

Sn1per's bet is the opposite: accept a large dependency surface and a shell engine in exchange for the orchestration and the detection and exploit content already written. The README puts that content at "90+ integrations," "600+ exploits" and "10,000+ detections." Whether that trade is worth it depends on how much of the surface you actually use. If your engagement is five hosts and two web applications, a hand-rolled pipeline is probably the better fit and Sn1per's breadth is overhead. If you are running repeated external surface passes across a large estate, the orchestration is the point.

Maintenance, upgrades and what to verify before adopting

Upgrades are git pulls plus the install script, not package manager transactions. The Dockerfile's own pattern is to clone, run ./install.sh and then sniper -u force, and the 2026 release notes list -u as the update path alongside new flags -v for verbose, -db for debug and -rr to remove resume files. The presence of a resume-file cleanup flag implies interrupted runs leave state behind that you may need to clear, though the README does not document what those files contain or where they live.

The maintenance cost that is easy to underestimate is the 90+ integrations. Each one is a third-party binary with its own release cycle, and the Kali rolling base the Dockerfile pins to moves continuously. A working install today can break when an upstream tool changes its output format, and the failure appears mid-scan. The repository has no dependency lock beyond the Kali snapshot you happen to build from.

On licensing, the practical points are that the Community Edition is "source-available, custom EULA" rather than a recognised open source licence, and that the Professional and Enterprise editions are commercial products with pricing pages. This is not legal advice: read LICENSE.md and, if you plan to redistribute or embed Sn1per, get your own reading of what the custom EULA permits.

Editorial conclusion

Adopt the Community Edition if you already run Kali tooling and want a repeatable recon-to-scan pass driven from one command, and if you accept a custom EULA that is not a standard open source licence. Skip it if you need a web dashboard, commercial integrations or support, because the README places those in the Professional and Enterprise editions, or if you want a small, auditable script rather than a large third-party tool surface. Before committing, read LICENSE.md in full, check which of the 90+ integrations your distribution provides, and confirm whether the modules you depend on live under pro/, which a Community Edition install may not ship.

Frequently asked questions

Official sources

1. 1N3/Sn1per on GitHub
2. Issues
3. Project website
4. README
5. Releases