Solana Security Auditing Skill

Solana Security Auditing

Systematic security review framework for Solana programs, supporting both Anchor and native Rust implementations.

Review Process

Follow this systematic 5-step process for comprehensive security audits:

Step 1: Initial Assessment

Understand the program's context and structure:

Framework: Anchor vs Native Rust (check for use anchor_lang::prelude::*)
Anchor version: Check Cargo.toml for compatibility and known issues
Dependencies: Oracles (Pyth, Switchboard), external programs, token programs
Program structure: Count instructions, identify account types, analyze state management
Complexity: Lines of code, instruction count, PDA patterns
Purpose: DeFi, NFT, governance, gaming, etc.

Step 2: Systematic Security Review

For each instruction, perform security checks in this order:

Account Validation - Verify signer, owner, writable, and initialization checks
Arithmetic Safety - Check all math operations use checked_* methods
PDA Security - Validate canonical bumps and seed uniqueness
CPI Security - Ensure cross-program invocations validate target programs
Oracle/External Data - Verify price staleness and oracle status checks

→ See references/security-checklists.md for detailed checklists

Step 3: Vulnerability Pattern Detection

Scan for common vulnerability patterns:

Type cosplay attacks
Account reloading issues
Improper account closing
Missing lamports checks
PDA substitution attacks
Arbitrary CPI vulnerabilities
Missing ownership validation
Integer overflow/underflow

→ See references/vulnerability-patterns.md for code examples and exploit scenarios

Step 4: Architecture and Testing Review

Evaluate overall design quality:

PDA design patterns and collision prevention
Account space allocation and rent exemption
Error handling approach and coverage
Event emission for critical state changes
Compute budget optimization
Test coverage (unit, integration, fuzz)
Upgrade strategy and authority management

Step 5: Generate Security Report

Provide findings using this structure:

Severity Levels:

🔴 Critical: Funds can be stolen/lost, protocol completely broken
🟠 High: Protocol can be disrupted, partial fund loss possible
🟡 Medium: Suboptimal behavior, edge cases, griefing attacks
🔵 Low: Code quality, gas optimization, best practices
💡 Informational: Recommendations, improvements, documentation

Finding Format:

## 🔴 [CRITICAL] Title

**Location:** `programs/vault/src/lib.rs:45-52`

**Issue:**
Brief description of the vulnerability

**Vulnerable Code:**
```rust
// Show the problematic code

Exploit Scenario: Step-by-step explanation of how this can be exploited

Recommendation:

// Show the secure alternative

References:

[Link to relevant documentation or similar exploits]


**Report Summary:**
- Total findings by severity
- Critical issues first (prioritize by risk)
- Quick wins (easy fixes with high impact)
- Recommendations for testing improvements

## Quick Reference

### Essential Checks (Every Instruction)

**Anchor:**
```rust
// ✅ Account validation with constraints
#[derive(Accounts)]
pub struct SecureInstruction<'info> {
    #[account(
        mut,
        has_one = authority,  // Relationship check
        seeds = [b"vault", user.key().as_ref()],
        bump,  // Canonical bump
    )]
    pub vault: Account<'info, Vault>,

    pub authority: Signer<'info>,  // Signer required

    pub token_program: Program<'info, Token>,  // Program validation
}

// ✅ Checked arithmetic
let total = balance.checked_add(amount)
    .ok_or(ErrorCode::Overflow)?;

Native Rust:

// ✅ Manual account validation
if !authority.is_signer {
    return Err(ProgramError::MissingRequiredSignature);
}

if vault.owner != program_id {
    return Err(ProgramError::IllegalOwner);
}

// ✅ Checked arithmetic
let total = balance.checked_add(amount)
    .ok_or(ProgramError::ArithmeticOverflow)?;

Critical Anti-Patterns

❌ Never Do:

Use saturating_* arithmetic methods (hide errors)
Use unwrap() or expect() in production code
Use init_if_needed without additional checks
Skip signer validation ("they wouldn't call this...")
Use unchecked arithmetic operations
Allow arbitrary CPI targets
Forget to reload accounts after mutations

