I’ve seen an extensive amount of discussions recently (past few weeks especially) surrounding the effectiveness of security audits and whether they are worth the investment or should be done at all. Having worked directly in this area, I’d love to share my own perspective and thoughts on why I find them valuable, but also why people should understand their inherent limitations and unavoidable compromises.

The very fresh Balancer V2 hack has brought more conversations around the effectiveness of security reviews, especially since there have been reviews of this code by notable security firms. This isn’t the first time that community has questioned the effectiveness of security reviews.

A research paper released earlier this year in NDSS examined community perceptions of security auditing, showing that there are challenges and implications around the auditing space: Exploring User Perceptions of Security Auditing in the Web3 Ecosystem, M.Z. Huang and R. Jiang and T. Sharma and K.Y. Wang, NDSS 2025.

I’m a firm believer that things should go through an audit and full security review - at minimum it guarantees that an external party has walked through the implementation. While it doesn’t guarantee anything in terms of findings and vulnerabilities, the hopes are that audits from notable, reputable security firms provide a level of meaningful evaluation.

First off, why should you get a security audit?

Security audits are a great way to get an external third party to view and validate your ideas and implementations. The reviewers often have experience working across a range of implementations and may be able to quickly assist in locating common mistakes or assumptions that don’t hold in practice.

Depending on your requirements, reviews can come in a variety of different approaches:

  • Automated tooling-based security audits that use tools like fuzzers, static analysis, and testing frameworks to go through your implementation to identify vulnerabilities.
  • Manual code reviews where experts comb through selected code to find potential assumptions in code implementations that could lead to logic flaws or exploitable paths.
  • Penetration testing on applications and infrastructure to identify weaknesses.
  • Formal proving of concepts to ensure that there is theoretical soundness.

These external validations are, in my personal opinion, critical to ensuring a level of safety when your implementation eventually goes live. I also hold quite a high regard for public reviews (both reports released publicly and code that is released to the public for community reviews) and open sourced code. I’ve gone through my fair share of public code which has helped me locate bugs and provide PRs with the fix.

I think that having a formal security review, especially of the core concepts and components, are always beneficial, but should be treated with care. One review doesn’t guarantee everything is secure forever.

What a security review won’t do.

A security review will never be the silver bullet to ensuring that your implementation is 100% secure. There are a number of considerations to make when you undertake a security review, as both a reviewer and a recipient of a review:

  1. Time-boxing: The security reviews are completed in a time-boxed engagement, meaning these reviewers will have to (1) get up to speed on your code, (2) comb through the code and examine the implementation, and (3) identify and demonstrate potential vulnerable pathways to exploit. This puts immense pressure on the analysts working on the reviews, but also means that they will find what they possibly can during this time. It may, or may not, be enough time to go through every pathway, even with the assistance of tooling and automated tooling - things can be missed.
  2. Importance of scope boundaries and definition: When engaging in a review, it’s common to define which parts will be assessed as in-scope, versus requiring the examination of the entire codebase. These considerations mean that the reviewers will aim to constrain their exploration of the implementation based on what is in scope. Some good security firms might find things around the edges, and will investigate things that lie on the edges of the scope, or if it might be significant, have a look in the components surrounding the core scope. An example might be constraining your review of the protocol to only the consensus, but a bug from the network layer makes it vulnerable.
  3. Concerning Changes: New changes to the components should mean new security reviews. A project that has been audited for a specific version/commit/implementation is only valid for that state. Any changes to those components could introduce vulnerabilities that weren’t picked up or audited. This becomes more significant if the changes touch something sensitive or critical. For example, a slight change in permission logic could cause havoc. Be aware that the security review is valid for that state at that time with the deployment specified.
  4. Future-proofing is impossible: evolving technology means evolving attack vectors and ways that your product/protocol/implementation can be used. For something like a contract, changes to the underlying virtual machine could mean changes to the way your code executes and how data structures perform. For protocols, upstream changes to libraries could change the handling of messages or executions. While an external security review can give some element of safety for the deployment, there is no guarantee that it will secure you for the foreseeable future.
  5. External influences: Beyond the scope definition within your product/protocol lies the interactions of a user. Typically this is open ended and not included directly in a security review. Your protocol could be the most secure, hardened implementation - but a compromised user account, faulty wallet software, or indirect information manipulation could still result in unwanted effects (such as drained funds). Many external influences should be taken into consideration when planning the review scopes, deployment, and user interactions.

(I wish I had the time to go on…)

All in all, I want to say that something getting a security review is a positive addition, but there are many factors to consider and understand. A security review means that someone else has explored the code and they could/couldn’t find something in the time they spent looking at it.

Security review firms

It’s no secret that there are a number of security review firms on the market, each with their specialties. I’m a strong believer in having multiple eyes on something to get different opinions and perspectives, but choosing who to go with is often a challenge itself.

It typically comes down to budget (time, cost), implementation familiarity (code language, core, contract, network, logic, etc.) and preference. I usually have a small checklist of questions that I go through when looking at protocols that have been audited, and looking at who to engage with:

  • How mature is the security firm? What do they work on?
  • What reviews are public, and to what degree? (Reports, multiple rounds, etc.)
    • Aside: I do know that some NDAs and some protocols don’t permit the release of reports in the public, but if a firm has reputation for it, there will be something to look for.
  • Have they ever missed anything? How do they hold themselves accountable? Are there explanations?
  • What is their team like?
  • Have they performed reviews on something similar and can discuss/show?
  • Do they have anything on their web presence for knowledge sharing/information?

Reading some of the materials online and looking at what community sentiment is around, it’s quite obvious that the security review firms need to have some proof of what they do. Being able to read reports, go through documentation, see what they’re sharing is always something that builds confidence.

Closing thoughts

Overall, I think it’s important to acknowledge the benefits of getting a security review. Security reviews ensure that external parties have gone through critical aspects of the code, and any findings have (hopefully) been identified and fixed. Ideally, it is great when a product/protocol/implementation has multiple reviews because it has more opinions and perspectives that aid in confidence that something is somewhat safe.

It should be taken into consideration that security reviews are often time-boxed and scoped, so they can’t find absolutely everything that could go wrong. Moreover, there are external factors that should be taken into consideration, things that aren’t tied directly to the security review (e.g. interfaces, wallets, etc.) that have major impacts.

I’ve always liked principle of ’trust but verify’.