A2A Mesh is a pre-1.0 project with a supported stable npm channel. Support applies to the newest fully published linked stable release exposed through the npm latest dist-tag. All six public packages move together; mixing package versions is outside the supported configuration.

A stable release reaches end of support as soon as its supported successor is fully published, registry parity is verified, and the latest dist-tag advances. Historical prereleases, including the preserved alpha channel, do not receive routine backports. The default branch, untagged commits, local builds, and source snapshots receive best-effort development attention but are not supported installable releases.

Do not open a public issue, discussion, or pull request containing suspected exploit details, credentials, private logs, or reproduction steps.

Use GitHub's private vulnerability reporting. Include the affected package and version, deployment assumptions, impact, reproduction steps, and any proposed mitigation. Remove real credentials, personal data, and unrelated secrets.

Use the following channels consistently:

• Private vulnerability report: suspected exploitable behavior or a security-boundary bypass.
• Draft repository advisory: maintainer coordination, private remediation, release preparation, and coordinated disclosure for a confirmed vulnerability.
• Public issue: non-sensitive hardening, defense-in-depth, documentation, or test improvements that do not reveal an unpatched vulnerability.
• Ordinary security pull request: routine dependency, tooling, policy, or hardening work with no confidential vulnerability context.

The current repository setting and governance evidence are recorded in the vulnerability reporting and review policy.

These are operational targets for a solo-maintained project, not contractual service-level agreements. Active exploitation, credible credential exposure, or cross-tenant impact is handled as an emergency and may change the sequence below.

If a target cannot be met, maintainers should update the reporter privately with the current risk, blocker, mitigation, and next review date.

For dependency advisories, the daily freshness gate targets detection of a newly published fixable high- or critical-severity advisory within 24 hours. @oaslananka owns dependency advisory triage and targets an initial remediation decision within 48 hours of detection. The daily gate is read-only and complements, rather than replaces, the blocking pull-request audit and OSV checks.

1. Reproduce and assess the report privately.
2. Create or update a draft repository security advisory for confirmed vulnerabilities.
3. Develop regression tests and a fail-closed fix without exposing private details.
4. Publish and verify the linked package release, provenance, registry parity, and expected npm dist-tag.
5. Publish the advisory with affected and patched version ranges plus practical upgrade guidance.
6. Request a CVE when a high-impact or broadly deployed vulnerability benefits from a globally recognized identifier. CVE assignment is not required to delay publication of an available fix.

The project may publish limited mitigation guidance before a fix when active exploitation or user safety requires it. Otherwise, implementation and reproduction details remain private until a patched release is installable.

Before upgrading, review the current compatibility matrix, the package changelogs, and the API stability policy. Release-integrity and provenance requirements are documented in the release integrity guide. Breaking pre-1.0 changes and required application updates are documented in the security upgrade guide.