Blockchain Penetration Testing Services: How to Evaluate a Vendor

A Practical Guide for CTOs, CISOs, and Product Leaders

When it comes to picking a blockchain pen-testing partner, it’s more than just a simple task to tick off your list. It's actually super important for reducing the risks of exploits in your smart contracts, L2s/bridges, nodes, and key management. You want to make sure you find someone who really gets it! So, let’s chat about how to find a partner who really has your back. I’m talking about someone who aligns with today’s standards, uses the right tools, and delivers real results.

What to Look For

1. Expertise in Blockchain Security.

It's important to check that they have a solid history when it comes to blockchain security, particularly with smart contracts and Layer 2 solutions.
I'm curious to hear about your experience with various blockchain protocols and ecosystems. What have you tried out?

2. What's Going On Right Now: Standards & Best Practices

Find partners who are always in the loop with the latest security frameworks and guidelines, such as those from NIST or OWASP. It’s super important to work with folks who are up-to-date! Their methods should definitely line up with industry standards to make sure they provide thorough coverage.

Advanced Tooling Make sure they’re using high-quality tools and technologies for testing, such as static analyzers or fuzzing tools, which are specially made for blockchain environments.

They should be ready to share how they make the most of these tools when they're testing things out.

Measurable Deliverables

You’re looking for straightforward and useful reports that lay out any vulnerabilities, the risks of potential exploits, and some solid recommendations for how to mitigate those issues.
It's really important for them to share some metrics that demonstrate progress as time goes on.

Building a Relationship

Open Communication: Let’s create a way to chat openly and honestly. It’s all about being transparent and making sure everyone feels comfortable sharing their thoughts. Feel free to bring up any worries or changes you have in mind. I'm here to chat about it whenever you need!
Stay in the Loop: Make it a habit to have regular check-ins and updates. This way, you’ll always know what’s happening with the testing progress and any findings that come up.
Post-Test Support: Once testing wraps up, your partner should stick around to help you make sense of the results and lend a hand with any follow-up fixes you need.

Final Thoughts

Choosing the right partner for blockchain pen-testing can definitely be a bit daunting. But don’t worry! Just remember these tips, and you'll be on your way to making a smart choice. The ideal partner isn’t just there to help lower your risk; they should also team up with you to create a safer future together.

In this post, we’re diving into what you can look forward to when teaming up with a blockchain penetration testing vendor in 2025. We’ll cover a bunch of important stuff, like the scope of the tests and the standards they'll follow--think OWASP SCSVS, EthTrust, and CVSS v4. Plus, we’ll touch on L2/bridge risk frameworks, and the cool tools they might use, like Slither, Foundry invariants, Certora, and Move Prover.

We’ll also go over what kind of artifacts you should expect to get and the service level agreements (SLAs) you’ll want to keep an eye on. And to make things super easy, I’ve put together a helpful RFP checklist complete with some real-world examples. Let's get started!

Why blockchain pen testing is different (and urgent)

So, in 2024, hackers pulled off a heist and snagged around $2. Over 303 different incidents, around 2 billion has been lost from various crypto platforms. Wow, that's a whopping 21% increase from last year! So, what's behind this surge? Well, it all comes down to compromised keys. On top of that, there were some pretty serious centralized attacks, like what happened to DMM Bitcoin and WazirX. Just keep this in mind as a starting point for figuring out the risks. (chainalysis.com).

So, what’s the takeaway for decision-makers from all this? It’s pretty simple, really: choose vendors that are willing to go above and beyond. When you're on the hunt, try to find folks who do more than just code reviews. You want people who really get into the nitty-gritty, like on-chain logic, cross-chain trust assumptions, how validators and MEV infrastructure work, and even key custody. It’s definitely a good idea for them to stick to modern standards and reliable methods when it comes to their testing.

The scope you should require (six planes of testing)

Reach out to the vendor and ask them to send you a written confirmation about which planes they'll be testing. Also, it would be great to get a list of the artifacts you'll be getting for each one.

Smart Contracts (both EVM and Non-EVM).

