DakshSCRA

Strumento di analisi statica del codice consapevole del framework per la revisione automatica del codice sorgente con regole specifiche per piattaforma, analisi del taint, stima dello sforzo e baseline di soppressione.

Modalità distaccata / in background:```bash docker compose up --build -d

Ferma lo stack con:```bash docker compose down

Cosa contiene l'immagine

• Backend FastAPI + frontend Web UI
• L'intera CLI Daksh SCRA, come servizio separato
• Playwright Chromium, per la generazione di PDF
• Volumi persistenti reports/ e runtime/
• Montaggi di percorsi host in modo che le scansioni possano raggiungere gli alberi sorgente dall'interno del container

Punti di montaggio principali:

Variabili d'ambiente (configurare in .env):

Copiare .env.example in .env e impostare i percorsi e le credenziali per la propria macchina prima di eseguire Docker.

Configurazione CLI

Preferisci eseguire Daksh SCRA direttamente con Python? Ecco come configurarlo localmente.

Prerequisiti

• Python 3.8+
• Tutte le librerie elencate in requirements.txt

1. Scaricare Daksh SCRA```bash

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

Questo script crea l'ambiente virtuale, installa tutte le dipendenze e installa il browser Chromium di Playwright (richiesto per l'esportazione in PDF).

Opzione B: Configurazione manuale

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

Allora installa le dipendenze:```bash cd path/to/DakshSCRA pip install -r requirements.txt playwright install chromium

Esempio di utilizzo

-f (tipi di file) è opzionale. Se non specificato, DakshSCRA utilizza i tipi di file predefiniti per le piattaforme selezionate.```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

Piattaforme e framework attualmente supportati:

Per ottenere le ultime piattaforme e framework supportati, esegui sempre:```bash python dakshscra.py -l R

Opzioni di configurazione dell'analizzatore:

• analysis.run_by_default
  • true: l'analizzatore viene eseguito automaticamente durante la scansione
  • false: l'analizzatore è disabilitato a meno che non venga riabilitato nella configurazione o tramite CLI
• analysis.include_frameworks
  • true: include le voci dell'analizzatore a livello di framework dove esiste il rilevamento del framework
  • false: solo output dell'analizzatore a livello di piattaforma
• analysis.report_theme
  • hacker_mode: tema analizzatore moderno scuro ad alto contrasto (predefinito)
  • professional_mode: tema analizzatore moderno chiaro
  • both: genera entrambe le varianti di tema affiancate

Creazione di regole RDL

RDL (Rule Description Language) è il livello di logica delle regole esternalizzato di DakshSCRA. Nell'architettura attuale:

• Le regole XML rimangono l'inventario delle regole e contengono metadati come name, regex, descrizioni e scan_config opzionale.
• La logica RDL viene eseguita da core/rdl_engine.py.
• I file di logica delle regole si trovano in rules/scanning/logic/... e vengono referenziati dall'XML tramite <rdl_ref>.
• I valori rdl_ref vengono risolti relativamente a rules/scanning/, ad esempio: logic/php/core/some_rule.rdl -> rules/scanning/logic/php/core/some_rule.rdl
• I risultati della logica vengono esportati nel JSON del report come metadati come logic_engine, logic_source, logic_reason, logic_trace, logic_consulted_files e logic_outcome.

La vecchia forma inline <rdl> non è più l'architettura attiva e non dovrebbe essere utilizzata per nuove regole.

Architettura RDL a colpo d'occhio```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

Struttura .rdl corrente```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.

Semantica di esecuzione

• WHEN PRESENT, WHEN MISSING e WHEN CURRENT_FILE_MATCHES vengono valutati rispetto al testo del file corrente.
• WHEN FILE_NAME_IS e WHEN FILE_PATH_MATCHES vengono valutati rispetto al contesto del percorso del file corrente.
• WHEN EXPR supporta la logica booleana sui predicati PRESENT:, MISSING: ed EXISTS:.
• OBSERVE PROJECT_HAS_GLOB ... AS ... non blocca il finding; registra i file di progetto correlati nei metadati di traccia.
• REPORT AS, REASON, FAIL_REASON e TRACE controllano i metadati di reporting esportati.
• I token regex possono essere scritti sia come pattern grezzi sia come /pattern/flags, con supporto per i, m e s.

Comandi RDL supportati

Le espressioni booleane in WHEN EXPR supportano:

• PRESENT:<regex>
• MISSING:<regex>
• EXISTS:<regex>
• &&, ||, ! e parentesi

Esempio 1 - Gating per SQL injection in PHP

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

Esempio 2 - Regola manifest Android con controlli sensibili ai file

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

Esempio 3 - Regola area di interesse basata sul percorso file

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

Linee guida per l'autore

• Mantieni regex sufficientemente ampio da individuare i candidati, poi usa RDL per filtrare il contesto.
• Preferisci rdl_ref per tutta la logica delle regole e tieni il file .rdl accanto all'albero logico della piattaforma/framework appropriato.
• Non aggiungere nuovi blocchi <rdl> inline.
• Usa WHEN PRESENT / WHEN MISSING per controlli semplici e WHEN EXPR solo quando la logica è genuinamente booleana.
• Metti le motivazioni rivolte ai revisori in REASON e le spiegazioni di soppressione in FAIL_REASON.
• Tratta PRESENT e MISSING come controlli a livello di intero file. Una mitigazione in qualsiasi punto del file può sopprimere ogni corrispondenza proveniente da quel file.
• Usa OBSERVE PROJECT_HAS_GLOB per arricchire i risultati con il contesto del progetto, non come gate di superamento/fallimento.
• Mantieni stabili e limitati alla piattaforma i percorsi logic/... così che le regole XML restino sottili e il livello logico rimanga riutilizzabile.

Struttura dell'output dei report

Tutti gli output vengono scritti nella directory 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