Framework-bewusstes statisches Code-Analyse-Tool für automatisierte Quellcode-Reviews mit plattformspezifischen Regeln, Taint-Analyse, Aufwandsabschätzung und Unterdrückungsbaselines.

Detached / Hintergrundmodus:```bash docker compose up --build -d

Stoppe den Stack mit:```bash docker compose down

Was im Image enthalten ist

• FastAPI-Backend + Web-UI-Frontend
• Die vollständige Daksh-SCRA-CLI als separater Dienst
• Playwright Chromium für die PDF-Erzeugung
• Persistente reports/- und runtime/-Volumes
• Host-Pfad-Mounts, damit Scans Quellcode-Bäume aus dem Container heraus erreichen können

Wichtige Mount-Punkte:

Umgebungsvariablen (in .env konfigurieren):

Kopieren Sie .env.example nach .env und setzen Sie die Pfade und Anmeldedaten für Ihre Maschine, bevor Sie Docker ausführen.

CLI-Einrichtung

Bevorzugen Sie es, Daksh SCRA direkt mit Python auszuführen? So richten Sie es lokal ein.

Voraussetzungen

• Python 3.8+
• Alle in requirements.txt aufgeführten Bibliotheken

1. Daksh SCRA herunterladen```bash

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

Dieses Skript erstellt die virtuelle Umgebung, installiert alle Abhängigkeiten und installiert den Chromium-Browser von Playwright (erforderlich für den PDF-Export).

Option B: Manuelle Einrichtung

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

Dann installiere die Abhängigkeiten:```bash cd path/to/DakshSCRA pip install -r requirements.txt playwright install chromium

Beispielverwendung

-f (Dateitypen) ist optional. Wenn nicht angegeben, verwendet DakshSCRA die Standard-Dateitypen für die ausgewählte(n) Plattform(en).```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

Aktuell unterstützte Plattformen und Framework-Zuordnungen:

Um die neuesten unterstützten Plattformen und Frameworks zu erhalten, führen Sie immer Folgendes aus:```bash python dakshscra.py -l R

Analyzer-Konfigurationsoptionen:

• analysis.run_by_default
  • true: Der Analyzer läuft automatisch während des Scans
  • false: Der Analyzer ist deaktiviert, sofern er nicht in der Konfiguration oder über die CLI wieder aktiviert wird
• analysis.include_frameworks
  • true: Framework-Ebene-Analyzer-Einträge einbeziehen, wo Framework-Erkennung vorhanden ist
  • false: Nur Ausgabe auf Plattform-Ebene des Analyzers
• analysis.report_theme
  • hacker_mode: Dunkles, kontrastreiches, modernes Analyzer-Theme (Standard)
  • professional_mode: Helles, modernes Analyzer-Theme
  • both: Beide Theme-Varianten nebeneinander generieren

RDL-Regelautoren

RDL (Rule Description Language) ist die externalisierte Regellogik-Schicht von DakshSCRA. In der aktuellen Architektur:

• XML-Regeln bleiben das Regel-Inventar und tragen Metadaten wie name, regex, Beschreibungen und optional scan_config.
• RDL-Logik wird von core/rdl_engine.py ausgeführt.
• Regellogik-Dateien liegen unter rules/scanning/logic/... und werden aus XML über <rdl_ref> referenziert.
• rdl_ref-Werte werden relativ zu rules/scanning/ aufgelöst, zum Beispiel: logic/php/core/some_rule.rdl -> rules/scanning/logic/php/core/some_rule.rdl
• Logik-Ergebnisse werden als Metadaten wie logic_engine, logic_source, logic_reason, logic_trace, logic_consulted_files und logic_outcome in das Berichts-JSON exportiert.

Die ältere Inline-<rdl>-Form ist nicht mehr die aktive Architektur und sollte für neue Regeln nicht verwendet werden.

RDL-Architektur auf einen Blick```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

Aktuelle .rdl-Struktur```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.

Ausführungssemantik

• WHEN PRESENT, WHEN MISSING und WHEN CURRENT_FILE_MATCHES werden gegen den aktuellen Dateitext ausgewertet.
• WHEN FILE_NAME_IS und WHEN FILE_PATH_MATCHES werden gegen den aktuellen Dateipfad-Kontext ausgewertet.
• WHEN EXPR unterstützt boolesche Logik über PRESENT:, MISSING: und EXISTS:-Prädikate.
• OBSERVE PROJECT_HAS_GLOB ... AS ... steuert den Befund nicht; es zeichnet zugehörige Projektdateien in den Trace-Metadaten auf.
• REPORT AS, REASON, FAIL_REASON und TRACE steuern die exportierten Berichtsmetadaten.
• Regex-Tokens können entweder als rohe Muster oder als /pattern/flags geschrieben werden, wobei i, m und s unterstützt werden.

Unterstützte RDL-Befehle

Boolesche Ausdrücke in WHEN EXPR unterstützen:

• PRESENT:<regex>
• MISSING:<regex>
• EXISTS:<regex>
• &&, ||, ! und Klammern

Beispiel 1 - PHP-SQL-Injection-Gating

XML-Regel:```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>

Beispiel 2 – Android-Manifest-Regel mit dateibewussten Prüfungen

XML-Regel:```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>

Beispiel 3 – Dateipfad-Interessensbereich-Regel

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

Autorenhinweise

• Halte regex breit genug, um Kandidaten zu erfassen, und filtere den Kontext anschließend mit RDL.
• Bevorzuge rdl_ref für die gesamte Regellogik und platziere die .rdl-Datei neben dem entsprechenden Plattform-/Framework-Logikbaum.
• Füge keine neuen Inline-<rdl>-Blöcke hinzu.
• Verwende WHEN PRESENT / WHEN MISSING für einfache Bedingungen und WHEN EXPR nur, wenn die Logik wirklich boolesch ist.
• Platziere prüferorientierte Begründungen in REASON und Unterdrückungserklärungen in FAIL_REASON.
• Behandle PRESENT und MISSING als dateiweite Prüfungen. Eine Abhilfemaßnahme an beliebiger Stelle in der Datei kann jeden Treffer aus dieser Datei unterdrücken.
• Verwende OBSERVE PROJECT_HAS_GLOB, um Ergebnisse mit Projektkontext anzureichern, nicht als Bestanden-/Nicht-bestanden-Gate.
• Halte logic/...-Pfade stabil und plattformspezifisch, damit XML-Regeln schlank bleiben und die Logikebene wiederverwendbar bleibt.

Berichtsausgabestruktur

Alle Ausgaben werden unter dem Verzeichnis reports/ geschrieben:``` 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