Skip to content

Security: ZeeshanSultan/DefectDojo-MCP-Server

Security

SECURITY.md

Security Policy

This server brokers access to a DefectDojo instance — the system of record for an organisation's vulnerabilities. A flaw here can expose findings to someone who should not see them, or leak an API token into a model's context. Please treat reports accordingly.

Reporting a vulnerability

Do not open a public issue, pull request, or discussion for a security problem. Public disclosure before a fix exists puts every install at risk at once, including installs whose operators have no idea they are affected.

Reporting address: zeeshi7897@gmail.com

A personal mailbox is a deliberate interim choice, not an oversight. It should become a role address before this project has outside contributors: a personal address makes disclosure depend on one person being reachable, and it cannot be handed over. Until then, reports reach a human, which is the property that matters most.

Please include the commit SHA you tested, the transport in use (stdio or streamable-HTTP), your DefectDojo version, and the smallest reproduction you can manage. If you have a patch, send it privately rather than as a public PR.

Expect an acknowledgement within a week. If you do not hear back, assume the mail was missed and send it again rather than assuming it was ignored.

The security properties this server is built on

These are the claims worth attacking. If you can break one, that is a report:

  • Authorization is DefectDojo's, never this server's. Every call carries the caller's own DefectDojo API token, so DefectDojo decides what is visible. There is no service account, no privilege of its own, and no place where the server substitutes its own judgement for DefectDojo's permission model. A path that returns data the caller's token could not fetch directly is a vulnerability.
  • Tokens live in memory for the duration of a request. They are never written to disk, never logged, and never placed in a tool result or prompt that reaches the model.
  • Responses are redacted before they leave. Secrets that appear inside finding descriptions — the very thing a secret scanner puts there — are stripped on the way out, because a finding that says "we found this credential" should not hand the credential to a language model.
  • Write tools are opt-in and confirmation-gated. They are disabled unless the operator enables them, and the destructive ones require explicit confirmation.

Known limitations

  • Targets DefectDojo OSS v2.58.4. Other versions may differ in ways that affect what the permission model actually enforces.
  • The streamable-HTTP deployment is only as safe as the reverse proxy in front of it. It binds to a container-internal address and expects the proxy to terminate TLS and forward the Authorization header unchanged.

There aren't any published security advisories