VulnStatus Trust Center
Transparency about security, compliance, and infrastructure in one place.
Trust Center
VulnStatus
Attack Surface Management
We assess your internet-facing surface the way an external, unauthenticated attacker would - discovery, exposure detection, and AI attack-surface - and grade your AI Attack Survivability.
Isolation
Per-tenant
database-level access backstop so one tenant can never read another's
Secrets
Encrypted
scanning credentials via a dedicated key-management service, never plaintext
Scanning
Consent-based
target ownership verified before any scan
Access
Least-privilege
capability-based roles; privileged support access is just-in-time and time-boxed
Change control
CI-gated
every change blocked on SAST, secret scanning, tests and type-checks before merge
Trust & scanning overview
OverviewPlain-language account of exactly what we do and never do.
Scan Authorization & Consent
AgreementsYou attest you own or are authorized to test each target, and consent to non-destructive active checks.
Terms of Service
AgreementsThe terms your use of the platform is subject to.
Privacy Policy
AgreementsWhat we collect, how it is stored, and your rights over it.
SOC 2 Type II
Scope: Security, Availability, Confidentiality
Audit year: 2026
Illustrative control mapping
Scope: Implemented app-level technical controls
Period
2026-02-15 to 2026-08-15 (illustrative)
Scope
VulnStatus SaaS application - authentication, authorization, tenant isolation, encryption, audit logging, and change management. Excludes corporate policies, HR, vendor and physical controls.
Trust Services categories
Illustrative self-assessment prepared by VulnStatus engineering: implemented app-level technical controls mapped to SOC 2 Trust Services Criteria. This is NOT an independent third-party audit, opinion, or attestation and confers no certification. A formal SOC 2 Type II examination is in preparation.
| Ref | Control | Implementation | Test performed | Result |
|---|---|---|---|---|
| CC6.1 | Password storage User passwords are stored only as one-way, salted hashes. | bcrypt via passlib (per-password salt, tunable cost); plaintext passwords are never stored or logged. | Inspected the CryptContext configuration and the login path; confirmed compare-against-hash with no plaintext persistence. | No exceptions noted |
| CC6.1 | Session tokens Authenticated sessions use short-lived signed tokens. | Signed JWT access (30 min) and refresh (14 day) tokens; a boot-time guard hard-fails startup if the default signing secret is used in production. | Verified token issuance/expiry claims and the production insecure-default startup guard. | No exceptions noted |
| CC6.1 | Strong authentication option A phishing-resistant second factor is available. | WebAuthn / passkeys with a hardware sign-count replay counter; enabled per deployment. | Inspected the WebAuthn credential + challenge model and registration/assertion flow. | Operating (opt-in) |
| CC6.2 | Access provisioning New accounts are granted only the access an existing admin is entitled to delegate. | Membership is added only through email invite; an admin may invite strictly-lower roles only, never a peer or higher role. | Confirmed the invite role-ceiling rule rejects same-tier and higher-tier invitations. | No exceptions noted |
| CC6.3 | Role-based authorization Every privileged operation checks an explicit capability. | Capability-based permission bundles per role; a request missing the required capability is refused with 403 before any handler logic runs. | Traced representative endpoints through the require_permission dependency to a 403 on missing capability. | No exceptions noted |
| CC6.3 | Tenant isolation One tenant can never read another tenant's data. | Org-scoped queries are constrained to a recursive set of the caller's own organization and only descendants reached through an unbroken managed relationship. | Reviewed the visible-org resolution and confirmed cross-tenant reads are excluded outside a managed chain. | No exceptions noted |
| CC6.1 | Database isolation backstop Isolation is enforced a second time at the database layer. | PostgreSQL row-level security policies keyed to the request's organization context, fail-closed if application scoping is ever bypassed. | Confirmed the RLS policy and per-request org-context binding. | No exceptions noted |
| CC6.3 | Just-in-time privileged access Support/admin access to customer data is temporary and justified. | Break-glass access grants are approved, time-boxed with automatic expiry, and every use records a required justification. | Walked the grant lifecycle (request, approve, expiry, revoke) and confirmed justification is mandatory. | No exceptions noted |
| CC6.3 | Controlled impersonation MSSP act-as-client access is scoped, time-boxed, and fully recorded. | Impersonation is token-scoped and re-validated against a database session each request, time-boxed, rotates the target credential afterward, and is visible to the affected tenant. | Confirmed per-request session revalidation and the impersonation audit chain. | No exceptions noted |
| C1.1 | Encryption of sensitive data at rest Sensitive fields are encrypted in the database. | Per-organization envelope encryption of sensitive columns (scanning and storage credentials, data keys); credential fields are excluded from all API responses. | Inspected the column-encryption scheme and confirmed credentials are never serialized. | No exceptions noted |
| C1.1 | Customer-controlled keys (BYOK) Customers may hold the encryption key for their own data. | The per-org data key can be wrapped under a customer-managed KMS key via assume-role; revoking that key crypto-shreds the organization's data. | Confirmed the customer-CMK wrap path and the revoke-to-shred behavior. | Operating (when configured) |
| C1.1 | Object storage encryption Stored reports and findings are encrypted at rest. | When a customer bucket is configured, objects are written with SSE-KMS (customer key) or SSE-S3. | Verified the server-side-encryption headers on the storage write path. | Operating (when configured) |
| CC6.7 | Encryption in transit Data in transit is protected. | TLS 1.3 terminated at the edge; baseline response-hardening headers (no-sniff, frame-deny, no-referrer) are set on API responses. | Confirmed edge TLS termination and the security-header middleware. | Operating |
| CC7.2 | Security audit trail Security-relevant actions are recorded immutably. | An append-only, write-only audit log records key issuance/revocation, storage-config changes, plan changes, and invites, written atomically with the action itself. | Confirmed the append-only model and that records commit in the same transaction as the action. | No exceptions noted |
| CC7.2 | Privileged-action justification log Justification-bearing admin actions are recorded. | Every justification-requiring admin action and break-glass event is written to an append-only log with a mandatory reason. | Inspected the justification-log model and its write points. | No exceptions noted |
| CC7.1 | Abuse throttling Authentication endpoints resist brute force and abuse. | Rate limiting on register/login/demo endpoints keyed to the true client IP (unspoofable edge header), backed by Redis for multi-replica consistency. | Confirmed the limits and the client-IP resolution that rejects spoofed forwarded headers. | No exceptions noted |
| CC6.6 | Input validation and injection resistance Untrusted input is validated and cannot alter queries. | All requests are validated against typed schemas; database access is exclusively through a parameterized ORM. | Reviewed request schemas and confirmed no string-built SQL. | No exceptions noted |
| CC8.1 | Secure change management Code changes are gated by automated security checks. | Each change is blocked in CI by build-failing SAST (security-audit, OWASP, secrets rules), full-history secret scanning plus a pre-commit hook, and automated tests and type-checks; schema changes ship only via reviewed migrations. | Inspected the CI workflow gates and the migration history. | No exceptions noted |
| A1.1 | Availability health probing Unhealthy instances are detected and removed. | Liveness and readiness endpoints; readiness returns 503 when the database, crypto backend, or scheduler is degraded so orchestration drains the instance. | Confirmed readiness degradation returns 503. | No exceptions noted |
| A1.2 | Resilient background processing Security lifecycle jobs run reliably and can scale out. | Redis-backed workers run session-timeout enforcement, credential rotation, and grant/impersonation expiry; shared state supports horizontal scaling. | Reviewed the scheduled security-lifecycle jobs and their shared-state backend. | No exceptions noted |
Tenant data isolation
Owner: Engineering • Per-org isolation plus a database-level access backstop.
Cadence: Enforced in code
Credential handling
Owner: Security • Scanning credentials encrypted via KMS; leaked secrets redacted on capture.
Cadence: Continuous
Consent-based scanning
Owner: Security • Target ownership verified before scanning; scanning is opt-in per authorization.
Cadence: Per target
Hosting: Self-hosted, fronted by Cloudflare
Encryption: TLS 1.3 in transit (edge-terminated); sensitive columns (scanning + storage credentials, data keys) encrypted at rest with per-tenant envelope encryption; customers can bring their own KMS key so revoking it crypto-shreds their data
Retention: Confirmed leaked-secret findings are recorded redacted (the value is never stored or shown); storage location is customer-controllable via BYOK
Backups: Database backups managed at the infrastructure layer
Regions: Per-tenant isolation enforced in application queries and again by database row-level security, Optional customer-owned S3 bucket + region for findings and reports (BYOK)
No incidents recorded in the past months.
Bring-your-own-key storage connect flow
2026-08-15
A guided setup for pointing findings and reports at your own bucket with your own KMS key, including a live read/write connection test.
Security audit trail
2026-08-15
An append-only audit log now records security-relevant account actions (key issuance/revocation, storage-config changes, plan changes, invites).
Cloudflare
Public edge, DNS, and secure tunnel fronting the platform.
Amazon Web Services (S3, KMS)
Used only when a customer enables BYOK storage; the bucket and encryption key can be customer-owned.
Office hours: Reach the team via the in-app support portal