Read the coverage before you read the score
Decide when a configuration score is meaningful, why small reports show counts, and what to compare after a change.
Two checks do not need a score
A report says that neither of two header checks passed. After a change, both pass. Has the website become secure? The evidence answers a smaller question: those two settings changed in the inspected responses. It says nothing by itself about account access, background jobs or the rest of the application.
Start with this synthetic example. It teaches display eligibility, not a scoring formula, and none of its rows is an exported scan result.
| Constructed case | Completed checks eligible for scoring | What to read |
|---|---|---|
| Two header checks fail; one report area is assessed | 2 | “0 of 2 checks passed,” alongside coverage; no /100 number |
| The same two checks pass after a change | 2 | “2 of 2 checks passed,” alongside coverage; still no /100 number |
| Five distinct weighted checks complete, with a valid recorded score | 5 | A numeric display becomes eligible; read the recorded value, not a number calculated from this table |
| Four distinct checks, with one record repeated | At most 4 | A repeated record cannot supply a fifth completed check |
The first two rows can describe useful progress without a large number. You can explain the change, identify the inspected settings and decide what to investigate next. Turning the pass count into a percentage would make the display look broader without adding evidence.
Checks and areas have different denominators
A check asks a defined question about a resource. An area groups part of the report's scope. Several checks can contribute evidence within one area, so “two checks completed” and “one area assessed” are not conflicting statements. Neither denominator counts every security question someone could ask about the application.
Read the coverage labels as part of the result. An assessed area can contain failed checks. A partially assessed area has useful evidence and remaining gaps. An unassessed area was not established as safe; it remains unassessed even when another area has no findings.
In our example, the homepage header checks do not inspect what happens when one signed-in user requests another user's records. That question needs different evidence. The scan-limits article explains how to separate an observation from the wider conclusion you might be tempted to draw.
Why the display waits for five
SecurityFuse shows a /100 score only when at least five completed weighted checks support the display and a valid recorded score is available. Five is SecurityFuse's presentation threshold. It is not a security standard, an accuracy claim or a promise that five checks cover your application.
The count concerns distinct checks, not the sum of their weights. A single heavily weighted check still counts as one. A check that could not be assessed does not become a pass or help satisfy the completed-check threshold. A check outside the applicable scope does not supply evidence merely because its record exists.
Repeated or conflicting records need care, too. They must not inflate the count. If the retained records do not support a reliable display, the right response is an explanation of what is missing, rather than a reassuring number inferred from the finding count.
Below the threshold, read the passed-check count with the recorded scope and coverage. Above it, keep reading those same facts. Eligibility permits the number to be displayed; it does not promote the result into an overall security rating.
A pass fraction is not the recorded score
The table deliberately includes no invented numeric score. A weighted policy can treat checks differently, and the recorded result has its own policy and evidence basis. Dividing passing checks by completed checks is not a substitute for that result.
The distinction matters when evidence is incomplete. A report might contain a successful observation, a failed observation and another check that could not finish. The unfinished check is neither a pass nor a reason to describe the report as complete. Look for the limitation and decide whether another observation is needed.
Configuration presence is also narrower than overall security. A header being present does not establish that every directive is appropriate, that the application handles untrusted input correctly or that all deployment paths return the same response. Read what each completed check actually evaluated before deciding what its outcome means for your next change.
Compare the basis before the result
If two reports display numbers, check whether they concern compatible resources, methods and scoring policies. A broader inspection can reveal a failed setting that the earlier inspection never reached. That is new information, not evidence that the earlier unknown was a pass.
Likewise, a change in coverage can make a simple numeric comparison misleading. Read which observations completed in both reports, which remain unknown and whether the comparison is inconclusive. The repair-to-recheck article walks through the evidence needed to say an earlier absence is no longer observed.
SecurityFuse's hosted website scans are available to invited users, with Quick and Deep profiles. Access does not change how a result should be read. Whether you are reviewing two header checks or a broader report, begin with the assessed scope, then the findings, and only then the score if the evidence supports displaying it.