Inside CD Security's Audit Methodology: How We Secure 100+ Protocols

Inside CD Security's Audit Methodology: How We Secure 100+ Protocols

Most security firms treat their audit process like a trade secret. We think that's backwards. Here's exactly how we work—because you deserve to know what you're paying for.

In the first month of 2026 alone, Web3 lost over $27 million to exploits. The Truebit hack. Phishing campaigns draining MetaMask users. Supply chain attacks hitting major exchanges.

Here's what's frustrating: many of these protocols had been audited.

An audit isn't a magic shield. It's only as good as the methodology behind it. Yet most security firms won't tell you how they actually work. You get a report, a badge for your website, and hope for the best.

We think you deserve better. So here's our entire process—every phase, every tool, every decision point.

Phase 1: Scoping & Architecture Review

Timeline: Days 1-2

Before we read a single line of code, we need to understand what we're protecting.

Every engagement starts with a kickoff call where we ask:

• What does this protocol actually do? (In plain English, not marketing speak)
• What's the intended user flow?
• Where does value move, and who controls it?
• What's already been audited? What changed since?
• What keeps you up at night?

That last question matters. Founders often have intuitions about where their code feels fragile. Sometimes they're right. Sometimes the real risk is somewhere they've never considered.

We then map the architecture:

• Contract relationships and inheritance patterns
• External dependencies and oracle integrations
• Admin functions and access controls
• Upgrade mechanisms and proxy patterns

This isn't busywork. Architecture review catches entire categories of bugs before we dive into implementation details. A protocol with a flawed design can't be saved by perfect code.

Phase 2: Manual Code Review

Timeline: Days 3-10 (varies by codebase size)

This is where audits are won or lost.

Automated tools catch maybe 20% of real vulnerabilities. The critical bugs—the ones that drain protocols—require human reasoning. They live in the gap between what the code does and what it should do.

Our manual review process:

• Line-by-line reading. Every function. Every modifier. Every external call. We read code the way an attacker would: looking for assumptions that might not hold.
• Invariant identification. What must always be true for this protocol to be safe? Total supply should equal sum of balances. Users can only withdraw what they deposited. Admin functions can only be called by admins. We write these down, then try to break them.
• Attack surface mapping. Which functions are externally callable? What happens if they're called in unexpected order? With unexpected inputs? By unexpected actors?
• Cross-function analysis. Many vulnerabilities span multiple functions. A state change in function A enables an exploit in function B. We trace these paths.
• Business logic review. The most dangerous bugs aren't technical—they're logical. The code works exactly as written, but what's written doesn't match the intended behavior. These require understanding the protocol deeply.

Our team brings:

• Combined 15+ years of smart contract security experience
• Backgrounds in traditional security research
• Experience across Solidity, Rust, Move, Cadence, TypeScript
• Real-world attack experience from contests and bug bounties

We don't just run checklists. We think like attackers.

Phase 3: Attack Simulation

Timeline: Days 8-12

Finding a potential vulnerability isn't enough. We need to prove it's exploitable.

For every medium, high, and critical finding, we:

• Write a proof of concept. Actual code that demonstrates the exploit, where needed.
• Calculate the impact. How much could be stolen? What's the blast radius?
• Assess exploitability. Does this require special conditions? How likely is it to be discovered by attackers?

For protocols handling significant value, we also run:

• Flash loan attack simulations. Can an attacker manipulate prices or drain pools using borrowed capital?
• Sandwich attack analysis. Is the protocol vulnerable to MEV extraction?
• Governance attacks. Can someone acquire enough voting power to pass malicious proposals?
• Oracle manipulation testing. What happens if price feeds are stale, wrong, or manipulated?

This phase often reveals new vulnerabilities. The process of building one exploit exposes adjacent attack paths.

Deliverable: Working PoCs for all significant findings.

Phase 4: Report & Severity Classification

Timeline: Days 12-14

Our reports aren't walls of text. They're actionable documents designed to help you fix issues fast.

For each finding, we include:

• Title: Clear, descriptive name
• Severity: Critical / High / Medium / Low / Informational
• Description: What's wrong and why it matters
• Impact: What an attacker could do
• Proof of Concept: Code demonstrating the issue
• Recommendation: How to fix it, with code examples
• References: Links to similar vulnerabilities or relevant documentation

We also include an executive summary for stakeholders who won't read the technical details, and a findings overview table for quick reference.

Phase 5: Remediation Support

Timeline: Ongoing until launch

The audit doesn't end when we deliver the report.

What's included:

• Unlimited questions. Confused about a finding? Not sure how to implement a fix? We're available.
• Fix review. Send us your patches, we'll verify they address the issue without introducing new ones.
• Re-audit of changed code. Your final commit gets a fresh review—included in the original engagement.

We've seen protocols "fix" a vulnerability and accidentally create a worse one. Fix review catches this.

Our commitment: We don't disappear after delivering the report. Your security is our reputation.

What Makes CD Security Different

Multi-language expertise. We audit Solidity, Rust, Move, Cadence and TypeScript. Most firms only know EVM. When 40% of new protocols are building on Solana, Aptos, Sui, or Cosmos, that matters.

Polygon ecosystem depth. As a trusted security partner of Polygon Labs, we've audited many protocols across Polygon PoS, zkEVM, and CDK chains. We understand the ecosystem's specific patterns and risks.

Senior-only team. No junior auditors learning on your codebase. Every reviewer has years of production audit experience.

Communication. We explain findings in plain English. We're available during remediation. We treat this as a partnership, not a transaction.

Track record. 100+ audits completed. Zero post-audit exploits on protocols that implemented our recommendations.

Ready to Secure Your Protocol?

We have limited slots each month to ensure every engagement gets the attention it deserves.

What to expect:

• Initial call (free) — We discuss your protocol, timeline, and scope
• Proposal — Detailed scope, timeline, and pricing within 24 hours
• Engagement — Typically 1-2-3 weeks depending on codebase size
• Ongoing support — We're here until you launch (and after)

Questions about our methodology? DM us @CDSecurity_ or email info@cdsecurity.io