Framework-aware static code analysis tool for automated source code review with platform-specific rules, taint analysis, effort estimation, and suppression baselines.

Active enhancements are ongoing. Multiple new features and improvements are planned for upcoming releases.

Feel free to contribute towards updating or adding new rules and future development.

If you find any bugs, report them to [email protected].

Detailed documentation: https://dakshlabs.com/#docs

Getting Started

There are two ways to run Daksh SCRA - pick whichever fits your workflow:

Both paths run the exact same scanning engine - the Web UI is a browser front end over the same CLI, so results are identical either way.

Web UI (Docker)

The fastest way to run Daksh SCRA is through its browser-based Web UI, launched with a single Docker Compose command. It gives you a scan launcher, a live console feed, and a browsable history of past reports, without needing a local Python environment.

The Docker setup runs the Web UI and the CLI as independent services built from the same image, so you can use either (or both) from the same container.

Launch the Web UI

Foreground mode (logs stream to your terminal):

Detached / background mode:

Then open http://localhost:8080.

To use a different port:

Stop the stack with:

Logging in

The Web UI requires an account. On first startup, an initial admin account is created from DAKSH_ADMIN_USERNAME / DAKSH_ADMIN_PASSWORD (set these in .env); if DAKSH_ADMIN_PASSWORD is left unset, a random password is generated and printed once to the API's startup log - save it, since it cannot be recovered afterward.

You'll be required to set your own password (and, optionally, username) the first time you log in. An admin account can create further accounts via the POST /api/v1/auth/users API endpoint (no dedicated UI for this yet). See .env.example for the full list of authentication-related settings (session lifetime, cookie security, CORS).

What you get

• Responsive command builder for scan, recon, estimate, recon+estimate, list, and PDF-from-JSON modes
• Real-time console feed and live per-stage progress during execution
• Per-job artifact snapshots for HTML / PDF / JSON outputs
• Fast in-browser navigation across run form, live feed, artifacts, and recent jobs
• Built-in directory browser for selecting target paths (OS-aware: Windows, macOS, Linux / Docker)

Under the hood, the CLI remains the source of truth - it does all the scanning and generates every HTML / PDF / JSON output. The Web UI runs one active job at a time and snapshots each completed job's outputs into runtime/webui/jobs/<job-id>/artifacts/ so past reports stay accessible.

Running the CLI in Docker

You don't need a local Python environment to use the CLI either - it's available as its own Compose service, built from the same image:

What's in the image

• FastAPI backend + Web UI frontend
• The full Daksh SCRA CLI, as a separate service
• Playwright Chromium, for PDF generation
• Persistent reports/ and runtime/ volumes
• Host path mounts so scans can reach source trees from inside the container

Key mount points:

Environment variables (configure in .env):

Copy .env.example to .env and set the paths and credentials for your machine before running Docker.

CLI Setup

Prefer running Daksh SCRA directly with Python? Here's how to set it up locally.

Pre-requisites

• Python 3.8+
• All libraries listed in requirements.txt

1. Download Daksh SCRA

Or download the latest zip from https://github.com/coffeeandsecurity/DakshSCRA and unzip it.

2. Set Up a Virtual Environment

💡 The virtual environment can be created in any directory - it does not need to be inside the DakshSCRA folder.

Option A: One-step setup (recommended)

This script creates the virtual environment, installs all dependencies, and installs Playwright's Chromium browser (required for PDF export).

Option B: Manual setup

Windows:

macOS / Linux:

Then install dependencies:

CLI Usage

Use python inside a virtual environment, or python3 outside one.

Command-Line Options

Example Usage

-f (file types) is optional. If not specified, DakshSCRA uses the default filetypes for the selected platform(s).

Supported Platform Rules and Frameworks

Current supported platforms and framework mappings:

To get the latest supported platforms and frameworks, always run:

Configuration Reference

config/tool.yaml

Daksh SCRA runtime defaults are controlled through config/tool.yaml.

Analyzer config options:

• analysis.run_by_default
  • true: analyzer runs automatically during scan
  • false: analyzer disabled unless re-enabled in config or via CLI
• analysis.include_frameworks
  • true: include framework-level analyzer entries where framework detection exists
  • false: platform-level analyzer output only
