Car Shop Analytics Security Whitepaper

1. Executive Summary

Car Shop Analytics provides a cloud-based shop management platform for independent automotive repair shops and multi-shop groups: repair-order workflow, scheduling, estimates and approvals, parts and inventory, payroll, and cross-shop analytics. Shops run their business on the platform, and the platform holds their business data — we treat the protection of that data as a foundational engineering requirement, not a feature.

Our security program is built on defense in depth, least privilege, and fail-closed design. Tenant isolation is enforced by the database engine itself rather than by application code alone. The platform holds no static database credentials. Sessions are short-lived, revocable, and protected against token theft and replay. Every production change passes mandatory automated checks before deployment, and every remediated security finding is pinned in place by a permanent regression test.

This document describes the controls protecting the platform and the data within it. It deliberately describes only what is implemented and in production as of the date above; planned improvements are listed separately in Section 14.

2. Scope of This Document

This whitepaper covers the security capabilities, practices, and protections of the Car Shop Analytics platform and the infrastructure it runs on. It is intended for shop owners, group operators, and the IT, security, and procurement professionals who evaluate vendors on their behalf.

This document does not describe capabilities that are not yet generally available. Statements reflect the platform as deployed on the “last updated” date on the cover page.

3. Platform Overview and Shared Responsibility

3.1 Architecture

The platform runs on Amazon Web Services (AWS), primarily in the us-east-1 (N. Virginia) region, and consists of three tiers:

• Web tier. A single-page web application delivered through Amazon CloudFront from private object storage. Origin access control restricts the object storage so that assets are served through the CDN and the storage is not publicly readable.
• Application tier. Containerized API services on Amazon ECS behind an Application Load Balancer. Plain-HTTP requests are redirected to HTTPS.
• Data tier. PostgreSQL on Amazon RDS, deployed in private subnets with no public network exposure. The database server itself rejects unencrypted connections.

Customer data is primarily processed and stored in the United States (AWS us-east-1). Static web assets are delivered through a global content-delivery network, and certain third-party features (such as AI assistance) may process the data submitted to them on the provider’s infrastructure.

3.2 Shared responsibility

Security of the platform is a responsibility shared across three parties:

• AWS is responsible for the security of the cloud: physical data center security, hardware, and the virtualization layer. AWS maintains an extensive, independently audited compliance program (including SOC 2 and ISO/IEC 27001) covering these layers.
• Car Shop Analytics is responsible for security in the cloud: the platform’s architecture, application code, data protection, tenant isolation, identity systems, monitoring, and the secure operation of all services described in this document.
• Customers are responsible for the security of their own credentials and devices, for assigning appropriate roles to their staff (Section 8.3), and for the configuration of any third-party integrations they choose to connect.

4. Organizational Security

Security at Car Shop Analytics is integrated directly into engineering practice rather than operated as a separate function:

• All production changes are made through reviewed pull requests with required automated checks; no engineer modifies production systems by hand.
• Administrative access to production infrastructure is limited to authorized engineering personnel, individually authenticated, and captured in immutable audit logs (Section 5.3).
• Every remediated security finding becomes a permanent automated regression test, so a recurrence in a later release is caught automatically rather than shipping unnoticed.
• An internal adversarial review program continuously probes the live product for weaknesses and tracks findings through the same remediation pipeline as external reports (Section 11).

5. Infrastructure Security

5.1 Network security

Production systems are segmented within a virtual private cloud. Databases are reachable only from inside the network — there is no public database endpoint. Database connections additionally require TLS, enforced by the database server itself.

At the edge, the platform is fronted by Amazon CloudFront and AWS WAF web access control lists at both the CDN and load-balancer layers. The CDN enforces TLS 1.2 or higher for client connections to the platform’s domains, and the load balancer redirects any plain-HTTP request to HTTPS.

5.2 Account-level threat detection

Continuous account-level monitoring is active across the AWS environment:

