CarCare is a pre-launch, Milestone-1 project (see README.md) — there is no production deployment handling real user data yet, and no dedicated security team or bug-bounty program. This policy is intentionally lightweight for that stage, and should be revisited before any real deployment goes live.

docs/GAP_ANALYSIS.md §3 ("Security & compliance gaps") is a codebase-verified, maintained list of known security shortcomings — wide-open CORS, missing security headers, unaudited admin actions, access tokens in localStorage, and others, each with severity and the specific file/mechanism involved. If what you found is already listed there, it's a known, tracked gap, not a new report — no need to file it again, though a PR fixing it is always welcome (see CONTRIBUTING.md).

If this repository is hosted on GitHub, please use GitHub's private security advisory feature on the repo rather than a public issue, so the report isn't visible before a fix is available.

If that's not available to you, contact the maintainer directly rather than filing a public issue — do not post exploit details, proof-of-concept code, or affected-tenant identifiers anywhere public.

Please include:

• What you found and where (file/endpoint/table).
• Steps to reproduce, or a proof of concept if safe to share privately.
• What you believe the impact is (e.g. "cross-tenant read" vs. "requires an already-authenticated RoleScope.PLATFORM account" — this project's threat model treats those very differently, see ADR 0002 and ADR 0005's notes on the internal-ops trust boundary).

• Row-Level Security is the tenant-isolation backstop (ADR 0002). A report demonstrating that a tenant-scoped guard or service-layer check can be bypassed to read another tenant's data despite RLS still blocking it at the database layer is real but lower severity than a report showing the RLS policy itself can be bypassed — the latter is the one this project's whole isolation model depends on holding.
• Internal ops (apps/web's /platform section) intentionally has a different, more privileged trust model than the rest of the tenant-facing API — the same JWT chain, but checked against a RoleScope.PLATFORM grant (PlatformMember) instead of workspace membership, and its backing queries connect as the postgres owner role (bypasses RLS) by design, since cross-tenant search is the whole point. This is a documented, deliberate boundary (ADR 0005), not itself a vulnerability — but a report showing a tenant-scoped account can reach /platform privileges without a genuine RoleScope.PLATFORM grant is exactly the kind of thing this policy exists to catch.
• Two SECURITY DEFINER Postgres functions (carcare_lookup_vehicle_for_consent(_by_id)) deliberately bypass RLS to return non-sensitive vehicle-identifying columns only — a report showing they leak more than plate/make/model/year/type/tenant_id is in scope and taken seriously.

• Don't access, modify, or exfiltrate data belonging to any tenant you don't control, beyond the minimum needed to demonstrate the issue.
• Don't run automated scanners against any deployed instance without permission — this is a small project, not a hardened target, and noisy scanning is likely to just look like an attack.
• Don't publicly disclose before a fix is available, given there's currently no formal coordinated-disclosure timeline in place — reach a private agreement on timing with the maintainer instead.