solana-security

Audit Solana programs (Anchor or native Rust) for security vulnerabilities. Use when reviewing smart contract security, finding exploits, analyzing attack ve...

Security Scan

The skill is an instruction-only Solana program security audit framework (checklists, patterns, report templates) and its requirements and instructions are consistent with that purpose — it does not request credentials, binaries, or install code.

Purpose & Capability

Name and description match the provided materials: SKILL.md plus multiple reference docs describing Anchor/native Rust security patterns, checklists, and reporting formats. No unrelated dependencies, binaries, or credentials are requested.

Instruction Scope

Runtime instructions describe reading and analyzing Solana program source (Cargo.toml, instruction handlers, account checks, PDAs, CPIs, oracles, etc.) and producing structured findings — all within the stated audit purpose. The instructions do not direct reading of unrelated system paths, environment secrets, or sending data to external endpoints.

Install Mechanism

No install spec and no code files to execute (content is documentation/markdown). This is lower-risk because nothing is written to disk or fetched at install time.

Credentials

The skill declares no required environment variables, credentials, or config paths. The audit guidance expects access to the audited codebase only, which is appropriate for its purpose.

Persistence & Privilege

Skill is not always-enabled and does not request special platform privileges. It does not modify other skills or system-wide settings according to the provided metadata.

Scan Findings in Context

[no-findings] expected: The regex-based scanner reported no findings. That is expected for an instruction-only skill composed of markdown/reference docs (there's no executable code for static regex rules to match).

Assessment

This skill appears to be a coherent audit template and reference pack for Solana programs. It does not ask for credentials or install code, but be cautious when using it: (1) only provide the agent with source code and manifests (Cargo.toml, program files) relevant to the audit — never paste private keys, seed phrases, wallet JSONs, CI secrets, or deployment credentials; (2) the skill's source/homepage is unspecified — if provenance or integrity matters, prefer tools with a known maintainer or review the reference documents yourself first; (3) because it's instruction-only, the agent will rely on whatever code you give it — scrub secrets before sharing and consider running audits locally/offline if code is sensitive; (4) if you want the agent to run automated tests or fuzzers, use vetted, locally running tools rather than sending keys or credentials to the skill. Overall the package is internally consistent, but verify provenance and avoid sharing secrets.

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:

1. Account Validation - Verify signer, owner, writable, and initialization checks
2. Arithmetic Safety - Check all math operations use checked_* methods
3. PDA Security - Validate canonical bumps and seed uniqueness
4. CPI Security - Ensure cross-program invocations validate target programs
5. 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:

1. Can an attacker substitute accounts?

   • PDA validation, program ID checks, has_one constraints

2. Can arithmetic overflow or underflow?

   • All math uses checked operations, division by zero protected

3. Are all accounts properly validated?

   • Owner, signer, writable, initialized checks present

4. Can the program be drained?

   • Authorization checks, reentrancy protection, account confusion prevention

5. What happens in edge cases?

   • Zero amounts, max values, closed accounts, expired data

6. Are external dependencies safe?

   • Oracle validation (staleness, status), CPI targets verified, token program checks

Audit Workflow

Before Starting

1. Understand the protocol purpose and mechanics
2. Review documentation and specifications
3. Set up local development environment
4. Run existing tests and check coverage

During Audit

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

After Audit

1. Present findings clearly prioritized by severity
2. Provide actionable remediation steps
3. Re-audit after fixes are implemented
4. 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.