EVM: We're putting a lot of effort into making sure we’re well-prepared for the OWASP Smart Contract Top 10 list for 2025, along with the SCSVS controls. On top of that, we're making sure everything lines up with the EthTrust requirements when it comes to our Solidity codebases. Take a look at this: (scs.owasp.org). It’s definitely worth checking out!
Non-EVM: When it comes to Move/Aptos and Sui, we're stepping up our game! We're making it a point to ask for formal specifications and proofs whenever we can--shoutout to Move Prover for making this easier! It's not just about running those linting checks, you know?
Check out all the juicy details here: aptos.dev. You won't want to miss it!

2) Protocol/L2/Bridge

Take a look at how this compares with L2BEAT's risk dimensions. They look at things like state validation, upgradeability, data availability, and sequencing. It's pretty interesting to see how everything lines up! Don't forget to think about the trust issues that come into play with DA bridges, as well as how developed the L2 "Stages" are. "If you're looking to explore this topic further, check out the discussion on the L2BEAT forum. It's a great place to get into the nitty-gritty details!"

3) Oracles and Market Interactions

When you’re pricing tests, it’s a good idea to go for methods that can’t easily be manipulated, like TWAP or median pricing. Think about how depth and duration sensitivity come into play, along with those tricky flash-loan situations. Honestly, don’t just take their word when they say, “we checked the price feed.” You really should consider advocating for some robust adversarial simulations. Check it out here.

4) Off-chain and Admin Surfaces

We're jumping into some front-end action, exploring RPC, relayer and signing backends, governance UIs, and all those admin workflows. It’s going to be an exciting ride! Hey, just a heads up to keep an eye out for those process abuse situations, like when it comes to upgrade guardianship and pause mechanics. They're important to consider!

Node, Validator, and MEV Infrastructure

So, let's talk about the Node, Validator, and MEV infrastructure. This stuff is essential for keeping everything running smoothly in the blockchain world. Nodes are basically the backbone of the network; they store and share all the data, making sure everything is up-to-date and secure. Validators, on the other hand, are the ones who confirm transactions and add them to the blockchain, kind of like a digital notary public. They play a crucial role in maintaining the integrity of the network.

And then we have MEV, which stands for Maximum Extractable Value. This is all about how certain players can extract extra value from transactions, often by taking advantage of their position in the network. It’s a pretty complex topic, but it’s super important for understanding how incentives work within blockchain ecosystems.

In short, Nodes, Validators, and MEV all work together to ensure everything runs properly, making the whole system efficient and trustworthy. It’s fascinating how these elements interact in the ever-evolving world of blockchain technology!

We're diving into the MEV-Boost and checking out how well the relays are holding up. We want to make sure our backup options are functioning just like they should. Plus, we're taking a close look at the multi-relay setups and keeping an eye on whether the relays are following the monitoring guidelines properly. (docs.flashbots.net).

6) Keys, Custody, and HSM/KMS Controls

It's really crucial to check how you access your keys and make sure you're keeping everything secure to avoid any potential misuse. If you're working with a cloud KMS or HSM, make sure to reach out to your vendor and ask them to confirm that their setup hits the FIPS 140‑3 Level 3 baseline when it’s applicable. Don’t forget to ask for some proof--like the kind of documentation you'd see with AWS KMS L3. It's always good to have that assurance! If you want to dive deeper into this topic, you can check it out here.

The standards and benchmarks that separate real pen tests from box‑checking

