Start a projectContact us

Security testing

Hands-on tests. Proof you can reproduce.

All security testingHow we workWhat happens after the first call.See the process

Build

We break software for a living. This is what we build.

All build servicesProof of workOur own apps, built the same way.See them

We test other people’s software for a living. We’d be glad to hear what you find in ours.

Email a reportRead security.txt

  1. Email us

    Send your report to vulnaratechnologies@gmail.com, with “Security report” in the subject.

  2. Include enough to reproduce it

    What’s affected, the steps, the impact and a proof of concept.

  3. Give us time to fix it

    Keep it private until it’s fixed and we’ve agreed a date with you.

Sending something sensitive? Say so first and we’ll agree a secure channel.

New report
To
vulnaratechnologies@gmail.com
Subject
Security report: [short summary]
Summary:
[One or two sentences: what is wrong and where.]

Affected:
[URL, product and version, or build number]

Steps to reproduce:
1.
2.
3.

Impact:
[What an attacker could do, and to whom.]

Proof of concept:
[Requests, screenshots or a short video. Attach, or share a private link.]

Credit:
[Your name or handle to thank publicly, or "anonymous".]
Open in your email app

In scope

This policy covers systems and software that Vulnara Technologies owns and runs:

  • the website at vulnaratechnologies.com, including its forms;
  • our products, Plumb, Aegis and imgosint, including pre-release and early-access builds we have shared with you;
  • source code we publish, once it is public.

We want real impact: cross-site scripting, a way round our Content Security Policy, injection, data exposure, or one of our apps doing more than it says it does.

Out of scope

  • Our clients’ systems. This policy never covers them. Report to the client directly.
  • Services we use but don’t run, such as our host, Web3Forms, Google and sites we link to. Report to them under their own programmes.
  • Denial of service, load testing, spam, social engineering and physical attacks.
  • Findings with no demonstrated impact: missing headers without an exploit, version banners, clickjacking on pages with no actions, SPF, DKIM or DMARC records, self-XSS.
  • Unchecked scanner output.

Safe harbour

If you research and report in good faith and follow this policy, we will:

  • treat your research as authorised, and not pursue or support legal action against you for it;
  • work with you to understand and fix the issue quickly;
  • make clear, if anyone else raises your research with us, that you acted with our permission.

Safe harbour can’t cover systems we don’t own, and doesn’t apply to anyone who breaks the rules below or acts to harm us or our users. Unsure? Ask first.

Testing rules

  • Use only accounts you created yourself, and access no more data than you need to show the problem.
  • If you reach personal or client data, stop, do not keep it, and tell us straight away.
  • Do not change or delete data, and do not degrade the site for anyone else.
  • Do not try to keep access, move sideways or pivot to other systems.
  • Keep the details private until the issue is fixed and we have agreed a publication date together.
  • Follow the law that applies to you.

What to expect

  • Within three business days: a reply, once we’ve tried to reproduce it.
  • Next: our assessment, the severity we give it, and whether we can reproduce it.
  • While we fix it: updates, and a note when the fix is live so you can check it.
  • Publication: a date we agree together. We ask for up to 90 days from your report, and we’re happy to go sooner once the fix is out.

Thanks and rewards

No paid bug bounty yet. With your permission, we thank you by name or handle here and in the fixed product’s release notes.

security.txt

Also published at /.well-known/security.txt (RFC 9116), pointing back to this page.

Last updated 28 September 2026