Enterprise Trust & Security

Security claims should be verifiable, not decorative.

Log Intelligence is designed for private incident investigation in customer-controlled infrastructure. This page separates implemented controls, release-verification workflow and customer responsibilities so security teams can review the product without relying on unsupported certification claims.

Current product release
v2.27.5
Published on Docker Hub
Evidence location
Customer environment
Air-gap model
Enterprise supported

Implemented buyer-review controls

A practical enterprise trust package around the forensic workflow.

These controls are designed to answer the questions security, platform and procurement teams usually ask before a pilot or production deployment.

Private evidence boundary

Incident evidence is analysed inside the customer-managed Docker deployment. CloudBridgeIT licensing does not require uploaded incident logs, and Enterprise can operate with an air-gapped activation workflow.

Enterprise identity boundary

Enterprise supports SAML/OIDC-backed sign-in through a customer-controlled identity-aware reverse proxy. Trusted identity headers are accepted only when proxy trust and the shared proxy secret are explicitly configured.

Tamper-evident audit evidence

New audit events are SHA-256 hash chained. Authenticated administrators can validate chain integrity and export audit evidence as JSON or CSV for review.

Immutable RCA decision record

The Decision & Approval Ledger preserves each RCA conclusion, evidence snapshot, rejected hypotheses, reasoning, approvals and corrective actions as a new SHA-256 chained version. Signed .li-case exports cover the complete ledger.

Release supply-chain controls

The production publication workflow builds multi-architecture images, generates OCI SBOM and provenance attestations, gates HIGH/CRITICAL vulnerabilities with Trivy, and signs pushed digests using Sigstore Cosign.

Hardened container runtime

Recommended Compose deployment uses a non-root runtime, no-new-privileges, dropped Linux capabilities, a read-only root filesystem, temporary /tmp storage and a PID limit.

Procurement documentation

Security architecture, data-flow, reverse-proxy SSO, customer deployment and support/SLA guidance are maintained with the Docker release so technical and procurement reviews use the same operating model.

Identity & access

Keep authentication at your enterprise boundary.

The Enterprise SSO design does not embed a second identity platform inside the incident product. A customer identity-aware proxy terminates SAML or OIDC, enforces the organisation's IdP policy, and forwards trusted identity only across an explicitly configured application boundary.

Trusted-header SSO is disabled by default.
A configured proxy secret is required before identity headers are accepted.
Allowed email domains, auto-provisioning, default roles and administrator-group mapping can be controlled.
Named-seat enforcement remains part of the application entitlement model.
The customer's proxy and IdP configuration must be validated in the target environment.
Enterprise SSO boundary
1
Enterprise IdP
SAML / OIDC policy, MFA and conditional access
2
Identity-aware proxy
Authenticates the user and injects trusted identity headers
3
Log Intelligence
Validates proxy trust, secret, domain, seat and application role
4
Private investigation
User enters the evidence workspace without exposing incident data to CloudBridgeIT
Audit assurance

Export evidence that can be reviewed outside the application.

New audit events are chained with SHA-256 hashes so administrators can test whether the recorded sequence remains intact. Authenticated JSON and CSV exports provide a portable review trail for internal assurance, customer review or audit preparation.

Hash chaining is a tamper-evidence mechanism. It is not presented as a substitute for an external immutable archive, SIEM retention policy or independent compliance certification.
Pilot value proof

Measure the investigation, not a marketing estimate.

Pilot outcome snapshots capture measurable investigation outputs that can be compared with the organisation's normal incident-review baseline. This avoids inventing universal time or cost savings.

Evidence sources included
Events correlated across the incident window
Competing hypotheses tested
Evidence gaps identified
RCA confidence and supporting evidence
Elapsed investigation time

Release assurance

The pipeline can produce assurance artefacts. The registry digest still has to prove them.

The production publishing workflow is configured for SBOM, provenance, vulnerability policy and image signing. A source package or local build is not labelled as registry-verified merely because that workflow exists.

SBOM

OCI software bill of materials generated during production publication.

Provenance

Maximum-level build provenance attached to the published image.

Vulnerability gate

Trivy policy blocks publication on HIGH/CRITICAL findings under the configured release policy.

Cosign

The pushed digest is signed keylessly through Sigstore OIDC in the production workflow.

Verification boundary

Before production procurement, verify the actual published registry digest, signature and attestations. This site does not mark an image as signed or scanned merely from source-package metadata.

Shared responsibility

What the customer still controls.

Enterprise readiness also depends on the environment in which Log Intelligence runs. Production review should include network segmentation, TLS termination, backup and recovery for the persistent data volume, identity-provider policy, connector credentials, registry verification and retention requirements.

No unsupported claims
No certification is claimed unless independently obtained.
SLA commitments are contractual, not inferred from the product UI.
Customer IdP/proxy interoperability must be tested in the customer's environment.
Published image assurance is verified against the registry digest, not a source archive.

Bring security and operations into the pilot from day one.

Review the data boundary, identity model, audit evidence, deployment controls and measurable pilot outcomes before expanding beyond the first investigation team.

We use cookies

We use cookies to improve your experience, analyze site traffic, and personalize content. By continuing, you agree to our use of cookies.