Smart contract audit report: how risk ratings work

That ranking determines what gets fixed before deployment and what gets filed under "acceptable risk." If the auditor's risk calculus is wrong, or deliberately inflated, the document that was supposed to protect user funds becomes a liability disguised as due diligence.

Understanding how auditors assign severity levels is not academic. It is the difference between reading an audit report as a useful signal and reading it as a false sense of security. We are going to dismantle the machinery behind those ratings — from the raw inputs of likelihood and impact, through the standardization attempts by bodies like OWASP, to the systemic problem of severity inflation that corrupts the entire ecosystem.

The Mechanics of Risk Scoring: Likelihood vs. Impact

Every vulnerability in a smart contract audit report receives a severity classification. The standard taxonomy across the industry is five tiers: Critical, High, Medium, Low, and Informational. The assignment is not arbitrary — or at least, it should not be. It is the output of a two-dimensional assessment.

Likelihood measures how easy it is to trigger and exploit a vulnerability in practice. An auditor considers whether the attack requires a privileged role, a specific market condition, or a sequence of transactions that is improbable in the wild. A reentrancy vulnerability in an unprotected withdraw() function has high likelihood — any external call can trigger it. A logic error that only manifests when a governance vote coincides with an oracle deviation exceeding 40% has low likelihood.

Impact measures what happens if the vulnerability is exploited. Complete loss of funds is the ceiling. A denial-of-service condition that temporarily halts withdrawals sits in the middle. A gas inefficiency that costs users an extra 5,000 gas per transaction is near the floor.

The severity rating is the intersection of these two vectors. A vulnerability with high likelihood and catastrophic impact is Critical. A vulnerability with low likelihood and minor impact is Informational. Everything else falls between.

Here is where the process starts to degrade. Individual auditing firms do not all use the same matrix. Some publish their scoring methodology; many do not. The result is that the same vulnerability can receive different severity ratings from different auditors — not because the code changed, but because the evaluative framework is proprietary, qualitative, and often opaque.

The community has attempted to standardize this. The most structured effort is OWASP.

Standardizing Security: From OWASP SCSVS to the SWC Registry

The OWASP Smart Contract Security Verification Standard (SCSVS), with its stable version 0.0.1 released in September 2024, provides a structured framework for assessing smart contract security. It defines three verification levels:

• Level 1 — Basic Security. Covers foundational controls: access control, proper use of cryptographic primitives, basic input validation. Most protocols should pass this as a minimum.
• Level 2 — Moderate Security. Adds controls for business logic integrity, oracle manipulation resistance, and more nuanced reentrancy protections. Appropriate for protocols managing significant TVL.
• Level 3 — High Assurance Security. Targets protocols with systemic importance — lending markets, cross-chain bridges, liquid staking derivatives — where failure cascades across the ecosystem.

The SCSVS is a verification standard, not an audit methodology. It tells you what security properties a contract should exhibit, but it does not prescribe how to score individual findings. That gap is filled, imperfectly, by the Smart Contract Weakness Classification Registry (SWC Registry).

The SWC Registry is a community-maintained catalog of smart contract weakness classes, aligned with the broader CWE taxonomy used in traditional software security. It provides standardized identifiers — SWC-101 for integer overflow and underflow, SWC-107 for reentrancy, SWC-112 for delegatecall to untrusted callee — that allow auditors and protocols to speak a common language about vulnerability types.

The problem: the SWC Registry has not been updated with new entries since 2020. The DeFi attack surface has evolved dramatically in six years. Flash loan vectors, oracle manipulation patterns, cross-chain message verification failures, and governance attack mechanics have no standardized SWC identifiers. Auditors referencing the SWC for classification are working with an incomplete map.

