Security

Security reports need a private path. Do not report a suspected vulnerability in a public GitHub issue, pull request, discussion, or Discord thread.

Report a vulnerability Email the maintainers with Security: at the start of the subject.

Check production guidance Review the operational checklist for TLS, secrets, storage, observability, and deployment.

Browse product repositories Find the repository that owns the affected code.

Report privately

Email oss@cratis.io with Security: at the start of the subject. Include only what is needed to route and reproduce the report:

• The affected Cratis repository, package, or Docker image, and the exact version, tag, or commit.
• The behavior you observed and the behavior you expected.
• Bounded reproduction steps or a minimal reproducer.
• The conditions required to reach the behavior.
• The potential impact as you understand it: what an attacker could read, change, disrupt, or escalate.
• A safe way to contact you for follow-up.

Keep sensitive data out of the first message

Do not put credentials, tokens, customer data, personal data, production data, or sensitive logs in the first email. If more evidence is needed, ask for a private way to transfer it.

What not to share publicly

Do not post exploit details, secrets, tokens, customer data, private logs, private topology, or reproduction repositories in public channels. If you already opened a public issue, remove the sensitive details and email the maintainers with a link to it.

Ordinary defects and feature requests that contain no sensitive security information belong in the affected repository’s public issue tracker; see GitHub issue trackers.

What this route commits to

This is a private reporting route. It does not create a response-time commitment, service-level agreement, support plan, disclosure deadline, or bug bounty, and it is not a statement about the security posture of any Cratis product. A public issue, build, release, or package does not establish that a product is secure, compliant, supported, or suitable for a particular environment.

When you report a problem in an older release, include the version you run so the maintainers can judge the practical fix path. For package and runtime compatibility, see Version compatibility. For operational hardening, see Production readiness.