OWASP Smart Contract SCSVS and SCSTG: Just a heads up, double-check that all your findings align with the SCSVS controls and test cases. It’s super important to keep everything in sync! If you want to dig a little deeper and get more insights, definitely check out SCSTG. Hey, just a quick heads up: OWASP doesn’t actually certify vendors. So if you come across anyone promising “OWASP certificates,” it’s best to give them a pass. ” (owasp.org).
OWASP Smart Contract Top 10 (2025): While you're diving into testing, make sure you hit on the major issues--things like access control, reentrancy, unchecked external calls, price oracle manipulation, and those sneaky flash-loan vectors. Don't let them slip by! (scs.owasp.org).
EEA EthTrust Security Levels (v2): If you're diving into any Solidity or EVM projects, make sure to request coverage that matches up with the EthTrust v2 controls. It’s a smart move! So, this new spec has basically replaced the old SWC registry and it's still being updated! We're actually looking forward to version 3, which is set to drop in 2025.
(entethalliance.org).
SWC Registry: It’s definitely a useful tool for sorting through things, but just a heads-up--it’s not being actively maintained anymore. So, it’s best to use it in combination with EthTrust or SCSVS, rather than relying on it as your sole source. (github.com).
**CVSS v4. Make sure to use severity scoring that sticks to the CVSS v4 labels (like CVSS-B/BT/BE/BTE) and takes environmental factors into account. Simply checking the base severity isn’t going to cut it when it comes to really understanding the risk. (first.org).
L2/Bridge frameworks: When it comes to rollups and data availability layers, definitely check out L2BEAT for their risk assessments. Just remember, there’s a difference between the risks tied to data availability layers and those related to data bridges, so keep that in mind! (forum.l2beat.com).
Source verification: Once you've done the remediation, make sure to get a thorough exact-match check using Sourcify or Etherscan. Make sure to include all the reproducible metadata and the compiler settings for every deployment. (docs.sourcify.dev).

What a high‑caliber vendor’s methodology looks like (and the artifacts you should get)

Threat Modeling Outputs You’ll come across some diagrams along with a few written notes that touch on topics like upgrade control, cross-chain trust roots, DA/bridge attestations, oracle freshness thresholds, MEV/relay dependencies, and key ceremonies.

2) Static, Symbolic, Fuzz, and Invariant Testing Evidence

Take a look at static analysis tools like Slither. They’ve got some really useful reports that break down detector lists and show you how to tackle false positives. If you're curious to learn more about it, check it out here. You’ll find some really interesting info!

When it comes to property and invariant specs, you've got some solid options. You can use annotated properties with tools like Scribble, which is pretty handy. Plus, there’s also fuzzing to consider, along with those invariant test setups, runs, and counterexamples you can gather from Foundry and Diligence Fuzzing. It’s a pretty well-rounded toolkit to work with! If you’re looking for more details, check this out here.

If it feels right, think about using formal specs with tools like Certora, particularly for those important invariants that really matter. This covers the CVL rule set along with the checks for coverage and the constraints we need to prove. If you want to explore more about this, check it out here. You'll find all the details you need!

If you’re looking into non-EVM formal proofs, I’d definitely recommend checking out Move Prover when it makes sense to use it. It’s particularly great for making sure your resource safety and access control rules are on point. If you're looking for more info, you can check it out here. There's a lot to dive into!

3) L2/Bridge Risk Analysis

Let’s dive into how your rollup or bridge compares with the risk factors laid out by L2BEAT. We’ll also touch on some of the assumptions that come into play with data availability bridges. This will touch on everything from escape hatches to upgrade guardianship. Hey, take a look at the details over here: (forum.l2beat.com). You might find it interesting!

4) Oracle Manipulation Simulations

We're going to explore TWAP and median windows, taking a closer look at how liquidity sensitivity affects things. Plus, we're going to play around with some adversarial simulations using flash loans. It should be interesting! So, when it comes to the acceptance criteria, we’re really focused on looking at those manipulation costs in relation to the funds we’ve got on the line. We’re also taking cues from the Uniswap V2 and V3 oracles; they’re kind of our guide through this whole thing. If you want to dive deeper into it, just check it out here.

5) Validator/MEV Checks

Hey, just a quick reminder! Make sure you have some solid proof of relay diversity. It’s also super important to have those liveness circuit-breaker tests set up. Oh, and don’t forget to whip up a backup plan for local block-building in case any of the relays decide to take a day off. Better safe than sorry, right? If you're looking for more info, just check this out here. It's got all the details you might need!

