This policy applies to every repository in the kotoba-lang organization unless that repository overrides it with its own SECURITY.md.

Do not open a public issue for a security vulnerability.

Report privately by either route:

• GitHub private vulnerability reporting — the Security tab of the affected repository → Report a vulnerability. Preferred, because it keeps the report attached to the code.
• Email root@junkawasaki.com with [security] in the subject.

Please include: the repository and commit SHA, the affected version or deployed endpoint, reproduction steps, and the impact you believe it has. A proof of concept helps but is not required.

• Acknowledgement within 5 business days.
• An assessment (accepted / not-a-vulnerability / needs-more-information) within 15 business days.
• If accepted, a fix or documented mitigation, and coordinated disclosure once a fix is available.

This is a small project without a paid on-call rotation. These are the targets we hold ourselves to, not a contractual SLA.

In scope: source in kotoba-lang repositories, and the hosted kotobase.net service endpoints.

Out of scope: findings that require a compromised host or an already-privileged account; volumetric denial of service; reports generated by automated scanners with no demonstrated impact; social engineering.

We will not pursue action against good-faith research that respects this scope, avoids privacy violations and service degradation, and gives us a reasonable window to remediate before disclosure.

kotobase's threat model, auth boundaries, and data classes are documented per service rather than here. The authoritative documents live in the net-kotobase repository (docs/THREAT-MODEL.md, docs/DATA-HANDLING.md). If a report concerns those boundaries, cite the document and section so we can tell a policy gap from an implementation bug.