Please do NOT report security vulnerabilities through public GitHub issues.

1. Navigate to Security Advisories
2. Click "New draft security advisory"
3. Fill in the details including:
   • A description of the vulnerability
   • Steps to reproduce
   • Potential impact assessment
   • Any suggested fixes (optional)

The following areas are in scope for security reports:

• Authentication bypass in the Gateway or Admin API
• Injection attacks (SQL, command, header injection)
• Privilege escalation between tenants, or between the data and admin planes
• Exposure of provider API keys through any route, log line or error response
• Key or secret material surviving where it should not — a minted secret readable after creation, or a captured request body outliving its TTL

The following are out of scope:

• Denial of Service (DoS) attacks against rate-limited endpoints
• Issues in third-party dependencies that have already been publicly disclosed
• Theoretical vulnerabilities without a working proof of concept

Worth understanding before reporting, because it shapes what counts as a vulnerability here.

Provider API keys are held in gateway memory only. They are returned by no route, written to no disk, and printed in no log line; a provider listing shows key_prefixes, never keys. There is no key vault and no encryption at rest, because there is nothing at rest to encrypt — a restart loses them and they are re-registered. Any path that causes a provider key to leave the process is a vulnerability, and that is the property to attack.

CogniGate keys are stored as a SHA-256 hash plus a displayable prefix. A minted secret is returned exactly once and cannot be recovered afterwards, by anyone, including an operator with database access.

The two credentials an operator must protect are GATEWAY_BOOTSTRAP_KEY, which is unrestricted admin access, and ANALYTICS_TOKEN, which is the only thing standing in front of the metering API. Both are generated by setup.sh / setup.ps1 into .env. Never commit either, and rotate both if a deployment is suspected of exposure.

We follow coordinated disclosure. We ask that:

• You give us reasonable time to fix the issue before public disclosure
• You do not exploit the vulnerability in production systems
• You do not share the vulnerability with anyone else until it is patched

We credit all security researchers who report valid vulnerabilities in our release notes.