✅ Always Do:

Use checked_* arithmetic (checked_add, checked_sub, etc.)
Use ok_or(error)? for Option unwrapping
Use explicit init with proper validation
Require Signer<'info> or is_signer checks
Use Program<'info, T> for CPI program validation
Reload accounts after external calls that mutate state
Validate account ownership, discriminators, and relationships

Framework-Specific Patterns

Anchor Security Patterns

→ See references/anchor-security.md for:

Account constraint best practices
Common Anchor-specific vulnerabilities
Secure CPI patterns with CpiContext
Event emission and monitoring
Custom error handling

Native Rust Security Patterns

→ See references/native-security.md for:

Manual account validation patterns
Secure PDA derivation and signing
Low-level CPI security
Account discriminator patterns
Rent exemption validation

Modern Practices (2025)

Use Anchor 0.30+ for latest security features
Implement Token-2022 with proper extension handling
Use InitSpace derive for automatic space calculation
Emit events for all critical state changes
Write fuzz tests with Trident framework
Document invariants in code comments
Follow progressive roadmap: Dev → Audit → Testnet → Audit → Mainnet

Security Fundamentals

→ See references/security-fundamentals.md for:

Security mindset and threat modeling
Core validation patterns (signers, owners, mutability)
Input validation best practices
State management security
Arithmetic safety
Re-entrancy considerations

Common Vulnerabilities

→ See references/vulnerability-patterns.md for:

Missing signer validation
Integer overflow/underflow
PDA substitution attacks
Account confusion
Arbitrary CPI
Type cosplay
Improper account closing
Precision loss in calculations

Each vulnerability includes:

❌ Vulnerable code example
💥 Exploit scenario
✅ Secure alternative
📚 References

Security Checklists

→ See references/security-checklists.md for:

Account validation checklist
Arithmetic safety checklist
PDA and account security checklist
CPI security checklist
Oracle and external data checklist
Token integration checklist

Known Issues and Caveats

→ See references/caveats.md for:

Solana-specific quirks and gotchas
Anchor framework limitations
Testing blind spots
Common misconceptions
Version-specific issues

Security Resources

→ See references/resources.md for:

Official security documentation
Security courses and tutorials
Vulnerability databases
Audit report examples
Security tools (Trident, fuzzers)
Security firms and auditors

Key Questions for Every Audit

Always verify these critical security properties:

Can an attacker substitute accounts?
- PDA validation, program ID checks, has_one constraints
Can arithmetic overflow or underflow?
- All math uses checked operations, division by zero protected
Are all accounts properly validated?
- Owner, signer, writable, initialized checks present
Can the program be drained?
- Authorization checks, reentrancy protection, account confusion prevention
What happens in edge cases?
- Zero amounts, max values, closed accounts, expired data
Are external dependencies safe?
- Oracle validation (staleness, status), CPI targets verified, token program checks

Audit Workflow

Before Starting

Understand the protocol purpose and mechanics
Review documentation and specifications
Set up local development environment
Run existing tests and check coverage

During Audit

Follow the 5-step review process systematically
Document findings with severity and remediation
Create proof-of-concept exploits for critical issues
Test fixes and verify they work

After Audit

Present findings clearly prioritized by severity
Provide actionable remediation steps
Re-audit after fixes are implemented
Document lessons learned for the protocol

Testing for Security

Beyond code review, validate security through testing:

Unit tests: Test each instruction's edge cases
Integration tests: Test cross-instruction interactions
Fuzz testing: Use Trident to discover unexpected behaviors
Exploit scenarios: Write POCs for found vulnerabilities
Upgrade testing: Verify migration paths are secure

Core Principle

In Solana's account model, attackers can pass arbitrary accounts to any instruction.

Security requires explicitly validating:

✅ Every account's ownership
✅ Every account's type (discriminator)
✅ Every account's relationships
✅ Every account's state
✅ Every signer requirement
✅ Every arithmetic operation
✅ Every external call

There are no implicit guarantees. Validate everything, trust nothing.

Agent Skills: Solana Security Auditing

Install this agent skill to your local

Skill Files