Vulnerability disclosure

How to privately report a security vulnerability in CodeGate, what to include in your report, and what to expect from the response process.

If you discover a security vulnerability in CodeGate, do not open a public GitHub issue. Public disclosure before a fix is available gives attackers information before users can protect themselves.

Follow the private disclosure process below.

Supported versions

Version	Support status
Latest 0.x release	Supported
Older 0.x releases	Best effort
Unreleased branches	Not supported

Disclosure process

1. Prepare your report

   Gather the following before submitting:

   • Affected version: The exact version of codegate-ai where the issue is reproducible. Run codegate --help or check your package.json for the installed version.
   • Reproduction steps: A clear, minimal sequence of steps that demonstrates the vulnerability. Include commands, input files, and expected vs. actual behavior.
   • Impact assessment: What an attacker can achieve by exploiting this issue. Consider confidentiality, integrity, and availability impact.
   • Proof of concept: If available, include a PoC that demonstrates exploitability without causing harm to third parties.
2. Send the report by email

   Email your report to:

   [e-mail]
   

   Use a subject line that makes the security nature of the report clear, for example: [CodeGate] Security vulnerability report — <brief description>.

   Do not open a GitHub issue, discussion, or pull request for the vulnerability before coordinating with the maintainers.

3. Wait for acknowledgment

   The maintainers will acknowledge receipt within 5 business days and assign a tracking status. If you do not receive an acknowledgment within that window, follow up by replying to your original email.

4. Coordinate fix and disclosure timeline

   The maintainers will:

   • Validate and triage the report.
   • Coordinate a fix and release timeline with you.
   • Publish a GitHub Security Advisory after a fix is available, or provide mitigation guidance if no immediate fix is possible.

   You will be credited in the advisory unless you request otherwise.

Security notes for users

While waiting for a fix, or when using CodeGate in security-sensitive contexts, consider the following practices from SECURITY.md:

• Use --format sarif in CI to keep security findings visible in code-scanning workflows.
• Treat exit code 2 as a deployment-blocking condition in CI/CD pipelines.
• Use codegate run <tool> as a local pre-flight guard before launching AI coding tools. It blocks dangerous findings, can require confirmation for warning-only findings, and rechecks the scanned config surface before launch.
• Use --deep only when you explicitly want Layer 3 remote metadata analysis.
• Layer 3 requests are consent-gated per resource. Skipped consent is recorded in the output for auditability.
• CodeGate does not execute untrusted MCP stdio command arrays during tool-description scanning.
• Use codegate scan --reset-state only when you intentionally want to clear MCP config change history stored at the resolved scan_state_path location.

For general questions or non-security issues, use the standard GitHub issue tracker. The private disclosure process is for vulnerabilities only.