How to report
There’s one way to report, and no email address: GitHub’s private vulnerability reporting. On the repository page, open the Security tab and choose Report a vulnerability. This creates a private advisory that only the maintainers can see, where you and they discuss the fix and when to make it public.
Please include:
- a description of the problem and what harm it could do
- steps to reproduce it, ideally with a proof of concept that shows it working
- the affected version or commit ID, and how you run TestLookup: Docker Compose, Kubernetes or the bundle for networks with no internet access
- any ways around the problem you’ve already found
When GitHub was checked, private vulnerability reporting was turned on for the repository. If you can’t find the button, read the current SECURITY.md instead of posting details in public.
Response times
The maintainers commit to confirming they’ve received your report within 72 hours. They aim to send a status update within 7 days. For a confirmed critical problem, they aim to deliver a fix or a workaround within 30 days of confirming it.
These are the project’s own stated targets, not a contractual service-level agreement. The policy names no email address, so please don’t send reports by email.
Open the current security policy.
Scope
The policy covers these kinds of problem:
- getting around sign-in or permission checks: JWT sign-in tokens, API keys, single sign-on, SCIM user provisioning and the rules on who can reach which project
- getting data out without permission through the REST API, the command-line tool or the MCP server, which connects AI assistants to TestLookup
- personal data leaking through logs, prompts sent to an AI language model, or rendered reports
- leaks of the secrets TestLookup stores
- injection attacks, such as SQL, command or prompt injection, that affect other users’ data
- attacks on the web app such as cross-site request forgery, cross-site scripting or clickjacking
- supply-chain problems in the dependencies TestLookup lists or in its published container images
- unsafe default settings in the files TestLookup ships for installing it: the Docker Compose files, the Kubernetes overlays, and the install and deploy scripts
These are out of scope:
- denial of service by using up the resources of a TestLookup installation you host yourself, because you control that hardware
- problems in third-party dependencies that TestLookup’s own code can’t reach, which you should report to the project that makes the dependency
- social engineering or phishing aimed at the maintainers
- anything that needs physical access to the server
The maintainers practise coordinated disclosure. Once they confirm a problem, they agree a timeline with you for making it public. By default, the details stay private for 90 days from confirmation, or until a fix ships, whichever comes first.
Reporters are credited in the release notes and the GitHub advisory, unless they’d rather stay anonymous.
Under the policy’s safe harbour, the project won’t take legal action against researchers who:
- make a good-faith effort to avoid privacy violations, data destruction and service interruption
- report only through the private channel above
- allow reasonable time to investigate and fix the problem before disclosing it publicly
- don’t exploit the problem beyond what’s needed to confirm it
Read the full policy before you test. This summary doesn’t widen the scope or allow testing that disrupts anyone’s service.
Supported versions
The policy supports two versions, both on a “best effort” basis:
- 0.1.x, the latest patch release of the first public release line
- the main branch, where development happens
Builds made from code older than version 0.1.0 are marked unsupported, and the policy advises upgrading to the latest 0.1.x. Until version 1.0, only the latest release line and the main branch get security fixes. The policy will list long-term support versions once version 1.0.0 ships.
“Best effort” means the maintainers look into and fix security problems as time allows, with no contractual service-level agreement.
There is no 0.1.x release yet. When GitHub was checked on 7 November 2026, the repository had no releases and no version tags. Until 0.1.0 is released, the supported version is the main branch, and that’s where security fixes go.
The policy
The repository’s SECURITY.md file is the security policy. This page summarizes that policy: how to report, what to include, what’s in scope, how disclosure works, the safe-harbour terms and the response targets. For an analysis of where attacks could come from and which parts of TestLookup trust each other, it points to the threat model.
Please don’t post details of a suspected security problem in a GitHub issue, discussion or pull request. Check the current SECURITY.md before you report, in case the policy has changed.
Current version
The button at the top of this page opens the current SECURITY.md file on GitHub. This summary was written for the current development version of TestLookup. If the two differ, the file on GitHub wins.
The contribution policy, the code of conduct and the security policy all live in the repository, and this page doesn’t change them.