Responsible Disclosure Policy

Last updated: 3 June 2026

Our responsible disclosure commitment

The security of SalesSign and the data our customers entrust to us matters to us. We believe that working openly with the security research community makes our products safer. We are committed to:

• Investigating and resolving security issues reported to us in good faith.
• Working with you to understand and validate your report.
• Treating researchers who follow this policy as partners, not adversaries.
• Not pursuing legal action against good-faith research conducted within the terms of this policy — see Safe harbour below.

SalesSign is a Salesforce-native proposal and eSignature platform. Customer documents and CRM data live inside the customer’s own Salesforce org; our marketing website and our web application are hosted on separate infrastructure. SalesSign is currently undergoing Salesforce’s AppExchange Security Review.

Scope

This policy applies to the SalesSign systems we own and operate. Before testing, please confirm a target is in scope.

In scope

• The SalesSign marketing website at salessign.io.
• The SalesSign web application at app.salessign.io.
• The SalesSign Salesforce managed package as installed and configured in a test org you own or are authorised to test.
• SalesSign public APIs and endpoints documented as part of the above services.

The following classes of issue are generally of interest to us: authentication and authorisation flaws, injection, server-side request forgery, insecure direct object references, remote code execution, exposure of secrets or customer data, and significant business-logic flaws.

Out of scope

The following are out of scope. Please do not test against them, and reports about them will usually be closed without action:

• Customer Salesforce orgs, customer data, or any system you do not own or are not authorised to test. Customer documents and CRM data reside in the customer’s own Salesforce org and are governed by Salesforce’s own security and disclosure programmes.
• Third-party services, sub-processors, hosting providers, and platforms we rely on but do not control. Please report issues in those services directly to the relevant provider.
• Social engineering, phishing, or physical attacks against SalesSign staff, contractors, or facilities.
• Denial-of-service (DoS/DDoS), volumetric, brute-force, or load-testing attacks.
• Spam, or content/configuration issues with no security impact.
• Reports generated solely by automated scanners without a demonstrated, exploitable impact.
• Missing best-practice headers or cookie flags, TLS configuration nitpicks, and similar findings with no demonstrable exploit.
• Reports about software versions without a working proof of concept showing impact.
• Vulnerabilities in the underlying Salesforce Platform — report these to Salesforce via their own programme.

Rules of engagement

To keep research safe for everyone, we ask that you:

• Only test against accounts, orgs, and data that you own or are explicitly authorised to use.
• Access only the minimum amount of data needed to demonstrate an issue, and stop as soon as impact is established.
• Do not access, modify, delete, or exfiltrate data that does not belong to you, and do not degrade the experience of other users.
• Do not run automated scanning at a volume that could affect availability.
• Keep the details of any vulnerability confidential until we have confirmed it is resolved — see Coordinated disclosure.
• Comply with all applicable laws, including data-protection and computer-misuse legislation.

Safe harbour

We consider security research and vulnerability disclosure conducted in good faith and in accordance with this policy to be authorised activity. Where you act in good faith and stay within this policy:

• We will not initiate or pursue legal action against you in relation to that research.
• We will not report your activity to law-enforcement authorities for that research.
• To the extent your testing might otherwise breach our Terms of Service or Acceptable Use Policy, we waive those restrictions for the limited purpose of good-faith research conducted under this policy.

This safe harbour does not extend to activity that is unlawful, that falls outside the scope above, that accesses or damages data belonging to others, or that otherwise breaches this policy. If legal action is initiated by a third party against you for activity conducted in line with this policy, and you have complied with it, we will take reasonable steps to make it known that your actions were authorised. If you are ever unsure whether specific testing is permitted, contact us first and ask.

How to report a vulnerability

Please send your report to our security team at admin@salessign.io. We prefer reports in English.

To help us triage and reproduce the issue quickly, please include:

• A clear description of the vulnerability and its potential impact.
• The affected system, URL, endpoint, or package component, and the environment you tested against.
• Step-by-step instructions to reproduce the issue.
• Any proof-of-concept code, requests, screenshots, or logs that demonstrate the issue.
• The date and time of your testing, and the source IP address(es) you used, where possible.
• Your name or handle if you would like to be credited, and how you would like us to contact you.

Please do not include real customer data in your report. If your testing inadvertently exposed personal or customer data, tell us in the report and do not retain, copy, or share it.

Acknowledgement and response targets

These are the targets we aim to meet for reports that follow this policy. They are goals, not contractual commitments, and may vary with severity and complexity.

We will keep you informed of our progress and let you know when the issue has been resolved. SalesSign does not currently operate a paid bug-bounty programme; we are, however, happy to acknowledge researchers who report valid issues — see below.

Coordinated disclosure

Please give us a reasonable opportunity to investigate and fix an issue before disclosing it publicly. We ask that you do not publish, share, or otherwise disclose details of a vulnerability until we have confirmed it has been resolved and have agreed a disclosure timing with you. We will work with you in good faith on a coordinated disclosure timeline and are glad to credit researchers who report valid issues, with your consent.

Recognition

If you would like to be credited for a valid report, let us know in your submission and we will acknowledge your contribution once the issue is resolved, subject to your agreement on what is published.

Changes to this policy

We may update this policy from time to time. The version in force is the one published on this page, with the effective date shown above. Reports are handled under the policy in force at the time of submission.