DeepSec's scope manifest refuses unauthorized targets rather than warning about them

Three detection layers, each with a stated time budget and a stated method

Shield is not one scanner. It is three, distinguished by what they can detect and what they cost.

L1 runs in under fifty milliseconds and uses regex, entropy analysis and a directory of known seeds. It looks for hallucinated packages, hardcoded secrets, insecure configuration and AI error patterns, which is the class of defect that appears specifically when code is generated rather than written.

L2 runs in under two seconds and uses Tree-sitter WASM AST analysis rather than pattern matching. It covers SQL injection, XSS, SSRF, path traversal and command injection, so the injection family is handled by structure.

L3 runs in under five seconds and uses a language model, with DeepSeek, Claude, OpenAI and Ollama named, plus a local heuristic fallback. It targets semantic gaps: missing authentication, missing rate limiting, missing validation.

The command surface reflects the split. A plain scan is L1 and L2 and works offline:

deepsec shield scan ./src
DEEPSEEK_API_KEY=... deepsec shield scan ./src --layer l3
deepsec shield scan . --format sarif --output deepsec.sarif
deepsec shield scan . --stream

Two auxiliary commands exist alongside it: shield agent-audit for auditing an agent configuration, and shield supply-chain check for the dependency picture.

One dependency detail explains the provider list. The only language model SDK in the package is openai at 1.30.0 or newer, so DeepSeek, Claude and Ollama are reached through a compatible interface rather than four separate clients.

The scope file is an allowlist checked in the backend, not a prompt instruction

Spear is the automated penetration side, and everything about how it is invoked is about authorisation.

A run requires a scope file:

deepsec spear run https://authorized-target.example --authorized ./scope.json
deepsec spear recon https://authorized-target.example --authorized ./scope.json

The rules are stated as boundaries rather than warnings. Targets outside the whitelist are refused with the message target ... is not present in the scope manifest. Private, loopback and non-public addresses are blocked separately, so an allowlisted name cannot be used to reach an internal network. And the whitelist accepts only assets you own or have written authorisation for, which is why any third-party production domain absent from targets cannot be attacked.

The file lives at ~/.deepsec/targets/scope.json by default and can be signed. Setting DEEPSEC_SCOPE_SIGNING_KEY and running deepsec scope sign produces a file whose integrity can be verified, so a target list cannot be quietly edited between approval and use.

The terminal workbench manages the same list through slash commands, and the normalisation rules are spelled out: scheme and host lowercased, a trailing slash removed, duplicates dropped, matching the backend's own comparison.

Inside the workbench, Plan mode is read-only and cannot arm Spear at all, so an exploratory pass cannot become an attack. Pressing Y confirms the authorisation check and starts; Esc cancels. Ctrl+C aborts the running task while keeping the workbench open, and only exits it when idle.

Spear runs a six-stage pipeline over forty skill packs and five roles

The engine is described as end-to-end automation with a named sequence: Recon, Explore, Fact, Reflect, Report, PoC.

The skill packs are the recognisable reconnaissance and exploitation tools, including nmap, dirsearch, subfinder, nuclei, sqlmap, ffuf, httpx and feroxbuster, described as forty or more in total.

On top of that sit five roles, which determine what a given run is allowed to reach for: pentester, redteam, auditor, blueteam and ctf_player. Two introspection commands make that concrete:

deepsec spear roles
deepsec spear tools --role pentester

So the tool set is not a flat list. Asking what a role can do is a supported query rather than something you infer from documentation.

The scope is signed, time-limited and written to an audit log, which makes an engagement reproducible: there is a record of what was authorised and when it expired.

Output is visualised as an attack chain and written in four formats, Markdown, SARIF, JSON and HTML. SARIF matters more than the others for tooling, since it is what lets a finding land in a code scanning dashboard rather than in a document somebody has to read.

The engine was migrated in from a project called VulnClaw, which is visible in the history rather than hidden.

There are two terminal workbenches, one in Rust and one in Python

This is worth spotting in the manifests, because it is not obvious from the documentation.

The entry points declare two workbenches. The Python one is deepsec-tui, mapped to deepsec.cli.tui:main, and the package depends on textual at 0.40.0 or newer, which is the Python terminal UI framework.

The Rust one is separate. It is built from tui/Cargo.toml and the resulting binary is named deepsec-tui-native. Its documentation describes it as built on Rust and ratatui, with the interaction design borrowed from DeepSeek-TUI.

The richer feature list belongs to the Rust workbench: a three-panel layout of workspace sidebar, session log and vulnerability inspector; Plan, Agent and YOLO execution modes; a slash command system with command history replay; Side-Git snapshots; and session persistence with Ctrl+S to save and Ctrl+R to restore.

The container images start the Python one. The Dockerfile's entrypoint is deepsec with a command of tui, and the compose file does the same with command: ["tui"], which resolves to the Typer CLI and then to the textual entry point.

The Docker build keeps the Rust binary alongside it. A first stage on rust:1-bookworm compiles tui with --release --locked and only the resulting executable is copied into the final python:3.12-slim image, so the shipped container has no Rust toolchain in it.

Side-Git snapshots put a revert around a scan that rewrites your code

