Severity & Scoring

Cerberus turns its 59-check native catalog into a 0–100 score and letter grade. Each of the nine native agents owns a weight; ALIGNMENT is scored separately and feeder evidence never changes native points.

Check states

Every check in checks.json resolves to exactly one of four states when a scan runs. Only fail deducts points — the other three are informational.

A healthy, well-run repository can still score in the 90s even though most of its checks are not_applicable or pass rather than fail — the score only ever moves for fail.

Per-hit deductions

Every finding is assigned one of four severity levels, each with a fixed per-hit deduction:

For a failed check, the deduction is per_hit[severity] × min(hits, hit_cap) — hits beyond the cap don't cost extra, since one badly-matched file with 40 instances of the same problem shouldn't sink the score harder than a single instance would. The default cap is 3 hits per check; some checks (like R-01 hardcoded IPs, or C-04 cleartext HTTP) set a lower or higher cap explicitly in checks.json because their detector is inherently noisier or cleaner.

agent_score = agent.weight - Σ over failed checks in that agent of (
    per_hit[check.severity] × min(check.hits, check.hit_cap)
)
agent_score = max(agent_score, 0)   // floored at 0, never negative

total_score = Σ agent_score over all 9 agents   // 0–100

Why per-agent weight instead of one flat deduction?

Weighting by agent means a single domain going badly wrong (say, every VAULT check failing) can zero out that agent's 13 points without being able to drag checks in other, unrelated domains below their own floor. It also means the same severity finding costs a different amount depending on which agent it's in — a GATEKEEPER critical (weight 12) and an AUDITOR critical (weight 8) both deduct 4.0 points per hit, but AUDITOR has less room to give before it floors at 0.

Letter grades

The numerical score maps to a familiar letter grade. This makes it easy to communicate posture to stakeholders who are not reading the detailed report.

Agent weights

Each agent's weight is its maximum possible contribution to the 100-point score, defined once in checks.json and summing to exactly 100:

Agent scores help you see which part of the security surface needs the most attention. A low SENTINEL score means the code itself has material issues; a low WATCHTOWER score means container/CI/repo-hygiene configuration needs hardening.

Worked example

Suppose SENTINEL (weight 14) has these failed checks in a scan:

• S-01 (Hardcoded credential assignment, critical) — 1 finding
• S-06 (Dynamic code evaluation, high) — 2 findings
• S-08 (Non-cryptographic randomness, medium) — 1 finding

Using the default hit cap of 3, SENTINEL's score is:

14 - (4.0 × min(1,3)) - (2.0 × min(2,3)) - (1.0 × min(1,3))
= 14 - 4.0 - 4.0 - 1.0
= 5.0

If every other agent passed clean (contributing its full weight), the total score would be 100 - 14 + 5.0 = 91.0, which maps to grade A — SENTINEL's own three failures pull its own domain down hard (5.0 of 14), while the overall score stays high because the other eight domains are clean.