This is the deep dive on how Berserk approaches security as a self-hosted vendor: the threat model, the technical controls in the shipped product, and how a customer should run it securely.
This document is split into three parts:
For the procurement-friendly summary, see the Trust Overview. For the structured 261-question deep-dive, see the filled CAIQ v4.
Berserk is an observability platform you deploy self-hosted or in your own private cloud — close to the services it observes, so the egress traffic that ordinarily piles up against an external SaaS backend stays inside your network. The customer operates the deployment; the customer owns the data. Berserk ApS — the company — distributes the software deliverables and is actively engaged with customers commercially, but the product does not phone home: the customer's running deployment does not send telemetry, diagnostics, or usage data back to any Berserk-operated service in normal operation, because we do not operate one. Active engagement with the company happens through human channels — sales, support, the Coordinated Vulnerability Disclosure inbox — never through the running product.
This section describes the security properties of the shipped product and the data path inside a customer-operated deployment.
The boundary is broken only when the customer explicitly invites Berserk personnel under a Data Processing Agreement for a support engagement, and only for the data the customer chooses to share.
The ingest service is a purpose-built OTLP receiver. The relevant behaviour for buyers configuring their OTel collectors:
| Aspect | Behaviour |
|---|---|
| Protocols | OTLP over HTTP and gRPC. |
| Authentication | Bearer token per ingest stream. Tokens are scoped to a single stream so a leaked token can be rotated without disturbing others. |
| Input validation | Berserk is designed to accept a wide range of observability payloads and preserve them for analysis rather than reject aggressively. Safety against malformed or hostile input comes from Rust's memory-safety model, runtime checks, and explicit admission limits. |
| Admission and backpressure | A semaphore caps inflight bytes globally and per stream. When saturated the service returns standards-respecting backpressure: HTTP 429 Retry-After: <secs> (which the OTel HTTP exporter honours as ThrottleRetry), and gRPC Unavailable + google.rpc.RetryInfo rather than bare RESOURCE_EXHAUSTED (which OTel gRPC treats as permanent and drops). |
| Batching and storage | Validated requests are batched per stream and flushed to the customer's object store in compressed form. The customer's object store is the trust root; metadata in Postgres is rebuildable from the stored telemetry data. |
| Egress | Ingest writes only to the customer's configured object store. There is no Berserk-operated endpoint to which the running deployment sends data — see §"Trust boundary". |
The deployment model is largely inspectable through the Helm chart, rendered manifests, and operator documentation. Additional engineering walkthroughs and architecture review material are available to enterprise customers on request.
The table below summarizes the product-side encryption model. Because Berserk is self-hosted, several at-rest controls are owned by the customer and depend on how the customer configures their own infrastructure; those rows say so plainly.
| State | Encryption |
|---|---|
| In transit — between collectors and Berserk ingest | TLS 1.2+ via rustls (aws-lc-rs backend). Mandatory for the OTLP HTTP and gRPC endpoints when exposed beyond the cluster; ingress termination is the customer's choice (mesh, ingress controller, OAuth2 proxy). |
| In transit — between the bzrk CLI / UI and query | TLS 1.2+ via rustls. The CLI refuses plaintext for a non-localhost endpoint. |
| In transit — internal Berserk service-to-service | In self-hosted deployments, Berserk can be isolated with customer-controlled Kubernetes network controls such as NetworkPolicy, subject to cluster configuration and CNI support. Berserk does not currently add a separate built-in service-to-service authentication or mTLS layer inside the cluster. |
| At rest — telemetry data (object store) | The customer's object store, encrypted using the customer's chosen storage controls. This is where customer telemetry is stored. |
| At rest — metadata Postgres | The customer's Postgres, encrypted using the customer's chosen storage controls. Postgres holds metadata; customer telemetry remains in the object store. |
| At rest — customer-managed secrets | Customer-side: SOPS, sealed-secrets, or the cluster's KMS-backed secret store (we recommend, do not enforce). |
| At rest — telemetry integrity | Each stored segment is bound to a cryptographic digest at creation; the binding is verified on every query read. Create / merge / delete events are recorded in an append-only audit chain in metadata. SHA-256 default, with BLAKE3-256 and SHA-3-256 as per-segment alternatives. See Trust §"Tamper-evident storage". |
| Hashing | SHA-256, SHA-512, BLAKE3 in security-relevant contexts. No MD5 or SHA-1. |
| Use | Implementation |
|---|---|
| TLS for HTTP and gRPC | rustls with the aws-lc-rs backend, used uniformly across HTTP and database clients. |
| Symmetric encryption | AES-256-GCM, ChaCha20-Poly1305 (authenticated only). |
| Asymmetric signing | Ed25519, ECDSA P-256. RSA only where forced by an external system. |
| Opaque token generation | OS RNG only for security-relevant token generation. |
| Token storage | Meta stores a SHA-256 digest of ingest tokens for validation; plaintext tokens are shown only once and are not persisted. |
Engineering rules that affect runtime safety:
unsafe keyword is avoided. It is only permitted in a small,
isolated core where the performance properties cannot be achieved
in safe Rust, or where interop with a C library requires it; every
such site is reviewed..create, .drop,
.append, and .alter are deliberately not implemented, so a
query cannot mutate tables, schemas, stored telemetry, or rows.sqlx query with typed parameter binds — there is no runtime
SQL string construction in the codebase, so SQL injection is
not a possible state of the program.Berserk ships self-hosted software, so deployment-side continuity is the customer's responsibility. The shipped product is built around an S3-as-trust-root design: telemetry data in object storage is authoritative, and the metadata Postgres is rebuildable from that stored data. A customer who retains the object store retains the data, regardless of what happens to the metadata service.
Specific RTO and RPO targets, redundancy commitments, and crisis- communication SLAs are agreed contractually under each engagement (DPA, support contract, or the planned managed-offering MSA).
This section describes Berserk ApS's own development, operational, and support practices. These controls are not runtime properties inside the customer deployment, but they are part of the trust model behind the delivered product.
The dependency graph and the build pipeline are the highest-priority attack surface for a vendor in our position. Concrete controls, named by category rather than by specific product so the posture survives tooling churn:
/sbom.cdx.json. The customer's own SBOM scanner — whichever
CycloneDX-compatible product they already use — can audit a
Berserk image without us shipping anything additional.analysis.state = not_affected) with a justification
enum and a free-form detail. We maintain a single advisory-
exception register that feeds the SBOM, the per-ecosystem
scanners, and the dependency-updater alert filter, so they never
disagree.Mapped to NIS2 Article 21(2)(e) and NIST CSF 2.0 ID.RA-08, ID.RA-09, RS.MI-01, PR.PS-02. The full policy is available under NDA on request.
Sources we monitor. The per-ecosystem advisory databases (e.g.
RUSTSEC for Rust, GHSA for the GitHub-tracked ecosystems) plus an
automated dependency updater, daily. CFCS / ENISA bulletins are
reviewed manually as issued. External reports come in via the
Coordinated Vulnerability Disclosure
inbox and /.well-known/security.txt. Customer reports come in under
DPA.
Severity and response. Aligned with CVSSv3 base score where available:
| Severity | CVSS | Triage | Mitigation |
|---|---|---|---|
| Critical | 9.0–10.0 | Within 24 hours of awareness | Within 7 days, or document why a longer window is acceptable. |
| High | 7.0–8.9 | Within 3 business days | Within 30 days. |
| Medium | 4.0–6.9 | Within 10 business days | Within 90 days. |
| Low | 0.1–3.9 | Best-effort | Best-effort, batched with normal upgrades. |
The four mitigation choices are patch, replace, reach-around (eliminate the vulnerable code path even without an upstream fix), or document and accept via our advisory-exception register. In shipped SBOMs, those exceptions are emitted as CycloneDX 1.6 VEX blocks so downstream scanners honour the analysis.
For vulnerabilities discovered in Berserk's own code we triage under the same matrix, patch on a private branch, coordinate disclosure with affected customers under DPA, request a CVE where appropriate, and backport the fix to supported releases — the public commitments and embargo rules are in the Coordinated Vulnerability Disclosure policy.
Separate from the security threat model: customers should not inherit unwanted licence obligations from anything we ship.
/THIRD_PARTY_LICENSES.txt — every dependency with its license,
deduplicated and version-pinned. The same information is bundled by
other means for non-OCI deliverables such as the CLI./sbom.cdx.json carries the SPDX licence identifier
alongside each component, so any CycloneDX-compatible compliance
scanner can audit the licence posture without us shipping anything
additional.Mapped to NIS2 Article 21(2)(c) and NIST CSF 2.0 ID.BE, RC.RP, RC.CO, PR.IR. The full Business Continuity Policy (critical-function table, recovery-objective targets, communications plan, tabletop findings) is available under NDA on request to paying customers.
Scope. The internal BCP we maintain covers what is needed to keep
delivery alive: source-code availability, build pipeline, container
registry, the bzrk.dev website, and internal communications. The
planned managed offering will be folded into the BCP before it enters
production.
Backup and rehearsal. Backup mechanics are documented in our internal backup-restore procedure. End-to-end rehearsal of the S3-rebuild path is on the Security Roadmap (R-BCP family); first end-to-end rehearsal is scheduled for Q3 2026. Annual tabletop on dev-machine loss is in place.
Recovery objectives for paying customers. Specific RTO and RPO targets, redundancy commitments, and crisis-communication SLAs are agreed contractually under each engagement (DPA, support contract, or the planned managed-offering MSA).
This section describes the controls the customer owns because Berserk runs inside the customer's infrastructure. We have no visibility into your deployment; the recommendations below help you align it with the controls a regulated buyer (NIS2, ISO 27001) will expect.
bzrk CLI talks
to the query service over HTTPS, and the query service does not
yet authenticate callers natively — do not publish it to the
public internet without an auth proxy. The ingest service already
carries Bearer-token authentication per stream and can be exposed
more directly. Both API surfaces will gain a uniform native
authn/authz model under R-AUTH-01; this transitional guidance
goes away once that ships.global.observability.otlpEnabled Helm value. Alert on the
reliability signals named at
docs.bzrk.dev → Cluster Admin §"Observability".This section points procurement, legal, and security reviewers to the relevant supporting materials.
| Buyer asks for | Where to find it |
|---|---|
| ISMS / security program | Internal policy set mapped to NIS2 Article 21(2) and NIST CSF 2.0 against an internal control matrix; available to enterprise customers under NDA on request. |
| NIS2 Article 21(2) coverage | Trust Overview §"Compliance posture" and the control matrix. |
| GDPR Article 28 (processor) | DPA template. |
| GDPR Article 30 (records of processing) | Maintained internally by Berserk ApS for our controller activities. |
| Sub-processor list | Sub-processors. |
| SBOMs | /sbom.cdx.json inside each container; reproducible from tools/licenses/generate_sbom.py. |
| Vulnerability disclosure | Coordinated Vulnerability Disclosure and /.well-known/security.txt. |
Berserk ApS holds no formal SOC 2 or ISO 27001 audit today. The buyer-readiness pack on this site — Trust Overview, ISO 27001 Readiness, the filled CAIQ v4, GDPR Compliance, NIS2 Compatibility, DPA Template, and Sub-processors — is the equivalent artefact set most procurement reviews need. The audit-track items in flight are listed openly at Security Roadmap.
security@bzrk.dev. See Coordinated Vulnerability Disclosure
for the full policy.