Security Policy
Supported Versions
Only the latest major line is supported, and security fixes ship in its latest release.
| Version | Supported |
|---|---|
| 3.x | ✓ (latest release) |
| 2.x | ✗ end of life since 2026-07-18 |
| 1.x | ✗ end of life since 2026-07-18 |
| 0.x | ✗ |
See docs/lts.md for the full support and deprecation policy.
Reporting a Vulnerability
Do not open a public GitHub issue for security vulnerabilities.
Report using GitHub Security Advisories.
Include in your report:
- Description of the vulnerability
- Steps to reproduce
- Potential impact and affected versions
Response Timeline
- Acknowledgment: within 48 hours
- Initial triage: within 5 business days
- Status updates: every 7 days until resolved
- Target resolution: within 90 days for critical issues
Scope
In scope: boruna-vm (capability gateway, replay engine), boruna-compiler, boruna-orchestrator
(workflow runner, evidence bundle verification), boruna-mcp server.
Out of scope: example files, documentation, third-party dependencies.
Backport Policy
Security fixes are released as a new patch or minor release of the current major line. There are no backports to older minor releases or to earlier major lines; upgrade to the latest release to get a fix.
Severity follows CVSS v4:
- CRITICAL or HIGH — fix released within 7 days of confirmed disclosure (or an interim advisory with mitigations if no fix is ready).
- MEDIUM — fix released within 30 days of confirmed disclosure.
- LOW — bundled with the next scheduled release.
Support-window definitions live in docs/lts.md.
Disclosure Policy
We follow coordinated disclosure:
- Reporter submits privately via GitHub Security Advisories
- We confirm the issue and assess severity
- We develop and test a fix
- We release the fix and publish a security advisory
- Reporter is credited (unless they prefer anonymity)
Safe Harbor
Good-faith security research conducted in accordance with this policy constitutes authorized testing. We will not pursue legal action for responsible vulnerability disclosure.