Responsible disclosure policy, version rdp-1

. The policy

Sovrasign Responsible Disclosure Policy. Version rdp-1, effective 10 November 2026.

In short: if you find a security problem in Sovrasign, tell us at security@sovrasign.com. If you follow this policy in good faith, we will not take legal action against you, we will keep you informed while we fix the problem, and we will thank you publicly if you wish. We do not pay rewards yet.

1. What this policy covers

1.1 In scope. The services and software of Sovrasign LLC:

• our websites and services at sovrasign.com and its subdomains: the web app, the signing page, the verifier, the API, sign-in, the help center and the marketing site;
• our desktop and mobile apps, once released, in their latest released version;
• our open-source verifier and the envelope format description, in the repository at https://github.com/sovrasign/verify.

1.2 Signed documents count. A document that our verifier accepts although a signature, a signer's identity or the document's history was forged or changed is a serious problem, even when it can only be exploited offline, without our servers. The verifier is part of what we promise.

1.3 Out of scope. Please do not report, or do not test:

• services of other companies that we use (for example Microsoft Azure, Google, Microsoft and Apple sign-in, Stripe, our email providers). Report problems in them to those companies; tell us too if you think the way we use them is unsafe;
• denial of service, load tests, or anything that degrades the service for others;
• social engineering, phishing or physical attacks against our staff, our customers or our providers;
• findings from automated scanners without a demonstrated security impact, such as missing headers, software versions shown in responses, or best-practice settings;
• problems that need a compromised device or browser, an outdated browser without security updates, or a victim who pastes code into their own browser;
• questions about whether an electronic signature is legally valid in a given country. That is not a security problem; our terms and help center explain it.

2. How to report

2.1 Where. Write to security@sovrasign.com (there is no separate form yet). For the open-source verifier and the format description, you can also use GitHub's private vulnerability reporting on https://github.com/sovrasign/verify. To encrypt your report, use our OpenPGP key. The same contact details are in machine-readable form at /.well-known/security.txt on each of our domains (section 7).

2.2 What to send. Please include:

• what the problem is and what an attacker could do with it;
• where it is: the address, app or verifier version, and the browser or device you used;
• the steps to reproduce it, and a proof of concept if you have one;
• how to reach you, and whether and how you want to be credited (section 6).

Write in English if you can. We also read reports in other languages, with a machine translation.

2.3 Personal data you came across. Send only what is needed to show the problem. If you saw or saved personal data or documents of other people, tell us what you saw, do not keep copies, and do not share them.

3. Rules for testing

3.1 Your own accounts only. Test with accounts you created yourself, or with the written permission of the account owner. A Free account is enough for most tests. Do not access, change or delete data that is not yours. If you reach other people's data, stop, do not keep a copy, and report it to us at once.

3.2 Send only to yourself. Send envelopes, invitations, reminders and sign-in codes only to email addresses and phone numbers you control. Do not send to anyone who has not agreed to it, and do not send in bulk: e-signature emails are a common phishing lure, and our customers rely on our emails being trusted.

3.3 Stay gentle. Keep automated testing to a rate that does not slow the service down for others, and stop when you have shown the problem. Do not try to keep access, move to other systems, or plant anything that stays behind.

3.4 Payments. Do not make payments with cards that are not yours, and do not test refunds or chargebacks with real payments. Report a problem in a payment flow with the steps to reproduce it.

3.5 Keep it confidential. Do not publish the problem before the time section 5.4 sets, unless we agree otherwise. You may still take confidential advice from a lawyer or a vulnerability coordinator and make any report the law requires. Never share other people's data or documents.

3.6 The law. Follow the law where you are. This policy authorizes research on systems we control and waives our own claims (section 4). It cannot authorize testing of systems that are not ours, waive anyone else's rights, or exempt you from laws we cannot waive.

4. Safe harbor

4.1 Our promise. When you research and report under this policy in good faith, we consider your research authorized. That means:

• we consider it authorized under the US Computer Fraud and Abuse Act, the Washington Cybercrime Act (RCW 9A.90) and similar laws of the US states and other countries, and we will not bring a claim against you or ask the authorities to pursue you for it. This does not stop reports the law requires of us; where we can, we will say that we authorized your research;
• we will not bring a claim against you under the US Digital Millennium Copyright Act or similar laws for getting around the technical measures we use to protect the service in scope;
• we waive, for this research only, the rules of our terms and acceptable use policy that would forbid it, such as the ban on probing or testing the service's security (terms Schedule 1);
• if someone else brings legal action against you for research that followed this policy, we will make it known that we authorized it.

4.2 Mistakes. If you break a rule of section 3 by accident, stop that test, tell us and limit the harm, we treat the research as made in good faith.

4.3 Limits. This promise comes from Sovrasign LLC for our own systems. We cannot authorize research on systems of other companies, and we cannot bind anyone else, such as a customer, a provider or a public prosecutor. If you are unsure whether something you want to try follows this policy, ask us first at security@sovrasign.com.

5. What we do with your report

5.1 Our commitments. We acknowledge your report within 2 business days. We assess it and tell you our first view of its severity within 7 days. We keep you informed at least every 30 days until the problem is fixed, and we tell you when it is.

5.2 Severity. We rate each problem on this scale:

5.3 Fixing. Our targets are to fix critical problems within 7 days and high ones within 30 days of confirming them. We fix our service before we publish anything about a problem in the verifier, because the same code runs in both.

5.4 Disclosure. We publish a security advisory once a problem is fixed, or 90 days after your report, whichever comes first, unless we agree a longer time with you because a fix needs it. The advisory leaves out personal data and anything the law forbids us to publish. This timetable never delays the breach notices and warnings the law or our DPA require. We publish security advisories for software we distribute, with a CVE identifier where one applies, through GitHub Security Advisories. When customers need to act, we also tell them directly.

5.5 Rewards. We do not pay rewards at this time. We plan a bug bounty later and will announce it here.

5.6 Your data. We use your contact details only to handle your report and to credit you. We do not share your name without your permission, unless the law requires it.

6. Thanks

With your permission, we name you on our acknowledgments page at sovrasign.com/security/#acknowledgments once the problem is published, unless sanctions forbid it or you are in a location blocked under clause 3.4 of our terms. We accept reports from those locations, but that does not permit using or testing the service there. We do not pay rewards. Tell us the name or handle you want, or ask to stay anonymous.

7. security.txt

Each of our domains publishes /.well-known/security.txt (RFC 9116), signed with our OpenPGP key, with the contact addresses of section 2.1, the address of this policy, our key, the acknowledgments page and an expiry date. We renew it every year.

8. Changes

We may change this policy. Each version has its own id and date, and earlier versions stay available on our legal page. A change never takes away the safe harbor of section 4 for research done under the version in force at the time.