DakshSCRA

Ferramenta de análise estática de código consciente de frameworks para revisão automatizada de código-fonte com regras específicas de plataforma, análise de fluxo de dados, estimativa de esforço e linhas de base de supressão.

Modo destacado / em segundo plano:```bash docker compose up --build -d

Pare a pilha com:```bash docker compose down

O que há na imagem

• Backend FastAPI + frontend Web UI
• A CLI completa do Daksh SCRA, como um serviço separado
• Playwright Chromium, para geração de PDF
• Volumes persistentes reports/ e runtime/
• Montagens de caminhos do host para que as varreduras possam acessar as árvores de origem de dentro do contêiner

Pontos de montagem principais:

Variáveis de ambiente (configure em .env):

Copie .env.example para .env e defina os caminhos e credenciais para sua máquina antes de executar o Docker.

Configuração da CLI

Prefere executar o Daksh SCRA diretamente com Python? Veja como configurá-lo localmente.

Pré-requisitos

• Python 3.8+
• Todas as bibliotecas listadas em requirements.txt

1. Baixar o Daksh SCRA```bash

git clone https://github.com/coffeeandsecurity/DakshSCRA.git

Este script cria o ambiente virtual, instala todas as dependências e instala o navegador Chromium do Playwright (necessário para exportação de PDF).

Opção B: Configuração manual

Windows:```bash python -m venv daksh-env .\daksh-env\Scripts\activate

Em seguida, instale as dependências:```bash cd path/to/DakshSCRA pip install -r requirements.txt playwright install chromium

Exemplo de Uso

-f (tipos de arquivo) é opcional. Se não for especificado, o DakshSCRA usa os tipos de arquivo padrão para a(s) plataforma(s) selecionada(s).```bash

Single platform scan

python dakshscra.py -r php -t /path/to/source

Multiple platforms

python dakshscra.py -r php,java,cpp -t /path/to/source

Auto-detect platform and apply matching rules

python dakshscra.py -r auto -t /path/to/source

Override filetypes

python dakshscra.py -r php -f dotnet -t /path/to/source

Reconnaissance only (no scanning)

python dakshscra.py --recon -t /path/to/source

Reconnaissance + scanning

python dakshscra.py --recon -r php -t /path/to/source

Strict recon (high-confidence detections only)

python dakshscra.py --recon --rs -t /path/to/source

Effort estimation

python dakshscra.py --estimate -t /path/to/source

Scan with HTML + PDF report output

python dakshscra.py -r auto -t /path/to/source -rpt html,pdf

Verbosity levels

python dakshscra.py -r php -v -t /path/to/source # default python dakshscra.py -r php -vvv -t /path/to/source # show all pattern checks

Generate suppression baseline from current findings

python dakshscra.py -r auto -t /path/to/source --baseline-generate

Apply suppression baseline (suppress known FPs)

python dakshscra.py -r auto -t /path/to/source --baseline-file config/suppressions.json

Disable baseline for this run

python dakshscra.py -r auto -t /path/to/source --no-baseline

Apply findings triage / review config

python dakshscra.py -r auto -t /path/to/source --review-config config/review.json

Scan with checkpoint state enabled

python dakshscra.py -r auto -t /path/to/source --state

Resume an interrupted scan

python dakshscra.py -r auto -t /path/to/source --resume-scan

Resume with a custom state file

python dakshscra.py -r auto -t /path/to/source --resume-scan --state-file runtime/scan_state.json

Generate PDF from existing JSON outputs (no re-scan)

python dakshscra.py --pdf-from-json

Generate PDF from a custom JSON directory

python dakshscra.py --pdf-from-json --json-input-dir ./custom/reports/data

Custom output paths for PDF

python dakshscra.py --pdf-from-json --pdf-output ./reports/scan/pdf/custom.pdf --pdf-multi-dir ./reports/scan/pdf/multi-file

Single combined PDF only (skip per-platform set)

python dakshscra.py --pdf-from-json --pdf-single-only

Plataformas e frameworks atualmente suportados:

Para obter as plataformas e frameworks mais recentes suportados, execute sempre:```bash python dakshscra.py -l R

Opções de configuração do analisador:

• analysis.run_by_default
  • true: o analisador é executado automaticamente durante a verificação
  • false: o analisador fica desabilitado, a menos que seja reativado na configuração ou via CLI
• analysis.include_frameworks
  • true: inclui entradas do analisador em nível de framework onde a detecção de framework existe
  • false: apenas a saída do analisador em nível de plataforma
• analysis.report_theme
  • hacker_mode: tema de analisador moderno escuro de alto contraste (padrão)
  • professional_mode: tema de analisador moderno claro
  • both: gera ambas as variantes de tema lado a lado

Criação de Regras RDL

RDL (Rule Description Language) é a camada de lógica de regras externalizada do DakshSCRA. Na arquitetura atual:

• As regras XML permanecem como o inventário de regras e carregam metadados como name, regex, descrições e scan_config opcional.
• A lógica RDL é executada por core/rdl_engine.py.
• Os arquivos de lógica de regras ficam em rules/scanning/logic/... e são referenciados a partir do XML usando <rdl_ref>.
• Os valores de rdl_ref são resolvidos em relação a rules/scanning/, por exemplo: logic/php/core/some_rule.rdl -> rules/scanning/logic/php/core/some_rule.rdl
• Os resultados da lógica são exportados para o JSON do relatório como metadados, como logic_engine, logic_source, logic_reason, logic_trace, logic_consulted_files e logic_outcome.

A forma inline <rdl> mais antiga não é mais a arquitetura ativa e não deve ser usada para novas regras.

Arquitetura RDL em resumo```text

