Security and trust
VehicleDesk separates implemented local controls from deployment proof, provider dependencies, operating ownership, legal review, and planned recovery work. Nothing on this page is a certification or a substitute for a shop-specific security review.
Current posture
Statuses describe the current repository and known operating dependencies without publishing secrets. The implementation traceability record remains the engineering authority, and deployed evidence must be rechecked before reliance.
Verified sessions create a shop-scoped principal, and API capabilities separate Owner, Admin Advisor, read-only, and external support responsibilities. The database-backed two-shop matrix continues to expand with each protected resource.
Session secrets are random and stored only as hashes, with idle and absolute expiry, rotation, revocation, privilege-version checks, bounded device metadata, and an active-session workspace. Production cookie and cross-origin evidence remains required.
Integration credentials and supported authentication secrets stay server-side in encrypted form. Rotation tooling is shop-scoped and records conflicts rather than silently replacing changed records.
Authenticated browser mutations require trusted origin and fetch metadata, JSON, and a per-session CSRF token. OAuth attempts use one-time state and PKCE, while provider webhooks retain their own signature and replay checks.
Strict content-security and transport policies are defined for the public and authenticated applications. Cloudflare WAF, bot, rate, direct-origin, HSTS, and real-header evidence must be verified in the hosted environment.
Secret, dependency, route-authorization, strict-request-schema, browser-sink, supply-chain, build, and security-baseline checks exist in the repository. Protected-branch and hosted-check enforcement still requires platform evidence.
AI receives bounded context, treats imported text as untrusted, validates outputs, applies request and cost budgets, and produces advisory drafts only. Consent, eligibility, approval, and customer contact remain deterministic human-controlled decisions.
An allowlisted event catalogue, integrity metadata, correlation identifiers, and preapproved kill switches cover messaging, AI, sync, webhooks, exports, support access, public booking, and portal issuance. External alert routing, staffed ownership, and exercises remain pending.
The repository defines encrypted, immutable, independently controlled backup and restore requirements. A provider, retained backup, restore drill, recovery objectives, and observed alert evidence are still required before this is operational.
Product controls and policies address data minimization, export, deletion, portal access, retention, subprocessors, and offboarding. Counsel-approved public notices, deployed workflows, owners, and operating evidence remain prerequisites.
Product access boundaries
These implemented mechanisms are useful evaluation evidence. They still require deployed configuration, database migrations, operating owners, and shop-specific acceptance before production reliance.
Owners can administer the workspace, Admin Advisors can manage operational work, and read-only users can inspect supported operational surfaces without receiving management capability. Route and API checks both enforce restricted areas.
A shop owner can approve an eligible support operator for a 15-minute to 8-hour window limited to readiness, health, audit, and job evidence. Every view requires a case-specific reason, remains read-only, and is written to the target shop's audit history.
Authorized Owner or Admin Advisor users can issue scoped, expiring, revocable read-only links for customer-safe records. Internal notes, margins, payment handling, communications, reviews, do-not-contact state, and other customers remain withheld.
Preapproved controls can block messaging, AI, sync, webhooks, exports, support access, public booking, or portal issuance during an incident. A blocked operation returns an explicit state and records security evidence.
Communication and AI boundary
Consent, suppression, shop and channel feature gates, provider readiness, staff approval, queue state, and delivery evidence remain deterministic application decisions outside the model.
Operational evidence
Migration state, deployment configuration, owner assignment, provider transition, alerting, recovery drills, and production proof are required before a local implementation is described as operational.
Report a vulnerability
Do not include customer data or active secrets in an initial report. The repository publishes a dedicated contact and scope, but continuous mailbox monitoring and counsel-reviewed safe-harbor language remain production launch requirements.
Vulnerability disclosure
Report only VehicleDesk-owned surfaces and accounts or data you are authorized to test. Stop immediately after any accidental customer-data, credential, or cross-tenant exposure. This engineering draft requires confirmed mailbox monitoring and qualified legal review before production reliance.
In scope
Public VehicleDesk properties and the authenticated CRM and API are in scope when you use only your own authorized account and data. Tenant isolation, authentication, authorization, export, portal, booking, webhook, integration, messaging, and AI-boundary defects are useful reports.
Out of scope
Do not test Shopmonkey, Google, OpenAI, Twilio, Resend, Cloudflare, Railway, GitHub, customer sites, or other third parties. No denial of service, credential attacks, social engineering, spam, persistence, destructive changes, data exfiltration, or high-volume scanning.
Good-faith safe harbor
The draft policy describes a safe-harbor posture for research that stays in scope, uses authorized accounts and data, avoids harm, stops after demonstrating the issue, and is reported promptly. It does not authorize unlawful activity or testing third-party systems, and the legal language still requires counsel review.
Response targets
The engineering draft targets acknowledgement within three staffed business days, initial triage within seven, and an update at least every 14 staffed business days for accepted reports. These are not active guarantees, a bounty promise, or a remediation deadline until monitoring and ownership are confirmed.
How to report
The published address is security@vehicledesk.io. Include the affected surface, impact, minimal steps using your own data, and UTC references. Do not email credentials, active secrets, raw customer data, exploit archives, or provider payloads. Do not assume an immediate response until monitoring is confirmed.
Practical workflow review
Preview the workflow-review agenda, current product scope, safety boundaries, and implementation questions before public requests open.