Several DeepSec commands modify a working tree. The snapshots exist for that reason.

The lifecycle is three commands:

deepsec snapshot create . --mode shield --description "before-refactor"
deepsec snapshot list .
deepsec restore <snapshot-id>

A snapshot records a named code state, tagged with the mode that produced it and a description, and a restore puts it back by identifier. Because the metadata is a mode and a sentence rather than a timestamp alone, a list of snapshots reads as a record of what you were doing at each point.

That is a meaningful design position for a tool that applies fixes. The editor extension registers commands for applying a fix, applying a finding fix, and applying all safe fixes or all pro fixes, so an automated remediation path exists. A revertible checkpoint is the precondition for letting an agent run it.

The workbench adds session persistence alongside it: Ctrl+S saves and Ctrl+R restores, so an interactive session survives the same way the code does.

Both features are described as TUI capabilities, Side-Git among the Rust workbench's feature list, which means the guardrail is attached to the interactive surface rather than to the CLI.

The VS Code extension manifest is marked private, so it is not on the marketplace

The extension manifest describes a full editor integration and then prevents it being distributed.

package.json sets private to true, which means it cannot be published to the Visual Studio Code Marketplace. The same file names publisher unclecheng, version 0.2.0, and the MIT licence, so the intent to open the code is present; only the distribution step is withheld.

Everything else is a conventional extension. It targets Visual Studio Code 1.92.0 or newer, declares itself a workspace extension, and categorises under Linters, Programming Languages and Other. Two binaries are registered, deepsec-vscode and deepsec-lsp, the latter being the language server behind the in-editor findings.

The activation list is long: startup finished plus sixteen commands and views, covering scanning the current file, scanning the workspace, scanning with AI, running Spear, syncing a package cache, exporting a dashboard, setting and deleting an API key, showing status, applying fixes individually or in bulk, and two contributed views.

Two entries in that list are unexplained by anything visible here. A command for showing subscription status implies some account or tier concept, and a sync for a package cache implies a registry the scanner consults. Neither is described in the README, so treat both as surfaces to ask about rather than features to rely on.

Alpha by classifier, with two earlier project names still visible in the tree

The project has absorbed two predecessors and has not finished tidying the evidence.

The README states that DeepSec evolved from VibeGuard, and that Spear was migrated in from VulnClaw. Both names survive in the tree. One recent release tag is titled VibeGuard v0.1.5, published alongside v0.1.4 on the same day in July 2026. The demo directory contains vibeguard-demo.ass, an advanced subtitles file that has nothing to do with security tooling.

Meanwhile the classifier says Development Status :: 3 - Alpha, which is the honest label for a platform whose newest release is v0.2.0 from August 2026.

The runtime floors are stated clearly and are wide. The Python package requires 3.10 or newer, and the tomli dependency is conditional on Python below 3.11, which is consistent with that floor rather than an accident. The container runs python:3.12-slim and the Rust stage is rust:1-bookworm, so the built artefacts target newer interpreters than the declared minimum.

Dependencies use lower bounds throughout rather than pins, with typer, rich, prompt_toolkit, httpx, openai, pydantic, pyyaml, jinja2, textual, beautifulsoup4, lxml, pycryptodome and tree-sitter. pycryptodome is what makes the scope signature possible. Optional extras cover pytest for development, reportlab for PDF output, and mitmproxy with playwright for traffic work.

The repository ships a file full of deliberate vulnerabilities so you can see it work

The onboarding path is unusually direct, and it depends on a purpose-built sample.

The three-minute quickstart is to download deepsec-tui-windows.exe from the releases, double-click it, and type a slash command naming your project. A vulnerabilities result is expected in about two seconds.

The reason that claim is credible is that the repository includes demo/unsafe-ai-sample.ts, described as a file deliberately written full of vulnerabilities. Scanning it is the way to see the scanner fire, and demo/README.md sits alongside it.

For anyone who does not want a binary, the install path is pip install -e . for the Python core and CLI, with the Rust workbench optional via cargo build --manifest-path tui/Cargo.toml. The editor plugins are built from the same checkout, with F5 in the project root for Visual Studio Code and a Gradle buildPlugin task under jetbrains for JetBrains.

Configuration is a single YAML file at ~/.deepsec/config.yaml, created and inspected with deepsec config init and deepsec config show, with individual values set by path such as deepsec config set llm.provide.

The container path redirects HOME and DEEPSEC_HOME to /data so state and configuration land in a mounted volume rather than in the container layer, which is why the compose file declares a named volume alongside the workspace bind mount.

Editorial conclusion

This fits someone reviewing AI-generated code who wants to know whether the model invented a package or skipped an auth check, and someone running an authorised engagement who wants the target list to be machine-enforced rather than a promise in a prompt. It does not fit an unscoped engagement, because there is no path that omits the scope file, and that is deliberate. Two things to check before you rely on it. The classifier says alpha, and two of its release tags still carry the names of the projects it absorbed, so treat the version numbers as unstable. And the VS Code extension manifest is marked private, which means the in-editor integration is a development-host experience rather than a published extension. The last push is dated 2026-08-24.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Unclecheng-li/DeepSec on GitHub