Reading a Scan Report: Critical, High, Medium, Low

A scan report is only useful if it tells you what to do next. Severity exists to answer one question: what needs attention in the next ten minutes, and what can wait for the next sprint. Everything else in a report is supporting evidence for that decision.

The four levels below are the ones KAIKI assigns, and the definitions are deliberately behavioural. A level is not a description of how alarming a string looks. It is an instruction about what to do.

Critical: rotate before you do anything else

An active production secret is directly exposed. An AWS access key in committed code, a live database password, a payment provider secret, an admin API token in a config file the application imports at boot.

Two things make a finding critical: the credential is almost certainly valid, and the code path that reads it belongs to something that matters. Rotation comes first, before cleaning history, before writing the incident note, before deciding who should have caught it.

What critical does not mean

It does not mean the repository is compromised, and it does not mean you should page the whole team. It means one specific value needs to be dead within the hour.

High: treat as compromised, fix today

Sensitive credentials or configuration that could be exploited but sit one step further from production. A committed .env file with staging database credentials. A service token with a narrow scope. A cloud key that has been rotated once already but still appears in history.

These usually allow a short, ordinary change window rather than an emergency. Plan the rotation properly, verify every consumer, and do it before the end of the day rather than the end of the quarter.

Medium: investigate, then clean up

Potentially sensitive values that may not be active. A hardcoded internal endpoint, a stale token nobody recognises, an internal hostname that reveals more about the architecture than it should.

Medium findings are where judgement earns its keep. A stale token is harmless until someone reactivates the account it belongs to. Worth investigating and removing; not worth interrupting a release for.

Low: fix while you are already in the file

Informational findings and best-practice recommendations. A missing .gitignore entry, a secret referenced in a comment, a placeholder that looks close enough to a real key to confuse the next reader.

Low findings age badly if ignored, because they describe the conditions that produce critical findings later. Batch them into a cleanup pass rather than a ticket each.

Severity is not a measure of how bad a string looks. It is a measure of how quickly you should act, and how much of your day it deserves.

Working through a report without losing an afternoon

1. Sort by severity and finish every critical finding before opening anything else.

2. Rotate before you rewrite history, because removing the code does not invalidate the key.

3. Read the file path as part of the evidence: the same value in a production config outranks the same value in a test.

4. Check the provider audit log for anything you rotated, then write down what you found.

5. Re-scan after remediation so the report reflects reality rather than intentions.

What a good finding contains

A severity alone is not actionable. Every finding should carry the file, the line, the credential type, and a remediation suggestion, because those four facts decide which console you open and what you type into it.

The credential type matters more than teams expect. Knowing a value is a Stripe restricted key rather than a generic forty-character string tells you where to rotate, what breaks when you do, and how much access was exposed while it was public.

When you disagree with a severity

Sometimes a finding rated High is genuinely inert, and sometimes a Medium finding is the most dangerous thing in the repository because of context the scanner cannot see. Both cases are normal, and both are worth a note in the ticket rather than silent dismissal.

The useful test is not how the value looks, it is what an attacker could do with it in the next five minutes. A stale token for a decommissioned service is noise. A narrowly scoped key that can read your customer table is not, whatever the label says.

Keep a record of dismissals

Write down why a finding was closed without action. Six months later, when the same value appears again after a refactor, that sentence is the difference between a two-minute decision and a repeat investigation.

Reading the report as a work queue

The healthiest way to use severity is as a queue, not a grade. A repository with twelve low findings and no criticals is in good shape. A repository with one critical finding and nothing else has one urgent job.

Every KAIKI finding includes the file, the line, the credential type, and a suggested fix, so the report doubles as a task list you can work top to bottom.