Skip to content

Reporting a vulnerability

TOPS reads customers' AWS accounts, so a vulnerability here can expose another organisation's cloud posture. If you've found one, this is what to do and what happens next. The full policy lives in SECURITY.md at the repository root; this page is the short version.

Do this

Do not open a public issue. Use one of these instead:

  1. Report it privately on GitHub — preferred. Keeps the report private while a fix is developed.
  2. security@teemops.com — if you'd rather not use GitHub.

You don't need a fix, a CVE, or a polished write-up first. A rough description of something that looks wrong is worth sending, with whatever you have: what the issue is, how to reproduce it, and the version you found it on.

What happens next
Acknowledgement Within 5 working days
Initial assessment Within 10 working days
Fix and release Depends on severity — you'll be told the plan and kept updated
Credit Named in the advisory and the changelog, unless you'd rather not be

Before you report

Never test against infrastructure you don't own. Reproduce against a local install or your own AWS account — a report isn't worth another organisation's data.

A finding the scanner reports about your AWS account is the product working as intended, not a vulnerability in TOPS — that's a normal issue, not a security report. And anything that needs shell access to the host TOPS runs on is out of scope by design: this is a self-hosted application, and an operator with a shell can read the database on purpose — see The security model.

SECURITY.md has the complete scope, the full list of what's already known and being worked on, and the disclosure timeline in full.

Source of truth for this page: SECURITY.md in the TOPS repository — read that one if anything here is out of date, not the other way around.