Security disclosure

Email a suspected security issue to support@veripsa.com. Mark the subject line with [security]so it's triaged ahead of general support.

Please don't open a public GitHub issue for a suspected vulnerability — email is the right channel so we can fix and notify before the details are public.

A report we can act on usually has four things. Anything you can give us helps; nothing here is a hard requirement.

• Scope. Which surface is affected — the GitHub App (Veripsa Core), the platform website, the dashboard, the billing flow, or something else.
• Reproduction. The steps to reproduce the issue, the request or input that triggered it, and the observed behavior versus what you expected. A minimal repro is more useful than a long write-up.
• Impact.Your assessment of what an attacker could actually do — read another tenant's data, escalate privileges, take the service down, etc. — and any constraints you know about.
• Contact.How to reach you for follow-up, and whether you'd like to be credited if and when we publish a fix.

Please don't paste source code, secrets, or other repository contents into the report. Veripsa is content-freeby design, and we don't need them — minimal content-free service metadata and clear reproduction steps are enough.

We aim to acknowledge a suspected security report on a best-effort basis within about three business days, and to share an initial assessment shortly after. That is a goal, not a contractual SLA — Veripsa is run by a small team and we don't publish numbers we can't honor. If your report is time-sensitive, say so in the subject line.

• Acknowledgement— we confirm we've received the report and have a human looking at it.
• Triage — we assess scope and severity, and if a service outage is involved we begin remediation in parallel.
• Status updates — described in structural terms (which subsystem, which tenants were affected). We do not echo source code or repository contents back to you.
• Customer notification— if a confirmed issue affected your account's data, we will reach out with what we know, what we've done, and what you may want to do.

We follow a coordinated-disclosure model. We ask that you give us a reasonable window to investigate and ship a fix before publishing details — typically about 90 daysfrom the day we acknowledge the report, or sooner by mutual agreement if a fix lands earlier. For issues that are unusually complex or that require a coordinated upstream change, we may ask to extend that window, and we'll explain why.

We're happy to coordinate the public write-up with you and to credit you in any advisory we publish, unless you'd prefer to remain anonymous.

If you're researching in good faith — making a sincere effort to avoid privacy violations, service disruption, and data destruction — we will not pursue or support legal action against you for the research itself. Specifically:

• Access only accounts you own, or accounts of an organization that has authorized you. Don't access, modify, or exfiltrate another tenant's data; structural proof of the issue is enough.
• Don't run denial-of-service tests, large-scale automated scans, or social-engineering attempts against Veripsa staff, users, or our subprocessors.
• Don't use the vulnerability beyond what's needed to demonstrate it — stop and report, rather than escalating further.
• Give us a reasonable chance to fix before public disclosure (see above).

Research that stays within those limits is welcome. This isn't a contract, and it doesn't override third-party terms (for example, GitHub's terms of service still apply to its platform), but it's how we intend to behave.

To save you time, a few categories that we typically won't treat as security vulnerabilities on their own:

• Best-practice header or TLS configuration findings without a demonstrated impact (for example, a missing optional header on a static page).
• Reports generated by automated scanners with no manual analysis or reproduction.
• Social-engineering, phishing, or physical attacks on Veripsa staff or our subprocessors.
• Volumetric denial-of-service or brute-force findings against production endpoints.
• Vulnerabilities in third-party services (GitHub, Render, etc.) — please report those to the vendor; we're happy to coordinate if it affects Veripsa users.

If you're not sure whether something counts, send it anyway with a short note on why you think it matters.

• Security overview— what we store, what we don't, and how it's protected.
• Trust Center — the longer security and procurement page, including the incident process.
• Procurement & security review — the same answers in questionnaire shape, print-to-PDF for your vendor file.
• Privacy Policy — what data Veripsa Core processes and stores.
• Support — for non-security questions.