XML rule -> regex / exclude / scan_config / descriptions -> rdl_ref -> rules/scanning/logic///.rdl -> core/rdl_engine.py -> pass / fail -> reason / fail_reason -> trace / consulted_files / outcome

Estrutura atual do `.rdl````text

VERSION 1 WHEN PRESENT /\b(?:mysql_query|mysqli_query|->query)\s*\(/i WHEN EXPR PRESENT:\$_(GET|POST|REQUEST|COOKIE) && MISSING:\b(?:prepare|bindParam|bindValue|PDO::prepare)\b REPORT AS area_of_interest REASON SQL query execution appears reachable without parameterisation in this file. FAIL_REASON Matching query API was found, but the file also contains prepared-statement indicators. TRACE SQLi gate: input source present and mitigation missing.

Semântica de execução

• WHEN PRESENT, WHEN MISSING e WHEN CURRENT_FILE_MATCHES avaliam o texto do arquivo atual.
• WHEN FILE_NAME_IS e WHEN FILE_PATH_MATCHES avaliam o contexto do caminho do arquivo atual.
• WHEN EXPR suporta lógica booleana sobre os predicados PRESENT:, MISSING: e EXISTS:.
• OBSERVE PROJECT_HAS_GLOB ... AS ... não bloqueia o achado; ele registra arquivos de projeto relacionados nos metadados de rastreamento.
• REPORT AS, REASON, FAIL_REASON e TRACE controlam os metadados de relatório exportados.
• Tokens de regex podem ser escritos como padrões brutos ou como /padrão/flags, com suporte a i, m e s.

Comandos RDL suportados

Expressões booleanas em WHEN EXPR suportam:

• PRESENT:<regex>
• MISSING:<regex>
• EXISTS:<regex>
• &&, ||, ! e parênteses

Exemplo 1 - Portão de injeção SQL em PHP

Regra XML:```xml Possible SQL Injection in Query Execution query)\s*\(]]> <rdl_ref>logic/common/core/insecure_sql_query_unsafe_string_concatenation.rdl</rdl_ref> <rule_desc>...</rule_desc>

Exemplo 2 - Regra de manifesto Android com verificações cientes de arquivos

Regra XML:```xml Exported Components Without Permission activity|service|receiver|provider)\s[^>]*android:name="(?P[^"]+)"[^>]*android:exported="true"[^>]*(?:/>|>)]]> <rdl_ref>logic/mobile/android/core/exported_components.rdl</rdl_ref> <scan_config>...</scan_config>

Exemplo 3 - Regra de área de interesse por caminho de arquivo

Regra XML:```xml Admin Section File Path <rdl_ref>logic/filepaths/core/admin_section.rdl</rdl_ref>

Orientações de autoria

• Mantenha regex amplo o suficiente para capturar candidatos e, em seguida, use RDL para filtrar o contexto.
• Prefira rdl_ref para toda a lógica de regras e mantenha o arquivo .rdl ao lado da árvore de lógica apropriada da plataforma/framework.
• Não adicione novos blocos inline <rdl>.
• Use WHEN PRESENT / WHEN MISSING para portas simples e WHEN EXPR apenas quando a lógica for genuinamente booleana.
• Coloque o raciocínio voltado ao revisor em REASON e as explicações de supressão em FAIL_REASON.
• Trate PRESENT e MISSING como verificações de arquivo inteiro. Uma mitigação em qualquer lugar do arquivo pode suprimir todas as correspondências desse arquivo.
• Use OBSERVE PROJECT_HAS_GLOB para enriquecer descobertas com contexto do projeto, não como uma porta de aprovação/reprovação.
• Mantenha os caminhos logic/... estáveis e com escopo de plataforma para que as regras XML permaneçam enxutas e a camada de lógica continue reutilizável.

Estrutura de saída do relatório

Todas as saídas são gravadas no diretório reports/:``` reports/ ├── scan/ │ ├── html/ │ │ ├── report.html # Single-file HTML scan report │ │ └── multi-file/ # Per-platform HTML report set │ ├── pdf/ │ │ ├── report.pdf # Single-file PDF scan report │ │ └── multi-file/ # Per-platform PDF report set │ ├── recon/ │ │ └── reconnaissance.html # Reconnaissance HTML report │ └── estimate/ │ └── estimation.html # Effort estimation HTML report ├── analysis/ │ └── / │ ├── analysis.html # Taint analysis report (default theme) │ ├── analysis_professional.html # Professional theme (if theme=both) │ ├── analysis_xref.html # Cross-reference report │ └── analysis.json # Structured analysis data └── data/ ├── areas_of_interest.json # AoI findings ├── filepaths_aoi.json # File path AoI findings ├── summary.json # Scan summary ├── recon.json # Recon summary └── analysis.json # Analyzer output