• AWS CloudTrail (multi-region) records an immutable audit trail of all administrative API activity.
• Amazon GuardDuty provides continuous threat detection over account activity, network telemetry, and credential usage.
• AWS IAM Access Analyzer continuously checks for unintended resource exposure.

5.3 Administrative access

Operational access to production infrastructure is performed through AWS Systems Manager with full session auditing; production hosts do not accept open inbound SSH from the internet. EC2 instances enforce IMDSv2, mitigating credential theft through request-forgery attacks.

5.4 Infrastructure change management

Infrastructure changes are executed through a gated, phase-by-phase change-management workflow with a documented rollback path for each phase. Ad-hoc console changes are not part of our operating model.

6. Data Protection

6.1 Encryption in transit

All data transmitted between clients and the platform is encrypted using TLS, with TLS 1.2 as the minimum accepted protocol version on the platform’s customer-facing endpoints. HTTP Strict Transport Security (HSTS) is set for one year, including subdomains, instructing browsers to refuse protocol downgrade. Connections between the application tier and the databases are also TLS-encrypted, enforced server-side.

6.2 Encryption at rest

Production database instances and their underlying storage volumes are encrypted at rest, with deletion protection enabled on production databases.

6.3 Secrets and key management

Application secrets are stored in AWS-encrypted parameter storage and injected into containers at start time. Secrets are not stored in plaintext in task definitions or source code, and the source repository is guarded by an automated check against committed credentials.

6.4 Database credentials

The platform’s services hold no static database passwords. Database authentication uses AWS IAM with short-lived, cryptographically signed tokens, scoped to the service’s IAM role.

6.5 Backups and data durability

Production databases take encrypted automated daily snapshots with continuous point-in-time recovery over a 7-day window.

7. Tenant Isolation

The platform is multi-tenant, and isolation between tenants is enforced in layers — with the database engine, not application code alone, as the last line of enforcement:

• Row-level security (RLS) in PostgreSQL. Tenant-scoped tables carry RLS policies keyed to the requesting organization. The policy is evaluated by the database engine on every query, so tenant separation does not depend on each query carrying a correct application-side filter.
• Per-request tenant context. Each authenticated request establishes the caller’s organization on its database session before any query runs.
• A runtime database role without RLS-bypass privilege. The application’s database user is explicitly denied the RLS-bypass privilege. Background processing that legitimately spans organizations runs under a separate, dedicated role that is not reachable from request handling.
• Tenant-scoped caching. Cached report and query results are keyed by organization, so a cached result is not served outside the organization it belongs to.

8. Identity and Access Management

8.1 Authentication

• Session model. Access tokens are short-lived (15 minutes) and delivered exclusively in HttpOnly, Secure, SameSite=Strict cookies — by virtue of the HttpOnly flag they are not accessible to page JavaScript, and they are not placed in browser storage. Sessions are renewed by opaque, single-use refresh tokens (hashed at rest, 30-day maximum lifetime) that rotate on every use. Reuse of a rotated refresh token is treated as evidence of theft and revokes the entire session chain.
• Server-side revocation. Sessions are individually revocable on the server. Logout, “sign out everywhere,” and password reset all invalidate sessions immediately; a revoked session is rejected even if its token has not yet expired.
• Passkeys (WebAuthn). Users can authenticate with phishing-resistant passkeys. User verification (biometric or device PIN) is required at both enrollment and sign-in, and the flow is designed so it cannot be used to test whether an email address has an account.
• Password controls. Passwords require a minimum of 12 characters and are stored using the bcrypt adaptive hashing algorithm. Login credentials are additionally encrypted at the application layer inside the TLS channel. Sign-in attempts are rate-limited per account and per source address, and the service responds in uniform time whether or not an account exists, to resist account-enumeration probing.

8.2 Authorization

Permissions are role-based and tiered (owner → manager → bookkeeper → service advisor → technician), enforced server-side on every request. Sensitive surfaces such as payroll require elevated tiers. Authorization fails closed: a request that cannot positively establish its identity and tier is rejected.