Keys/KMS/HSM posture We're really diving into our setup to make sure it meets FIPS 140‑3 L3 standards wherever it's relevant. This means you'll want to check a few things: first, make sure mTLS is working properly. Then, double-check that admin duties are separated the right way. Lastly, don't forget to confirm that the cloud KMS module has been validated. If you’re looking for more details, just check this out here. There’s a lot of good info waiting for you!

7) Reproducible Builds and Verification

To make sure everything's in order, we rely on build manifests that lay out stuff like the compiler versions and optimizer settings we’re using. We also check out the differences in bytecode and have some pretty reliable verification receipts from platforms like Sourcify and Etherscan. If you want to dive deeper into it, check it out here. Happy reading!

8) Traceable Standards Mapping

Put together a coverage matrix that connects every finding to the SCSVS controls and the EthTrust requirements. Make sure to point out anything that isn’t included in the scope. (owasp.org).

1) Upgradeable Proxy Hardening (UUPS vs. Transparent Proxy)

So, if you're diving into upgradeable proxies and want to keep things secure, there are a few key tests you should definitely run:

Make sure to:
Avoid using UUPS setups with Transparent proxies. Doing so might lead to some unexpected upgrade risks. Make sure to set up the _authorizeUpgrade function so it only allows approved UUPS destinations. Anything else should be blocked.
Make sure to double-check that all the initializer guards are set and that atomic initialization is sorted out before we go live.

Why does this matter?

If you mix UUPS with Transparent proxies, you might run into some trouble with unauthorized upgrades if everything isn't configured correctly. It's definitely one of those things where a little oversight can lead to big issues down the line! It's really important for vendors to prove that they've not only run static checks but also tested how their systems hold up against possible sneaky upgrade attempts from adversaries. If you want to dive deeper into the details, take a look at the documentation over on OpenZeppelin. It's got all the info you need!

2) Oracle Manipulation in Lending/AMM Integrations

Alright, so here's the plan: we gotta get those Foundry fuzz and invariant suites set up. It's important because...

Go ahead and experiment with a 30-60 minute TWAP while staying aware of the different liquidity situations.
Keep an eye out for any liquidation price shifts that exceed a specific tolerance level.

So, why does this matter? Well, even though TWAPs are built to be tough against manipulation, they still rely on a few key factors. It's really important for a vendor to weigh the attack costs against the potential risks, especially when considering the sizes of your pools. (docs.uniswap.org).

3) Hardening Hyperledger Fabric Chaincode and CA

Chaincode: Keep an eye out for any chaincode weaknesses, like poor randomness or areas of the state that aren't being used. These can really be a problem! You can totally use a CWC-style taxonomy to help you with your checks. It'll make the process a lot smoother! Make sure to check out a few edge cases for endorsement and validation. You never know what might pop up! If you’re looking for more details, check this out here.
Fabric CA/Operations: Just a friendly reminder to ensure you're using mutual TLS for the operations API and the CA endpoints. It's super important for security! Make sure to demonstrate that your ops endpoints are locked down tight, denying access to anyone who isn't logged in. If you want to dive deeper into the details, feel free to check out the documentation right here. It’s packed with useful info!
For Peers and Orderers: Make sure that TLS is turned on, client authentication is properly configured for the ops endpoints, and check that your persistent ledger and MSP storage are safe and sound. When you're working with CouchDB, it's super important to keep it isolated and manage who gets access to it. If you want to dive deeper into this topic, check it out here. It's got a ton of info that could be really helpful!

MEV-Boost Relay Dependency Tests.

Let’s run a “malicious relay” test to see if we can catch any block withholding issues. It’s also important to ensure that our liveness fallback kicks in smoothly and we switch back to local block production when needed. Could you please double-check that we have multiple relays set up and that they’re being monitored? Thanks! If you want to dive deeper into the details, just check this out here.

Formal Verification Beyond EVM (Move). When you're working with key Move modules like custody and lending core, don't forget to request the Move Prover specs. These should cover stuff like resource conservation, role-gated functions, and keeping those invariants intact. Oh, and make sure to grab those proof artifacts while you’re at it! Take a look at this link: (aptos.dev). It’s got some cool info waiting for you!

