Research

Your Security Score Is Lying to You

Four ways a security score misleads without a single check being wrong — counted fixtures, presence theatre, severity without likelihood, and the average that hides the critical. What to demand from any number before trusting it.

Webcuris Research

Security Engineering

·3 min read

score: 90 with a tick, beside findings: 1 critical, unread

A security score can be built from individually correct checks and still tell you something false. No bug required — just four structural ways the compression from findings to number loses exactly the information you needed. We know because our own scanner did most of these to us before we fixed it, scored our own repository 24/100, and taught us what an honest number has to survive.

Lie #1: counting findings that are not about your product

Any real repository accumulates code that should look dangerous: deliberately vulnerable test fixtures, security tooling whose rule definitions match their own patterns, vendored examples, a training app kept around for onboarding. A scanner that scores these as production findings produces a number dominated by code no attacker can reach — which is exactly how our repository earned 24/100 from its own fixtures.

The wrong fix is a quiet ignore-list, because a finding suppressed is a finding nobody can audit. The honest mechanism is scope classification: findings outside product code stay recorded, listed and readable — they just stop deciding the number. A credential committed to a fixtures directory is still a committed credential; it is a different fact from one in your checkout handler, and the score should know the difference.

Lie #2: presence theatre

Checks that award points for a control existing rather than working inflate every score they touch. The canonical example is a Content-Security-Policy carrying 'unsafe-inline': present, green on every checker, and useless against the attack the header exists to stop. The same pattern hides in an HSTS header with a five-minute max-age, a DMARC record at p=none forever, cookie flags on the cookie that does not matter. A score that reads presence gives you the grade for owning a fire extinguisher, empty.

Lie #3: severity without likelihood

Scores that weight findings by CVSS alone rank a never-exploited critical above a medium being actively harvested. Severity answers how bad if it happens; a score meant to order your week also needs how likely — exploit probability, whether the vulnerable path is even reachable, whether the asset faces the internet. Fold those in, or the number optimises for the wrong queue.

Lie #4: the average that hides the critical

Ninety-nine perfect checks and one exposed database can average to a comfortable 90. Any score that lets volume of passing checks dilute a single catastrophic finding is a dashboard designed to reassure. An honest aggregate is asymmetric: one critical should drag the number to somewhere that ruins a morning, and the score should recover only when the finding does.

What to demand from any score

AskWhy it separates honest numbers from theatre
Which findings decide the number, and which are shown but not counted?Scope classification is auditable; a silent ignore-list is not
Does it read values, or presence?The difference between a working CSP and a decorative one
What weights it — severity alone, or likelihood and exposure too?Decides whether the score orders your actual risk
Can one critical sink it?If not, the aggregate is an anaesthetic
Can you see the delta, not just the level?A 71 means little; went from 85 to 71 on Tuesday means a deploy did something

If your current tool's score seems either flattering or absurd, the diagnostic is the first row of the table: ask it which findings are deciding the number. A free scan here shows you both layers — the score, and every finding with the evidence that produced it, marked by whether it counts.

Get the next one

One email when a new article goes out. No newsletter, no drip sequence, no sales follow-up.

Unsubscribe in one click. We never sell or share the address.

Keep reading

Contact

Talk to us.

Questions about what the engine checks, whether it fits your estate, or what it deliberately refuses to do. A person reads every message.

  1. 01You writePlain form, no qualifying call, no obligation. The marketing checkbox is optional and unticked.
  2. 02A person reads itMessages land with the team, not a queue-bot. Nothing is auto-replied.
  3. 03You get an answerTo the address you gave — including “this product is not the right fit”, when that is the honest answer.
Reporting a vulnerability?
Read the disclosure policy first — it tells you what is in scope and what to expect.
New messagereplies go to your email

We reply to this address, so a disposable one will not reach you.

+91

0 / 4000