DakshSCRA

Herramienta de análisis estático de código sensible al framework para la revisión automatizada del código fuente con reglas específicas de plataforma, análisis de contaminación, estimación de esfuerzo y líneas de base de supresión.

Modo desacoplado / en segundo plano:```bash docker compose up --build -d

Detén la pila con:```bash docker compose down

Qué hay en la imagen

• Backend FastAPI + frontend de interfaz web
• La CLI completa de Daksh SCRA, como servicio independiente
• Playwright Chromium, para la generación de PDF
• Volúmenes persistentes reports/ y runtime/
• Montajes de rutas del host para que los escaneos puedan acceder a los árboles de código fuente desde dentro del contenedor

Puntos de montaje clave:

Variables de entorno (configúralas en .env):

Copia .env.example a .env y establece las rutas y credenciales para tu máquina antes de ejecutar Docker.

Configuración de la CLI

¿Prefieres ejecutar Daksh SCRA directamente con Python? Así es como se configura localmente.

Requisitos previos

• Python 3.8+
• Todas las bibliotecas listadas en requirements.txt

1. Descargar Daksh SCRA```bash

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

Este script crea el entorno virtual, instala todas las dependencias e instala el navegador Chromium de Playwright (necesario para la exportación a PDF).

Opción B: Configuración manual

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

Entonces instala las dependencias:```bash cd path/to/DakshSCRA pip install -r requirements.txt playwright install chromium

Ejemplo de uso

-f (tipos de archivo) es opcional. Si no se especifica, DakshSCRA usa los tipos de archivo predeterminados para la(s) plataforma(s) seleccionada(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 y frameworks compatibles actualmente:

Para obtener las plataformas y frameworks compatibles más recientes, ejecuta siempre:```bash python dakshscra.py -l R

Opciones de configuración del analizador:

• analysis.run_by_default
  • true: el analizador se ejecuta automáticamente durante el escaneo
  • false: el analizador está deshabilitado a menos que se vuelva a habilitar en la configuración o mediante CLI
• analysis.include_frameworks
  • true: incluir entradas del analizador a nivel de framework donde exista detección de framework
  • false: solo salida del analizador a nivel de plataforma
• analysis.report_theme
  • hacker_mode: tema de analizador moderno oscuro de alto contraste (predeterminado)
  • professional_mode: tema de analizador moderno claro
  • both: generar ambas variantes de tema lado a lado

Autoría de reglas RDL

RDL (Lenguaje de Descripción de Reglas) es la capa de lógica de reglas externalizada de DakshSCRA. En la arquitectura actual:

• Las reglas XML siguen siendo el inventario de reglas y contienen metadatos como name, regex, descripciones y scan_config opcional.
• La lógica RDL se ejecuta mediante core/rdl_engine.py.
• Los archivos de lógica de reglas se encuentran en rules/scanning/logic/... y se referencian desde XML usando <rdl_ref>.
• Los valores de rdl_ref se resuelven relativos a rules/scanning/, por ejemplo: logic/php/core/some_rule.rdl -> rules/scanning/logic/php/core/some_rule.rdl
• Los resultados de la lógica se exportan al JSON del informe como metadatos como logic_engine, logic_source, logic_reason, logic_trace, logic_consulted_files y logic_outcome.

La forma antigua en línea <rdl> ya no es la arquitectura activa y no debe usarse para nuevas reglas.

Arquitectura RDL de un vistazo```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

Estructura actual de `.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 ejecución

• WHEN PRESENT, WHEN MISSING y WHEN CURRENT_FILE_MATCHES se evalúan contra el texto del archivo actual.
• WHEN FILE_NAME_IS y WHEN FILE_PATH_MATCHES se evalúan contra el contexto de la ruta del archivo actual.
• WHEN EXPR admite lógica booleana sobre los predicados PRESENT:, MISSING: y EXISTS:.
• OBSERVE PROJECT_HAS_GLOB ... AS ... no condiciona el hallazgo; registra archivos de proyecto relacionados en los metadatos de traza.
• REPORT AS, REASON, FAIL_REASON y TRACE controlan los metadatos de informe exportados.
• Los tokens de expresiones regulares pueden escribirse como patrones sin formato o como /patrón/banderas, con soporte para i, m y s.

Comandos RDL admitidos

Las expresiones booleanas en WHEN EXPR admiten:

• PRESENT:<regex>
• MISSING:<regex>
• EXISTS:<regex>
• &&, ||, ! y paréntesis

Ejemplo 1 - Compuerta de inyección SQL en PHP

Regla 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>

Ejemplo 2 - Regla de manifiesto de Android con comprobaciones conscientes de archivos

Regla 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>

Ejemplo 3 - Regla de área de interés por ruta de archivo

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

Guía de autoría

• Mantén regex lo suficientemente amplio para captar candidatos y luego usa RDL para filtrar el contexto.
• Prefiere rdl_ref para toda la lógica de reglas y mantén el archivo .rdl junto al árbol de lógica de la plataforma/marco correspondiente.
• No agregues nuevos bloques <rdl> en línea.
• Usa WHEN PRESENT / WHEN MISSING para compuertas simples y WHEN EXPR solo cuando la lógica sea genuinamente booleana.
• Coloca el razonamiento dirigido a revisores en REASON y las explicaciones de supresión en FAIL_REASON.
• Trata PRESENT y MISSING como comprobaciones de archivo completo. Una mitigación en cualquier parte del archivo puede suprimir todas las coincidencias de ese archivo.
• Usa OBSERVE PROJECT_HAS_GLOB para enriquecer los hallazgos con contexto del proyecto, no como una compuerta de aprobado/reprobado.
• Mantén las rutas logic/... estables y con ámbito de plataforma para que las reglas XML sigan siendo delgadas y la capa de lógica siga siendo reutilizable.

Estructura de salida de informes

Todas las salidas se escriben bajo el directorio 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