Vulnerability Disclosure Policy

Status: DRAFT — pending licensed-attorney review. Not yet published; not yet in force. Version 1.0-draft · Grounded in docs/legal/FACT_REGISTER.md (code facts verified 2026-07-23; owner decisions D1–D14 updated 2026-08-04) Intended effective date: 2026-08-04 · Last updated: 2026-08-04 — takes effect when published, which happens only after attorney sign-off.

Publisher: Single Case Informatics, PBC — a Delaware public benefit corporation (FACT_REGISTER D1). Service: SingleCase.ai (the web application and API operated by Single Case Informatics, PBC). Governing law / principal office: Pennsylvania; State College, PA 16803 (FACT_REGISTER D1). Security contact: [email protected] — please put "Security" in the subject line (FACT_REGISTER D7, D11).

This page is a draft prepared for attorney review. It is not legal advice and is not yet in force. Its intended effective date takes effect when the page is published, which happens only after counsel signs off (FACT_REGISTER D1).

1. Our commitment

Single Case Informatics, PBC ("SCI", "we", "us") builds SingleCase.ai to hold sensitive research, protocol, and participant data. We take the security of that data seriously and we welcome reports from the security research community. This policy explains what you may test, how to report what you find, what we commit to in return, and the protections that apply to good-faith research.

If you believe you have found a security vulnerability in a system that is in scope (Section 3), please report it to us (Section 5). We will work with you to understand and resolve the issue.

2. Who operates what (why scope is split)

SingleCase.ai is a web application and API operated by SCI but hosted on infrastructure owned and run by third-party providers (FACT_REGISTER §B). This distinction defines our scope:

• SCI controls the SingleCase.ai application code, its API endpoints, its access-control and tenant-isolation logic, and its configuration. Vulnerabilities here are in scope and are ours to fix.
• Third-party providers control the underlying platforms — authentication/database/storage (Supabase), hosting/serverless/parse runtime (Vercel), the document store (MongoDB Atlas), the default AI provider (Google / Gemini), and document parsing (LlamaCloud / LlamaParse) (FACT_REGISTER §B.1). Vulnerabilities in their platforms are out of scope for us and should be reported to those providers under their own disclosure programs (Section 4).

If you are unsure whether something is in scope, email us and ask before testing.

3. In scope

The following, when operated by SCI, are in scope:

• The SingleCase.ai web application and its authenticated user-facing surfaces, at these hostnames:
  • alpha.singlecase.ai — the current application hostname.
  • app.singlecase.ai — the planned application hostname. It is in scope from the moment it serves the application; testing it before then simply finds nothing.
