Vulnerability Disclosure Policy

Owner: John Crighton, Managing Member

1. Purpose

Contrayo LLC (“Contrayo,” “we,” “us”) welcomes reports from security researchers who find a vulnerability in the Contrayo contract lifecycle management platform (the “Service”) or its supporting infrastructure. This policy describes what is in scope, how to report a finding, what a reporter can expect from us in return, and the legal protection (“safe harbor”) we offer for good-faith research conducted under this policy.

This is not a paid bug bounty program. Contrayo does not currently offer monetary rewards for reports. We do commit to acknowledging every valid report, keeping the reporter updated on remediation, and publicly crediting them if they want that (see §6).

2. Scope

In scope:

• The production Service at app.contrayo.com and any subdomain serving the product itself (dev.contrayo.com, uat.contrayo.com are non-production and also in scope, since a finding there often applies to production too).
• The public marketing site at contrayo.com and its subdomains.
• Contrayo’s own use of third-party infrastructure, to the extent a finding demonstrates a real impact on Contrayo customer data or the Service itself (for example, a misconfiguration in a Contrayo-controlled cloud resource that exposes customer data) — not a vulnerability in the third-party provider’s own product that doesn’t involve Contrayo’s configuration or data.

Out of scope:

• Denial-of-service attacks, or any test that degrades the Service for other users. Do not run load tests, fuzzing, or automated scanners configured for volume against production — this applies to Contrayo’s own commissioned assessments too (see §7).
• Social engineering, phishing, or physical-access attempts against Contrayo personnel or customers.
• Findings that require physical access to a device, or a compromised account/credential the reporter obtained by means other than the vulnerability itself.
• Spam, content injection into publicly-editable fields that doesn’t demonstrate a real security impact, or reports based solely on automated scanner output with no verified, reproducible impact (a raw scanner report with no proof-of-concept is not actionable — see §4).
• Missing security headers, cookie flags, or TLS/cipher configuration findings with no demonstrated exploit — these are welcome as informational notes but are not treated as vulnerabilities under this policy unless a reporter can show a concrete resulting impact.
• Third-party services Contrayo uses but does not control the configuration of (for example, a vulnerability in Google Cloud Platform itself, Stripe, or Resend’s own infrastructure) — report those to the vendor directly.
• Reports concerning a customer organization’s own configuration choices within the Service (for example, a customer’s own weak password policy setting for their organization) rather than a flaw in the Service itself.

3. How to report

Email security@contrayo.com with:

• A description of the vulnerability and its potential impact.
• Steps to reproduce, including the specific URL, request, or account state involved.
• Any proof-of-concept code, screenshots, or request/response captures needed to reproduce it.
• Whether you’ve already disclosed this to anyone else, or plan to.

Encrypt anything sensitive (a working exploit, real customer data your testing may have inadvertently touched) before sending, or ask us for a secure channel in an initial unencrypted message first.

Do not include real customer data in a report. If your testing incidentally accessed another customer’s data, stop immediately, do not save or exfiltrate it beyond what’s minimally needed to prove the finding, and say so explicitly in your report — this does not disqualify the report or void the safe harbor below; the opposite would only discourage honest reporting.

4. What to expect from us

• Acknowledgment within 3 business days of a report reaching security@contrayo.com.
• An initial triage assessment within 10 business days, including our assessment of severity and, where we can share it, a rough remediation timeline.
• Ongoing updates at least every 2 weeks while a valid report remains open, until it’s resolved.
• Notification when the fix ships, and an invitation to verify it if the reporter wants to.

Severity and response priority follow the real-world impact of the finding, not a fixed SLA table — a cross-tenant data-access or authentication-bypass finding gets immediate attention; a low-impact informational finding is queued behind higher-severity work. As a one-person engineering organization as of this policy’s adoption date, Contrayo cannot commit to fixed-calendar-day remediation SLAs the way a larger security team might, but will communicate honestly about timeline and priority rather than going silent.

5. Coordinated disclosure

We ask reporters to give us a reasonable opportunity to investigate and remediate a finding before any public disclosure — 90 days from our acknowledgment of the report, or sooner if we confirm a fix has shipped and both parties agree. We’ll work with a reporter in good faith to agree on an adjusted timeline if remediation genuinely needs longer than that, rather than treating 90 days as a hard deadline that forces a rushed fix.

We will not take legal action against, or ask law enforcement to investigate, a reporter for research conducted in good faith and in accordance with this policy, including §2’s scope limitations and this section’s disclosure window.

6. Recognition

With the reporter’s permission, we will credit them by name (or handle, if preferred) in a public acknowledgments page once the finding is resolved and any agreed disclosure window has passed. A reporter who prefers to stay anonymous, or not be listed at all, only needs to say so.

7. Relationship to independent assessments

Contrayo separately commissions its own third-party security assessments from time to time (for example, a CASA — Cloud Application Security Assessment — scan run under a Google OAuth verification requirement). Those assessments operate under their own engagement terms with the assessor, not under this policy, and are not a substitute for it — this policy exists for anyone who finds something outside of a commissioned engagement.

8. Changes to this policy

This policy may be updated as the Service and Contrayo’s own team grow (in particular, the response-time commitments in §4 are stated for a one-person team and will tighten as that changes). The version and adoption date at the top of this document reflect the current version; material changes will be dated and noted here.

Security acknowledgments