DakshSCRA

Outil d'analyse statique de code sensible au framework pour une revue automatisée du code source avec des règles spécifiques à la plateforme, analyse de flux de données (taint), estimation d'effort, et lignes de base de suppression.

Mode détaché / arrière-plan :```bash docker compose up --build -d

Arrêtez la pile avec :```bash docker compose down

Contenu de l'image

• Backend FastAPI + interface Web frontend
• Le CLI complet Daksh SCRA, en tant que service séparé
• Playwright Chromium, pour la génération de PDF
• Volumes persistants reports/ et runtime/
• Montages de chemins hôtes pour que les scans puissent atteindre les arborescences source depuis l'intérieur du conteneur

Points de montage clés :

Variables d'environnement (à configurer dans .env) :

Copiez .env.example vers .env et définissez les chemins et identifiants pour votre machine avant d'exécuter Docker.

Configuration du CLI

Vous préférez exécuter Daksh SCRA directement avec Python ? Voici comment le configurer localement.

Prérequis

• Python 3.8+
• Toutes les bibliothèques listées dans requirements.txt

1. Télécharger Daksh SCRA```bash

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

Ce script crée l'environnement virtuel, installe toutes les dépendances et installe le navigateur Chromium de Playwright (requis pour l'export PDF).

Option B : Configuration manuelle

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

Alors installez les dépendances :```bash cd path/to/DakshSCRA pip install -r requirements.txt playwright install chromium

Exemple d'utilisation

-f (types de fichiers) est facultatif. S'il n'est pas spécifié, DakshSCRA utilise les types de fichiers par défaut pour la ou les plateformes sélectionnées.```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

Plateformes et frameworks actuellement pris en charge :

Pour obtenir la liste la plus récente des plateformes et frameworks pris en charge, exécutez toujours :```bash python dakshscra.py -l R

Options de configuration de l'analyseur :

• analysis.run_by_default
  • true : l'analyseur s'exécute automatiquement lors de l'analyse
  • false : l'analyseur est désactivé sauf s'il est réactivé dans la configuration ou via la CLI
• analysis.include_frameworks
  • true : inclure les entrées d'analyseur au niveau des frameworks lorsque la détection de framework existe
  • false : sortie de l'analyseur au niveau de la plateforme uniquement
• analysis.report_theme
  • hacker_mode : thème d'analyseur moderne sombre à contraste élevé (par défaut)
  • professional_mode : thème d'analyseur moderne clair
  • both : générer les deux variantes de thème côte à côte

Création de règles RDL

RDL (Rule Description Language) est la couche de logique de règles externalisée de DakshSCRA. Dans l'architecture actuelle :

• Les règles XML restent l'inventaire des règles et portent des métadonnées telles que name, regex, des descriptions et un scan_config facultatif.
• La logique RDL est exécutée par core/rdl_engine.py.
• Les fichiers de logique de règles se trouvent sous rules/scanning/logic/... et sont référencés depuis le XML à l'aide de <rdl_ref>.
• Les valeurs rdl_ref sont résolues par rapport à rules/scanning/, par exemple : logic/php/core/some_rule.rdl -> rules/scanning/logic/php/core/some_rule.rdl
• Les résultats de logique sont exportés dans le JSON du rapport sous forme de métadonnées telles que logic_engine, logic_source, logic_reason, logic_trace, logic_consulted_files et logic_outcome.

L'ancienne forme inline <rdl> ne fait plus partie de l'architecture active et ne doit pas être utilisée pour les nouvelles règles.

Architecture RDL en un coup d'œil```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

Structure actuelle `.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.

Sémantique d'exécution

• WHEN PRESENT, WHEN MISSING et WHEN CURRENT_FILE_MATCHES s'évaluent par rapport au texte du fichier courant.
• WHEN FILE_NAME_IS et WHEN FILE_PATH_MATCHES s'évaluent par rapport au contexte du chemin du fichier courant.
• WHEN EXPR prend en charge la logique booléenne sur les prédicats PRESENT:, MISSING: et EXISTS:.
• OBSERVE PROJECT_HAS_GLOB ... AS ... ne conditionne pas le résultat ; il enregistre les fichiers projet associés dans les métadonnées de trace.
• REPORT AS, REASON, FAIL_REASON et TRACE contrôlent les métadonnées de rapport exportées.
• Les jetons regex peuvent être écrits soit comme des motifs bruts, soit comme /motif/drapeaux, avec prise en charge de i, m et s.

Commandes RDL prises en charge

Les expressions booléennes dans WHEN EXPR prennent en charge :

• PRESENT:<regex>
• MISSING:<regex>
• EXISTS:<regex>
• &&, ||, ! et les parenthèses

Exemple 1 - Conditionnement d'injection SQL PHP

Règle 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>

Exemple 2 - Règle de manifeste Android avec vérifications tenant compte des fichiers

Règle 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>

Exemple 3 - Règle de zone d'intérêt basée sur le chemin de fichier

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

Directives de rédaction

• Gardez regex suffisamment large pour détecter les candidats, puis utilisez RDL pour filtrer le contexte.
• Privilégiez rdl_ref pour toute la logique des règles et conservez le fichier .rdl à côté de l’arborescence de logique de la plateforme/cadre appropriée.
• N’ajoutez pas de nouveaux blocs <rdl> en ligne.
• Utilisez WHEN PRESENT / WHEN MISSING pour les portes simples et WHEN EXPR uniquement lorsque la logique est réellement booléenne.
• Placez le raisonnement destiné aux réviseurs dans REASON et les explications de suppression dans FAIL_REASON.
• Traitez PRESENT et MISSING comme des vérifications à l’échelle du fichier. Une atténuation n’importe où dans le fichier peut supprimer chaque correspondance de ce fichier.
• Utilisez OBSERVE PROJECT_HAS_GLOB pour enrichir les résultats avec le contexte du projet, et non comme une porte de réussite/échec.
• Gardez les chemins logic/... stables et limités à la plateforme afin que les règles XML restent légères et que la couche logique reste réutilisable.

Structure de sortie des rapports

Toutes les sorties sont écrites sous le répertoire 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