# Security Policy

## Supported versions

Security fixes are made against the latest supported release line. Until
Zynor reaches 1.0, only the newest published `0.x` minor line and its latest
patch receive fixes; older `0.x` lines should be treated as unsupported.

| Version | Security support |
| --- | --- |
| Latest published `0.x` line | Supported |
| Older `0.x` lines | Unsupported; upgrade first |
| Unreleased branches/builds | Best effort; never production releases |

Runtime support and end-of-life rules are maintained in [SUPPORT.md](SUPPORT.md).

## Report a vulnerability privately

Do not open a public issue for a suspected vulnerability and do not attach
credentials, session data, private customer data, or a weaponized proof of
concept to an ordinary issue or pull request.

Use GitHub's private vulnerability-reporting flow when it is enabled for the
repository. If that control is unavailable, email `git@yuniq.solutions` with
the subject `[SECURITY] Zynor`. Include:

- affected version, runtime, entry point, and provider;
- the security boundary that fails and the expected boundary;
- minimal reproduction steps with synthetic data;
- likely impact and whether exploitation has been observed;
- a safe way to coordinate any sensitive attachment.

Never send live tokens or customer data. Redact secrets and rotate anything
that may already have been exposed.

## Response targets

These are operating targets, not a guarantee that every report has the same
complexity:

| Milestone | Target |
| --- | --- |
| Acknowledge receipt | 2 business days |
| Initial severity and scope assessment | 5 business days |
| Critical mitigation or compensating control | 7 calendar days after confirmation |
| High-severity fix | 30 calendar days after confirmation |
| Moderate/low fix | Next planned supported release, with status updates |

The maintainer may ask for coordinated disclosure while a fix and downstream
notification are prepared. Credit is offered when requested and when doing so
does not disclose private information.

## Security-sensitive surfaces

Reports are especially useful around DNS wire parsing, provider failover and
rate limits, SSRF/redirect handling, cache ownership and persistence, native
addon loading, conditional-export isolation, bundled provider data, and
release/package provenance.

## Release and advisory handling

A confirmed vulnerability receives a private remediation branch, regression
tests, independent review, and a release/advisory decision. Release artifacts
must be rebuilt from reviewed source; an old mutable `lib/` directory is never
promoted. Revocation, deprecation, or yanking decisions follow
[RELEASING.md](RELEASING.md).