Crypto projects lost $1.18 billion to hacks and exploits in the third quarter, a 55% increase from the prior quarter, according to a new quarterly security review by a blockchain security firm. The report’s central warning is not simply that losses are rising. It is that many investors are treating audit badges as a seal of safety when the reviews behind those badges often cover only a narrow slice of a project’s attack surface.

The firm found that approximately $900 million of third-quarter losses — roughly 77% — involved compromised suppliers or developer tools, security fixes that were available but not installed, or systems that were left outside the scope of the latest security reviews. In other words, the largest losses did not necessarily come from flaws in the specific smart contracts that had been audited. They came from the surrounding infrastructure, dependencies and operational choices that attackers increasingly target.

Key facts from the third-quarter review

• Crypto projects lost $1.18 billion to hacks in the third quarter, up 55% from the previous quarter.
• About $900 million, or 77% of losses, involved compromised suppliers or developer tools, uninstalled security fixes, or components excluded from security reviews.
• The security firm warns that audit badges can give investors a false sense of security because reviews often omit wallets, signing systems and third-party software.
• Attackers are increasingly focusing on the edges of audited systems: supply chains, deployment pipelines, key management and vendor access.
• Projects and investors need to examine what an audit actually covers, not merely whether an audit exists.

The distinction matters because crypto security has become a market-signaling exercise as much as a technical one. A project can publish an audit logo, link to a PDF and present itself as reviewed. Investors often treat that signal as evidence that the code has been checked for serious flaws. But an audit is not a guarantee that a protocol is safe. It is a point-in-time assessment with a defined scope, assumptions and limitations. If the scope excludes the wallets that hold funds, the systems that authorize transactions, or the third-party tools that touch code before deployment, the review may leave the most dangerous parts of the operation untouched.

That gap is especially important in crypto because projects do not operate as isolated code. They depend on open-source libraries, cloud services, developer tooling, remote access systems, oracles, bridges and custody arrangements. Each dependency can become an entry point. Attackers do not need to defeat the audited smart contract if they can compromise a supplier, steal credentials from a developer, plant malicious code in a build pipeline, or exploit a signing system that was never part of the review. The third-quarter data suggests that this is not a theoretical concern. It is where a large share of the money went.

Why audit badges can mislead investors

Audit badges are easy to display and hard to interpret. Most investors do not read the full report. Fewer still check the scope, date, severity ratings or remediation status. A badge may refer to a review of a single contract, while the live protocol has since added new contracts, upgraded admin controls, connected new bridges or changed its treasury management. A review completed before a major upgrade may say little about the current system. A report may list critical findings that were supposedly fixed, but without evidence that the fixes were deployed and verified on the live network.

The problem is compounded by the way audits are marketed. Projects often present an audit as a milestone, similar to a compliance certificate, rather than a snapshot of one part of their security posture. That framing encourages investors to ask whether an audit exists instead of asking what it covers, who performed it, how recent it is and whether the findings were resolved. The security firm’s warning effectively challenges that shortcut. An audit badge can be real and still be misleading if it creates confidence beyond the boundaries of the work performed.

Suppliers, developer tools and delayed fixes

The finding that compromised suppliers or developer tools account for a major share of losses points to a broader shift in attack patterns. Instead of searching only for bugs in public smart contracts, attackers look for weaker links in the production chain. A compromised vendor can provide access to multiple projects at once. A malicious package or development tool can affect code before it reaches the blockchain. A stolen credential can allow an attacker to alter deployment settings or move funds through administrative functions. These risks are not always visible in a code audit, and they may not be covered by a review focused on contract logic.

Delayed fixes are another recurring problem. Security reviews often identify issues, but remediation depends on development teams, release schedules and operational discipline. A fix that exists in a report but has not been installed in production does not protect users. In some cases, projects may believe an issue is low risk because of assumptions that later change. In others, teams may prioritize new features over maintenance. Attackers only need one unpatched path. The third-quarter losses suggest that the gap between knowing about a weakness and actually removing it remains a major source of exposure.

Systems outside the latest review are equally important. Wallets, signing infrastructure, multi-signature arrangements, key management, dashboards, APIs and internal tools may be essential to how a protocol operates, yet they are often treated as separate from the smart contract audit. Attackers understand this. If the audited code is solid but the signing process is weak, the audited code may not matter. If the treasury is controlled through a system that was never reviewed, the project’s audit badge offers limited comfort.

What investors should ask

Investors can use the report as a checklist for better due diligence. First, they should identify the exact scope of an audit: which contracts, which commit, which version, which date and which components were excluded. Second, they should check whether critical findings were resolved and whether the fixes were verified on the live network. Third, they should ask whether wallets, signing systems, admin keys and third-party dependencies were included. Fourth, they should look for evidence of continuous monitoring rather than a one-time review. Finally, they should treat an audit as one input among many, not as a substitute for understanding how funds can move and who can move them.

Projects also face a clearer set of expectations. Security work should extend beyond a single pre-launch review. It should include dependency monitoring, vendor risk management, patch management, access controls, key management, incident response planning and regular reviews after major changes. Disclosure matters as well. A project that explains the limits of its audits is more credible than one that implies a badge eliminates risk. Transparency about scope and remediation can help investors distinguish between a genuine security program and a marketing exercise.

The market implications of false confidence

False confidence is not only an investor-protection issue. It can distort competition. Projects that invest in broader security programs may struggle to communicate that work through a simple badge, while projects that rely on narrow audits can present a similar-looking signal at lower cost. Over time, that can weaken incentives to address the less visible but more dangerous parts of the stack. The third-quarter loss figures suggest that the market pays a price for this gap. When an exploit occurs, users lose funds, confidence falls and the entire sector faces harder questions from regulators, institutional partners and mainstream users.

The data also complicates the common claim that an audited protocol is inherently safer than an unaudited one. An audit can be valuable, but its value depends on scope, quality and follow-through. A narrow review of a smart contract may reduce some risks while leaving operational and supply-chain risks unchanged. Investors who treat the badge as a binary signal may underestimate the residual risk. A more accurate view is that security is a continuous process with layers, and audits are one layer among several.

For the industry, the report adds pressure to standardize how audit scope and remediation are disclosed. If projects were required or encouraged to state what was not reviewed, how findings were resolved and which third-party dependencies remain exposed, investors would have a better basis for comparison. That would not eliminate hacks, but it would make it harder for a limited review to be marketed as comprehensive protection. It would also push security teams to look beyond contract logic and toward the operational systems that attackers already target.

The quarter’s loss pattern shows that the biggest losses are often not confined to the code that received the most attention. They emerge from the spaces between audited components: the suppliers, tools, upgrades, permissions and maintenance work that determine whether a protocol remains secure after launch. Until investors and projects treat those areas as part of the security perimeter, audit badges will continue to create more confidence than they can justify.

Source:Coindesk News