Toolchain: what you should expect the vendor to actually run

Static/Semantic Analysis: If you’re diving into this, definitely take a look at Slither. It's got some handy detector lists, plus you can whip up custom detectors for your project whenever it feels right! If you're curious to dive deeper into this topic, check it out here. You'll find some really interesting insights!
Property/Invariant Testing: Dive into Foundry's fuzz testing and pair it with some solid invariant tests. Just make sure to tweak the run and depth settings to suit your needs, and don’t forget to save those counterexamples! They can really help you nail down any issues. Hey, make sure to take a look at Diligence Fuzzing too, especially when it comes to properties that have been set up with Scribble. You’ll find it really interesting! If you're looking for more info, you can check it out here.
Symbolic Execution: If you ever find yourself dealing with those pesky edge cases, definitely consider trying out Manticore. It can really help tackle those tricky paths! You can check it out here.
Formal Verification: If you've got some important code on your hands, definitely check out Certora Prover with CVL rules. You won’t want to miss it! Just make sure you've got your coverage reports and proof obligations laid out nice and clear, alright? It’ll help avoid any confusion down the line! If you're looking for more details, you can check it out here.
Keeping an Eye on Your Runtime: Once you've deployed, don’t forget to take advantage of Forta and Defender’s monitoring templates. They’re super handy for managing governance, upgrades, and even pausing events. Plus, they'll alert you if anything out of the ordinary pops up. It’s a great way to stay on top of things, even if you’re considering switching tools down the line. If you want to dive deeper into this topic, check it out here. It's a great resource!

Deliverables and SLAs that avoid “audit theater”

Just a quick reminder to double-check that the SOW covers the following points:

Evidence‑based report: You’ll receive a straightforward executive summary that breaks down the risk-ranked issues, using the latest CVSS v4 terms. Plus, we'll include an analysis of how exploitable these issues are and share some thoughts on how they could affect your business. Oh, and don’t forget about the technical appendix! It’s packed with all sorts of useful stuff. You’ll find proof of concepts (PoCs), easy-to-follow instructions for recreating the issues, and all the test data you could want--like fuzz seeds and invariant configurations. It’s all there to help you out! (first.org).
Fix‑validation re‑test: You're guaranteed at least one free re-test within 30 days. Plus, you'll get a detailed report that shows the fixes we made and checks to ensure nothing has slipped through the cracks.
Verification and release gating: We'll hook you up with build and verification scripts, along with those exact-match verification receipts from Sourcify and Etherscan. This way, you can be sure everything aligns just right!
On‑chain monitoring runbook: We've got some handy monitor triggers already in place for stuff like ownership transfers, upgrades, pauses, and any weirdness with oracle deviations. You’ll get alerts sent right to PagerDuty or Slack, so you can jump on them fast! (docs.openzeppelin.com).
Incident response expectations: If you run into any problems, don't worry! We're here to help. We’ll keep you in the loop with clear contact windows, assist you in setting up secure channels, and provide advisory support for about 24 to 72 hours while we tackle those critical hotfixes.

Budgeting for continuous assurance (not just pre‑launch audits)

So, here’s the deal: you should definitely mix audits with bug bounties. Just remember, it’s best not to have them happening simultaneously. This helps keep things organized and prevents us from handing out duplicate payments. When you’re setting your critical bounty limits, aim for something between 5% and 10% of the funds you’ve got at risk. Plus, it's a good idea to have about 2-3 times the maximum critical payout ready for the program’s liquidity. That way, you’re in a solid position to handle things when they come up! (immunefisupport.zendesk.com). Just keeping it real here: Immunefi has actually helped shell out more than $100 million! When it comes to bug bounties, the return on investment is pretty impressive, especially when programs are well-funded and given the attention they deserve. (globenewswire.com).

Red flags when vetting a vendor

