Security

Vioro is built by a solo founder who holds a CompTIA PenTest+ certification and approaches security as a core product value — not an afterthought. This page documents the technical and organisational measures (TOMs) in place for the Vioro platform, operated by Cyze AS, Norway.

For legal obligations relating to data protection, see our Privacy Policy and Data Processing Agreement.

Encryption in Transit

All communication between your browser, the Vioro dashboard, and our backend services is encrypted using TLS 1.3. Older protocol versions (TLS 1.0, 1.1, 1.2) are not accepted. HTTP traffic is redirected to HTTPS.

Internal service-to-service communication within the platform is conducted over gRPC with mutual TLS on private VLAN interfaces. No internal traffic is transmitted in plaintext.

Encryption at Rest

Sensitive data fields are encrypted at rest at the field level. This is a stronger guarantee than standard disk-level encryption: even if an attacker gains access to the raw database, they cannot read the protected fields without the corresponding encryption keys.

Field-Level Encryption

The following data categories are encrypted at the field level using ChaCha20-Poly1305 (AEAD — Authenticated Encryption with Associated Data). AEAD provides both confidentiality and tamper detection in a single operation; any attempt to modify ciphertext is detectable upon decryption.

Encryption keys are derived per-record. Keys are managed via Kubernetes Secrets, provisioned through CI/CD, and mounted at runtime as volumes. Key rotation capability is implemented; Key Encryption Keys (KEKs) and Data Encryption Keys (DEKs) are part of the roadmap.

Disk-level (volume) encryption is not currently implemented at the operating system layer. This is a known, accepted risk item. The field-level encryption described above provides the primary at-rest protection against database-level compromise, as plaintext data is never written to disk in unencrypted form at the application layer. Volume-level encryption (via LUKS/Clevis/Tang) is planned as an additional defence-in-depth measure.

Access Controls

• SSH access to all production systems is key-based only; password authentication is disabled
• FIDO2 hardware security key (Google Titan) is required for all privileged administrative access
• Non-root principle: no root logins permitted; all administrative tasks use dedicated non-root users with principle of least privilege
• Network isolation: the Kubernetes API server and internal services are accessible only via private VLAN — not exposed to the public internet
• Jump server with Clevis/Tang-based automated disk unlock is planned to further harden remote access

Infrastructure & Availability

Vioro’s infrastructure runs exclusively in the European Union on dedicated hardware provided by Netcup GmbH (Germany). No customer data is stored or processed outside the EU/EEA.

Storage uses a multi-node Ceph cluster providing redundant, distributed block storage with automated replication. Backup durability target is 99.9%.

Network-level DDoS protection is provided by Netcup GmbH as part of the hosting infrastructure.

The platform is monitored continuously via Grafana dashboards for uptime, performance, and anomalies.

Frontend performance and error telemetry is collected via OpenTelemetry and processed exclusively on Vioro’s own infrastructure.

Vulnerability Management

• cargo deny, cargo clippy, and cargo audit run in CI on every commit, scanning for known CVEs in all Rust dependencies
• Dependency update checks are performed regularly to address newly disclosed vulnerabilities
• A self-conducted penetration test was performed in 2025 by the founder (CompTIA PenTest+ certified). One accepted risk item was identified (SSH port exposure on a non-standard port); this is addressed in the jump server roadmap item
• The platform is designed with reference to the OWASP Top 10

Incident Response

In the event of a confirmed security incident or personal data breach, Cyze AS will:

1. Contain and assess the incident as quickly as possible
2. Notify the Norwegian Data Protection Authority (Datatilsynet) within 72 hours of becoming aware, where required under GDPR Art. 33
3. Notify affected customers without undue delay, as required by applicable law and our DPA obligations
4. Document the incident, impact, and remediation steps for audit purposes

Responsible Disclosure

If you discover a security vulnerability in Vioro, please report it responsibly to security@vioro.io. We will acknowledge your report within 5 business days and work to resolve confirmed issues promptly. We do not currently operate a formal bug bounty programme, but we recognise and appreciate responsible disclosures. See security.txt.

Probe Ethics & Authorisation

Vioro performs outbound monitoring probes against customer-configured targets. For standard monitoring (uptime, TLS certificate validation, broken link detection), no domain ownership verification is required, and probes are strictly passive HTTP(S) requests.

For security-oriented features (CMS detection, port scanning, header analysis, vulnerability assessments, and any active or offensive tests), explicit domain ownership verification is required prior to scanning. Accepted verification methods:

• DNS TXT record
• HTML <meta> tag
• .well-known/ file placement

Verifications are re-checked daily. Vioro will not conduct active security scans against a domain without current, valid verification on record.

Last updated: 2026-04-06