Security architecture

This page is the long form of every trust claim on the homepage. Each claim names its mechanism, and nothing here describes an aspiration — only what is built and running today.

Findings, never code

Sinterly ingests scanner findings, not source code, and there is no path by which it could read your code. File uploads contain what your scanner chose to output — nothing more. The GitHub Code Scanning connector authenticates with a token you scope yourself: a fine-grained token with code scanning alerts: read-only cannot read repository contents. We recommend exactly that scope and nothing wider.

Tenant isolation, enforced by the database

Every table carries a tenant identity and row-level security policies are enforced by PostgreSQL itself — not by application filters. A query from your session physically cannot return another tenant's rows. The isolation is covered by an automated test suite (27 tests) and an execution-level isolation test that runs a full pipeline for one tenant and asserts zero writes to any other.

Append-only audit log

Every administrative decision — scoring changes, merges, credential changes, uploads, user administration — is recorded. A database trigger makes the log immutable: updates and deletes are rejected at the database layer, for us as well as for you.

Credentials encrypted app-side

Integration secrets are encrypted with AES-256-GCM before they reach the database; the database only ever stores ciphertext, a random nonce, and a last-four hint. The encryption key lives in a separate secrets manager and never touches the database provider. There is deliberately no API that returns a stored secret: once saved, a credential can be replaced or deleted, never viewed. Decryption happens only in pipeline process memory at the moment a connector needs it.

Authentication

Multi-factor authentication is required, not optional — first login enforces enrolment, and API access requires a session that has actually completed the second factor, verified from the token's assurance claim.

Explainable scoring

Every priority score stores its five component inputs and the weight set used at calculation time. Reweighting the formula creates a new version and never rewrites history.

Where we are honest about limits

We have not undergone SOC 2 certification. An audit costs more than makes sense at our stage, and we would rather say so than imply otherwise. What we have done instead: a self-assessment against OWASP ASVS 5.0 — Level 2 for the core chapters (authentication, session management, access control, validation, logging and error handling) and Level 1 elsewhere — plus the mechanisms above, each of which is verifiable in the product. SOC 2 is planned when customer procurement requires it. A third-party penetration test is likewise planned when a customer's procurement demands one.

Vulnerability disclosure

If you believe you have found a security vulnerability in Sinterly, email security@sinterly.com with enough detail to reproduce it. It reaches the team directly. You will get a human acknowledgement within 72 hours and updates until the issue is resolved; we will credit you if you want credit and stay quiet if you prefer.

We ask that you give us reasonable time to fix before publishing, avoid accessing data that is not yours (use a trial tenant — we will happily provision one for testing), and do not run denial-of-service or volumetric attacks. We will not take legal action over good-faith research that respects those bounds.

Data handling and deletion

How tenant data is stored, where it lives, and how deletion works when a trial ends is documented plainly in the privacy policy. Trial use is governed by the trial terms.