8.3 Customer-controlled security capabilities

Customers manage their own security posture within the platform:

• Assignment of role tiers to staff, scoping each user to the minimum access their job requires
• Passkey enrollment for phishing-resistant sign-in
• Per-session visibility and revocation, including “sign out everywhere”
• An in-product, append-only audit trail of repair-order workflow changes

8.4 Operational access to customer data

Internal access to production systems is restricted to authorized engineering personnel, individually authenticated, and logged immutably (Sections 4 and 5.3).

9. Application Security

• Request forgery (CSRF). State-changing requests must originate from an allow-listed web origin, layered on top of SameSite=Strict cookie scoping — two independent defenses.
• Browser protections. The application ships X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a strict referrer policy, HSTS, and a Content-Security-Policy that pins network connections to first-party origins. Security headers are additionally enforced at the CDN layer.
• Email authentication. Mail sent from the platform’s domain is authenticated with SPF and DKIM and protected by a DMARC policy at enforcement (quarantine), so receiving mail servers can detect and quarantine messages that spoof the platform’s domain.
• Input handling. Every endpoint validates request bodies against typed schemas. Global limits bound request size and JSON nesting depth. File uploads are verified against content signatures (magic bytes) rather than trusted file extensions.
• Rate limiting. Authentication endpoints and public-facing endpoints (for example, customer approval links) are rate-limited.
• Real-time channel. WebSocket upgrade requests are validated against the same origin allowlist, and browser sessions authenticate the socket with the same HttpOnly cookie used for HTTP — tokens are not placed in URLs.
• Fingerprint reduction. Framework identification headers are stripped from responses.

10. Secure Development Lifecycle

• Change control. All code reaches production through pull requests gated by required automated checks — unit, integration, and end-to-end browser test suites. These checks are required on every change, and the CI/CD pipeline is the only route used to deploy to production.
• Deployment security. Deployments are performed exclusively by CI/CD pipelines that authenticate to AWS through OIDC federation with narrowly scoped roles. No long-lived deployment credentials exist, and engineers do not hand-deliver artifacts to production.
• Security regression pinning. Each remediated security finding is captured as a permanent automated test that runs on every subsequent change.
• Architectural enforcement. The codebase enforces strict separation between transport, business logic, and data access layers, with tenancy and authorization implemented in shared infrastructure rather than re-implemented per feature — reducing the surface where an individual feature change can introduce an access-control defect.

11. Security Assessments and Vulnerability Management

• Authentication surface audit (May 2026). A formal greybox audit covered the full authentication surface — login, session machinery, credential encryption, token and cookie handling, middleware, CORS/CSP, and the passkey flow — rated against an internet-exposed multi-tenant SaaS threat model. All findings were remediated and verified, and the audit record, remediation order, and per-finding regression tests are retained.
• Infrastructure audit (May 2026). An account-wide infrastructure review drove the phased hardening program described in Sections 5 and 6, including encryption at rest, IAM database authentication, storage lockdown, IMDSv2 enforcement, TLS hardening, and account-level threat detection.
• Continuous internal review. An internal adversarial review program runs against the live product as part of routine engineering, filing severity-rated findings that are remediated through the standard pull-request pipeline and pinned by regression tests.
• Dependency monitoring. Third-party dependencies across the backend and frontend are tracked by automated dependency monitoring, and every change is scanned for known vulnerabilities in continuous integration. Findings are surfaced to engineering and remediated through the standard pull-request pipeline; promotion of the scan to a merge-blocking gate is on the roadmap (Section 14).
• External reports. Vulnerability reports from customers and researchers are handled through the disclosure process in Section 15.

12. Logging, Monitoring, and Security Event Response

