Shipvise Service security

Version: 1.0
Effective: upon publication of this version
Last updated: 21 August 2026
Stable URL: https://shipvise.com/en/legal/security/

Translation notice: This English version is a machine-assisted translation provided for convenience. The original Czech version is the authoritative version. Where mandatory law requires otherwise, rights granted by mandatory law remain unaffected.

This document provides a conservative public overview of the Shipvise security principles. It is not a certification, an audit report or a promise of measures that are not actually deployed.

1. Approach to security

Shipvise is a platform that builds and runs Customer software. It therefore addresses security separately for:

• the Customer account and the Portal;
• the control plane;
• source code and build;
• Preview/staging;
• Production;
• runtime configuration and secrets;
• data and backups;
• human support and review.

Security measures change continuously with the architecture. Public statements are to relate only to the current production state.

2. Public communication

The public Shipvise web services are intended to be operated over HTTPS/TLS. Before this version is published, the production configuration must verify the validity of certificates, the HTTPS redirect and security headers.

Internal communication inside the infrastructure need not be end-to-end TLS at every layer. Shipvise therefore does not claim that every internal connection is separately encrypted with TLS.

3. Passwords and login

Local passwords are not stored in plaintext; the authentication stack uses one-way password hashing.

Browser login uses a server-side session and CSRF protection. The session cookie is intended to be set as Secure and HttpOnly with a corresponding SameSite mode.

The Provider may use a temporary lock after repeated failed login attempts and other anti-abuse measures.

4. MFA

MFA is not part of the MVP and the Provider does not claim to support or enforce it.

Its possible introduction will be a separate security change.

5. Roles and permissions

The Provider uses roles and application permissions to restrict features according to the user's role in the Workspace.

The principle is least privilege: a user and a technical identity should have only the permissions needed for the given operation.

Not all future administrator or Enterprise features need be available in the MVP.

6. Staging and Production

Preview/staging and Production are logically distinguished as separate environments and are to use separate configuration and permissions.

This does not mean physically separated hardware or a separate kernel for each tenant. Shipvise must not describe the current model as physical tenant isolation unless such an architecture is actually deployed.

Production data is not to be copied automatically into staging without a deliberate feature or a Customer instruction.

7. Build environment

Shipvise accepts the fact that a Customer build may contain untrusted code.

Before public arbitrary-code builds are enabled, the production build infrastructure must use a security boundary corresponding to that risk, in particular separation from the sensitive control plane, restricted permissions, resource limits and appropriate network restrictions.

Public arbitrary-code operation must not be launched on a known configuration that is internally marked as non-compliant for untrusted builds.

8. Runtime workloads

The production runtime is designed with restricted workload permissions and resource limits. Depending on the current architecture, the following may be used, for example:

• non-root execution;
• prohibition of privilege escalation;
• restriction of Linux capabilities;
• a read-only root filesystem where technically appropriate;
• seccomp/runtime hardening;
• Kubernetes resource quotas/limits;
• logical network policies.

The effectiveness of a specific control depends on the cluster actually deployed and must be verified operationally.

9. Immutable artifacts and releases

Shipvise is designed so that a build produces a specific OCI artifact identified by an immutable digest and so that promotion/rollback works with the same artifact without a hidden rebuild.

This principle improves the reproducibility and traceability of releases. It does not, however, automatically mean that the artifact contains no defect or security vulnerability.

10. Secrets

Runtime secrets are to be separated from source code and from the immutable build artifact.

The ordinary Customer-facing API is not to return plaintext secret values, and secrets are not to be deliberately written into build/runtime logs or AI prompts.

A revoked or compromised secret must not become usable again merely because the Customer activates an older Release.

Before the public MVP, the complete production path for securely accepting, storing and injecting a runtime secret must be finished and verified.

11. Encryption of stored data

Shipvise does not claim universal encryption-at-rest until encryption of the specific storage has been technically verified.

Password hashing is not the same as encryption-at-rest of all databases, Git repositories, OCI registries, Kubernetes secrets or backups.

The security documentation will be updated accordingly once verified encryption-at-rest is introduced.

12. Backups

Selected Customer and platform data is backed up daily as a standard, and operational backups have a standard rotating retention of 7 days.

Backups are stored outside the main running workload on Shipvise's own operational infrastructure and the transfer takes place over a private secured link.

A backup is intended for disaster recovery, not as a permanent archive.

The standard plan does not guarantee a contractual RPO/RTO or an exact restoration time. In the event of an incident, Shipvise endeavours to carry out restoration without undue delay from an available usable backup.

13. Logs and audit records

Shipvise records selected technical and security-relevant operations, for example build/deployment/release or changes to runtime configuration, where the given feature is audited by the application.

Standard build/runtime logs have an ordinary retention period of 14 days.

The Provider does not claim that all direct infrastructure administrator actions are today audited in a cryptographically immutable manner. The scope of auditing will be extended progressively.

14. Vulnerability management

Shipvise continuously maintains the platform software and dependencies. Unless a specific automated scan or release gate is expressly stated as an available feature, the Customer should not assume that every build, image or dependency automatically undergoes a full vulnerability scan.

Review is not a substitute for security testing of the Customer's application.

15. Human administrator access

Shipvise does not pretend that the operator of the infrastructure cannot technically obtain access to Customer data.

Access is to be limited to the necessary scope and purpose, for example:

• a Senior Review or Assisted Fix ordered by the Customer;
• a support request;
• an operational or security incident;
• a legal obligation.

Persons with access are bound by confidentiality.

16. Senior Review

Senior Review is an independent expert assessment within a scope agreed in advance. To the extent necessary to carry out the ordered Review, the reviewer may obtain access to the changes, to the relevant parts of the source code, to the related build/runtime logs and to the configuration and, where the nature or context of the Review requires it, also to the entire relevant repository. Access is purpose-limited to the ordered Review, minimised, and the reviewer is bound by confidentiality.

Review must not be presented as an absolute security certification or a guarantee that the Application has no defects or vulnerabilities.

17. Monitoring and incidents

The Provider uses technical health and operational mechanisms to the extent of the current platform and may have alerts on selected critical components.

The standard service does not have guaranteed 24/7 human on-call support. Ordinary support is provided mainly on business days. A critical incident may also be handled outside those days subject to availability, but this is not a contractual SLA.

In the case of a personal data breach where Shipvise acts as a processor, it informs the Customer without undue delay in accordance with the DPA.

18. Customer responsibility

The Customer is responsible for securing their own application logic, for using correct access controls, for updating dependencies, for the secure management of their own third-party accounts and for not deliberately placing secrets into logs or source.

The Shipvise security controls do not replace the Customer's security obligations towards their own users.

19. What the standard MVP does not guarantee

Unless an individual contract expressly provides otherwise, Shipvise in particular does not guarantee:

• a specific uptime percentage;
• a contractual RPO/RTO;
• 24/7 human support;
• MFA;
• physical isolation of each Customer;
• universal encryption-at-rest across all layers;
• a complete immutable audit of all administrator actions;
• an automatic vulnerability scan of every Customer build;
• absolute security or freedom from defects of the Customer's Application.

20. Reporting a security problem

A security incident or abuse can be reported to abuse@shipvise.com. Ordinary technical problems to support@shipvise.com.