• analysis.report_theme
  • hacker_mode: dark high-contrast modern analyzer theme (default)
  • professional_mode: light modern analyzer theme
  • both: generate both theme variants side-by-side

RDL Rule Authoring

RDL (Rule Description Language) is DakshSCRA's externalized rule-logic layer. In the current architecture:

• XML rules remain the rule inventory and carry metadata such as name, regex, descriptions, and optional scan_config.
• RDL logic is executed by core/rdl_engine.py.
• Rule logic files live under rules/scanning/logic/... and are referenced from XML using <rdl_ref>.
• rdl_ref values are resolved relative to rules/scanning/, for example: logic/php/core/some_rule.rdl -> rules/scanning/logic/php/core/some_rule.rdl
• Logic outcomes are exported into report JSON as metadata such as logic_engine, logic_source, logic_reason, logic_trace, logic_consulted_files, and logic_outcome.

The older inline <rdl> form is no longer the active architecture and should not be used for new rules.

RDL architecture at a glance

Scan sequence

For a source rule, DakshSCRA evaluates logic in this order:

1. Recon selects matching platforms and frameworks.
2. The XML rule is loaded from rules/scanning/platform/....
3. regex finds candidate lines or whole-file matches when present.
4. exclude removes obvious noise for that rule, if present.
5. The external .rdl file from rdl_ref is evaluated against the current file text, current file path, and project root.
6. If the RDL script passes, DakshSCRA keeps the finding and merges exported logic metadata into the report output.
7. If the RDL script fails, the match is suppressed with the RDL fail reason and decision trace metadata.

For file-path rules in filepaths.xml, the same rdl_ref model applies, but the matching subject is the normalized relative path instead of source code text. In that mode, RDL receives the relative path string as the current-file text and path context.

Current rule structure

Current .rdl structure

Current layout

Execution semantics

• WHEN PRESENT, WHEN MISSING, and WHEN CURRENT_FILE_MATCHES evaluate against the current file text.
• WHEN FILE_NAME_IS and WHEN FILE_PATH_MATCHES evaluate against the current file path context.
• WHEN EXPR supports boolean logic over PRESENT:, MISSING:, and EXISTS: predicates.
• OBSERVE PROJECT_HAS_GLOB ... AS ... does not gate the finding; it records related project files in trace metadata.
• REPORT AS, REASON, FAIL_REASON, and TRACE control the exported reporting metadata.
• Regex tokens can be written either as raw patterns or as /pattern/flags, with i, m, and s supported.

Supported RDL commands

Boolean expressions in WHEN EXPR support:

• PRESENT:<regex>
• MISSING:<regex>
• EXISTS:<regex>
• &&, ||, !, and parentheses

Example 1 - PHP SQL injection gating

XML rule:

External RDL:

Example 2 - Android manifest rule with file-aware checks

XML rule:

External RDL:

Example 3 - File-path area-of-interest rule

XML rule:

External RDL:

Authoring guidance

• Keep regex broad enough to catch candidates, then use RDL to filter context.
• Prefer rdl_ref for all rule logic and keep the .rdl file beside the appropriate platform/framework logic tree.
• Do not add new inline <rdl> blocks.
• Use WHEN PRESENT / WHEN MISSING for simple gates and WHEN EXPR only when the logic is genuinely boolean.
• Put reviewer-facing reasoning in REASON and suppression explanations in FAIL_REASON.
• Treat PRESENT and MISSING as whole-file checks. A mitigation anywhere in the file can suppress every match from that file.
• Use OBSERVE PROJECT_HAS_GLOB to enrich findings with project context, not as a pass/fail gate.
• Keep logic/... paths stable and platform-scoped so XML rules remain thin and the logic layer stays reusable.

Report Output Structure

All outputs are written under the reports/ directory:

Runtime files (scan state, logs, inventory) are written under runtime/.

When running via the Web UI, each job's outputs are additionally snapshotted under runtime/webui/jobs/<job-id>/artifacts/ (see Web UI (Docker)).

Author

If DakshSCRA has helped your team save significant time, effort, or cost, reduced dependence on expensive commercial tools, improved review coverage, or made code review more structured and effective, feel free to reach out and share your experience. I am always open to thoughtful feedback and interesting conversations.

Found a bug or want to contribute? Open an issue or pull request on GitHub.