• Application logging. The platform emits structured, machine-parseable logs centralized in Amazon CloudWatch. Every request-path record carries request, user, and organization identifiers, enabling precise reconstruction of activity during an investigation.
• Audit trails. Administrative infrastructure activity is recorded immutably by CloudTrail (Section 5.2); repair-order workflow changes are recorded in an append-only, in-product audit trail.
• Threat detection. Amazon GuardDuty continuously analyzes account activity, network telemetry, and credential usage for indicators of compromise.
• Response capability. Sessions and credentials are revocable platform-wide and individually (Section 8.1); infrastructure access is role-scoped and individually attributable. In the event of a security incident affecting customer data, affected customers are notified in accordance with applicable law and their agreement.

13. Privacy and Data Governance

• Data ownership. Customer data is processed solely to operate the platform for the customer. Car Shop Analytics does not sell customer data and does not use it for advertising.
• K-anonymized network analytics. Cross-shop benchmarks (for example, network labor-time distributions) are computed only over aggregate cells containing at least 3 contributing shops and at least 8 repair orders, with no single shop contributing more than 60 percent of a cell’s data. Cells that fail any threshold are suppressed and are not published. These floors are enforced inside the aggregation pipeline itself, rather than at display time, so that an individual shop’s performance is not exposed in a published network statistic.
• Licensed industry data. Vehicle and parts reference data is licensed from recognized industry sources. License compliance is enforced architecturally: external interfaces exchange opaque industry identifiers only, with a suppression boundary designed to prevent redistribution of decoded reference content.
• AI features. AI-assisted features transmit only the data needed for the requested operation, to providers whose commercial API terms, as of publication, exclude the use of submitted data to train their models.
• Third-party integrations. Integrations with third-party shop-management, parts-procurement, and ordering systems exchange data only at the customer’s direction and under the customer’s configuration.
• Subprocessors. The platform’s principal infrastructure provider is Amazon Web Services. A current list of subprocessors and their functions is available upon request via the security contact on the cover page.
• Retention, export, and deletion. Data export and deletion requests are supported through our support process, consistent with applicable law and the customer’s agreement. Self-service export and deletion tooling is on the roadmap (Section 14).

14. Compliance Posture and Roadmap

Car Shop Analytics inherits the physical and environmental control attestations of AWS (SOC 2, ISO/IEC 27001, and others) for the infrastructure layers AWS operates, as described in Section 3.2. Car Shop Analytics has not itself completed a SOC 2 or ISO/IEC 27001 certification of its own controls; such examinations are listed in the roadmap below.

Consistent with this document’s commitment to describing only what exists today, the following are in progress or planned, not yet delivered:

• SOC 2 Type II examination of the platform’s own controls
• Independent third-party penetration testing
• Enterprise single sign-on (OIDC / SAML) and TOTP-based multi-factor authentication as an alternative to passkeys
• Promotion of the existing dependency vulnerability scan to a required, merge-blocking CI gate
• An organization-wide administrative audit console, expanding the existing in-product audit trail
• Self-service data export and deletion

15. Reporting a Vulnerability

We welcome reports from security researchers and customers. Contact security@carshopanalytics.com with a description of the issue and reproduction steps. We will acknowledge your report promptly, keep you informed through remediation, and will not pursue good-faith research conducted within the law.

16. Conclusion

Repair shops trust the platform with the operational heart of their business. The controls in this document — database-enforced tenant isolation, credential-less data-tier access, short-lived revocable sessions, gated change management, and privacy-preserving analytics — exist to be worthy of that trust, and the program behind them treats every closed finding as a permanent, regression-tested fix rather than a one-time patch.

Questions about anything in this document, requests for the current subprocessor list, or vulnerability reports can be directed to security@carshopanalytics.com.

Document history

Version	Date	Changes
1.0	June 3, 2026	Initial release

This document is provided for informational purposes only, describes the platform as of the date stated, and may change without notice. It is provided “as is,” creates no contractual commitment, representation, or warranty of any kind, express or implied, and is not intended to be relied upon by any third party. Car Shop Analytics may update this document from time to time; the most recent version supersedes all prior versions. © 2026 Car Shop Analytics. All rights reserved.