Security & Responsible Disclosure
This page tells security researchers, customers, and members of the public how to report a vulnerability in AuditFlow to us, what to expect when they do, and the protection from legal action that we extend to good-faith researchers.
1. Scope
In scope:
- The hosted application at
*.audit-flow.net, including the marketing site, the authenticated workspace, and the super-admin surfaces. - The Python source code in the public GitHub repository.
- The transactional emails AuditFlow sends from the
audit-flow.netdomain.
Out of scope:
- Denial-of-service attacks against the production environment. Demonstrating that a request is slow or that a queue can be overwhelmed without an actual outage is fine; running the outage is not.
- Social engineering of AuditFlow staff or customers, including phishing simulations against either group.
- Physical attacks against AuditFlow infrastructure or staff.
- Reports that are exclusively about missing best-practice headers, cookie attributes, or CSP refinements, without a demonstrated impact path. Please open a normal GitHub issue or PR for those.
- Issues in our third-party sub-processors (Render, OpenAI, SMTP provider). Please report those directly to the affected vendor.
- Findings that require physical access to a user's already-unlocked device.
2. What we ask of researchers
To remain protected under the safe-harbor provisions in section 4 below, please:
- Make a good-faith effort to avoid privacy violations, destruction of data, and interruption of the Service.
- Use test accounts you have created yourself. Do not access, modify, or exfiltrate other customers' data.
- Stop testing and contact us if you encounter customer data (real personal data, real credentials, real audit content) during testing.
- Give us a reasonable time to remediate before public disclosure — 90 days is the default. We are happy to extend or shorten by mutual agreement, particularly for findings with a partially-deployed fix.
- Do not include real customer data, real passwords, or live tokens in your report.
3. What to include in your report
- A concise description of the issue.
- Reproduction steps and the affected URL, commit hash, or feature flag.
- Any proof-of-concept code, traffic captures, or screenshots that help us validate the report.
- Your assessment of impact (what an attacker could do).
- Optional: how you would like to be credited if we publish the disclosure.
4. Safe harbor
We will not pursue civil or criminal action against, or refer law enforcement to, any researcher who:
- Makes a good-faith effort to comply with this policy;
- Stops testing and reports the issue promptly upon discovery;
- Does not exploit the issue beyond what is necessary to demonstrate it; and
- Does not publicly disclose the issue before we have had a reasonable opportunity to remediate, as defined in section 2.
If your research is conducted in line with the above, we consider it authorised under our Terms of Service and any applicable computer-misuse law in the jurisdictions where we operate. We will say so in writing if you ask.
5. Our commitment to you
When you submit a valid report, we will:
- Acknowledge receipt within 1 business day.
- Give you a triage outcome (accepted / duplicate / out-of-scope / not-a-vulnerability) within 5 business days.
- Keep you informed of remediation progress at a cadence appropriate to the severity. Critical and high-severity findings get a weekly update; medium gets a biweekly update; low gets an update when the fix lands.
- Credit you on the public change log when the fix ships, unless you ask us not to.
- Where appropriate, request a CVE ID through the GitHub Security Advisory process.
6. Bug bounty
We do not currently operate a paid bug-bounty programme. We are working toward one in 2027 — see the security maturity roadmap for the planned rollout. Until then, we credit responsible disclosures publicly and reach out personally to researchers we want to keep talking to.
7. PGP / encrypted communication
We do not yet publish a PGP key for info@audit-flow.net.
If you have a finding that materially benefits from encrypted
transport (for example, the report includes live credentials or
exploit code), reply to our acknowledgement requesting an encrypted
channel and we will set one up before you send details.
8. Coordinated disclosure timeline
Once a fix has shipped to production, we publish:
- An entry on the public change log.
- An email notification to the account owners of affected customers, when there is identifiable customer impact.
- Where appropriate, a GitHub Security Advisory with a CVE ID.
9. Contact
info@audit-flow.net — all security communications.