DefectDojo Intelligence MCP Server

Сервер Model Context Protocol с сохранением разрешений поверх REST API v2 DefectDojo OSS v2.58.4. Он достигает 1:1 паритета возможностей с официальным встроенным MCP-сервером DefectDojo Pro (12 инструментов чтения + промпт Security Landscape) — и добавляет детерминированное надмножество аналитики/отчетности — реализованное как внешний адаптер, потому что встроенный Pro MCP требует редакции Pro и инстанса v2.51.2+ и недоступен на хосте OSS 2.58.4.

Каждый вызов использует собственный токен API DefectDojo вызывающего, поэтому DefectDojo определяет видимость. Токен хранится только в памяти, никогда не логируется и не отправляется в LLM.

• Статус: Фазы 0–4 завершены, укреплены и докеризованы. 140 тестов, ruff-clean.

• Развертывание: см. deploy/DEPLOY.md для докеризованной настройки https://dojo.example.com/mcp/. Обратите внимание: это развертывание включает группы инструментов записи и истории БД (см. Модель безопасности и DEPLOY.md). Спецификация: PRD.md.

Инструменты

26 инструментов — 20 включены по умолчанию (14 чтения + 6 аналитики/отчетов), 6 отключены по умолчанию. Плюс 1 примитив MCP-промпта.

Инструменты аналитики вычисляют детерминированно на стороне сервера (без LLM, без выдуманных данных — каждая цифра прослеживается до запроса к API находок) и возвращают типизированный структурированный вывод. SLA использует собственный фильтр DefectDojo outside_of_sla; приоритизация использует реальные сигналы KEV/EPSS/SLA.

Related MCP server: Kuroko MCP Server

Паритет возможностей с Pro

Модель безопасности

• Токен: Authorization: Token <token> (не Bearer). HTTP читает его для каждого запроса из входящего заголовка (собственный токен вызывающего); stdio читает DD_API_TOKEN. На streamable-http резервный вариант из env отключен — запрос с отсутствующим/искаженным заголовком Authorization отклоняется, никогда не выполняется молча с токеном из env сервера.

• Изоляция токенов при пулинге: общий пул соединений использует cookie-хранилище без сохранения, поэтому Set-Cookie от вышестоящего сервера никогда не воспроизводится для токенов разных вызывающих. Аутентификация только для каждого запроса.

• Проверка: токен проверяется один раз за TTL (кэшируется по 128-битному отпечатку, никогда не сам токен; кэш ограничен) перед первым вызовом инструмента.

• Редактирование: применяется централизованно к выводу каждого инструмента, когда установлены redact_secrets/treat_finding_text_as_untrusted — секреты вычищаются (включая учетные данные, встроенные в URL), PII удаляется при omit_user_pii, произвольный текст обрезается до max_evidence_chars.

• Ошибки: сбои (401/403/404/таймаут/…) отображаются как ошибки инструментов MCP (isError), а не как успешные ответы, чтобы клиент не мог принять отказ за данные.

• Запись: отключена по умолчанию; при включении каждая запись требует непустую причину + явный confirm=true (иначе предпросмотр без действия), с аудитом хэша состояния до/после. Только REST API — никогда не пишет в БД.

• История БД: отключена по умолчанию; каждый инструмент сначала авторизует объект через REST, затем читает разрешенное представление только для чтения (никогда произвольный SQL).

• Транспорт: streamable-http получает явные TransportSecuritySettings (защита от DNS-rebinding/Origin) из mcp.allowed_hosts/allowed_origins; loopback всегда разрешен для проверок здоровья.

• Устаревшие конечные точки (credentials, credential_mappings, stub_findings) заблокированы; при регистрации проверяется список разрешенных инструментов.

• Аудит: одно структурированное JSON-событие на каждый вызов инструмента, в stderr (stdout — это поток MCP).

Укрепление

Ограниченные повторные попытки/backoff для временных сбоев GET (429/502/503/504/таймаут; учитывает Retry-After, включая форму HTTP-date; никогда не повторяет записи или 4xx) · общепроцессный Semaphore для конкурентности · общий пулированный httpx-клиент (аутентификация для каждого запроса, закрывается при завершении жизненного цикла) · кэш ролей с TTL для каждого токена. См. tests/test_hardening.py.

Продакшн-развертывание (докеризованное, /mcp/)

Полное руководство: deploy/DEPLOY.md. Вкратце:

