Cherub checks your code.

In writing, every month.

What Cherub looks at

The list is short, and it is fixed. What is not on it does not get checked either — this is the point where a check report is either honest or merely reassuring.

1. 01

   Access rules

   Who may see and change what in your application is a rule in the database — not a setting in the interface. Cherub holds those rules against the state you laid down, continuously, and reports when something has shifted. A change that opens up a rule along the way goes unnoticed in day-to-day work: the interface looks exactly the same afterwards.

2. 02

   Tenant separation

   As soon as your customers look into the application themselves — each with their own quote, each with their own orders — their data sits side by side in the same database. What keeps it apart is a rule, not a wall. Cherub checks that rule from the wrong side and tries to reach one customer’s data with another customer’s permissions. If that works, it is a finding — even if nobody would ever have stumbled across it in day-to-day work. Because this mistake does not come to your attention: it comes to the attention of two of your customers at once.

3. 03

   Dependencies

   Your application is not only your own code. It uses third-party components, and vulnerabilities keep becoming known in them — including in ones that have been running unchanged for years. Cherub holds the list of those components against what is publicly reported. Anything from severity “high” upwards blocks the release anyway until it is fixed. The report also lists what sits below that and has stayed open.

If Cherub finds nothing, that does not mean nothing is there — only that the ways in we know about are closed.

A report that is allowed to say “not checkable”

A report in which everything is always fine is not a report. That is why Cherub has three results and not two. Whatever could not be checked cleanly goes in as “not checkable” and not as green — a tick without evidence is the point at which the whole report becomes worthless.

In order

Checked, and it held. Next to it stands what exactly was checked.

Finding

Something is not right. With a severity, with the place it refers to, and with the next step.

Not checkable

The check did not run through — access blocked, environment not reachable, case not covered. That is what it says, and it does not get rounded up into a tick.

And not every finding is the same: each one has a severity, and you see what it refers to. You can look into it yourself, or have anyone you like look into it — the code sits in your repository, not in ours. A month with three findings is not a bad month. It is the month in which three things are on the table instead of in the code.

What runs anyway, without Cherub

So that you take this tier for the right reason: without Cherub your application is not unchecked. In tier 1 as well, the access rules are enforced at database level, third-party components are held against known vulnerabilities continuously, and every change goes through the same chain of checks before it goes live. Cody applies security updates and then checks that everything still runs. That applies to every customer, at no extra charge.

The difference is not checked or unchecked. It is: continuously instead of at sign-off, and with a report instead of without. If nobody asks you for evidence and you do not need one yourself to sleep soundly, stay on tier 1.

None of that is an all-clear. What is described is what gets done — not that nothing can happen.

What people ask at this point

01

Doesn’t my hosting provider do that?

Part of it, and that part he usually does well. Your hosting provider keeps the server up to date, applies system updates and shields it from the outside. He provides the hall, locks the gate and keeps the roof tight.

What lies in the cabinets and who holds which key is not part of his job. That the fitter must not see the payroll list in your application is a rule in your code — not a setting on the server. Some platforms will at least tell you when there is no lock at all somewhere. Whether the right lock is on it, and whether it still closes after the next change, is something nobody there looks into.

That is Cherub’s work: checking the access rules continuously against the state you laid down, and reporting when something has shifted. No check is complete, ours included. But every month you get it in writing: what was checked and what came out of it.

The cross-check: ask your hosting provider whether he will confirm in writing that he checks who may see which data in your application. If he confirms it, you do not need Cherub for that.

02

What happens if Cherub finds something?

Small things Cody fixes in ongoing operations and writes into the report — you read what it was and what became of it. Anything bigger, or anything that needs your decision, goes into the report with a severity and a proposal and waits for you. Anything from severity “high” upwards does not go live anyway until it is fixed.

A finding that stays open does not disappear from the report. It is in the next one again, with the date it has been open since.

03

Why should I take your word on the checking? You don’t have a single customer.

True. That is why there is no reference and no quote with a company logo on this page.

What you can look at instead: the checks themselves, on our own software, in the conversation — running, not as a slide. You see what they trip on and what does not go live afterwards. You do not have to be able to read the code for that. And if you have someone who can judge it, bring them along.

Being the first has two sides. Short paths and direct influence on what gets built — and no customer before you from whose project we would already have learned. Both belong on the table before you sign.

If the second list fits better, stay on tier 1. You can add the tier later at any time — cancellable monthly, no minimum term.