Frequently Asked Questions

Believe Security works by analyzing your Solana program's source code (or bytecode) to identify potential security issues. The analysis process involves several steps:

1. 1
   Code Ingestion: Your program code is securely uploaded to our service from GitHub, as a file upload, or by providing a Program ID.
2. 2
   Static Analysis: Our system performs traditional static analysis to identify common code patterns, control flow issues, and potential vulnerabilities.
3. 3
   AI-Powered Analysis: Our specialized models, trained on Solana-specific security patterns, analyze your code for more complex vulnerability types.
4. 4
   Result Compilation: The findings are compiled, prioritized by severity, and presented in an easy-to-understand report.

All analysis is performed in a secure, isolated environment, and your code is never shared with third parties or used to train our models.

Believe Security is specifically designed for Solana programs, with several key advantages:

• Solana-Specific: Designed from the ground up to understand Solana's account model, Cross-Program Invocation (CPI) patterns, and common Solana security issues.
• AI-Enhanced Analysis: Leverages advanced language models to understand code semantics and identify complex vulnerability patterns that static analyzers might miss.
• Developer-Friendly: Provides clear explanations of issues, code examples showing how to fix them, and actionable recommendations.
• Continuous Learning: Our system is continuously updated with the latest Solana security best practices and vulnerability patterns.

Believe Security is a powerful tool that can identify many common security issues, but it's not a complete replacement for a professional security analysis conducted by human experts.

We recommend using Believe Security as:

• An early-stage security check during development
• A continuous security monitoring tool for your codebase
• A preparation step before a professional security analysis (to identify and fix obvious issues)
• An educational tool to learn about Solana security best practices

For critical applications handling significant value, we still recommend combining Believe Security with a professional security analysis from a reputable security firm specializing in Solana.

Believe Security can detect a wide range of Solana-specific and general program vulnerabilities, including:

• Missing signer verification
• Improper account validation
• Unchecked program ID in Cross-Program Invocations (CPIs)
• Integer overflow/underflow vulnerabilities
• Missing owner checks
• Improper rent exemption handling
• Data validation issues
• Re-initialization vulnerabilities
• Authorization bypass vulnerabilities
• Logic errors and control flow issues
• And many more...

For a comprehensive list of all vulnerability types, see our Vulnerability Types documentation.

Believe Security currently supports Solana programs written in:

• Rust - Full support for native Rust programs using the Solana SDK
• Anchor - Comprehensive support for programs built with the Anchor framework

We plan to add support for additional Solana development frameworks in the future.

Believe Security strives for high accuracy in its findings, but like any security tool, it's not perfect. Our current metrics show:

• True Positive Rate: ~95% for critical and high severity issues
• False Positive Rate: ~8% overall, with continuous improvements

We constantly work to improve accuracy by:

• Training our models on new vulnerability patterns
• Refining detection algorithms based on user feedback
• Incorporating real-world security analysis findings into our detection systems

To minimize false positives, each finding includes detailed context and explanation, allowing you to quickly determine if a reported issue is relevant to your specific implementation.

Yes, Believe Security can analyze private repositories in several ways:

• GitHub Integration with Token: You can provide a GitHub access token with read permissions to allow Believe Security to access your private repository.
• File Upload: You can download your code and upload it directly as a ZIP file.

All access to private code is handled securely, and your code is never shared with third parties or used for training purposes without explicit consent.

Analysis time depends on the size and complexity of your program:

• Small programs (up to 1,000 lines): Usually 30-60 seconds
• Medium programs (1,000-5,000 lines): Typically 1-3 minutes
• Large programs (5,000+ lines): May take 3-10 minutes

For very large or complex codebases, we offer options to focus the analysis on specific parts of your code to improve performance.

No, by default we do not use your code to train our AI models. Your code is processed solely to provide you with analysis results.

In some cases, with explicit opt-in consent, we may use anonymized patterns from your code to improve our detection algorithms. This is always:

• Completely optional
• Requires explicit consent
• Limited to technical patterns, never personal or identifying information
• Fully anonymized

You can adjust your data usage preferences in your account settings at any time.

For maximum effectiveness, we recommend using Believe Security at multiple stages of your development process:

• During Development: Run quick analyses on specific modules as you build them to catch issues early.
• Pre-Code Review: Before submitting code for review, run Believe Security to catch obvious security issues.
• Before Testnet Deployment: Run a full analysis before deploying to testnet to identify and fix security issues.
• Pre-Security Analysis Preparation: Before a professional security analysis, run Believe Security to fix common issues and get more value from human auditors.
• Before Mainnet Deployment: As a final check before going live.
• After Major Updates: When making significant changes to your code.

Many teams also integrate Believe Security into their CI/CD pipelines for continuous security monitoring.

We recommend addressing issues in this order:

1. 1
   Critical Vulnerabilities: These pose immediate and severe security risks and should be fixed immediately.
2. 2
   High Severity Issues: Address these before deploying to production, as they represent significant security risks.
3. 3
   Medium Severity Issues: Fix these in your next development cycle.
4. 4
   Low Severity Issues: Address these when convenient, as they represent minor concerns.
5. 5
   Best Practice Recommendations: Implement these to improve code quality and maintainability.

Within each severity level, consider:

• Issues in core functionality or frequently used code paths
• Issues affecting critical operations (e.g., fund transfers, access control)
• Issues that could be exploited without special access or conditions

The Believe Security report includes detailed explanations and remediation steps to help you fix each issue efficiently.

If you believe a finding is a false positive:

1. 1
   Review the Details: Carefully read the full description and context to understand why the issue was flagged.
2. 2
   Check the Code Context: Examine the surrounding code to ensure there isn't a related vulnerability.
3. 3
   Mark as False Positive: In the Believe Security interface, you can mark findings as false positives with an optional explanation.
4. 4
   Submit Feedback: We appreciate detailed feedback on false positives, as it helps us improve our detection algorithms.

Your feedback on false positives directly contributes to improving Believe Security for everyone. We review all reported false positives and use them to refine our detection systems.