Full Report
The Web3 space is innovative yet financially risky at the same time, due to attackers' ability to directly steal money. This innovative aspect has led to many hard-won lessons in security that need to be relearned in Web3. This post is about one of them: overall code quality. Code quality is code security. NASA famously implemented their Power of Ten rules for clear guidelines in coding. NASA specifically implemented this because projects with extreme consequences for failure require rigorous code quality standards. CURL contains very serious coding guidelines as well. When code is well-structured and adheres to clear patterns, security vulnerabilities become easier to identify and harder to introduce. Codebases characterized by inconsistency, complexity, and poor organization create fertile ground for security flaws. Now comes the reason for the name: chase boredom instead of beauty. Most secure code is boring and simple - the JC of our company has talked about this extensively as well. Security thrives in predictability and not novelty. Besides the code, this includes docs, standards, linting, and review processes. Why should we take code quality so seriously? Problems cost more to fix later. Whether it's re-architecting something, a major hack, or something else, it just costs much more later. Additionally, when developers trust their foundation and execute without fear, they can build systems that will last forever. Good read!
Analysis Summary
# Best Practices: Code Quality as Code Security (Boredom Over Beauty)
## Overview
These practices address the fundamental link between code legibility and system security. In high-stakes environments like Web3, security is not just about patching vulnerabilities ("culling rotten fruit") but about engineering "boring," predictable, and highly standardized codebases that minimize cognitive load and eliminate entire classes of errors before they are ever compiled.
## Key Recommendations
### Immediate Actions
1. **Adopt a "Zero Technical Debt" Policy:** Resolve quality issues (linting errors, inconsistent naming, dead code) immediately. Do not defer them to a future sprint.
2. **Enforce Strict Linting:** Implement automated linters and formatters (e.g., Prettier, Clippy, GoFmt) to eliminate "Galápagan diversity" in code style.
3. **Prioritize Boring Logic:** Reject "clever" or novel code patterns in favor of established, predictable patterns that any reviewer can understand at a glance.
### Short-term Improvements (1-3 months)
1. **Standardize Patterns and Measurement:** Create internal style guides inspired by the "Power of Ten" or "Tiger Style" rules to ensure consistency across all modules.
2. **Code-Comment Alignment Check:** Implement a review requirement where comments must match the implementation. Use LLM tools to specifically flag "deltas" where comments and code disagree.
3. **Modernize the Foundation:** Re-architect components that require complex mental models to operate, simplifying them until they are "legible."
### Long-term Strategy (3+ months)
1. **Shift from Reactive to Proactive:** Transition the security budget from purely external audits/bug bounties toward internal engineering quality and "soil health" (improving the development environment/tooling).
2. **Build for Automation:** Ensure the codebase is structured to be easily parsed by static analysis and "state machine" automated tools, enabling security at software scale.
3. **Cultivate a "Fearless" Development Culture:** Build a foundation so robust that developers can execute changes without fear of systemic collapse.
## Implementation Guidance
### For Small Organizations
- Focus on **automation over manual enforcement**. Use pre-commit hooks to ensure no "ugly" or inconsistent code ever enters the repository.
- Prioritize **documentation of intent**. Explain *why* a function exists, not just what it does.
### For Medium Organizations
- Implement **peer review checklists** that focus on "legibility" and complexity scores rather than just logic.
- Standardize on a single set of libraries and patterns to reduce the surface area that engineers need to learn.
### For Large Enterprises
- Adopt formal coding standards like **NASA’s Power of Ten**.
- Create a dedicated **Developer Experience (DevEx) or Tooling team** focused on making the "secure and boring way" the easiest path for developers to take.
## Configuration Examples
While specific code depends on the language, the "Power of Ten" philosophy suggests:
- **Avoid recursion:** Use fixed-size loops to prevent stack overflow.
- **Limit function length:** Functions should fit on a single screen (approx. 60 lines).
- **Assertion Density:** Use at least two assertions per function to catch anomalies early.
## Compliance Alignment
- **NIST SSDF (Secure Software Development Framework):** Aligns with "Produce Well-Secured Software" by reducing technical debt.
- **ISO/IEC 27001:** Supports operational security through documented and standardized processes.
- **CIS Benchmarks:** Aligns with software integrity and secure configuration requirements.
## Common Pitfalls to Avoid
- **Novelty Seeking:** Using a new, unproven language feature or library just because it is "elegant" or "innovative."
- **Silencing the "Pedantic":** Ignoring linting warnings or documentation gaps as "non-security" issues; these gaps hide real vulnerabilities.
- **The "Hero" Developer:** Relying on one person who understands a complex, undocumented system—this is a single point of failure and a security risk.
## Resources
- **NASA’s Power of Ten Rules:** `https[:]//spinroot[.]com/gerard/pdf/P10.pdf`
- **TigerBeetle Style Guide (Tiger Style):** `https[:]//github[.]com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md`
- **Curl Coding Standards:** `https[:]//daniel[.]haxx[.]se/blog/2025/04/07/writing-c-for-curl/`