Coin RevolutionAn independent
reading edition

Reading the numbers

A Security Score Is Not a Loss Probability

A vendor survey, an incident total and a vulnerability severity score describe different evidence. Keep their populations and purposes separate.

1,164 words6 min readCoin Revolution Editorial Desk

New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.

The recovered Coin Revolution collection includes a vendor press release about crypto-security threats and a much older description of security-team activities. Both can prompt useful questions, but neither is a complete probability model for a reader's own system. The common mistake is to turn an alarming count, a severity label or a list of controls into a personal estimate of loss. This new article offers a way to read such material without flattening its different kinds of evidence. All numerical examples below are fictional. They illustrate measurement and review problems rather than estimating the security of any named provider, wallet or protocol.

Identify the population behind the percentage

Suppose a fictional survey receives responses from 100 organisations and 40 report at least one relevant incident during a stated year. The observed proportion is 40 percent of respondents under the survey's incident definition. It is not automatically the annual probability that an arbitrary organisation, address or customer will suffer a loss. The respondents may have selected themselves, may belong to one market segment or may interpret incident differently. Even a carefully collected survey needs a defined population before its result can be used beyond the group actually observed.

Ask who could have appeared in the dataset and who could not. A report based on a vendor's customers describes a different observation channel from public incident disclosures or a randomly sampled research panel. A dataset can be informative without representing every service in the ecosystem. The report should distinguish respondent organisations, affected accounts, events and loss amounts. If those units change between paragraphs, a reader may believe several figures corroborate one claim when they actually describe different populations and different stages of the same event.

Separate a report, an incident and a loss

A fictional monitoring team records 100 alerts. After investigation, 40 concern confirmed issues, and several of those issues refer to the same ten services. The alert count, issue count and affected-service count are all useful operational measures. None can replace the others without explanation. A successful attempt, an unsuccessful attempt and a detected configuration weakness also do not establish the same outcome. Calling every alert a theft would erase the work of classification; calling only completed thefts relevant would hide important near misses and weaknesses.

Loss amounts introduce another measurement layer. A report might discuss an initial estimate, a later revised estimate, assets recovered or exposure that was never realised. An assessment should state which quantity it is using and at what observation date. For historical news, retain the estimate as reported rather than silently converting it into a final finding. The new question can then be precise: what evidence would establish the amount, the affected party and the event boundary? Precision about the claim is a prerequisite for meaningful comparison, not a reason to disregard the event.

Read severity according to its defined purpose

FIRST's CVSS specification describes a framework for communicating characteristics and severity of vulnerabilities. It separates intrinsic characteristics from threat-related and environment-specific information. That structure is useful because the same technical weakness can matter differently in different deployments. A severity score is not a direct estimate of an organisation's future monetary loss. It should be interpreted with the metric definitions and assessment context that produced it, rather than treated as a percentage or a complete ranking of businesses. This article does not assign a CVSS score to any actual vulnerability.

Consider a fictional weakness in software that one organisation runs on an isolated demonstration machine and another exposes through a critical production service. The underlying weakness can be the same while exposure, available mitigations and operational consequences differ. A review needs to connect the weakness to the actual deployment. It should also distinguish the presence of a vulnerability from evidence that it has been exploited in that environment. A compact score can organise part of the discussion, but it cannot supply missing asset inventories, dependency maps or incident observations.

A control list is not evidence of effectiveness

The older security-team source describes several kinds of work, including automated scanning, manual review, testing and response preparation. Such activities have different observation capabilities. A scanner finding no issue does not show that every relevant behaviour was examined, while a manual review does not imply that every future code change has the same properties. The useful reading is to ask what each activity covered, which version it examined and what evidence its result produced. A list of techniques becomes more informative when its boundaries are visible.

For a fictional service, compare two statements. One says that transaction monitoring exists. The other describes a test in which a defined suspicious condition generated an alert, reached the responsible person and triggered the expected response. The second provides evidence about a particular control path; it still does not prove that every attack would be detected. Keep that limited result rather than replacing it with either absolute confidence or blanket dismissal. Control effectiveness is investigated through scoped observations, not inferred solely from the name of a technique or a product feature.

Make uncertainty part of the comparison

Two fictional reports can differ because their methods differ, not because one ecosystem suddenly became safer. One may count attempted intrusions over a quarter, while another counts publicly disclosed losses over a year. Their coverage, disclosure delays and event definitions can all affect the result. Before drawing a trend, compare those dimensions and identify which remain unknown. A chart joining incompatible series can look precise while representing a change in measurement. The appropriate conclusion may be that the observations cannot support the proposed comparison without additional work.

A useful uncertainty statement names the missing information rather than attaching a vague caveat. For example, the analyst might lack the total number of exposed deployments, the number of incidents that were not reported or the final outcome of an investigation. Each gap limits a different inference. This also helps define the next research step: collect deployment coverage, establish reporting rules or update a provisional event record. Uncertainty becomes operationally useful when it tells the reader which question is unanswered and which kind of evidence could answer it.

Build a claim-to-evidence worksheet

For each important sentence in a security report, record the claimed object, its unit, its time interval and the source of the observation. Then note the inference being made. A vendor statement about its own capabilities, a survey response, a technical severity assessment and a confirmed incident investigation should remain distinct entries. The worksheet need not be complicated. Its purpose is to stop one category of evidence from being silently used as another, especially when a headline compresses several technical and commercial claims into one confident conclusion.

The final output should be proportionate to what was established. It may identify a serious weakness, a relevant pattern in a defined sample or a control path that needs testing. It should not manufacture a personal loss probability from a severity label, nor claim that an organisation is secure because a report lists familiar tools. Historical reports are valuable records of what their sources described at the time. A disciplined present reading adds context, checks the measurement boundaries and keeps the remaining uncertainty visible instead of converting it into an invented number.

Technical references

From the recovered archive

Keep reading.