Our Vulnerability Disclosure Policy: How to Report a Flaw in RaptorGRC

Illustration for: Our Vulnerability Disclosure Policy: How to Report a Flaw in RaptorGRC

The fifth goal of CISA’s Secure by Design pledge is the only one with a hard deliverable rather than a direction of travel. Within a year of signing, publish a vulnerability disclosure policy that authorises testing by members of the public, commits to not recommending or pursuing legal action against good-faith research, provides a clear channel to report, and allows public disclosure in line with coordinated disclosure practice.

We have published one, and it now meets all four criteria. This article says where it lives, what it commits us to, and where I still think it is thin.

Where the policy lives

The policy is on our Secure by Design page, under the disclosure heading, at /secure-by-design#disclosure. That is the human-readable version and it is the authoritative one.

There is also a machine-readable pointer at /.well-known/security.txt, following RFC 9116. It names both contact routes, the policy location, the canonical URL and the preferred language, and it carries an expiry date as the standard requires.

One implementation detail is worth mentioning because it is the sort of thing that usually rots. That file is not a static document sitting in a folder. It is generated in code, and there is a test in the build that fails when the expiry date is within reach of lapsing. An expired security.txt is worse than none at all, because it tells a researcher the policy behind it is unmaintained, so the expiry date is enforced by something that breaks the build rather than by somebody’s calendar reminder.

One channel that leads, and one alternative

If you find a security issue in RaptorGRC or in this site, email security@raptorgrc.com with enough detail to reproduce it. If you would rather not email, the contact form on this site reaches us too.

Both routes are named, in that order, in three places, which are the policy on the Secure by Design page, the product repository’s own security policy, and the two contact lines in security.txt. A researcher who starts from the product and a researcher who starts from the site now arrive at the same mailbox. That sounds like housekeeping. It is not. Inconsistency about where to send a report reads as inattention, and a researcher who has to guess which channel is real is a researcher who may not bother.

You are authorised to test your own deployment

CISA’s wording asks for an affirmative grant of permission, not merely a promise of restraint. Ours is explicit. You are authorised to test against your own RaptorGRC deployment, which is the only place the product runs, so nothing you do there reaches another customer.

Two limits, and they are the ordinary ones. Please do not test this website in ways that degrade it for other people, and never access or alter data that is not yours.

What we commit to in return

We acknowledge security reports within three working days. We keep you informed while we investigate. We credit reporters who want credit once a fix has shipped, and we do not name anyone who would rather stay anonymous.

We ask for coordinated disclosure, which means a reasonable window to fix before publication. The product’s own security policy sets that window at ninety days, which is the commonly used figure and is the one we work to.

We do not run a bug bounty. There is no money. RaptorGRC is free and Biff Labs is small, and I would rather say that plainly than advertise a reward programme we cannot fund.

We will not take legal action against good-faith research conducted within these terms.

What is unusual about testing a self-hosted product

Most disclosure policies assume a shared production system the vendor operates. Ours mostly does not have one.

RaptorGRC runs inside customer networks. There is no shared instance, no multi-tenant service to probe, and no demo environment. If you want to test the product, the right target is a deployment you control, which for the Community Edition means one you have downloaded and stood up yourself. Testing somebody else’s RaptorGRC installation is testing their network, not ours, and nothing in our policy authorises that.

The exception is this site. raptorgrc.com is ours, we operate it, and it is in scope.

That asymmetry is genuinely useful for a researcher, because it means you can be as aggressive as you like against your own container without any question of authorisation. It also means we get far fewer reports than a SaaS vendor would, which is a downside for us rather than for you.

Why the authorisation wording was worth the fuss

Earlier drafts of our policy said we would not pursue legal action against good-faith research, and stopped there. That is the half of CISA’s criterion most vendors get wrong, so it was not a bad place to be. It was also not the whole requirement, because a promise about what we will not do is not the same as a grant of permission to do something.

Somebody will reasonably say that the distinction is lawyer’s noise, that no researcher was ever deterred by a missing clause, and that our intent was obvious from the rest of the page. There is something in that. The practical difference on a Tuesday afternoon is nil, and a disclosure policy written like a contract is one nobody reads.

Where it stops being pedantry is when a researcher’s employer gets involved. Professional security testing is often reviewed by somebody in the tester’s own legal or compliance function before it starts, and that person reads for an affirmative grant of permission, not for tone. The clause is not there to reassure the researcher. It is there to get them past their own approvals.

The same argument applies to having one leading channel rather than two competing ones. Neither change altered what we would actually do about a report. Both changed whether a careful person can act on the policy without asking us a question first.

What is still thin

The supported-versions statement lives in the product repository rather than on the site, and it is the thing a customer most needs when they are deciding whether a fix will reach them. Security fixes are provided for the current released minor version and the one before it. Older releases have to upgrade. That should be on the public policy page, not only in a file in the source tree.

There is also no published record of what this policy has produced. CISA lists exactly that as a way of demonstrating progress, and it is the obvious next thing to add.

So here is the figure as it stands. Since the policy was published in August 2026 we have received no security reports through it at all. Not one. That is an unremarkable number for a product this young with this few deployments, and it says nothing about whether RaptorGRC has flaws, only that nobody has told us about one yet.

Reporting a small number honestly is the point of the exercise. A vendor who only publishes this figure once it is impressive is publishing marketing, not evidence, and the first honest number is always going to be a small one.

The full tracker is at /secure-by-design. What does and does not leave your network is set out at /transparency.