Rule packs
Ready-made rule and test packs instead of writing every check from scratch
A pack describes what to check in a specific technology, which permissions that takes and what the evidence looks like. Versioned, with a changelog and both vulnerable and safe examples.
01
A catalog of operator products
To start with, only our own packs. We will open the catalog to outside authors only once the review process has been proven in practice.
Operator product
Everything below is ours. We sell our own packs and assess other people's products at the same time, so we say so plainly wherever the two appear side by side. The rules are set out in our neutrality policy.
Buyers and the free check
Trust triage by URL
A tool's public surface by URL: who it shares data with, who is behind it, where its forms send data, encryption, keys in the page code.
- version
- 0.10.0
- rules
- 28
- level
- L0, no owner consent needed, only what anyone can see
- input
- page URL, plain GET requests
Teams and agencies before release
Data boundaries in Supabase
Data boundaries in Supabase: access policies, functions with elevated privileges, roles and storage buckets. Run on a configuration snapshot, without connecting to the system.
- version
- 1.1.0
- rules
- 9
- level
- L1, no authorization required
- input
- a configuration snapshot you export yourself
02
What a pack contains
A pack without all of this is a file of tips, not a control tool.
A permission declaration
What the pack needs, what it is not allowed to do and which authorization level it requires.
Vulnerable and safe examples
A rule has to find the problem in an example that has it and stay silent on one that does not. Otherwise there is no way to know it works at all.
An evidence format
What the pack records as evidence and how to reproduce it.
An outbound connection declaration
Where the pack reaches while it runs. Nowhere, by default.
A fix template
A specific fix for the problem found, not generic advice.
A version and changelog
A pack without a version cannot be tied to a result from three months ago.
03
When we will open the catalog to others
A catalog without trust is just a pile of packages. That is why we will open it only once the security review of a pack is a process rather than a promise, and once there is something to test it on.
The thresholds are written down and they do not move: at least fifty paying buyers or twenty repeat clients, plus a working review process with signed versions.