This repository is a documentation and knowledge-base platform. It does not ship a running service, but it contains code samples, CI workflows, and automation. This policy covers all of it.
| Version | Supported |
|---|---|
main (latest) |
Yes |
| Tagged releases within the last 12 months | Yes |
| Older tagged releases | No |
See RELEASE_STRATEGY.md for how versions are cut.
Do not open a public issue for a potential vulnerability. Use this repository's GitHub Private Vulnerability Reporting form once it has been enabled by the maintainer.
Before the first public release, the maintainer must enable Private vulnerability reporting in the repository's GitHub security settings. Until that setting is enabled, this repository does not have a public security reporting channel and must not be published as release-ready.
Include the affected file or workflow, why it is a security concern, and a suggested fix when possible. Maintainers target acknowledgment within five business days and a severity decision within ten business days.
- We will patch actively supported versions before public disclosure.
- We will credit the reporter in the fix's changelog entry unless anonymity is requested.
This platform teaches production engineering, which sometimes requires showing an insecure pattern to explain why it fails. Any such sample must:
- Be clearly labeled as insecure and not for use.
- Be immediately followed by the corrected, secure version.
- Never be presented as a copy-pasteable snippet without that framing.
If a sample violates this rule but does not expose a live vulnerability, report it as a standard content correction.
- Vulnerabilities in third-party tools linked from Knowledge Pack Further Reading sections: report those upstream.
- Vulnerabilities in the Custom GPT platform itself: report those to the platform provider.