The OWASP Smart Contract Top 10, updated for 2025–2026, partially addresses this gap as a standard awareness document. Its current list elevates Access Control Vulnerabilities, Price Oracle Manipulation, and Logic Errors as top threats. But awareness documents and severity-scoring frameworks serve different functions. The Top 10 tells you what to worry about; it does not tell you how to quantify the risk of a specific finding in a specific codebase.

The gap between what standardization bodies provide and what auditors need to produce in practice is exactly where subjective judgment — and subjective inflation — enters the equation.

Decoding Severity Tiers: Critical, High, Medium, and Low

The five-tier system is the backbone of every audit report. We will break down what each level means in practice, and more importantly, what it should trigger in terms of remediation.

Critical

A Critical vulnerability represents an immediate threat. It results in a complete breakdown of function, loss of control over contract state, or complete compromise of funds. These findings require immediate remediation before any deployment. A Critical finding in a pre-deployment audit halts the launch. A Critical finding in a post-deployment audit should trigger an emergency pause.

Examples: unprotected selfdestruct that can drain the contract, an unchecked external call in a withdrawal function enabling reentrancy, or a flawed access control that allows any address to call an admin-only function.

There is no ambiguity here. If an auditor labels something Critical, the protocol must not ship until it is resolved. Any audit report that lists Critical findings and gives the protocol a passing grade is a contradiction.

High

High-severity findings handicap core functionality or conditionally lead to loss of funds under plausible scenarios. The distinction from Critical is often about preconditions — a High finding might require a specific price movement, a particular transaction ordering, or the presence of a malicious actor with moderate resources.

Examples: an oracle dependency that can be manipulated by a flash loan, a liquidation mechanism that fails under extreme market conditions, or a bonding curve with a rounding error that can be exploited over many iterations.

High findings demand resolution before deployment. Auditors sometimes accept a mitigation — a documented workaround or a reduced attack surface — rather than a full fix. This is where the auditor's judgment is most consequential and most scrutinizable.

Medium

Medium-severity findings point to vulnerabilities that are exploitable under specific conditions but are unlikely to result in total fund loss. They may affect individual users rather than the entire protocol, or they may require a confluence of external factors.

Examples: a price feed staleness check with an insufficient timeout, a front-running vulnerability in a specific function, or a gas griefing vector that could deny service to certain users.

Protocols should resolve Medium findings, but they represent acceptable residual risk in some deployment contexts. The auditor's report should articulate the specific conditions under which the vulnerability activates.

Low and Informational

Low-severity findings are minor bugs, inefficiencies, or outdated syntax that do not directly result in a loss of funds. Informational findings are suggestions for code improvement, style corrections, or documentation gaps.

These categories do not trigger deployment holds. They are, however, signal. A report with dozens of Low and Informational findings but zero Critical or High findings can indicate either a robust codebase or an auditor that did not look hard enough. The distribution tells a story.

This table is a simplification. In practice, the boundaries between tiers are where auditor discretion — and auditor bias — operates.

The Hidden Reality of Severity Inflation in Audit Reports

Severity inflation is a known and under-discussed problem in smart contract auditing. It occurs when auditors intentionally classify lower-severity issues at higher severity levels to inflate the perceived value of the audit.

The incentive structure is straightforward. A protocol pays $50,000 for an audit. The audit firm delivers a report. If the report contains 3 Critical findings, 8 High findings, and 15 Medium findings, the protocol team perceives exhaustive, high-value work. If the same codebase yields 0 Critical, 2 High, and 5 Medium findings, the protocol team may question whether the audit was thorough — or whether the next audit should go to a different firm.

This creates a race to the bottom in one direction: toward over-classification. Firms that are rigorous and honest about severity may lose business to firms that pad their reports with inflated findings. The protocol team, lacking the expertise to independently assess whether a Medium should have been a Low, accepts the inflated report at face value.

The consequences are real. When everything is classified as High, nothing is High. Developers, overwhelmed by inflated reports, develop triage fatigue. Real High-severity findings get buried under a pile of misclassified Medium findings elevated for optics. The signal-to-noise ratio degrades, and the protocol's actual risk profile becomes harder to discern.

