Only the latest released version receives security fixes.
| Version | Supported |
|---|---|
Latest v0.x.y release |
Yes (until superseded by the next minor) |
Older v0.x.y releases |
No |
main (unreleased) |
Best-effort, not formally supported |
Please do not file a public GitHub issue for security reports. Public reports give attackers a window before a fix is available.
We accept reports through two channels — pick whichever is easier for you:
- Go to the repository's Security tab: https://github.com/amagioss/opentams/security
- Click Report a vulnerability.
- GitHub will create a private security advisory visible only to you and the maintainers.
GitHub's private reporting flow lets us collaborate on a fix, request a CVE, and coordinate disclosure inside one tracker. This is the path we prefer when you have a GitHub account.
Send a report to security@amagi.com.
For sensitive findings we encourage using GitHub Private Vulnerability Reporting (Channel 1) instead — it encrypts in transit and keeps the report, fix, and coordinated disclosure inside one tracker. If you must use email, please avoid attaching exploit binaries or sensitive customer data to plaintext mail; a brief description that lets us reproduce is enough to get the conversation started.
Whatever channel you use, please include:
- A description of the vulnerability and the affected component (
pkg/...,internal/..., an API endpoint, a deployment manifest, etc.). - Steps to reproduce — a minimal proof of concept, request payload, or test case is ideal.
- The version (image tag, release tag, or commit SHA) and deployment context (Docker, Kubernetes, etc.) where you observed it.
- Your assessment of impact (data exposure, privilege escalation, denial of service, etc.) if you have one — we'll re-assess regardless.
- Whether you'd like public credit and, if so, how to credit you.
| Stage | Target |
|---|---|
| Acknowledgement of receipt | Within 3 business days |
| Initial triage (severity, scope, reproduction confirmed) | Within 7 business days of acknowledgement |
| Coordinated disclosure window | Up to 90 days from triage; we aim to ship fixes much earlier for high-severity issues |
If we cannot meet a target, we will tell you why and propose a revised timeline rather than go silent. If you do not hear back within the acknowledgement window, please re-send — mail can get filtered.
- Give us reasonable time to investigate and ship a fix before public disclosure (the 90-day window above).
- Avoid testing against production OpenTAMS deployments you do not own. The repository ships a
deployments/docker/docker-compose.ymlthat brings up a complete local stack for safe testing. - Do not exfiltrate data, pivot to other systems, or otherwise expand impact while validating a finding.
- We will keep you informed of the fix's progress.
- We will publish a GitHub Security Advisory for every confirmed vulnerability, with a CVE where applicable.
- We will credit reporters in the advisory and in the release notes (unless you ask to remain anonymous).
- We will not pursue legal action against reporters who follow the guidelines above in good faith.
The following are not considered vulnerabilities for the purposes of this policy:
- Findings against versions older than the latest
v0.x.yrelease. - Issues that depend on a misconfigured deployment outside OpenTAMS's documented configuration surface (e.g. an operator disabling
DB_SSLMODEand exposing the DB to the internet). - Findings against third-party dependencies — please report those upstream and let us know so we can pull a patched version.
- Denial-of-service via unbounded request volume (rate limiting is the operator's responsibility per the deployment guide).
If you are unsure whether something is in scope, err on the side of reporting it — we would rather triage and decline than miss a real issue.