Skip to content

Security

How we secure our own systems — and how to tell us when we have not.

A company that sells security work should be willing to say what it does about its own, and to make reporting a problem straightforward rather than intimidating.

Our practices

The unglamorous things that prevent most incidents.

None of this is novel. It is applied consistently, which is the part that actually matters.

  • Dependencies kept current

    Known-vulnerable components are the most commonly exploited weakness on the web, largely because exploitation is automated. Dependencies are audited and updated as part of routine maintenance rather than after an incident.

  • Least privilege by default

    Accounts, tokens and service credentials are scoped to what they actually need. Administrative interfaces are not left reachable from the public internet without a reason.

  • Transport and headers

    HTTPS everywhere, with security headers set at the framework level so they apply to every route rather than being remembered page by page.

  • Backups that have been restored

    A backup nobody has ever restored is an assumption. Recovery is tested, because the moment you need it is the wrong time to discover it does not work.

  • Authorisation before testing

    We do not test systems without documented permission from the party entitled to grant it. That applies to prospective clients' systems as much as anyone else's.

Responsible disclosure

Found something? Tell us.

If you have found a security issue in this website or in a system we operate, we want to hear about it, and you will not face legal action from us for reporting it in good faith.

Please do

  • Report the issue privately, before disclosing it anywhere public
  • Include enough detail to reproduce it — a URL, the steps, and what you observed
  • Give us a reasonable opportunity to fix it before publishing

Please do not

  • Do not access, modify or delete data belonging to anyone else
  • Do not run denial-of-service or high-volume automated testing against live systems
  • Do not use social engineering, phishing or physical intrusion against staff

What happens next

We aim to acknowledge reports quickly, keep you informed while we investigate, and tell you when the issue is resolved. We are glad to credit reporters publicly if you would like that.

Report to

security@regenbyte.com

A machine-readable version of this policy is published at /.well-known/security.txt.

Need this level of scrutiny on your own systems?

Assessments, penetration testing and hardening across your website, applications and infrastructure.