Security
Last updated: July 2026
Our Commitment
Security is engineered into JinxQMS from the ground up, not added afterward. The platform's access controls, audit logging, tenant isolation, and input handling are built around a control set aligned with SOC 2 Trust Services Criteria, and every code change is checked against that control set before it can reach production. We do not claim SOC 2 certification or a completed independent audit — the statements on this page describe controls that are actually implemented in the platform today, not aspirational goals.
Infrastructure
JinxQMS runs on managed cloud infrastructure — application hosting through Render and database and authentication services through Supabase's managed Postgres platform. All traffic to the Service is encrypted in transit using TLS. Data at rest is protected by our infrastructure providers' managed storage encryption. We do not operate our own data centers or manage encryption keys on bespoke hardware; we rely on our providers' production-grade infrastructure so engineering effort stays focused on the application-layer controls described below.
Access Control
Every request to the Service is authenticated and authorized on the server — role-based permissions (super admin, admin, manager, employee, and work-group level permissions) are enforced in application code on every mutation, never trusted from the client. Session tokens are verified on every request rather than cached, so a revoked or expired session cannot be replayed. Multi-factor authentication is available for user accounts as an additional login safeguard, and administrative and cross-tenant routes require an explicit elevated role check before they will touch any data.
Multi-Tenant Isolation
JinxQMS is a multi-tenant platform, and tenant isolation is treated as the single highest-priority control in the codebase. Every database query that touches customer data is scoped to the requesting organization's tenant ID at the application layer, and PostgreSQL Row Level Security policies enforce the same boundary as a second, independent layer of defense inside the database itself. This isolation is not just a design intention — an automated check runs on every commit and blocks any change that would let one tenant's data leak into another tenant's query path.
Audit Trail
Every creation, update, and deletion of quality data is written to an append-only audit log capturing the acting user, their organization, the action taken, the affected record, the requesting IP address, a timestamp, and both the before and after state of the change. The audit log itself cannot be edited or deleted through the application — there is no update or delete path exposed for it. Each entry is chained to the previous entry for that organization using a SHA-256 hash, so any attempt to alter or remove a past entry breaks the chain and is detectable. Successful and failed login attempts are logged for the same reason security teams need them: to reconstruct exactly what happened, and when.
Data Retention
Completed quality records are retained in line with the aerospace industry's common ten-year retention convention, reflecting how long supply-chain traceability records typically need to remain accessible. Audit log entries are retained indefinitely and are never purged, preserving a complete history of every change made to a tenant's data for the life of the account.
Secure Development Practices
Before any commit can be merged or deployed, it must pass an automated security gate consisting of more than eighty codified rules — covering authentication and authorization on every route, tenant-scoping of every query, input validation and sanitization, secret-pattern detection, PII-in-logs prevention, and safe error handling — alongside strict TypeScript type checking and automated tests. The same gate runs again server-side in CI on every push, so a bypass of a local check cannot silently reach production. Rate limiting is enforced on every API route, with the strictest limits applied to authentication endpoints to slow credential-stuffing and brute-force attempts.
Vulnerability Reporting
If you believe you have found a security vulnerability in JinxQMS, we welcome a responsible disclosure report through the contact form on our home page. Please include enough detail to reproduce the issue and avoid accessing or modifying data beyond what is necessary to demonstrate it. We ask that you give us a reasonable opportunity to investigate and address a confirmed issue before any public disclosure.