Skip to content

Vulnerability Response Process

This document expands the reporting and response process summarized in SECURITY.md.

Reporting channel

Do not report suspected vulnerabilities in public GitHub issues. Use GitHub private vulnerability reporting for the repository when available. If that channel is unavailable, contact the maintainer privately using the public GitHub profile contact information.

Intake requirements

A useful report should include:

  • affected version, commit, workflow, or deployment mode;
  • reproduction steps or proof of concept;
  • expected and actual behavior;
  • impact assessment;
  • whether the issue affects parser input, MCP tools, REST API, plugin admission, generated artifacts, CI/release infrastructure, or dependency handling;
  • reporter credit preference, including anonymity requests.

Response targets

Stage Target
Acknowledge receipt within 48 hours
Initial triage within 7 calendar days
Fix plan for confirmed vulnerability within 14 calendar days where practical
Coordinated disclosure after a fix, mitigation, or advisory plan is available

These are best-effort targets for a pre-1.0 solo-maintainer project, not a commercial SLA.

Triage categories

  • Critical: Remote code execution, credential exposure, release compromise, or unauthenticated privileged action.
  • High: Arbitrary file read/write, auth bypass, unsafe plugin execution, or CI/release secret exposure.
  • Medium: Denial of service, unsafe default exposure, malformed artifact integrity issue, or significant data disclosure.
  • Low: Hardening issue, missing defense-in-depth, or documentation issue with limited exploitability.

Fix and disclosure workflow

  1. Confirm scope and impact privately.
  2. Create a private advisory or private branch if needed.
  3. Develop a minimal fix and regression test.
  4. Run relevant security, quality, and release gates.
  5. Publish a release, advisory, or workaround.
  6. Credit reporters unless they request anonymity.
  7. Update CHANGELOG.md, SECURITY.md, or release notes when the issue is public.

Reporter credit

ZapTrace gives public credit to reporters of resolved vulnerabilities unless they request anonymity or credit would increase risk before coordinated disclosure. If no vulnerabilities have been resolved in the last 12 months, vulnerability-credit criteria should be marked not applicable.

Non-claims

ZapTrace is pre-1.0 and not a sandboxed multi-tenant service by default. Users who expose MCP or REST interfaces to a network are responsible for deployment authentication, sandboxing, resource limits, monitoring, and secret handling.