Our Secure by Design pledge, goal by goal

In August 2026, Biff Labs Ltd, the company behind RaptorGRC, signed CISA's Secure by Design pledge: a voluntary, public commitment by software manufacturers to measurably reduce the exploitable flaws that reach customers. The pledge has seven goals, and signers are asked to show real, documented progress against them. This page is that documentation for RaptorGRC and for this site, kept current as things ship. Where something is not done yet, it says so.

1. Multi-factor authentication In progress

Every account on this portal, customer and staff alike, requires MFA: a sign-in code by email, upgradeable to an authenticator app with recovery codes. RaptorGRC itself ships MFA with a per-role enforcement policy an administrator controls. Still in flight: turning enforcement on by default for local accounts in new product deployments, so the secure path is the default path rather than a setting.

2. Default passwords Shipped

There are none. A RaptorGRC deployment refuses to start until you set the admin credential, and the first-run setup screen exists precisely so no installation ever runs on a credential the vendor chose. This portal's own seeded accounts follow the same rule.

3. Reducing entire classes of vulnerability In progress

RaptorGRC is built on the memory-safe .NET runtime and uses parameterised data access throughout, with no hand-built SQL. Every merge request is gated by injection-focused static analysis; every release adds Semgrep taint and pattern rules over vendored rulesets, plus a container vulnerability scan. So the two run at different points: continuous analysis on each change, the deeper scans before anything reaches a customer. A Semgrep finding can be suppressed inline, which requires a written justification alongside it in the code. One more thing worth saying out loud. A release can be pushed through with a failing code-quality gate by setting an explicit override on the pipeline, which prints a loud warning into the build log and exists for the case where a gate is wrong and a fix cannot wait. It is a decision someone has to take deliberately, not a default. We treat this goal as permanently in progress: each release cycle looks for the next class worth eliminating.

4. Security patches Shipped

Releases are published in the customer portal, and every organisation running an activated licence is emailed the changelog the moment a new version is uploaded. Because deployments are offline, patching is a pull, not a push: the announcement tells you a patch exists, and the portal gives you the verified artifact to carry across your own boundary.

5. Vulnerability disclosure policy Shipped

We publish a full vulnerability disclosure policy covering what is in scope, the authorisation and safe harbour you have when testing your own deployment, how to report, and what we commit to in return. In short, email security@raptorgrc.com, expect a human reply within three working days and an assessment within ten, and we will not pursue legal action over good-faith research that follows the policy. We do not run a bug bounty. The policy is discoverable from /.well-known/security.txt.

6. CVEs and vulnerability transparency In progress

Our release pipeline generates a software bill of materials for every build it produces, in both CycloneDX and SPDX, alongside the container vulnerability scan and build provenance. The image, the CycloneDX bill of materials, the provenance and the release metadata are each signed, and the bundle ships the public key and instructions so you can verify them yourself. The SPDX copy is not signed, so verify against the CycloneDX one. Releases in the customer portal carry that bill of materials and the full scan report for that exact build, with checksums, so customers see what we see. Being straight about the mechanism at the portal end. The artefacts are attached to a release after it is uploaded, and nothing there refuses a release that has neither. Generating the evidence is automatic; publishing it is our practice rather than a gate, and closing that gap is on the list. Also still under consideration: becoming a CVE Numbering Authority so issues in RaptorGRC get CVE identifiers issued and published by us directly.

7. Evidence of intrusions Shipped

RaptorGRC records security-relevant actions to its audit log as standard, in every edition, so the evidence an intrusion investigation needs exists before anyone knows they need it. Because the product runs inside your network, that evidence stays yours. What that does not mean. Auditing is written into each use case rather than captured automatically underneath them, so its coverage is a matter of engineering discipline, not a structural guarantee. The write queue is bounded, and if it fills, or a database write fails twice, that entry is dropped and the drop itself is logged rather than passing silently. We would rather tell you where the edges are than imply a guarantee we cannot make.