Security architecture

We are asking you to put a list of your vulnerabilities in our system. Every claim below names the mechanism behind it, because a security product that asks for trust without showing its work is asking the wrong thing.

What Sinterly never has

• Your source code. Sinterly ingests findings, not repositories. The GitHub connector uses a code scanning scope that cannot read code.
• Your password. Accounts are created with a random secret that is discarded immediately. No member of staff can produce your password, which is a stronger statement than declining to.
• Your stored credentials in readable form. Integration credentials are encrypted with AES-256-GCM before storage. The application has no decrypt path at all; only the pipeline decrypts, in memory, at the moment of use.

Tenant isolation

Every table carrying tenant data has row-level security enforced by the database. Requests run under your identity rather than an application service account, so isolation does not depend on the application getting a query right. A finding belonging to another tenant is not merely hidden from you; it does not exist as far as your session is concerned.

This is verified by an automated test suite that creates real users with real credentials and asserts the boundaries, rather than mocking them.

Authentication

• Multi-factor authentication is mandatory and cannot be skipped.
• Sessions must have completed the second factor, not merely enrolled for it. A session that has not is refused.
• Access tokens are short-lived and validated server-side on every request, so revocation takes effect immediately.
• Authentication endpoints are rate limited.

Records that cannot be rewritten

Four things are append-only, enforced by the database rather than by convention:

• The audit log of administrative actions.
• The history of decisions taken on findings.
• The raw ingested payloads.
• Exploitability verdicts and gate evaluations.

Updates and deletes are physically refused. The single exception is a deliberate tenant erasure, described below.

Data residency and processors

Data is held in the United Kingdom and the European Union. The full processor list is published in our privacy policy rather than summarised, so you can assess each one.

Deleting your data

A tenant erasure removes every row belonging to you, including the append-only tables, through one narrow and deliberate mechanism that exists for exactly this purpose. The audit log keeps the record that something happened, with all personal data stripped from it, because the fact of an action is not the data subject's to erase while their personal data is.

Trial tenants are deleted 30 days after the trial ends.

Verification

• Verified against OWASP ASVS 5.0 at level 2 for the core chapters, with the control inventory mapped to concrete evidence rather than asserted.
• Dependency vulnerabilities gate our own builds. Accepted exceptions are documented individually with the argument for each and a date to re-read them by.
• We run our own scanners over our own codebase and put the results through Sinterly.

Reporting a vulnerability

Email security@sinterly.com. We will acknowledge, keep you updated, and credit you if you would like that.

For anything else, including data protection requests, write to hello@sinterly.com.