feat: external security reviews & patrick addition (#160)

* feat: external security reviews & patrick addition

* fix: lint

* fix: moved smart contract audits to their own section

Author: PatrickAlphaC

src/SUMMARY.md

@@ -49,10 +49,11 @@
   - [Private Key & Seed Phrase Management](./wallet-security/private-key-management.md)
   - [Tools & Resources](./wallet-security/tools-&-resources.md)
 - [External Security Reviews](./external-security-reviews/README.md)
-  - [Expectation](./external-security-reviews/expectation.md)
-  - [Preparation](./external-security-reviews/preparation.md)
+  - [Smart Contract Audits](./external-security-reviews/smart-contracts/README.md)
+    - [Expectations](./external-security-reviews/smart-contracts/expectation.md)
+    - [Preparation Guide](./external-security-reviews/smart-contracts/preparation.md)
+    - [Vendor Selection](./external-security-reviews/smart-contracts/vendor-selection.md)
   - [Security Policies and Procedures](./external-security-reviews/security-policies-procedures.md)
-  - [Vendor Selection](./external-security-reviews/vendor-selection.md)
 - [Vulnerability Disclosure](./vulnerability-disclosure/README.md)
   - [Security Contact](./vulnerability-disclosure/security-contact.md)
   - [Bug Bounties](./vulnerability-disclosure/bug-bounties.md)

src/external-security-reviews/README.md

@@ -3,20 +3,42 @@ tags:
   - Security Specialist
   - Operations & Strategy
   - Devops
+contributors:
+  - role: wrote
+    users: [patrickalphac]
 ---
 
 # External Security Reviews
 
+An external security review is a time-boxed, security-based assessment of software systems, applications, and infrastructure to enhance security and identify vulnerabilities. External security reviews are essential for organizations to protect against threats and build trust with users and stakeholders.
 
-External security reviews are quite common in web3 when it comes to smart contract audits which are often being done to check if the smart contracts are secure.
+## Why Are External Security Reviews Important?
 
-It's important to note though that smart contracts are not the only components that should be considered during security reviews. Any relevant off-chain software (Bridges, Oracles, Sequencers, etc.) should also be reviewed in conjunction with any on-chain application.
+According to research, significant value and data have been compromised due to security vulnerabilities in software systems. Modern applications face complex threats from malicious actors, and security issues can lead to data breaches, financial losses, and reputation damage.
 
-While external security reviews are good, they are certainly not foolproof and cannot guarantee absolute security, and for that reason this type of security testing is not a one-time event but an ongoing commitment to the safety and security of your web3 project.
+Beyond preventing security incidents, external security reviews provide several key benefits:
+
+- **Enhanced Security**: Find and fix vulnerabilities before they can be exploited
+- **Team Education**: Level up your engineering team's knowledge through security best practices
+- **Trust Building**: Demonstrate maturity and safety to users and stakeholders
+- **Risk Mitigation**: Identify business logic issues and implementation flaws
+- **Compliance**: Meet regulatory and industry security requirements
+
+## Scope of External Security Reviews
+
+Security reviews can encompass multiple layers of an organization's technology stack:
+
+- **Applications**: Web applications, mobile apps, APIs, and microservices
+- **Infrastructure**: Cloud configurations, network security, access controls, and deployment pipelines
+- **Data Systems**: Databases, data processing pipelines, and storage security
+- **Third-party Integrations**: External APIs, libraries, and vendor services
+- **Documentation**: Technical specifications, security policies, and incident response procedures
+
+External security reviews are not foolproof and cannot guarantee absolute security. They represent an ongoing commitment to safety rather than a one-time event.
 
 ## Contents
 
-1. [Expectation](./expectation.md)
-2. [Preparation](./preparation.md)
-3. [Vendor Selection](./vendor-selection.md)
-4. [Security Policies and Procedures](./security-policies-and-procedures.md)
+There are many different kinds of external security reviews, and we have some context on many of them here.
+
+1. [Smart Contract Audits](./smart-contracts/README.md)
+5. [Security Policies and Procedures](./security-policies-and-procedures.md)

src/external-security-reviews/expectation.md

@@ -4,6 +4,9 @@ tags:
   - Legal & Compliance
   - Operations & Strategy
   - HR
+contributors:
+  - role: wrote
+    users: [patrickalphac]
 ---
 
 # Security Policies and Procedures

src/external-security-reviews/preparation.md

@@ -0,0 +1,62 @@
+---
+tags:
+  - Security Specialist
+  - Operations & Strategy
+  - Devops
+contributors:
+  - role: wrote
+    users: [patrickalphac]
+---
+
+# Smart Contract Security Reviews
+
+Smart contract security reviews are specialized assessments focused on identifying vulnerabilities in blockchain-based smart contracts and protocols. These reviews are critical for web3 projects due to the immutable nature of blockchain deployments and the high-value targets that smart contracts often represent.
+
+## Why Smart Contract Security Reviews Are Critical
+
+Smart contracts operate in a unique environment that makes security paramount:
+
+- **Immutability**: Once deployed, smart contracts cannot be easily changed
+- **Financial Risk**: Smart contracts often handle significant value in cryptocurrencies
+- **Public Accessibility**: All code and transactions are visible on the blockchain
+- **Adversarial Environment**: Attackers are incentivized by potential financial gains
+- **Complex Interactions**: DeFi protocols involve intricate interactions between multiple contracts
+
+According to industry data, billions of dollars have been lost due to smart contract vulnerabilities, making security reviews essential for protecting user funds and maintaining protocol integrity.
+
+## Smart Contract Security Review Process
+
+A security review engagement is typically divided into four phases:
+
+- **Scoping Phase**: The project team prepares the codebase and defines specific scope for security researchers
+- **Initial Assessment Phase**: Researchers conduct preliminary analysis to identify potential security issues
+- **Mitigation Phase**: The team works on fixing identified issues with ongoing auditor support
+- **Final Report Phase**: Auditors review implemented fixes and provide a comprehensive final report
+
+### Audit Methodologies
+- **Static Analysis**: Automated code scanning for known vulnerability patterns
+- **Dynamic Analysis**: Runtime testing and fuzzing
+- **Manual Review**: Expert analysis of business logic and complex vulnerabilities
+- **Formal Verification**: Mathematical proofs of contract correctness (where applicable)
+
+## Types of Smart Contract Audits
+
+### Private Audits
+- Dedicated security researchers assigned to your project
+- Confidential and personalized attention
+- Higher cost but comprehensive coverage
+- Direct communication with audit team
+
+### Public/Competitive Audits
+- Multiple researchers competing for prizes
+- Diverse perspectives and approaches
+- More cost-effective option
+- Broader coverage through competition
+
+## Contents
+
+This section contains detailed guidance on different aspects of smart contract security reviews:
+
+1. [Audit Expectations](./expectation.md) - What to expect during the audit process
+2. [Preparation Guide](./preparation.md) - How to prepare for a successful audit
+3. [Vendor Selection](./vendor-selection.md) - Choosing the right security auditor

src/external-security-reviews/security-policies-procedures.md

@@ -0,0 +1,60 @@
+---
+tags:
+  - Security Specialist
+  - Operations & Strategy
+contributors:
+  - role: wrote
+    users: [patrickalphac]
+---
+
+# Expectations
+
+
+## Scoping Phase
+The team looking for a security review will agree with the auditors/security researchers the exact parameters of the review. What *exact* contracts should they review? What should they not review? This is incredibly important so the can clearly estimate timelines on how long a review may take. This is also where compensation is discussed, usually the more aspects a team wants to review, the more expensive the audit will be.
+
+## Initial Assessment Phase
+- **Automated Testing**: Auditors will run various automated security tools including static analysis, fuzz testing, formal verification, and unit testing to identify basic vulnerabilities
+- **Manual Code Review**: Security researchers will manually analyze the code to understand context, complexity, and identify deeper vulnerabilities that automated tools might miss
+- **Documentation Review**: Auditors will review project specifications and documentation to understand intended functionality
+
+## Deliverables
+
+A comprehensive security review will generate the following:
+
+### Initial Report
+- **Vulnerability Identification**: Security vulnerabilities classified by severity (High, Medium, Low)
+- **Proof of Concept**: Demonstration of potential exploit scenarios where applicable
+- **Gas Optimizations**: Recommendations for improving contract efficiency
+- **Informational Findings**: Code quality improvements and best practice recommendations
+- **Mitigation Strategies**: Specific recommendations for addressing each identified issue
+
+### Mitigation Phase
+- **Fix Review Period**: Time allocated for your team to address identified vulnerabilities
+- **Collaborative Support**: Ongoing communication with auditors during the fix implementation
+- **Code Re-review**: Assessment of implemented fixes to ensure issues are properly resolved
+
+### Final Report
+- **Updated Assessment**: Review of all implemented fixes and their effectiveness
+- **Residual Risk Analysis**: Documentation of any remaining risks or limitations
+- **Public Publication**: In web3, audit reports are commonly published publicly to build community trust
+
+## Timeline and Cost Expectations
+
+The following are *incredibly rough estimates* for timelines/costs based on Solidity smart contract audits from around the industry. Actual timelines and costs will vary significantly based on the complexity of the codebase, the number of contracts, and the specific requirements of the project.
+
+### Duration
+- **Small Projects** (< 1000 lines): 1-2 weeks
+- **Medium Projects** (1000-4000 lines): 2-5 weeks  
+- **Large Projects** (> 4000 lines): 5+ weeks
+
+### Cost Range
+- **Per Week**: $1,000 - $60,000 depending on complexity and auditor expertise
+- **Factors Affecting Cost**: Codebase size, complexity, timeline requirements, auditor reputation
+
+## Important Limitations
+
+- **No Guarantee**: Audits do not guarantee bug-free code or complete security. However, the engagement with the team should still provide value (teaching better security practices, improving code quality, etc.)
+- **Snapshot in Time**: Audits assess code at a specific commit hash - any changes create unaudited code
+- **Ongoing Process**: Security should be viewed as a continuous journey, not a one-time event
+- **Emergency Preparedness**: Even audited protocols should have incident response plans and emergency communication channels

src/external-security-reviews/smart-contracts/README.md

@@ -0,0 +1,57 @@
+---
+tags:
+  - Security Specialist
+  - Operations & Strategy
+  - Devops
+contributors:
+  - role: wrote
+    users: [patrickalphac]
+---
+
+# Preparation
+
+A common misconception is that when doing a security review, you can just hand off the written code and let reviewers do their work. This approach is inefficient and costly, as auditors will spend time on issues you could have resolved beforehand. Proper preparation maximizes the value of your security review investment and helps auditors focus on complex vulnerabilities rather than basic issues.
+
+## How to Get the Most Out of Your Security Review
+
+## Set a Goal for the Review
+This is the most important step of a security review and often the most overlooked. By setting a scope that is not too large or undefined, you are more likely to have a successful audit. If the project is very large, you may want to focus on the most critical aspects of the project.
+
+## Internal Due Diligence
+Conduct internal testing before engaging an external security provider. You can do this by creating and running test vectors for your code, and leverage automated tools to identify low-hanging fruit. Here’s a list of free/open-source tools your project could use:
+
+- **Solidity**: slither, mythril, semgrep-smart-contracts
+- **Golang**: golangci-lint, go-critic, gosec
+- **Rust**: cargo audit, cargo outdated, clippy, cargo geiger, cargo tarpaulin
+
+## Write Clear Documentation
+Providing comprehensive documentation is essential for auditors to understand your protocol's intended functionality. Since 80% of all bugs are due to business logic issues, auditors need to understand what your protocol should do, not just what the code does.
+
+Documentation should include:
+
+- **Project Overview**: Describe your protocol in plain English—what it does and its components.
+- **Flow Diagrams**: Outline all possible interaction paths within your system.
+- **Design Choices**: Document design decisions and any known potential issues.
+- **Known Restrictions / Limitations**: Document centralization risks and known limitations (e.g., limited TVL, token support).
+- **Dependencies**: List all external dependencies.
+- **Access Control / Privileged Roles**: Record all roles and their privileges.
+
+## Provide a Robust Test Suite
+Maintaining a comprehensive test suite that covers significant portions of your codebase allows auditors to focus on finding vulnerabilities rather than understanding basic functionality. Before an audit, ensure you have:
+
+- **Unit Tests**: Test individual functions and components
+- **Integration Tests**: Test interactions between different parts of your system
+- **Fuzz Testing**: Automated testing with random inputs to find edge cases
+- **High Code Coverage**: Aim for substantial coverage of your critical code paths
+- **Formal Verification**: If applicable, use formal methods to prove correctness of critical components
+
+## Conduct an Initial Code Walkthrough
+The first step in a security audit should be a high-level video walkthrough where you:
+
+- Explain your codebase architecture and key components
+- Describe how the code is intended to function
+- Highlight critical areas that need special attention
+- Provide context for design decisions and trade-offs
+- Guide auditors on where to find answers to common questions
+
+This walkthrough helps auditors understand your system quickly and focus their time on security analysis rather than code comprehension.