cd deploy
# Optional: set DOJO_NETWORK / DD_URL / DD_MCP_REPORTING_DB_DSN in a deploy/.env
# (docker compose reads ${...} env defaults; there is no committed .env template —
#  config lives in deploy/config.prod.yaml, bind-mounted at /app/config.yaml).
docker compose up -d --build
curl -s http://127.0.0.1:9900/healthz   # -> {"status":"ok","transport":"streamable-http"}

Затем добавьте блок location ~ ^/(mcp|sse|messages) из deploy/nginx-mcp.conf в nginx хоста и перезагрузите. Клиенты подключаются к https://dojo.example.com/mcp/ со своим Authorization: Token <token> (через mcp-remote). Контейнер привязывается к 0.0.0.0:9000 внутри контейнера, публикуется на хосте только как 127.0.0.1:9900 и обращается к DefectDojo внутренне по адресу http://nginx:8080. Продакшн-конфиг включает группы инструментов записи и истории БД (enable_write_tools / enable_db_tools); записи остаются с подтверждением, а инструменты БД сначала авторизуются через API — см. DEPLOY.md.

Локальная разработка

Фаза 0 — сначала проверьте живую схему

DD_URL=https://dojo.internal DD_API_TOKEN=xxxx ./scripts/check_schema.sh

Подтверждает наличие требуемых конечных точек коллекций и отмечает устаревшие. Поисковые фильтры DRF в src/defectdojo_mcp/tools/* проверяются по исходникам DefectDojo 2.58.4 — перепроверьте их на своей живой схеме здесь.

Установка и запуск

pip install -e ".[dev]"
cp config.example.yaml config.yaml          # edit base_url
# stdio reads the token from the DD_API_TOKEN env var (and DD_URL) directly — no .env file.

# stdio (single user / desktop client)
DD_URL=https://dojo.internal DD_API_TOKEN=xxxx DD_MCP_CONFIG=config.yaml defectdojo-mcp

# streamable-http (multi-user; token per-request). Set mcp.allowed_hosts for a 0.0.0.0 bind.
DD_MCP_TRANSPORT=streamable-http DD_MCP_HOST=0.0.0.0 DD_MCP_PORT=9000 defectdojo-mcp
# endpoint: http://<host>:9000/mcp   health: http://<host>:9000/healthz

Claude Desktop (stdio)

{
  "mcpServers": {
    "defectdojo": {
      "command": "defectdojo-mcp",
      "env": {
        "DD_URL": "https://dojo.internal",
        "DD_API_TOKEN": "your-token",
        "DD_MCP_CONFIG": "/path/to/config.yaml"
      }
    }
  }
}

Тестирование

pytest          # 140 tests: redaction/sanitize, params, paging, auth+validator, context,
                # server gating, intelligence scoring, source resolution, writes, history,
                # hardening (retry/pool/semaphore/cache)
ruff check .

Конфигурация

Ключевые параметры config.yaml (см. config.example.yaml / deploy/config.prod.yaml):

• mcp.transport (stdio | streamable-http), mcp.host/port

• mcp.enable_write_tools, mcp.enable_db_tools — управляют группами, отключенными по умолчанию

• mcp.enable_dns_rebinding_protection, mcp.allowed_hosts, mcp.allowed_origins

• security.redact_secrets, omit_user_pii, require_confirmation_for_writes

• limits.max_concurrent_api_calls, max_retries, max_evidence_chars, roles_cache_ttl_seconds

• database.enabled, dsn_env, allowed_views (БД отчетности Фазы 3)

Обнаружимость и расширяемость

Каждый инструмент несет ToolAnnotations (readOnlyHint/idempotentHint/title; записи не только для чтения); параметры-перечисления публикуют перечисления; инструменты списков объявляют типизированную схему вывода Page; сервер рекламирует instructions; промпт имеет заголовок и документированные аргументы. Инструменты регистрируются через реестр (module, predicate) в server.py (один общий выключатель по умолчанию для каждой опциональной группы); ServerContext.execute() / execute_db_gated() / execute_write() — это точки контроля для проверки токена, центрального преобразования исходящих данных, аудита и сопоставления ошибок.

Лицензия

Только GNU Affero General Public License v3.0 (AGPL-3.0-only). Полный текст в LICENSE.

Copyright (C) 2026 Zeeshan Sultan.

Безопасность

Пожалуйста, сообщайте об уязвимостях конфиденциально — см. SECURITY.md. Не открывайте публичный issue для проблемы безопасности.

Связанное

Создан вместе с ShadowDSO, внеполосной платформой сканирования безопасности, которая использует DefectDojo как свою систему записи. Этот сервер автономен и не зависит от нее.