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 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 automated lint gates 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.

Accessibility

Sigvex targets WCAG 2.2 Level AA. The table below states where the platform actually stands, criterion by criterion, for the parts of the interface those criteria reach. Values are assigned from measurements taken against the shipping build in a browser — computed styles, contrast ratios, and accessibility-tree names on every route — not from a design review. Where we have not measured something, the row says "Partially supports" and names the gap rather than claiming conformance.

This is an accessibility conformance statement, not a full VPAT. It covers the success criteria that apply to an interactive analysis workspace; criteria that do not apply to this interface (pre-recorded media, audio description, sign language) are omitted rather than marked as passing. If you need a criterion evaluated that is not listed, or you hit a barrier we have not recorded, tell us — we treat an accessibility barrier as a defect, not a feature request.

Conformance by criterion

WCAG 2.2 Level A and AA conformance for the Sigvex platform
Criterion	Level	Conformance	Notes
1.1.1 Non-text Content	A	Partially supports	Every node/edge graph — threat graph, asset lineage, dependency map, call graph, evidence graph — carries a table view of the same nodes and relationships, reachable from a Graph/Table control next to the picture. Decorative icons are hidden from assistive technology. The economic simulator's sensitivity plot is still marked decorative and has no equivalent table, so the numbers behind that one chart are unavailable to a screen reader.
1.3.1 Info and Relationships	A	Partially supports	Headings, lists, form labels and data-table row/column scoping are conveyed in markup, and each page exposes a single main region and a single top-level heading. Not every one of the platform's several hundred routes has been individually audited for structural markup.
1.3.2 Meaningful Sequence	A	Partially supports	Reading order follows source order throughout; we have not systematically verified it on the densest multi-panel workspaces.
1.3.4 Orientation	AA	Supports	No view is locked to an orientation.
1.3.5 Identify Input Purpose	AA	Partially supports	Sign-in fields carry autofill hints. Most fields in the product collect blockchain identifiers, which have no defined input purpose, so the criterion does not reach them; we have not audited the remaining account-settings fields.
1.4.1 Use of Color	A	Supports	Severity and status are never colour alone — every indicator pairs its colour with a shape and an uppercase text label. This is enforced on every route by an automated check that fails the build.
1.4.3 Contrast (Minimum)	AA	Supports	Text contrast is measured on the live build across every static route, in both the light and the dark theme, against the surface each element actually sits on.
1.4.4 Resize Text	AA	Partially supports	Type and spacing are defined in relative units and scale with the browser's text size. We have not verified every view at 200% without loss of content.
1.4.5 Images of Text	AA	Supports	All text is rendered as text. No interface copy is baked into an image.
1.4.10 Reflow	AA	Partially supports	Every route is checked for horizontal overflow down to 360 CSS pixels wide. The criterion asks for 320; the last 40 pixels are not yet verified, so this is not claimed as full support.
1.4.11 Non-text Contrast	AA	Partially supports	Focus indicators are measured against a 3:1 floor on every focusable control. Graph strokes and node fills are chosen from a validated categorical palette but have not been individually measured against their backdrop.
1.4.12 Text Spacing	AA	Partially supports	Layout uses flexible containers rather than fixed heights, so overridden spacing is expected to reflow. Not verified under the criterion's exact overrides.
1.4.13 Content on Hover or Focus	AA	Partially supports	Graph tooltips appear on focus as well as hover and dismiss on blur. They are not yet hoverable-over, so a magnifier user cannot move the pointer onto tooltip content.
2.1.1 Keyboard	A	Partially supports	Every graph node is focusable and activates with Enter or Space; the call graph adds an arrow-key cursor that announces each function as it moves; graph zoom is on the keyboard. Repositioning a node by dragging has no keyboard equivalent — it changes only the picture's layout, never the data, but it is a pointer-only action and is recorded as one.
2.1.2 No Keyboard Trap	A	Supports	Dialogs trap focus deliberately while open and release it on Escape or Close, returning focus to the control that opened them.
2.1.4 Character Key Shortcuts	A	Does not support	The analysis workspaces bind single-character shortcuts (digits to switch views, letters to switch panels). They are suppressed while a text field has focus, but they are active document-wide otherwise and cannot be turned off or remapped. Speech-input users will trigger them accidentally. A preference to disable them is the fix and is not yet built.
2.4.1 Bypass Blocks	A	Supports	Every page opens with a skip link to its main region, and navigation is in a labelled landmark.
2.4.2 Page Titled	A	Supports	Every route sets a descriptive document title.
2.4.3 Focus Order	A	Partially supports	Focus order follows the visual order and dialogs manage focus explicitly. Not audited on every route.
2.4.4 Link Purpose (In Context)	A	Partially supports	Icon-only controls carry accessible names. Some result tables still link on a truncated address, which is meaningful in its row but thin out of context.
2.4.5 Multiple Ways	AA	Supports	Persistent navigation, a command palette with search, and a sitemap page.
2.4.6 Headings and Labels	AA	Supports	Every form control has a visible label — verified automatically across every route, including the workspace pickers whose control is a button.
2.4.7 Focus Visible	AA	Supports	Every focusable control shows a focus ring, checked against a 3:1 contrast floor on the live build.
2.4.11 Focus Not Obscured (Minimum)	AA	Partially supports	Sticky headers and footers are shallow and scroll targets into view. Not measured against every sticky region.
2.5.3 Label in Name	A	Partially supports	Accessible names begin with the visible text on the controls we have audited. Not verified platform-wide.
2.5.7 Dragging Movements	AA	Supports	Dragging in the dependency map only rearranges the layout. Every action it can lead to — opening a contract, inspecting a node — is available from a single click or from the keyboard.
2.5.8 Target Size (Minimum)	AA	Partially supports	Controls come from a three-size scale with a 24-pixel floor, and touch devices get 44-pixel targets; graph nodes carry an enlarged invisible hit area for the same reason. Individual target sizes have not been measured across every view.
3.1.1 Language of Page	A	Supports	Every page declares its language.
3.2.1 On Focus / 3.2.2 On Input	A	Partially supports	No control changes context on focus. Some filter controls re-query on change, which updates the region they describe rather than navigating; not audited exhaustively.
3.3.1 Error Identification	A	Supports	Validation failures are reported next to the field that caused them, in plain language, and clear when corrected.
3.3.2 Labels or Instructions	A	Supports	Every input carries a visible label; placeholders are examples, never the label.
3.3.3 Error Suggestion	AA	Partially supports	Address and identifier errors suggest the expected format. Some server-side failures still report the condition without a suggested correction.
3.3.7 Redundant Entry	A	Partially supports	Workspace and contract selections persist across views. Multi-step flows have not been audited for repeated entry.
3.3.8 Accessible Authentication (Minimum)	AA	Supports	Sign-in uses federated identity or email. No cognitive-function test, no image puzzle, and pasting into every field is allowed.
4.1.2 Name, Role, Value	A	Partially supports	Every code editor in the product now states what it holds and whether it is editable — "EVM bytecode disassembly, read-only" rather than an unnamed text area — and every graph node states its identity and its type instead of announcing as a bare button. Both are held there by automated checks that fail the build if a new editor or node ships unnamed. Custom widgets outside those two families have not been individually audited.
4.1.3 Status Messages	AA	Partially supports	Analysis progress, graph selection, and run status are announced through live regions. Some background refreshes still update silently.

Known gaps we are working on

Single-key shortcuts: the workspace shortcut map has no off switch. This is the one criterion above marked "Does not support", and a preference to disable it is the planned fix.
Economic simulator chart: the sensitivity plot has no table equivalent yet, so it is the one visualisation in the product a screen-reader user cannot read. The other charts and gauges on the dashboards report their values as text alongside the picture, but have not been individually audited.
Coverage: the automated checks above run on every route, but they measure specific properties — contrast, names, labels, focus, overflow. They are not a substitute for an audit by a screen-reader user, which is the next step rather than a completed one.

Assistive technology and browsers

The platform is built and measured against current versions of Chromium-based browsers, Firefox, and Safari. Code editors run in their screen-reader-optimised mode automatically when one is detected. We have not completed a structured test pass with a specific screen reader and do not claim compatibility with one in particular.

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.

Security at Sigvex