Vulnerability Reporting

Canonical policy: the repository root SECURITY.md. This page is a short operator-facing summary.

How to report

If you discover a security vulnerability in Kazma:

Do not open a public GitHub issue
Email admin@kazma.ai, or use GitHub private vulnerability reporting when it is enabled on the repo
Include steps to reproduce, impact, and affected version
Allow ~48 hours for acknowledgment (best effort)

Machine-readable contacts (RFC 9116): /.well-known/security.txt on a running instance, and .well-known/security.txt in the repo.

We do not currently publish a PGP key. Prefer private GitHub reporting or email; request encrypted-mail coordination if you need it.

What to include

Description of the vulnerability
Steps to reproduce
Potential impact assessment
Affected version / environment
Suggested fix (if any)

Scope

In scope: Kazma core, gateway, UI/TUI, skills/MCP integration, document intelligence, configuration and secret handling.

Out of scope: pure third-party dependency issues (report upstream), social engineering, volume DoS against hosted instances, physical host attacks.

No paid bug bounty

There is no cash bounty program at this time. Responsible reports are still welcome; credit may be offered with your consent. See SECURITY.md and bug_bounty.enabled: false in kazma-security.yaml.

Disclosure timeline (targets)

Time	Action
Day 0	Report received
≤ 48 h	Acknowledgment (target)
≤ 7 days	Initial assessment (target)
≤ 30 days	Patch when practical and in our control
After fix / ~90 days	Coordinated public disclosure

These are best-effort targets, not contractual SLAs.

Advisory IDs

Internal trackers use KAZMA-ADV-YYYY-…. That is not a MITRE CVE. A real CVE is requested only when appropriate (e.g. GitHub Security Advisories).