Full Report
WhiteHatMage was in the top 3 on both Immunefi and HackenProof for web3 bug bounties last year. This post explains how they identify projects and the realities of finding vulnerabilities in live projects with impact. What makes vulnerabilities more likely? First, bugs hide within complexity. Most serious issues they find are simple mistakes, but in layered/complicated systems. Many fixes are just one-line changes. Next, innovation creates space for new bugs. When projects adopt a new approach, they are unlikely to consider attack paths correctly. Implementation-level innovation matters too. With new implementation experiments come subtle bugs. As ecosystems mature, there are fewer bugs. New chains, uncommon languages, etc. tend to have more basic issues simply because fewer people have looked at them. Optimizations are at the root of a lot of evil. Heavy assembly usage, manual memory management, rewritten math expressions... Optimizations often obscure edge cases that developers did not anticipate. Next, code quality tells a story. When developers rush a feature or lack attention to detail, bugs are more common. Poor code is hard to secure. Non-functional issues, such as sloppy comments, are even noteworthy. Ignoring best practices, missing of basic security patterns like CEI are all warning signs. Projects with poor code quality are high-risk for vulnerabilities. Audit reports are a useful context. Multiple critical findings are a serious red flag. Fixing every issue introduces the risk of introducing another issue or applying an improper patch. Depending on the quality of the codebase and the auditing company, they look for different types of issues. Good codebase with good audits. Novel or very complex bugs. Good codebase with average audits. Complex paths and known security pitfalls. Average codebase with good audits. Review audit fixes and leftover weak design. Average codebase with average audits. Missed but not extremely complex exploit paths. Being first is super important. Right after a big launch, there's a large chance of vulnerabilities. So, the author will often speedrun basic security checks on a project if they hear about a launch. In the first few weeks, more complex attack paths may be discovered that auditors didn't identify. When a project first gets the bug bounty program, the competition is intense. So, they tend to check early and then come back for a deeper pass later. The approach for finding critical bugs is very similar to my process. They focus only on critical paths; they ask themselves which invariants must hold for this to be secure. Over time, this builds intuition. After a while, they come back to a codebase. This is beneficial because they may have new techniques or the system may have changed. It's important to note that time is limited, so every decision matters. They add a list of bug bounty archetypes: The Digger. Goes super deep into a single program. The Differ. Compares one mechanism across many different projects. The Speedrunner. Reviews new programs quickly. The Watchman. Monitors deployments and upgrades. The Lead Hunter. Develops ideas around lesser-known attack vectors. The Scavenger. Inspired by obscure writeups or little-known incidents. The Scientist. Builds major tooling for analysis. When choosing a bounty program, they also consider the project's reputation itself. If they are well-known for lowballing or not paying, it's not worth your time. Do they have the money to pay you in the first place? Are the rewards and scope clear? Do they take security seriously via audits, or is it just a checkbox? Once they find a single bug then report it and see how the process goes. Only after this do they look for more. For them, red flags are vague rules, low caps, prior disputes, or a lack of response. A fantastic article from a fantastic security researcher. Thanks for taking the time to write up!
Analysis Summary
# Best Practices: Web3 Security & Vulnerability Management
## Overview
These practices address the identification, mitigation, and systematic hunting of vulnerabilities in decentralized ecosystems. They focus on recognizing risk "hotspots" created by complexity, innovation, and optimization, while providing a framework for both developers to secure projects and researchers to audit them effectively.
## Key Recommendations
### Immediate Actions
1. **Enforce Basic Patterns:** Audit all smart contracts specifically for the Checks-Effects-Interactions (CEI) pattern to prevent reentrancy.
2. **Audit Fix Verification:** Perform a "delta-audit" on any code changes made to fix previous audit findings; fixing one bug often introduces another.
3. **Speedrun Basic Checks:** Immediately following a launch or upgrade, execute automated and manual sanity checks on core invariants before "competition" increases.
### Short-term Improvements (1-3 months)
1. **Define Invariants:** Document the "security invariants" (logical truths that must never be broken) for every critical path. Use these to guide testing and bug hunting.
2. **Refine Bug Bounty Scope:** Ensure bounty programs have clear rewards, unambiguous scope, and a demonstrated path to payment to attract high-quality researchers.
3. **Monitor Deployments:** Implement "Watchman" protocols—real-time monitoring of on-chain upgrades and dependency changes.
### Long-term Strategy (3+ months)
1. **Reduce Complexity Overhang:** Systematically refactor "over-optimized" code (heavy assembly, manual memory management) unless the performance gains are mission-critical and heavily peer-reviewed.
2. **Cultivate Security Intuition:** Rotate developers through "attacker mindset" sessions to review peer code for complex logic paths that audits may have missed.
3. **Maturity Assessment:** Regularly evaluate the project against ecosystem maturity; as a project ages, shift focus from basic implementation bugs to novel, cross-chain, or indirect attack vectors.
## Implementation Guidance
### For Small Organizations
- **Focus on Fundamentals:** Prioritize code quality and legibility. Avoid "clever" gas optimizations in favor of readable, standard-compliant code.
- **Leverage Audits Early:** Use reputable firms even for small scopes to avoid basic architectural flaws.
### For Medium Organizations
- **Structured Bug Bounties:** Launch programs on established platforms (e.g., Immunefi, HackenProof) to manage researcher relations and dispute mediation.
- **Post-Audit Hygiene:** Treat every audit report as a sign of team health; multiple critical findings should trigger a pause in development to address underlying technical debt.
### For Large Enterprises
- **Specialized Hunting Roles:** Adopt the "Archetype" approach—assign teams to "Digger" roles (deep logic dives) and "Lead Hunters" (identifying new vector trends like RWA or ZK-tech).
- **Security Tooling:** Invest in the "Scientist" approach by building custom internal analysis tools and automated monitors for all deployments.
## Configuration Examples
While specific code is not provided, the following configuration "anchors" are recommended:
- **Invariant Monitoring:** Configure bots to alert if `totalBalance < totalLiability` or if administrative roles are altered without a timelock.
- **Bounty Rules:** Explicitly define "Out of Scope" (e.g., third-party library bugs) to prevent bureaucratic delays during disclosure.
## Compliance Alignment
- **NIST Cybersecurity Framework (CSF):** Aligns with *Identify* (Risk Assessment) and *Protect* (Information Protection and Procedures).
- **ISO/IEC 27001:** Addresses aspects of System Acquisition, Development, and Maintenance.
- **Web3 Standards:** Follows the "Security by Design" principles prevalent in leading DeFi protocols.
## Common Pitfalls to Avoid
- **The Optimization Trap:** Rewriting math expressions or using assembly for minor gas savings often introduces edge cases that developers miss.
- **The "Audit Checkbox" Mentality:** Assuming a system is safe because it was audited. Audits are points-in-time and can be subverted by subsequent "fix" patches.
- **Bureaucratic Lowballing:** Negotiating down a bounty after a critical bug is found. This destroys project reputation and discourages future whitehat involvement.
- **Complexity Blindness:** Thinking a bug is "too simple" to exist; most critical vulnerabilities are simple mistakes hidden under layers of complex logic.
## Resources
- **Platforms:** [hXXps://immunefi.com], [hXXps://hackenproof.com], [hXXps://cantina.xyz]
- **Methodologies:**
- *The Digger:* Deep-dive analysis.
- *The Differ:* Comparative mechanism analysis.
- *The Speedrunner:* Post-launch rapid review.