“Certification” claims: Just a quick note--OWASP SCSVS doesn’t actually certify vendors or smart contracts. So if you come across anything saying “OWASP-certified,” it’s probably a good idea to steer clear. Take a look for yourself here. You’ll find some pretty useful info!
SWC-only coverage: The SWC can be handy, but honestly, it doesn't get the best upkeep. So, when you're diving into it, definitely ask for the EthTrust v2/SCSVS mapping instead. Trust me, it’ll make your life a whole lot easier! If you’re looking for more details, check it out here. You’ll find a ton of useful info!
PDF-only deliverables: Just a heads-up! If you’re only receiving PDFs, you won’t be able to find things like fuzz seeds, invariant configs, or the build metadata that you need to reproduce the results.
Lack of L2/bridge analysis: Honestly, it's just not cool that we don't have a solid L2BEAT-style risk assessment for rollups and bridges. It’s super important to have that kind of insight! Check it out here.
Severity without context: Let’s face it, CVSS base scores are just numbers on their own, right? They really need some context to make sense! So, whenever you can, go ahead and use CVSS-BT/BE/BTE to get a better understanding of the situation. It makes a world of difference! If you want to dive deeper into it, check it out here. It's got all the details you might need!

Vendor evaluation rubric (scorecard you can copy)

Rate each dimension on a scale from 0 to 3. Once you've got your scores, set a pass threshold--maybe shoot for hitting at least 22 out of 30.

1) Scope Coverage

We dive into all six planes, using straightforward artifacts like threat models, tool outputs, and those DA/bridge reviews to keep everything clear and understandable.

2) Standards Mapping

So, we’ve put together a control-coverage matrix for the SCSVS/SCSTG and EthTrust v2. It points out any gaps and anything that might not be included. Give it a look right here: scs.owasp.org. Enjoy!

3) Tooling Depth

We make use of Slither detectors, and when it feels right, we also tap into Foundry for fuzzing and invariants, plus we bring in some symbolic execution when it’s necessary. When it comes to our most important projects, we like to use formal proofs and the Move Prover wherever it fits. Hey, if you want to dive deeper into Slither, you should definitely take a look at this Trail of Bits blog post. It’s got some great insights!

L2/bridge and oracle reliability. Take a deep dive into some L2BEAT-style risk analysis! You’ll want to check out those cool simulations of adversarial oracles that really break down what manipulation costs look like. It’s a fascinating way to understand the risks involved! If you want to dive deeper into this topic, you can check out more details here. Happy exploring!

5) Infra/MEV/keys

So, we did a few tests on the MEV-Boost relay. We checked to see how well it held up in terms of fallback and liveness, and we also took a look at the FIPS-aligned KMS/HSM when necessary. If you want to explore the nitty-gritty details, just click here. Enjoy the read!

Reporting and Re-test Just a heads up--make sure you've got your reproducible Proofs of Concept (PoCs) ready to go, along with those seeds and the exact-match verification receipts from Sourcify or Etherscan. It's super important to keep everything organized! Hey, just a quick reminder to make sure you add a re-test and the release gating! If you need more details, check out this link here. It's got everything you need!

7) Post‑Deploy Monitoring

Make sure you're checking in on those operational runbooks and monitoring templates. They're super important for handling stuff like governance, upgrades, and any quirks you might notice with your oracle. Hey, take a look at this: OpenZeppelin Docs. It's got some really cool information!

8) Bug Bounty Integration

Make sure you define a clear budget and scope for your project--aim for something like 5-10% of the total funds you have at risk as a solid upper limit. Also, be careful to avoid scheduling any of this during audit periods! If you're looking for more info, just head over here. You'll find all the details you need!

Sample RFP language (paste into your procurement doc)

