The AI security scanner that shows its work.
Local AppSec Lab is an open-source application security scanner and portable Agent Skill. It reads your source, tests your running app in a sandbox, and tells you what it proved, what it only suspects, and what it never got to.
python -m pip install local-appsec-labUser input reaches a SQL query
orders/api.py:88 · verified by a fresh workerPossible server-side request forgery
webhooks/fetch.py:41 · not yet provenAdmin role checks
No access policy configured, so nothing was triedThe problem
Most scanners hand you a number. Not an answer.
- Pattern matches with no proof, so real bugs drown in noise
- Source and secrets sent to someone else’s cloud
- “0 issues” can mean “never tested”, and you can’t tell
- Confirmed findings carry evidence from a fresh verifier
- Runs on your machine. Model workers are opt-in and budget-capped
- Skipped and blocked checks are listed, never hidden
Illustrative numbers.
Plan first. Then authorize.
Review mode never executes your code. Active testing needs an explicit authorization tied to the exact plan you inspected.
Inspect
Inventories files, routes and dependencies, then runs bounded Python data-flow analysis for candidates.
$ appsec-lab inspect --project .Plan
Prints exactly what would run, plus a plan_digest fingerprinting your configuration.
$ appsec-lab plan --project . plan_digest: 7f3a…c91e
Scan
Specialist workers analyse the code. A fresh verifier process tries to confirm each finding on its own.
$ appsec-lab scan --project . --mode reviewTest live
Optional. Boots the app in an isolated sandbox with disposable services, then probes via scoped HTTP and Chromium. Refused if the config changed after planning.
$ appsec-lab scan --mode local-active \
--authorize --plan-digest PLAN_DIGESTReport
JSON, Markdown, offline HTML and SARIF. Candidates and untested checks stay in view.
$ appsec-lab report --run latest --format htmlReads, never runs
Static analysis only. Application code is not executed. The right first run on any repository.
Runs, but sandboxed
Seatbelt or Docker isolation, synthetic data, and an authorization bound to your plan digest.
Security scanner features
Implemented, not promised.
Everything here ships today and is backed by the project’s validation docs.
Follows tainted data across functions.
File, route and dependency inventory, deterministic candidates, and bounded interprocedural Python provenance. Semgrep adds JS/TS taint rules.
Verified by someone else.
Distinct roles with parent-owned shared knowledge. Every finding is re-checked by a fresh verifier process.
Sandboxed by default.
macOS Seatbelt and Docker Linux containers. Experimental Linux bubblewrap.
No API key needed.
Deterministic scans need no model subscription. AI workers are opt-in, capped by tokens, and send only redacted context.
Real flows, rolled back.
Synthetic access policies, multi-step workflows with rollback, bounded schema fuzzing, and Playwright/Chromium.
Pinned and defanged.
Integrity-pinned wheels and npm packages with lifecycle scripts disabled. Disposable PostgreSQL and Redis from constrained Compose.
Four formats. Three offline scanners.
Semgrep, OSV-Scanner and Trivy run offline with explicit database updates and staleness reporting.
Use cases
Security scanning for the way you actually build.
Review what your agent wrote
Run a static review on code from Claude Code, Codex or Cursor before it ships, and get evidence for every confirmed issue.
Test the running app
Boot your app in a sandbox with disposable services and probe it with scoped HTTP and Chromium workflows.
Keep code on your machine
Deterministic scans need no cloud upload and no API key. Model workers are opt-in and budget-capped.
Feed your existing tools
Export SARIF for code-scanning dashboards, or JSON, Markdown and offline HTML for reviews.
Download & setup
Install the scanner in minutes.
Needs Python 3.11+. Active execution also needs a supported isolation backend; browser and database workflows need Docker with Linux containers.
Fastest route. Use a virtual environment, then check your setup.
# install the CLI and the portable skill python -m pip install local-appsec-lab appsec-lab doctor # first run: static review, executes nothing appsec-lab inspect --project /path/to/application appsec-lab scan --project /path/to/application --mode review appsec-lab report --project /path/to/application --run latest --format html
Clone and install in an isolated environment.
git clone https://github.com/aviqentech/local-appsec-lab.git cd local-appsec-lab python3 -m venv .venv . .venv/bin/activate python -m pip install . appsec-lab doctor
PowerShell, without activating scripts or changing the execution policy.
git clone https://github.com/aviqentech/local-appsec-lab.git cd local-appsec-lab py -3 -m venv .venv .\.venv\Scripts\python.exe -m pip install . .\.venv\Scripts\appsec-lab.exe doctor
Install the skill so your coding agent can drive the engine. Installing files, invoking a skill and running model workers are separate capabilities.
# every supported host, user-wide python -m local_appsec_lab.install --global --target all # or one project, one host python -m local_appsec_lab.install --project /path/to/application --target codex
Know the limits.
Experimental release
This is an early release. Use it on repositories you own or are authorized to test.
Evidence, not certification
Reports list what was tested and what wasn’t. A clean run is not proof an app is secure.
Bounded analysis
Data-flow analysis is deepest for Python, with JS/TS covered through Semgrep taint rules.
Your policies, your rules
Access tests use synthetic policies you define. It doesn’t guess your business logic.
Asked a lot.
What is Local AppSec Lab?
Local AppSec Lab is an open-source, local-first AI security scanner and application security engine from Aviqen Technologies. It combines source review, bounded data-flow analysis and optional sandboxed testing of your running app, then reports evidence-backed findings.
Is it a SAST or DAST tool?
It covers both styles. Review mode performs static analysis and never executes your code. Local-active mode starts your application in an isolated sandbox and tests it through scoped HTTP and Chromium. It supports a security program; it does not replace one.
Does my code leave my machine?
Not by default. Deterministic analysis is fully local. Model workers are opt-in: you set a token budget and pass --allow-model-requests, and only selected, redacted context goes to the host you chose.
Do I need an API key?
No, for deterministic scans. Automatic model workers use an authenticated CLI that you install separately: Codex, Claude, Cursor or Gemini.
Which AI coding agents does it work with?
The portable skill installs for Claude Code, Codex, Cursor, Gemini CLI and generic Agent Skills hosts, so your coding agent can drive the scanner.
Which languages does it analyse?
Data-flow analysis is deepest for Python. JavaScript and TypeScript are covered through Semgrep taint rules, and dependency scanning uses OSV-Scanner and Trivy offline.
What report formats does it produce?
JSON with a schema, SARIF for code-scanning tools, Markdown, and a self-contained offline HTML report. Candidates and untested checks stay visible in every format.
Is active testing safe?
It runs your app inside an isolation backend with synthetic data, and needs --authorize plus the matching --plan-digest. If the configuration changed since planning, the scan is refused.
What do the exit codes mean?
Exit code 1 means a confirmed finding. Exit code 2 means partial coverage, so check the blocked and untested items.
Can I contribute?
Yes. See CONTRIBUTING.md in the repository. Report vulnerabilities privately through SECURITY.md.