Security and trust overview¶
This page describes how Logstrm is deployed, where customer data goes, and which security controls are implemented today. It is written for vendor risk assessments. It states current capabilities and current gaps; it does not claim certifications that Logstrm does not hold.
Deployment and control-plane model¶
Logstrm is customer-hosted software. There is no Logstrm-operated SaaS service, no multi-tenant control plane and no vendor-side data processing.
| Component | Runs where | Operated by |
|---|---|---|
| Data Plane | Customer infrastructure (VM, container, Kubernetes) | Customer |
| Manager (Control Plane, optional) | Customer infrastructure | Customer |
| Configuration storage | Customer-owned SQLite volume | Customer |
| Dead-letter queue and archives | Customer-owned storage | Customer |
| Container images | Customer pulls from the authorized registry | Customer |
Consequences for risk assessment:
- Logstrm operates no production system that processes customer telemetry.
- The product performs no license check, usage telemetry, activation call or other vendor callback. The only outbound connections a deployment makes are the ones the operator configures: event sources, emitter destinations, the Azure or OIDC identity endpoints required for authentication, and the container registry during image pull.
- Logstrm personnel have no standing access to customer environments, data or credentials. Support diagnostics are limited to what a customer chooses to export and share.
Data residency¶
Residency is determined entirely by the customer's deployment topology, because no data path crosses vendor infrastructure.
- Event payloads stay within the customer's network path between the configured source and the configured destination.
- Buffered data at rest (DLQ, JSONL archive) stays on the volume the operator attaches.
- Manager configuration history stays in the customer's SQLite volume.
- Cross-region movement can only occur if the operator configures a destination in another region.
Control status¶
The status column reflects what is implemented in the product, not what a hardened deployment achieves after the operator applies the controls in Production hardening.
| Control | Status |
|---|---|
| Secretless Azure authentication (Managed Identity) | Implemented, functionally validated |
| Secretless Azure authentication (AKS Workload Identity) | Implemented, functionally validated |
| Sentinel DCR least-privilege role scoping | Supported; operator-assigned |
| Manager OIDC authentication | Implemented |
| Manager role-based access control (Viewer/Operator/Admin) | Implemented |
| Configuration versioning, rollout and rollback | Implemented |
| Sensitive-field masking in the event pipeline | Implemented; operator-configured |
| Container image signing and SLSA provenance | Implemented (details) |
| Hardened container defaults (non-root, read-only root filesystem, dropped capabilities, seccomp) | Implemented as chart defaults |
| Kubernetes NetworkPolicy | Template provided, disabled by default |
| TLS termination for inbound listeners | Not implemented in-process; terminate at ingress or reverse proxy |
| TLS for the Syslog listener | Not implemented; TCP and UDP only |
| Application-level encryption of DLQ, archives and Manager database | Not implemented; use volume/disk encryption |
| Customer-managed keys (CMK) | No product-level key management; inherited from the customer's storage platform |
| Private connectivity to destinations | Deployment property, not a product feature; see Production hardening |
Detailed treatment: Data protection and encryption, Identity, credentials and secrets.
Compliance status¶
Logstrm states its compliance position directly rather than implying assurance it has not obtained.
| Item | Status |
|---|---|
| SOC 2 Type II report | Not held |
| ISO/IEC 27001 certification | Not held |
| Independent third-party penetration test report | Not yet commissioned |
| Public bug bounty programme | Not operated |
| Coordinated vulnerability disclosure policy | In effect (see below) |
| Automated dependency and code security scanning in CI | In effect |
| Signed release artifacts with build provenance | In effect |
Because Logstrm processes no customer data on vendor-operated systems, the assurance surface relevant to most vendor risk assessments is the software supply chain and the security properties of the software itself, rather than a hosted service environment. Assessors who mandate an independent SOC 2 or ISO 27001 report for a software vendor should treat that requirement as currently unmet.
Reporting a vulnerability¶
Report suspected vulnerabilities to security@logstrm.com.
- Include affected version or image digest, deployment context, reproduction steps and observed impact.
- Do not include customer data, live credentials or personal data in the report.
- Expect an acknowledgement of receipt, an assessment of validity and severity, and notification when a fix or mitigation is available.
- Please allow remediation before public disclosure, and do not test against systems you are not authorised to test.
Logstrm does not operate a paid bug bounty programme and does not offer monetary rewards.