Test Plan: Don’t forget to include smart contracts, the trust models for L2 and bridges, oracles, validators/MEV, and keys/KMS. It's really important to cover all these bases! Make sure to line up your findings with the OWASP SCSVS and EEA EthTrust v2 controls. Oh, and don’t skip the CVSS v4 scores--just use the BT/BE/BTE labels while you're at it! Check it out here.
Fuzz Testing: Make sure to include all the stuff about fuzz and invariant configurations for Foundry. Don't forget to add in all those failing seeds and counterexamples, too! Could you share your static analysis results, like the list from the Slither detector? And if you've had a chance to use Certora, it would be great to see any CVL specs and coverage details you have as well! If you’re diving into some Aptos or Sui code, don’t forget to include the Move Prover specifications and the proof results! More info here.
Risk Assessment: When it comes to rollups and bridges, let's create a thorough risk assessment similar to what L2BEAT does. We need to dive into state validation, data availability, upgrade keys, and sequencing. Oh, and make sure you include a DA bridge trust analysis too! If you're curious to dive deeper into it, you can check it out here. It's definitely worth a read!
Oracle Simulations: Try running some adversarial oracle simulations, similar to the Uniswap TWAP, to better understand the costs of manipulation in relation to the funds you have at stake. Make sure to suggest some good strategies for addressing the issues. Dive deeper here.
Validator/MEV Setup: Make sure your validator/MEV setup is solid by using a multi-relay configuration. It’s a smart way to ensure everything runs smoothly! Hey, just a quick reminder to keep an eye on the relay monitor and make sure you check that everything's sticking to the plan. Also, don't forget to run those liveness circuit-breaker tests and the fallback tests, too. Thanks! If you want to dive deeper into the details, just click here. It’ll take you to a page packed with more info!
Contract Verification: Make sure to double-check the exact-match contract verification using Sourcify or Etherscan. It’s important to have that compiler metadata ready to replicate, just to keep everything consistent. Oh, and don’t forget to add the verification receipts to your release criteria, okay? Check instructions here.
KMS/HSM Configuration: Make sure to share some proof of your KMS/HSM setup that meets the FIPS 140-3 Level 3 standards, if it’s relevant. Sure! Here’s a quick list of the validated modules and regions for you: If you want to dive deeper into this topic, you can check out this link here. There's some great info waiting for you!
After Remediation: Once you’ve done the cleanup, make sure to schedule a re-test within the next 30 days. Don't forget to send over the diff report, along with the updated monitors for governance, upgrades, and those oracle deviation alerts. Thanks! More details here.

Emerging best practices to ask for in 2025

EthTrust v2 on SWC-only: Imagine EthTrust as your trusty checklist for Solidity projects, with SWC there as a reliable backup when you need it. (entethalliance.org).
CVSS v4 for Priority Setting: Whenever you can, try to request CVSS-BTE. This way, the severity level takes into account real-world threat intelligence and your unique environment, instead of just being based on the technical details alone. (first.org).
Testing for DA/bridge-aware rollups: If you’re tapping into some external data availability, it’s really important to take a good look at the risks involved between the DA layer and the DA bridge. Make sure to score those risks clearly! (forum.l2beat.com).
Where formal methods really matter: If you're dealing with essential EVM logic, definitely check out CVL or Certora. And when you're working with Move, don't forget to use Move Prover to keep things safe and sound resource-wise! (docs.certora.com).
Double-check everything, for real: Before you hit that launch button, make sure you’ve got spot-on verification (like from Sourcify or Etherscan). If you can’t find a verified source, just hold off on deploying for now. Trust me, it's not worth the risk! (docs.sourcify.dev).

Bottom line

When it comes to pen testing vendors, there’s a pretty wide range in how detailed their services can be. When you reach out, don't forget to ask for a detailed approach that really hits all the right notes. Look for something that’s mapped to standards, packed with tools, and backed by solid evidence. It’s important that it covers smart contracts, Layer 2 solutions and bridges, infrastructure, MEV concerns, and key management. Those are the essentials you definitely want to include! It's super important for them to give us reproducible artifacts, verification receipts that match up perfectly, and to keep an eye on things after deployment. Take those guidelines and the RFP language we talked about earlier, and let's turn that "audit theater" into something real that genuinely helps lower your risk of being taken advantage of.

Absolutely! We can create a super handy one-page checklist for you to share with any vendor before that first call. It'll make things a lot smoother!