Disclosure.

If you have found a security issue in any project I maintain — Project Velocity, Carpet PvP Practice, this site, or anything else under github.com/AndrewCTF — I want to hear about it. Reports from independent researchers have made every project I have shipped better than I could have made it alone.

The fastest path is encrypted email to security@andrewctf.dev. PGP is preferred for anything that includes a working exploit, a chain in active use, or any detail that would burn a defence if it leaked. Request the current public-key fingerprint by sending a short note to that address; the key is also mirrored on keys.openpgp.org under the same address.

If PGP is friction, send a short note to the same address asking for a Signal handle. I will respond within one business day to acknowledge receipt and arrange a channel.

You do not need a polished writeup to start a conversation, but the reports that move fastest tend to include:

• The affected project, version, commit hash, or live endpoint.
• A minimal reproduction — code, request, or step-by-step. A proof-of-concept that fires once is worth ten paragraphs of speculation.
• Your read of the impact and the conditions required to reach it (authenticated, on-path, locally privileged, etc.).
• Anything you have already tried that did not work — this is genuinely valuable for narrowing the bug class.
• A handle or alias you would like used in the eventual credit. Anonymous reports are welcome.

Do not test against systems you do not own. Do not exfiltrate data beyond what is needed to demonstrate the bug. Do not degrade availability for other users. Beyond that, get in first and ask questions later — I would rather receive a rough hunch than miss a real bug because the reporter felt underprepared.

Research conducted in good faith on projects I maintain — code you can clone and run locally, services I host directly, endpoints I operate — is welcome. You will not be threatened with legal action, sent an aggressive lawyer, or referred to law enforcement for the act of finding a bug and reporting it through this channel.

"Good faith" means the standard things: you stayed within the scope of the project, you did not access or modify data belonging to other users, you stopped at the point of proving impact, and you reported the issue privately before publishing it. If you are unsure whether something is in scope, ask before you test — I would much rather scope a question than read a writeup of an accident.

This commitment is mine, individually. It does not bind any third party — for example, a service provider that hosts an instance of one of my tools — and it does not authorise testing against systems I do not control.

The lifecycle for an inbound report is intentionally boring:

• Day 0–1. Acknowledge receipt. Confirm we can reach each other on the chosen channel.
• Day 1–7. Reproduce. Triage severity. Tell you what I found and where I disagree with the report, if I disagree.
• Day 7–30. Patch in a private branch. Share the candidate fix with you for sanity-checking. Request a CVE if the issue warrants one.
• At release. Ship the fix, publish the advisory, and credit you on the terms agreed up front.

These windows compress for actively exploited issues and expand for ones that need an upstream coordination. If a schedule is going to slip, you will hear from me before the date passes, not after.

The same standards I want applied to my own work apply to the work I do on other people's systems. To date that has produced fourteen public CVEs, plus a longer tail of issues fixed quietly under coordinated timelines that never warranted a public number. The rules I follow are short enough to fit on this page.

Coordinated disclosure by default. If I find a vulnerability in a third-party project or service, I report it to the maintainer or vendor through their published security channel before discussing it anywhere else. If the vendor has no security channel, I find a maintainer through public means and ask them where reports should go.

Ninety-day window. I follow a ninety-day disclosure deadline measured from the point of confirmed receipt. The clock can be paused or extended by mutual agreement when a fix is genuinely in flight, and I will shorten it for vulnerabilities under active exploitation after coordinating with the vendor.

CVE assignment. Where the issue meets the criteria, I request a CVE through MITRE or the relevant CNA so defenders downstream of the affected software have a durable identifier to track the patch. The advisory is written to be useful for IR teams, not for marketing.

No surprise disclosures. No public tweets, no conference talks, no blog posts that would let an adversary derive the bug before the patch is available to users. If the deadline passes without a fix, I notify the vendor of intent to disclose, share the planned writeup, and give them a final window to respond.

No exploit sales. Working exploits and chains discovered during this work are not sold, traded, or brokered to third parties under any circumstance. If you have heard otherwise, you have heard wrong.

The following are not in scope for the inbound program and will be politely declined:

• Reports generated entirely by automated scanners, with no human-confirmed reproduction or impact analysis.
• Best-practice findings on this static portfolio site that describe missing security headers without a corresponding attack scenario. Useful suggestions are welcome — phrase them as suggestions.
• Issues in dependencies that are already fixed upstream and only require a version bump in this repository. Open a pull request instead.
• Social-engineering or physical-access attacks against me or anyone I work with.

Researchers who report a confirmed issue are credited in the advisory and, where appropriate, in release notes and the CVE record. You can choose how you appear: real name, handle, organisation, or anonymous. The default is whatever you signed your report with. Credit is the smallest possible thank-you for work that makes everyone safer — please take it if you want it.

Security reports: security@andrewctf.dev (PGP preferred). Everything else: hello@andrewctf.dev. Privacy questions are answered in the privacy policy.