Responsible Disclosure Policy

1. Introduction

Sigvex is committed to the security of our platform and our users' data. We recognise that independent security researchers play a valuable role in helping us identify and address vulnerabilities. This Responsible Disclosure Policy describes how to report security vulnerabilities in the Sigvex platform, what you can expect from us, and what we ask of you.

This policy covers vulnerabilities in the Sigvex platform itself (sigvex.io, APIs, and infrastructure). It does not cover smart contracts or blockchain protocols that users analyse through the Service. For responsible disclosure of smart contract vulnerabilities discovered using Sigvex, please refer to our Terms of Service (Section 7: Responsible Security Research).

2. Scope

The following assets are in scope for responsible disclosure:

2.1 In Scope

• The Sigvex web application at sigvex.io.
• Sigvex REST APIs (EVM API, SVM API, Query API, API Gateway).
• Authentication and session management.
• Authorization and access control between user accounts and resources.
• Data exposure or leakage vulnerabilities.
• Server-side vulnerabilities (injection, SSRF, authentication bypass, etc.).
• Cross-site scripting (XSS), cross-site request forgery (CSRF), and other client-side vulnerabilities.
• Cryptographic weaknesses in how the Service handles user data.

2.2 Out of Scope

The following are out of scope and should not be tested or reported under this policy:

• Vulnerabilities in third-party services that Sigvex integrates with (e.g., GitHub OAuth, cloud providers, RPC providers). Report these directly to the affected vendor.
• Social engineering, phishing, or physical attacks against Sigvex employees or infrastructure.
• Denial-of-service (DoS/DDoS) attacks. Do not attempt to disrupt service availability.
• Automated scanning or brute-force attacks against production systems.
• Vulnerabilities in smart contracts analysed through the Service (these are not our assets).
• Spam, rate-limiting bypasses with no security impact, or missing best-practice headers with no demonstrable exploit.
• Issues in outdated browsers or platforms that are no longer supported.
• Self-XSS or issues requiring unlikely user interaction.

3. How to Report

If you believe you have found a security vulnerability in the Sigvex platform, please report it to us through our contact form, clearly marking the subject as a security vulnerability report.

In your report, please include:

• Description: A clear description of the vulnerability, including which asset is affected.
• Steps to Reproduce: Detailed, step-by-step instructions to reproduce the issue. Include URLs, request/response data, and screenshots where applicable.
• Impact Assessment: Your assessment of the potential security impact (e.g., data exposure, authentication bypass, privilege escalation).
• Proof of Concept: A working proof-of-concept demonstrating the vulnerability. Minimise the use of automated tools in your PoC. Do not include actual user data if encountered.
• Environment: Browser, operating system, and any relevant configuration details.

Please do not report vulnerabilities through public channels (social media, public issue trackers, forums) before we have had an opportunity to investigate and remediate.

4. What to Expect

When you submit a vulnerability report, you can expect the following from us:

We will keep you informed throughout the process. If we determine that the report is out of scope or not a valid vulnerability, we will explain our reasoning.

5. Safe Harbour

We consider security research conducted in accordance with this policy to be:

• Authorised: We will not pursue legal action against researchers who discover and report vulnerabilities in good faith, in compliance with this policy.
• Exempt from Terms of Service violations: Testing performed in accordance with this policy will not be considered a violation of the Sigvex Terms of Service or Acceptable Use Policy.
• Lawful: We will not pursue claims under the Computer Fraud and Abuse Act (CFAA), the Computer Misuse Act, or equivalent laws for research conducted under this policy.

Safe harbour applies provided that you:

• Act in good faith and comply with this policy.
• Do not access, modify, or delete data belonging to other users.
• Do not degrade the availability or performance of the Service for other users.
• Stop testing and report immediately once you have sufficient evidence to demonstrate a vulnerability.
• Do not publicly disclose the vulnerability before we have had a reasonable opportunity to remediate (see Section 6).
• Do not use the vulnerability for personal gain beyond the scope of this policy.

If at any point you are uncertain whether your actions comply with this policy, please stop and contact us before proceeding.

6. Disclosure Timeline

We ask that you do not publicly disclose the vulnerability until we have confirmed that a fix has been deployed. We commit to working with you on a mutually agreed disclosure timeline. In general:

• We aim to remediate confirmed vulnerabilities within 90 days of acknowledgement.
• If remediation requires more than 90 days due to complexity, we will communicate the revised timeline and work with you to agree on a disclosure date.
• Once a fix is deployed, you are welcome to publish details of the vulnerability. We appreciate being given a heads-up before publication so we can prepare any relevant communications.

7. Recognition

We value the contributions of security researchers and are happy to provide recognition for valid vulnerability reports. With your permission, we will:

• Credit you by name (or a handle of your choice) in any public advisory related to the vulnerability.
• Acknowledge your contribution in our security acknowledgements.

We do not currently operate a paid bug bounty programme. If this changes in the future, we will update this policy accordingly.

8. What We Ask of You

• Only test against accounts you own or have explicit permission to test.
• Do not attempt to access, modify, or exfiltrate data belonging to other users.
• Do not perform actions that could harm the availability of the Service (no DoS testing, no excessive automated requests against production).
• Do not test using social engineering, phishing, or physical methods.
• Minimise the data you access during testing. If you encounter personal data of other users during your research, stop, do not save it, and report it immediately.
• Provide sufficient detail in your report for us to reproduce and validate the issue.
• Allow reasonable time for remediation before any public disclosure.

9. Contact

To report a security vulnerability, please use our contact form with "Security Vulnerability Report" in the subject line.

For general security questions (not vulnerability reports), you can also reach us through the same form.