Security at Sigvex

Our Commitment

As a smart contract security analysis platform, we hold ourselves to the same rigorous security standards we help our users achieve. Sigvex is built from the ground up with security as a core requirement, not an afterthought. This page describes the practices, controls, and architecture we employ to protect the platform and your data.

Application Security

Secure Development

• Memory-Safe Language: The Sigvex analysis engine and all backend services are written in Rust, a memory-safe systems language that eliminates entire classes of vulnerabilities including buffer overflows, use-after-free, and data races at compile time.
• Dependency Management: All dependencies are reviewed and regularly audited for known vulnerabilities using automated scanning. Dependency updates are tracked and applied promptly.
• Static Analysis: All code changes are subjected to static analysis (Clippy with warnings-as-errors) and formatting checks before merging. We maintain a zero-warnings policy across the codebase.
• Code Review: All changes require peer review before being merged to production branches.

Input Validation and Sandboxing

• Bytecode Analysis Isolation: Smart contract bytecode analysis runs in isolated contexts. Each analysis request is processed independently, with no shared mutable state between analyses.
• Input Validation: All user inputs (contract addresses, network identifiers, API parameters) are validated and sanitised before processing. Contract addresses are verified against expected formats for each supported blockchain network.
• Rate Limiting: All API endpoints and web application routes are protected by rate limiting to prevent abuse and ensure fair access.
• CSRF Protection: All state-changing operations are protected against cross-site request forgery.

Browser-Based Fuzzing

• WASM Sandboxing: Browser-based fuzzing tools run as WebAssembly (WASM) modules within the browser's security sandbox. Fuzz inputs and outputs do not leave the user's browser unless explicitly submitted.
• No Server-Side Execution: User-provided fuzzing configurations are not executed on our servers. Coverage-guided fuzzing runs locally in the browser or through dedicated, isolated infrastructure.

Infrastructure Security

Hosting and Network

• Cloud Infrastructure: The Service runs on enterprise cloud infrastructure with SOC 2 and ISO 27001 certified providers.
• Network Segmentation: Backend services are deployed in private networks with no direct public internet access. Only the API gateway and web server are publicly reachable, through a reverse proxy and load balancer.
• DDoS Mitigation: Production infrastructure is protected by DDoS mitigation services at the network edge.
• Firewall Rules: Strict ingress and egress firewall rules limit traffic to the minimum necessary for each service.

Access Controls

• Principle of Least Privilege: Internal systems follow the principle of least privilege. Team members have access only to the resources required for their role.
• Multi-Factor Authentication: All internal access to infrastructure, source code repositories, and administrative tools requires multi-factor authentication (MFA).
• Secrets Management: API keys, credentials, and secrets are stored in dedicated key vault services. Secrets are never committed to source control, stored in environment variables on disk, or logged.
• Audit Logging: Access to production infrastructure and administrative actions are logged and monitored.

Data Protection

Encryption

• In Transit: All data transmitted between your device and the Service is encrypted using TLS 1.2 or higher. We enforce HTTPS on all endpoints and use HSTS headers to prevent protocol downgrade attacks.
• At Rest: Data stored on our servers is encrypted at rest using AES-256 or equivalent encryption provided by the underlying cloud infrastructure.
• API Keys: User API keys are hashed before storage. Original key values cannot be retrieved after initial generation.

Data Handling

• Analysis Data: Contract bytecode submitted for analysis is publicly available on-chain data. Analysis results are stored in per-contract isolated storage paths with access controls tied to the requesting user's account.
• Credential Masking: Internal error handling automatically masks API keys and credentials in error messages and logs to prevent accidental exposure.
• Data Retention: Data retention follows the schedules described in our Privacy Policy. Analysis results can be deleted by the user at any time.
• Data Portability: Users can export their analysis data in standard formats via the API.

Monitoring and Incident Response

Monitoring

• Continuous Monitoring: Production systems are monitored for availability, performance anomalies, and security events.
• Alerting: Automated alerts notify the engineering team of unusual activity patterns, elevated error rates, or potential security incidents.
• Log Aggregation: Application and infrastructure logs are centrally aggregated and retained for security analysis and forensic investigation.

Incident Response

• Documented Procedures: We maintain an incident response plan covering identification, containment, eradication, recovery, and post-incident review.
• Notification: In the event of a security incident that affects user data, we will notify affected users and relevant authorities within the timeframes required by applicable data protection laws (72 hours under GDPR for notifiable breaches).
• Post-Incident Review: All security incidents are followed by a root cause analysis and remediation plan to prevent recurrence.

Third-Party Security

• Sub-Processor Evaluation: Third-party service providers that process data on our behalf are evaluated for their security posture before engagement and are bound by data processing agreements.
• Blockchain RPC Providers: On-chain data retrieval is performed through reputable, established RPC providers. Only public blockchain data (contract bytecode, deployment transactions) is requested; no private keys or wallet credentials are transmitted.
• Authentication Providers: OAuth-based authentication uses industry-standard protocols (OAuth 2.0, OpenID Connect). We do not store third-party passwords.

Responsible Disclosure

We welcome security researchers to help us identify and fix vulnerabilities in the Sigvex platform. If you have discovered a security vulnerability, please review our Responsible Disclosure Policy for reporting guidelines, scope, and safe harbour provisions.

Contact

If you have questions about our security practices or need to report a security concern, please contact us:

Contact Form

For security vulnerability reports, please use our Responsible Disclosure process.