Platform architecture

How WASViking is built and operated. The security posture, the isolation model, and the engineering practices behind the platform.

This page is the architecture summary the procurement and security teams of prospects ask for. It covers the components, how they communicate, how data is protected, and the engineering practices behind the platform. It is written so it can be attached to a vendor diligence response without further editing.

Components

Data plane

The schema is owned by a single source of truth on the portal side. The API consumes that schema in read-mostly mode for its own data needs. Migrations and schema changes go through the same pull-request flow as application code.

Encryption

Key rotation is automated for short-lived material (agent client certificates, session keys) and operator-driven for long-lived material (API keys, with a 24-hour overlap window).

Tenant isolation

Isolation is enforced at four layers:

• View layer: every customer view refuses a request without an organization context.
• ORM layer: querysets are scoped to the requesting user's organization. Cross-tenant queries are treated as a bug.
• Audit layer: every audit row records the operator's organization. The customer-facing audit log is scoped accordingly.
• Billing layer: billing rows attach to organization, not to users, so a deleted user does not lose billing trail.

API keys carry their issuing organization. Cross-organization use of a key returns 404 (not 403) to avoid leaking the existence of other tenants.

The Partner Console uses a separate identity table from the customer realm. Partner operators are not customer users. The two cannot see each other across hosts.

Identity and access

• SAML 2.0 SSO as Service Provider. Standard attribute mapping, optional group-to-role propagation. First sign-in defaults to Read-only by policy; promotion requires an existing Admin or Manager.
• Multi-factor authentication is mandatory for every operator. TOTP-based when SSO is not enforced; IdP-enforced when SSO is on.
• RBAC with four default roles (Admin, Manager, Analyst, Read-only) and a granular capability catalog of 25+ scopes. Roles are editable per organization.
• API keys scoped per organization. Granular scope set per key. Hashed at rest, rotatable with overlap, optionally IP-restricted.
• Emergency local login for SSO-enforced organizations as break-glass, 72-hour TTL, high-severity audit event on use.

Network architecture

• Sentinel agent is outbound-only. The agent dials WASViking from inside the customer network. No inbound ports, no static IP allow- listing, no VPN required.
• mTLS termination at the proxy with the verified client certificate forwarded inward. Compatible with managed cloud load balancers. The agent's private key never leaves the host.
• Gateway redaction at the gRPC service layer. The server never logs full proto, job, or response payloads, so cookies, CSRF tokens, and internal target bodies do not appear in operator logs.
• Public endpoints sit behind a managed CDN with edge rate-limiting and bot management. Application-layer rate limits run on top as a second floor.

Hardening

Agent:

• Single static Go binary, distributed with cosign signatures so customers can verify before running.
• systemd unit with NoNewPrivileges, ProtectSystem=strict, MemoryDenyWriteExecute, restricted system call filter.
• Optional obfuscated enterprise build for higher-assurance customers.

Platform:

• Container images built from minimal base images, no source volumes in production.
• Runtime principal-of-least-privilege at the cloud account level.
• Production access requires MFA, is time-bound, and is logged.
• Secrets manager for application credentials. No long-lived cleartext secrets on disk.

Secure software development

WASViking dogfoods its own product against its own codebase:

• Continuous DAST runs against staging deployments on every release.
• SBOM and SCA with KEV cross-reference run in CI for every service.
• Secrets detection runs in CI for every push. CI exit codes block merges on KEV-listed components or verified-live secrets.
• Dependency review is mandatory on pull requests.
• Branch protection with required reviews, signed commits where the platform supports it, and required status checks before merge.
• Signed release artifacts for agent releases (cosign) and internal containers.
• Internal threat-model review for new analyzers and any change to the identity, billing, or data-isolation surface.

This is the same set of gates WASViking ships as a product. The product page set has the full reference: CI/CD with wasviking-sentinel.

Operational hygiene

The platform runs a small set of background jobs to keep the data plane consistent and the alert channel signal-only:

• Scheduled scans (per organization configuration).
• Hygiene sweeps for orphan and stale long-running scans.
• Daily threat-intel ingest (OSV.dev + CISA KEV) with retroactive match against live SBOMs.
• Smart re-notify rules so alerts only re-fire on KEV bump, severity bump, or fix availability.
• Integrations polling (Jira, SLA breach digest, AI quota reset).
• Monthly billing previews; daily annual renewal task.

Job names and schedules are an internal implementation detail. Customers see the outputs: dashboards, findings, webhooks, audit events.

Logging and audit

• Customer-facing audit log at /portal/audit-log/, gated by the audit_logs.view RBAC capability. Public REST scope audit_logs:read.
• Mutation events (RBAC change, API key issuance, finding status transition, posture share access, evidence bundle access) are written immutably.
• Operator and system events stream to the WASViking-side observability stack with their own retention.
• Default audit retention is 24 months; configurable up to 7 years on Enterprise plans.
• Signed webhook events mirror audit-relevant transitions for external SIEM ingestion.

Backups, durability, disaster recovery

• Daily automated backups of the relational and document databases.
• 30-day backup retention by default.
• Cross-region replication for Enterprise plans, with point-in- time recovery to a secondary region.
• Restoration is operator-initiated and audited; no silent rollbacks.
• Quarterly recovery exercises validate the runbook.

Data residency

Production data is hosted in US AWS regions today. Regional residency options for additional jurisdictions are part of the Enterprise roadmap. Sub-processors and their regions are documented on the Trust Center.

Compliance posture

Two postures, kept strictly separate:

What the product supports. WASViking maps findings to controls across PCI DSS v4.0, LGPD, GDPR, BACEN 4893 + 4658, and ISO 27001:2022, from a single rule table. Evidence Bundles are designed to be attached directly to an audit binder. See Framework mapping.

What the company is certified for. WASViking LLC is working toward SOC 2 Type I and ISO 27001 Certification. Current status, sub-processor list, DPA, and the security questionnaire (CAIQ / SIG) are available on the Trust Center at portal.wasviking.com/trust-center.

Vulnerability disclosure

WASViking welcomes coordinated disclosure. The policy, scope, safe harbor, and PGP key are at Reporting vulnerabilities. Acknowledged reporters are named (with permission) when WASViking notifies affected customers about the issue.

What we publish externally

• This documentation.
• The institutional marketing site.
• The Trust Center with DPA, privacy policy, sub-processors, and the SOC 2 roadmap.
• A coordinated disclosure policy and PGP key.

What we do not publish externally

The following are shared only on signed mutual NDA (or not at all):

• Internal IP ranges, network diagrams, and provider-account identifiers.
• Specific framework, database, and runtime versions in use.
• Internal admin routes and operator runbooks.
• Margin and cost models.
• Incident response procedures.
• Customer-specific configurations.

These are deliberately withheld because they are operationally sensitive and provide no security value to a prospect.