This policy tells you how to report a security vulnerability to Maelstrom AI. It sets out what we promise in return, and the safe harbour for good-faith research.
Scope
This policy covers these downpipes systems:
- the downpipes engine;
- the downpipes console;
- the downpipes offline reader, the
downpipecommand; - the downpipes update channel at update.downpipes.io;
- the downpipes control plane, the service that issues downpipes licences.
This policy also covers these websites and our support platform, for reports and the safe harbour only. The target times to fix do not apply to them:
- the maelstrom.au website;
- the downpipes.io website;
- the docs.downpipes.io website;
- our support platform.
Do not test our support platform in a way that reaches real support data.
The engine and the console run in each customer’s own Cloudflare account. Test them only against a deployment that you own.
How to report
Email your report to security@maelstrom.au. Do not open a public GitHub issue for a security finding. We have not turned on GitHub private vulnerability reporting, so use email.
Include:
- a description of the vulnerability and the affected component;
- steps to reproduce it, a proof of concept or a test vector, if you have one;
- the impact as you understand it;
- how we can contact you.
To encrypt your report, use our OpenPGP key at https://maelstrom.au/.well-known/security.asc. Before you use the key, make sure that its fingerprint is:
3AFA 3933 B25B 53B9 DBFA 1464 B047 75F6 8767 EF48
Our security.txt file gives the same contact and key.
What we promise
We acknowledge your report within 2 business days. We keep you informed while we fix the issue. We coordinate public disclosure with you. When the fix ships, we credit you by name, or anonymously if you prefer.
We set a target time to fix each confirmed finding in a downpipes system in scope. The target time starts on the date we become aware of the finding.
| Severity | Examples | Target time to fix |
|---|---|---|
| Critical | Remote code execution, authentication bypass, plaintext key exfiltration | 2 business days |
| High | Privilege escalation, authentication downgrade, data exposure | 7 calendar days |
| Medium | Defence-in-depth bypass, missing rate limit, server-side request forgery | 30 calendar days |
| Low | Missing header, documentation gap, informational finding | 90 calendar days |
You deploy the engine, the console and the reader yourself. They do not update automatically. You are responsible for deploying each fix to them within the target time above.
We assign severity from the CVSS 4.0 base score. A finding that first needs a compromise of the customer’s Cloudflare account gets a lower severity.
Some fixes need a coordinated release, for example a change to the archive format that the offline reader must also support. For such a fix, the target time can be up to 30 days longer. Each such extension needs a written internal record that accepts the risk. This extension never applies to a Critical or High finding.
We do not run a bug bounty programme at this time.
Supported versions
Every security fix lands first in the main branch of the affected downpipes component. We support each tagged release for 90 days after its tag. On request, we backport a Critical or High fix to a supported release. We do not support older releases. Upgrade to the latest release.
Coordinated disclosure
We follow a 90-day coordinated disclosure model. Give us up to 90 days from the date of your report before you disclose the finding publicly. This gives us time to confirm the issue, fix it and ship the fix.
If a fix is ready sooner, we disclose sooner. If a finding is unusually hard to fix, we agree any extension with you in writing. We never ask you to delay disclosure indefinitely.
We publish security advisories on our Security Advisories page.
Safe harbour
If you report a vulnerability in good faith and in line with this policy, we will not take or support legal action against you. We treat such research as authorised, and we do not consider it a breach of computer-misuse terms or our terms of service. If a third party raises a concern about your research under this policy, we will say so on your behalf. We work with you to understand and fix the issue quickly.
Good-faith research means that you:
- avoid privacy violations, data destruction, and any interruption or degradation of services or systems;
- interact only with accounts that you own or have explicit permission to test;
- do not access any data beyond the minimum needed to show the finding, and do not change or keep customer data beyond that minimum;
- never use, store, share or exfiltrate any data that you access beyond what the report needs;
- do not exploit a finding beyond what you need to confirm it;
- report the finding to us promptly;
- give us reasonable time to fix the issue before you disclose it publicly.
If you are not sure whether we allow an action, ask us at security@maelstrom.au before you proceed.
This safe harbour does not cover a breach of the law. It covers every system and website in scope, within the limits of this policy. It does not cover tests against any other system that you do not control.
Out of scope
This policy does not cover:
- denial of service, and load or volume tests;
- social engineering, including phishing of our staff or our customers;
- physical attacks;
- a downpipes deployment that you do not own;
- flaws in the platforms that other companies run, such as Cloudflare, Stripe and GitHub. Report those to the company that runs them. How we configure those platforms for a system or website in scope is part of that system or website.
Document Information
- Version. 1.1
- Last Updated. 2026-09-29
- Owner. ISMS Owner
- Review Frequency. Annually
- Classification. Public
- Change (1.1). The target time to fix starts when we become aware of a finding. The policy covers our support platform, for reports and the safe harbour only. Do not test the support platform in a way that reaches real support data.
- Change (1.0). First publication.