Vulnerability Disclosure Policy

We would rather hear about a security problem from you than from an incident. This policy tells you what we run, what you are permitted to test, how to reach us, and what we will do once you have. It applies to RaptorGRC the product and to this website. It is written to be usable by a researcher who has never spoken to us before.

1. Scope

In scope for testing and for reports.

• The RaptorGRC software itself, in any supported edition, running on infrastructure you control.
• The container images we publish, including their contents and their supply chain.
• This website and the customer portal at raptorgrc.com.
• Our published signing keys, signatures, software bills of materials and build provenance.

Out of scope.

• Another organisation's RaptorGRC deployment. RaptorGRC runs inside the customer's own network, so a deployment that is not yours belongs to someone else. Test your own.
• Third-party services we use but do not operate, including our hosting provider and content delivery network. Report those to the operator, and tell us if it affects us.
• The corporate systems of Biff Labs Ltd that are not part of the product or this website.

2. Authorisation and safe harbour

You are authorised to test RaptorGRC against your own deployment. That authorisation costs us nothing to give, because your deployment is yours. Nothing you do to it reaches another customer, and we have no visibility into it.

For this website and the portal, you are authorised to conduct good-faith research within the limits in section 3. If you follow this policy, we will treat your research as authorised conduct, we will not pursue or support legal action against you in relation to it, and we will say so in writing if a third party asks. If a court or regulator compels us to act, we will tell you as soon as we lawfully can. Should you break something inadvertently while following this policy in good faith, tell us and we will work it out with you rather than against you.

3. What we ask of you

• Stop as soon as you have proved the issue. Do not go further into a system than you need to demonstrate it.
• Do not access, copy, alter or delete data that is not yours. If you encounter someone else's personal data, stop, do not retain it, and tell us what you saw so we can assess the exposure.
• Do not degrade the service for anyone else. That rules out denial of service, load testing, spam, and automated scanning heavy enough to affect availability.
• Do not use social engineering, phishing, or physical attacks against our staff, our customers, or our suppliers.
• Give us a reasonable window to fix the issue before you publish. See section 5.
• Use test data you own. Do not create accounts or content that other users will see.

4. How to report

Email security@raptorgrc.com. If you would rather not email, use the contact form and say that your message is a security report, and we will reply with a route for the detail. Please write in English if you can.

A report is easiest to act on when it includes the following.

• Where the issue is, as a URL, an endpoint, or a file and version of RaptorGRC.
• What an attacker could achieve, in plain terms.
• Steps that reproduce it, ideally the smallest set that still works.
• Any proof you have, such as a request and response, a short recording, or a log extract.
• The version and deployment shape you tested, since RaptorGRC is self-hosted and configurations differ.
• How you would like to be credited, or that you would prefer not to be.

Please do not open a public issue, and please do not include real customer data in your report.

5. What you can expect from us

• Acknowledgement within 3 working days. A human reply, not an autoresponder.
• An assessment within 10 working days, telling you whether we have reproduced it, how we rate its severity, and what we intend to do.
• Progress updates at least every 14 days while the issue is open, so you are never left wondering.
• A fix target of 90 days from acknowledgement. If we cannot meet that, we will tell you why before the deadline rather than after it, and agree a revised date with you.
• Credit if you want it, in the release notes for the fix and in section 8 below.
• Notification to affected customers where an issue warrants it, alongside the fix.

6. Coordinated disclosure

We ask you to hold publication until a fix is available, or until 90 days have passed from our acknowledgement, whichever is sooner. If the issue is being actively exploited, tell us and we will move faster and coordinate a shorter timeline with you. We will not ask you to stay quiet indefinitely, and we will not treat a deadline you have honoured as a hostile act. If we disagree about timing, we would rather negotiate it with you openly than let it become a surprise for either side.

7. Things we already know about

The following are usually not treated as vulnerabilities on their own. Send them anyway if you can show real impact, because a chain of small things is still a problem.

• Missing security headers with no demonstrated exploit.
• Output from an automated scanner with no proof of concept behind it.
• Self inflicted issues that require the victim to paste content into their own browser console.
• Reports that a version number is out of date, without an exploitable path.
• Email configuration findings such as SPF, DKIM and DMARC policy strength, unless you can show a working spoof.
• Rate limiting on endpoints that are not sensitive, and account lockout policy preferences.
• Best practice advice with no attacker path, such as cookie flags on non-session cookies.
• Vulnerabilities that require a rooted device, a compromised host, or physical access to a machine the user already controls.

8. Recognition

We do not run a bug bounty and we do not pay for reports. RaptorGRC Community Edition is given away with every module included, and a small team giving software away has to choose where its effort goes. We would rather spend ours reproducing what you send, fixing it, and getting the fix into customers' hands quickly than run a bounty programme we could not run well. Saying so plainly seems better than implying a reward that is never coming.

What we offer instead is credit, published with the fix and listed here, a straight answer at every step, and a fix you can verify yourself rather than take on trust, since our releases ship with a signed bill of materials and the scan report for that build.

No reports have been credited yet. This section will list them as they arrive.

9. About this policy

This policy is published at /.well-known/security.txt so that automated tooling can find it, and it is referenced from our Secure by Design commitments, where goal five of CISA's pledge covers vulnerability disclosure. It sits alongside the SECURITY.md shipped in the product, which names the same mailbox.

We will revise this policy as we learn. Material changes will raise the version number shown at the top of this page.