Security
Properties you can verify
TRUSTIVAN asks for registry access and a place in your release path. That warrants specifics rather than badges, so every claim below corresponds to something enforced in the implementation.
Security properties
The scanner cannot reach your host
Images are pulled from the registry. TRUSTIVAN asks for no Docker socket and no container runtime — handing a runtime socket to the process that parses untrusted input would be root on the machine.
Isolation the compiler enforces
Tenant-scoped queries require a scope value constructible only after a membership check, so a handler that forgets to authorise does not compile. A CI guard fails the build if that structure is removed.
Existence is not disclosed
“Belongs to another tenant” and “does not exist” return byte-identical responses. Anything else would turn a guessed identifier into reconnaissance about who else is a customer.
Credentials are bounded by construction
Secrets are shown once and never readable again. Expiry is mandatory with no “never” option. Revocation is immediate and keeps the record, because an incident review needs to know which credential did what.
Ambient credentials are kept apart
Browser sessions are HttpOnly cookies with a CSRF requirement on unsafe methods. An API key presented in a cookie is refused outright — honouring it would create a credential that is both ambient and unprotected.
Stale data fails closed
If the vulnerability database is too old to trust, the scan fails rather than reporting a clean result. Silence from an out-of-date scanner is the most dangerous output a security tool can produce.
A second factor, and no half-authenticated session
TOTP with single-use recovery codes. A password that is correct but unaccompanied produces a challenge and no session at all — not a partial one — and a step already spent is refused even inside its own time window. Removing the factor demands proof of holding it, because a session alone being enough is what turns a stolen session back into a stolen account.
Registry credentials have no read path
A stored registry secret is encrypted under its own derived subkey and there is no endpoint that returns it, at any role — a secret that can be fetched is one that ends up in a screenshot. The scan carries a reference, never the secret, so the plaintext exists only in the few lines that hand it to a registry client.
SSO routes on a proved domain
SAML and OIDC are configured per tenant, and a login only routes to a provider once control of the email domain has been proved. Adding a domain, verifying it, and switching enforcement from optional to mandatory are each recorded — the last one because it is the change that can lock an organization out.
Deprovisioning leaves evidence
SCIM writes the membership table, so disabling someone in your directory removes their access here. Provisioning, deprovisioning and role changes are written to an append-only identity trail, because an offboarding claim is worth exactly what the record of it is worth.
Rejected logins are recorded, without the reason
A refused SSO assertion is audited — it is either a misconfiguration an admin must see or someone probing the login path, and a successful login leaves a session while a refused one leaves nothing. The entry never records which check failed, since that would hand back in the audit trail exactly what the HTTP response withholds.
What we cannot claim
No certifications, and no pretending otherwise
TRUSTIVAN holds no third-party attestations. Where a compliance question has an answer, it is below; where it does not, that is stated rather than implied.
Not available
- SOC 2, ISO 27001 or any third-party attestation of TRUSTIVAN itself — evidence mapping is a different thing, and it ships
- A data processing agreement or GDPR compliance programme
- A published penetration test
- Support or availability commitments
Single sign-on, directory sync, administrative audit, multi-factor authentication, member invitations and private registry credentials are no longer on this list because they now exist. Nor is compliance framework mapping: TRUSTIVAN maps evidence to controls in SOC 2, ISO 27001, PCI DSS 4.0, NIST SSDF and EU CRA, and exports a hash-chained audit package. That is a map of your evidence, never a certificate of ours, and no control is ever reported as “compliant” or “pass”.
Two-factor is per-user and opt-in: an organization cannot yet mandate it for its members. What is claimed for the rest is on the security model page, in terms of the routes and tables that implement them.
What that means for you
TRUSTIVAN is self-hosted, so your findings and your decision record stay in your own PostgreSQL instance. We do not operate infrastructure that holds your data, which removes the questions a hosted vendor's certifications exist to answer — and leaves the ones your own deployment must answer instead.
Upstream scanner telemetry is disabled in the configuration TRUSTIVAN ships.
Disclosure
Found something?
Report it privately. The disclosure policy sets out what to include, which testing is out of bounds, and what to expect back.