• The SingleCase.ai API (the application's own endpoints, served from the hostnames above).
• SCI-controlled security properties, including but not limited to:
  • authentication and session handling;
  • authorization / access-control and cross-tenant or cross-user data isolation (our isolation is logical, enforced at the application and database-policy layer — FACT_REGISTER §D);
  • injection, deserialization, SSRF, and similar application flaws in our code;
  • insecure direct object references and broken object-level authorization;
  • sensitive-data exposure originating in our application logic.

4. Out of scope

The following are out of scope under this policy. Testing them, or reporting them here, is not covered by this policy or its safe-harbor provision (Section 6).

A. Third-party provider infrastructure — report to the provider, not to us. Vulnerabilities in the platforms below belong to those vendors and are covered by their own security programs (FACT_REGISTER §B.1):

A defect in how SCI uses one of these platforms (for example, a misconfiguration in our access rules, or our failure to isolate one tenant's data from another) is in scope — that is our code and our responsibility. A defect in the platform itself is not.

B. Excluded classes of testing and findings. Regardless of the target, the following are out of scope:

• Social engineering of SCI staff, users, or vendors (phishing, pretexting, vishing, etc.).
• Physical attacks against offices, staff, or hardware.
• Denial-of-service (DoS/DDoS) and volumetric / load / stress testing of any kind.
• Automated-scanner output submitted without a demonstrated, manually-verified, security-relevant impact (theoretical/informational scanner noise).
• Findings that require a compromised or rooted device, a man-in-the-middle position, or an already-compromised account the researcher does not own.
• Best-practice / hardening suggestions with no demonstrated vulnerability — e.g., missing security headers, cookie flags, TLS-configuration nitpicks, SPF/DKIM/DMARC observations, version-disclosure banners, autocomplete on forms, rate-limiting on non-authentication endpoints, and clickjacking on pages with no sensitive state-changing action — unless you can chain them into a concrete, demonstrated impact.
• Reports affecting only unsupported or end-of-life browsers or platforms.
• Preview, staging, and per-deployment hosts — including Vercel deployment URLs (*.vercel.app) and any non-production hostname. Only the application hostnames listed in Section 3 are in scope.

5. How to report

Send your report to [email protected] with "Security" in the subject line, so it is routed to the right person quickly. (We are a small team and do not yet operate a dedicated security@ alias.)

Please include, to the extent you can:

1. A clear description of the vulnerability and the security impact you believe it has.
2. The in-scope component or URL affected.
3. Step-by-step reproduction instructions, including any proof-of-concept, request/response captures, or screenshots.
4. Any accounts, IP addresses, or timestamps you used, so we can correlate with our logs.
5. Whether the finding has been shared with, or is known to, any third party.

Please report only. Do not publicly disclose, and do not share the details with anyone outside SCI, until we have coordinated a disclosure timeline with you (Section 7).

Sensitive data. If your testing incidentally exposes personal, participant, IRB, or other sensitive data, stop, do not download or retain more than the minimum needed to demonstrate the issue, and tell us in your report. We would rather receive a report with a single screenshot than a copy of anyone's research data.

6. Safe harbor

If you make a good-faith effort to comply with this policy during your security research, we will consider your research to be authorized, and:

• We will not pursue or support legal action against you in connection with your research, including under the Computer Fraud and Abuse Act (CFAA), the Digital Millennium Copyright Act (DMCA) anti-circumvention provisions, or applicable state computer-crime or anti-hacking laws, to the extent those claims arise from activity that complied with this policy.
• We will not report you to, or pursue a complaint with, law enforcement for policy-compliant research.
• If a third party brings legal action against you for activity that complied with this policy, we will make it known that your actions were conducted in compliance with this policy.

This safe harbor applies only to activity that:

• stays within the scope defined in Sections 3 and 4;
• avoids privacy violations, data destruction, and service degradation — in particular, no accessing, downloading, modifying, or deleting data that is not your own beyond the minimum needed to demonstrate the issue, and no DoS/volumetric testing;
• stops as soon as a vulnerability is confirmed and reports it promptly; and
• does not publicly disclose the issue before coordinated disclosure (Section 7).

This safe harbor does not authorize activity against third-party provider infrastructure (Section 4.A) — that is governed by those providers' own programs and terms — and does not waive any rights of third parties.

7. What you can expect from us (response targets)

The following are SCI's target timelines. They are goals we set for ourselves under normal conditions, not contractual guarantees, and may vary with severity and complexity.

We will keep you reasonably informed of our progress and let you know when the issue is resolved.

8. Coordinated disclosure

We support coordinated disclosure. We ask that you give us up to 90 days from the point we triage and confirm a valid report before any public disclosure, so we can develop and deploy a fix. We are happy to coordinate a mutually agreeable disclosure date and, where you wish, to credit you (Section 9). If a vulnerability is being actively exploited, or a fix is straightforward, we will move faster.

Note on already-known issues. Some security-relevant items are already tracked internally and may be in progress at the time you report them. If your report matches an issue we are already remediating, we will tell you that in triage and coordinate disclosure timing with you.

9. Recognition

We are grateful to researchers who help keep SingleCase.ai and its users safe.

• SCI does not currently operate a paid bug-bounty program and does not offer monetary rewards. We do not want researchers to expect payment we have not committed to.
• With your permission, we are happy to publicly credit you for a valid, in-scope report once it is resolved.

10. Changes to this policy

We may update this policy as our service and security program evolve. The version and date at the top of this page reflect the current revision. Material changes will be reflected here and, where appropriate, in the security.txt file (which carries its own expiry — Section 9 of RFC 9116 requires it to be kept current).

security.txt

The block below is the machine-readable companion to this policy, formatted per RFC 9116.

Where it must be served:

• It must be served over HTTPS at https://<domain>/.well-known/security.txt (RFC 9116 §3) — from every hostname a researcher might visit. For SingleCase.ai today that is https://alpha.singlecase.ai/.well-known/security.txt, and after the move, https://app.singlecase.ai/.well-known/security.txt. If singlecase.ai serves a marketing site, serve a copy there too: researchers look at the apex first.
• A legacy copy may also be served at https://<domain>/security.txt, but the /.well-known/ location is authoritative.
• It must be served with an appropriate media type (text/plain; charset=utf-8).

# security.txt for SingleCase.ai (operated by Single Case Informatics, PBC)
# Format: RFC 9116  —  https://www.rfc-editor.org/rfc/rfc9116
# DRAFT for attorney/ops review — not yet published.

Contact: mailto:[email protected]
Expires: 2027-08-04T00:00:00Z
Preferred-Languages: en
Canonical: https://alpha.singlecase.ai/.well-known/security.txt
Canonical: https://app.singlecase.ai/.well-known/security.txt
Policy: https://alpha.singlecase.ai/legal/vulnerability-disclosure

Field notes (RFC 9116):

• Contact (required, at least one): hello@ is the only monitored inbox today (D11). Add security@ as the first Contact line if and when that alias is provisioned.
• Expires (required, exactly one): set to 2027-08-04, one year from the intended effective date. Refresh it before it lapses — an expired security.txt is treated as invalid. Put a calendar reminder at ~11 months. If publication slips well past 2026-08-04, roll this date forward so it stays ~1 year out.
• Preferred-Languages (optional, at most once): en.
• Canonical (optional, repeatable): every URI this file is served from. RFC 9116 permits multiple Canonical fields, which is how the alpha. → app. move is handled without a window where the field is wrong: list both, and drop alpha. once it stops serving. A Canonical that does not match the serving location invalidates the file.
• Policy (optional): the public URL of this policy once published — the /legal/vulnerability-disclosure route on the current application hostname. Update it at the hostname cutover.
• Encryption (optional, omitted): add only if SCI publishes an OpenPGP key for encrypted reports (Section 5).
• RFC 9116 recommends the file be digitally signed with an OpenPGP cleartext signature; if SCI adopts a signing key, sign the file and reference the key via Encryption.

OWNER/ops — hostnames confirmed 2026-08-04: the app is served from alpha.singlecase.ai today and moves to app.singlecase.ai soon, so both appear as Canonical and both must serve this file. At the cutover: re-serve from the new host, drop the alpha. Canonical line once it stops serving, and repoint Policy. The Policy path matches the route the app registry defines (lib/legal/registry.ts). Keep the calendar reminder for the 2027-08-04 Expires.