1337 Security Workbench
Open security workbench · Live Security Object Model · Modular tooling
Explore the system.
Build the model as you work
A fast, local-first workbench for penetration testing, security investigations, and security engineering. Built-in discovery creates the initial model; built-in and external tools continuously enrich it with observations, evidence, findings, relationships, reachability, and attack paths.
Models reason. 1337 keeps state, governs execution, and preserves evidence
One live model instead of disconnected tool output
Start with a useful baseline
1337 can discover targets, hosts, services, endpoints, technologies, and relationships on its own. As additional tools and data sources are connected, the model is refined and expanded.
Every tool contributes to the same model
Nmap, Nuclei, browsers, Kali toolsets, imported artifacts, and external systems add traceable observations to one model instead of leaving behind disconnected reports.
Long-running jobs do not block the operator
Commands run on the left while the selected model view updates on the right in real time: objects, evidence, findings, attack paths, or timelines.
From initial discovery to a durable Security Object Model
Built-in discovery
↓
Security Objects
↑
Tools / Sources
↓
Observations + Evidence
↓
Findings + Relationships
↓
Reachability / Attack PathsBuilt-in discovery creates the baseline. Your tools enrich it
Tools are part of the workbench, not bolted on. Built-in checks, familiar command-line tools, browsers, load generators, external scanners, and integrations all contribute to one workspace instead of producing separate data silos.
The core runs locally and requires no mandatory endpoint agents. Heavy scanners, Kali toolsets, browser runtimes, search indexes, and vendor connectors are enabled only when needed.
One model, four initial workflow lenses
Attack surface and attack paths
Discovery, findings, credentials, footholds, pivots, reachability, attack paths, and controlled validation — with direct access to familiar tools.
Evidence and attacker reconstruction
Provenance, artifacts, IOCs, timelines, relationships, confidence, and evidence-backed reconstruction. Every material conclusion remains traceable to source evidence.
From source to runtime
Source code, dependencies, SBOMs, images, deployments, APIs, runtime relationships, findings, and reproducible security gates in one model.
Attack, detection, control, retest
Link authorized offensive actions to telemetry, detections, defensive controls, and retest results in the same model.
Core architecture
Security Object Model
A shared model for targets, assets, services, endpoints, identities, evidence, findings, relationships, reachability, and attack paths.
Built-in Discovery (Native Discovery)
Builds the initial black-box model without requiring external scanners or integrations.
Modular Tooling
Built-in engines and replaceable external providers expose capabilities without tying the workbench to one scanner or distribution.
Evidence & Provenance
Observations and conclusions remain traceable to source, authorized scope, time, tool, executor, and supporting artifacts.
Scope & Policy
Explicit authorization and impact constraints govern execution without becoming the product itself.
Lenses & Interfaces
TUI, Web, API, SDK, MCP, CI, and AI use the same underlying state through workflow-focused views.
One Security Object Model · Multiple lenses · Any suitable tool
M4 showcase: reproducible attack paths
M4 is planned as a repository-owned Docker Compose lab with three attack-path scenarios over the same 1337 model. Users should be able to run the lab locally, assess it with authorized tools, inspect the evidence, validate an attack path, apply a security control, and recompute the graph.
Internet → Customer Portal → Identity → Billing API → Critical Business Action
Internet → Support Portal → User Identity → SSO/IAM → Admin Console
Repository → CI Job → Runner → Artifact Registry → Deployment → Production
Which paths to critical assets are actually reachable, what evidence supports them, and which security control breaks the chain?
M4 is roadmap work and is not part of v0.1.8. The goal is a reproducible Docker Compose lab, not a prerecorded demo.
Run the lab · reproduce the issue · validate the path · verify the fix
What works today
A working, reproducible pre-alpha foundation
- Apache-2.0 open-source core
- installable 1337 and 1337-dev commands
- Command Registry foundations
- repository-owned isolated test lab
- pytest-based functional test framework
- public versioned contracts and architecture documentation
- deterministic quality gates across supported platforms
In development
- live split-pane terminal workbench
- built-in discovery and a minimal Security Object Model
- pluggable scanners and tools, plus Quick Scan
- Pentest, DFIR, DevSecOps, and Purple Team workflow lenses
- evidence, reachability analysis, and attack paths
- API/SDK/MCP and vendor integrations
A capability is considered implemented only when it is backed by code, tests, and public contracts. Everything else remains explicitly roadmap work
Project resources
Responsible use
1337 is intended for defensive security engineering, authorized penetration testing, investigations, training, research, CTF/lab environments, and systems you own or are explicitly authorized to test.
Do not use the project to scan, probe, exploit, or disrupt third-party systems without authorization.