DakshSCRA

Инструмент статического анализа кода с учётом фреймворков для автоматизированного ревью исходного кода, включающий платформозависимые правила, анализ потоков данных (taint analysis), оценку трудозатрат и базовые линии подавления предупреждений.

Откреплённый / фоновый режим:```bash docker compose up --build -d

Остановите стек с помощью:```bash docker compose down

Что внутри образа

• Бэкенд FastAPI + фронтенд Web UI
• Полный CLI Daksh SCRA как отдельный сервис
• Playwright Chromium для генерации PDF
• Постоянные тома reports/ и runtime/
• Монтирование путей хоста, чтобы сканирование могло получать доступ к исходным деревьям изнутри контейнера

Ключевые точки монтирования:

Переменные окружения (настраиваются в .env):

Скопируйте .env.example в .env и задайте пути и учётные данные для вашей машины перед запуском Docker.

Настройка CLI

Предпочитаете запускать Daksh SCRA напрямую через Python? Вот как настроить его локально.

Предварительные требования

• Python 3.8+
• Все библиотеки, перечисленные в requirements.txt

1. Загрузка Daksh SCRA```bash

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

Этот скрипт создаёт виртуальное окружение, устанавливает все зависимости и устанавливает браузер Chromium для Playwright (требуется для экспорта в PDF).

Вариант B: Ручная настройка

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

Затем установите зависимости:```bash cd path/to/DakshSCRA pip install -r requirements.txt playwright install chromium

Пример использования

-f (типы файлов) необязателен. Если не указан, DakshSCRA использует типы файлов по умолчанию для выбранной(ых) платформы(форм).```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

Текущие поддерживаемые платформы и сопоставления фреймворков:

Чтобы получить последние поддерживаемые платформы и фреймворки, всегда запускайте:```bash python dakshscra.py -l R

Параметры конфигурации анализатора:

• analysis.run_by_default
  • true: анализатор запускается автоматически во время сканирования
  • false: анализатор отключен, если не включен повторно в конфигурации или через CLI
• analysis.include_frameworks
  • true: включать записи анализатора уровня фреймворков там, где существует определение фреймворка
  • false: только вывод анализатора уровня платформы
• analysis.report_theme
  • hacker_mode: темная высококонтрастная современная тема анализатора (по умолчанию)
  • professional_mode: светлая современная тема анализатора
  • both: генерировать оба варианта темы рядом

Создание правил RDL

RDL (Rule Description Language) — это внешний слой логики правил DakshSCRA. В текущей архитектуре:

• XML-правила остаются реестром правил и содержат метаданные, такие как name, regex, описания и необязательный scan_config.
• Логика RDL выполняется через core/rdl_engine.py.
• Файлы логики правил находятся в rules/scanning/logic/... и ссылаются из XML с помощью <rdl_ref>.
• Значения rdl_ref разрешаются относительно rules/scanning/, например: logic/php/core/some_rule.rdl -> rules/scanning/logic/php/core/some_rule.rdl
• Результаты логики экспортируются в JSON-отчет как метаданные, такие как logic_engine, logic_source, logic_reason, logic_trace, logic_consulted_files и logic_outcome.

Более старая встроенная форма <rdl> больше не является активной архитектурой и не должна использоваться для новых правил.

Архитектура RDL с первого взгляда```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

Текущая структура `.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.

Семантика выполнения

• WHEN PRESENT, WHEN MISSING и WHEN CURRENT_FILE_MATCHES оцениваются относительно текста текущего файла.
• WHEN FILE_NAME_IS и WHEN FILE_PATH_MATCHES оцениваются относительно контекста пути текущего файла.
• WHEN EXPR поддерживает булеву логику над предикатами PRESENT:, MISSING: и EXISTS:.
• OBSERVE PROJECT_HAS_GLOB ... AS ... не блокирует срабатывание правила; он записывает связанные файлы проекта в метаданные трассировки.
• REPORT AS, REASON, FAIL_REASON и TRACE управляют экспортируемыми метаданными отчёта.
• Токены регулярных выражений могут записываться либо как сырые шаблоны, либо как /pattern/flags, с поддержкой i, m и s.

Поддерживаемые команды RDL

Булевы выражения в WHEN EXPR поддерживают:

• PRESENT:<regex>
• MISSING:<regex>
• EXISTS:<regex>
• &&, ||, ! и круглые скобки

Пример 1 - Условие для SQL-инъекций в PHP

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>

Пример 2 — правило манифеста Android с проверками, учитывающими файлы

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>

Пример 3 — Правило области интереса по пути к файлу

XML-правило:```xml Admin Section File Path <rdl_ref>logic/filepaths/core/admin_section.rdl</rdl_ref>

Рекомендации по написанию правил

• Держите regex достаточно широким, чтобы находить кандидатов, а затем используйте RDL для фильтрации контекста.
• Отдавайте предпочтение rdl_ref для всей логики правил и храните файл .rdl рядом с соответствующим деревом логики платформы/фреймворка.
• Не добавляйте новые встроенные блоки <rdl>.
• Используйте WHEN PRESENT / WHEN MISSING для простых проверок и WHEN EXPR только когда логика действительно булева.
• Помещайте обоснования для рецензентов в REASON, а пояснения для подавления — в FAIL_REASON.
• Считайте PRESENT и MISSING проверками всего файла. Любая мера смягчения в любом месте файла может подавить все совпадения из этого файла.
• Используйте OBSERVE PROJECT_HAS_GLOB для обогащения результатов контекстом проекта, а не как проверку «пройдено/не пройдено».
• Держите пути logic/... стабильными и ограниченными платформой, чтобы XML-правила оставались тонкими, а слой логики — переиспользуемым.

Структура вывода отчётов

Все результаты записываются в каталог 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