Severity inflation is not a victimless distortion. It degrades the only mechanism DeFi protocols have for quantifying pre-deployment risk.

The exact percentage of audits affected by severity inflation is not publicly quantified — auditing firms have no incentive to disclose their internal scoring methodology or admit to the practice. But DAppSCAN's dataset of 1,199 open-source audit reports, which identified 9,154 weaknesses, shows the kind of volume that makes selective reclassification trivially easy to conceal.

How do you detect it? Look for patterns.

1. Vague descriptions. If a High-severity finding reads like a general recommendation rather than a specific, exploitable bug, it may be inflated. "The contract should implement additional access controls" is not a High finding — it is a Medium or Low observation packaged as a High.

2. Absence of proof-of-concept. Critical and High findings should come with a reproduction path — specific function calls, state conditions, and expected outcomes. If an auditor labels something Critical without demonstrating exploitability, demand the PoC.

3. Disproportionate volume. If one firm's report for a simple vault contract contains 40 findings while another firm's report for the same complexity level contains 12, the delta is worth interrogating.

4. Recycled findings. Some firms reclassify generic recommendations — "use SafeMath," "add event emissions," "renounce ownership" — as higher-severity findings to bulk up reports. These are legitimate suggestions but not vulnerability-tier issues.

The OWASP SCSVS and the SWC Registry were designed, in part, to give the ecosystem a shared baseline. But with the SWC frozen in 2020 and the SCSVS still in its early stable version, the tools for auditing-the-auditors remain underdeveloped.

Why Audit Reports Are Not a Guarantee of Protocol Safety

An audit report is a snapshot. It evaluates the specific code submitted at the specific time of review. It does not cover code deployed after the audit, configuration changes, governance proposals that alter parameters, or composability risks introduced by integrating with new protocols.

The limitations are structural:

1. Scope boundaries. Auditors audit what they are given. If a protocol submits its core contracts but not the peripheral routers, oromises, or migration scripts, those are outside scope. The report's findings apply only to the audited code. Protocols that trumpet their audit without disclosing its scope are performing theater.

2. Point-in-time analysis. The audit covers a specific commit hash. Any subsequent changes — even a single line — introduce un-audited code. Patches, hotfixes, and incremental upgrades are the most common source of post-audit vulnerabilities.

3. Composability blindspots. A contract may be individually sound but functionally dangerous when composed with another protocol. Auditors evaluate the code they see. Cross-protocol interaction risks — where Protocol A assumes Protocol B behaves in a specific way, and Protocol B's upgrade breaks that assumption — fall outside traditional audit scope.

4. Economic assumptions. Smart contract audits are primarily code-level assessments. They may flag oracle dependencies or liquidation assumptions, but they rarely perform full economic modeling. A lending market can have zero code-level vulnerabilities and still face systemic insolvency if its collateral parameters allow under-collateralized positions during volatile markets.

We can categorize the audit's actual utility as follows:

• What an audit does: Identify code-level vulnerabilities, logic errors, access control issues, and known attack patterns in the submitted code.
• What an audit partially does: Flag economic and composability concerns at a surface level, depending on the auditor's expertise and the engagement scope.
• What an audit does not do: Guarantee the absence of vulnerabilities, assess economic soundness, monitor deployed contracts, or evaluate operational security (multisig configuration, key management, upgrade timelocks).

A protocol with a clean audit report from a reputable firm has cleared one bar. It has not cleared all bars. The reports that matter most are the ones where the auditor is explicit about what was not covered — where the scope boundaries sit, what assumptions were tested, and where the residual risk lives.

The binary verdict on any audit report is this: it is a necessary data point and an insufficient one. Treat it as a floor, not a ceiling. If your due diligence begins and ends with "we passed the audit," you have not performed due diligence. You have performed a ritual.