Logging + telemetry governance

Cerbi scans logging before runtime, manages policy centrally, and enforces it either inside selected applications or at the OpenTelemetry boundary - without replacing Splunk, Datadog, Elastic, Azure Monitor, Sentinel, or your existing logging frameworks.

Scan a repositorySee Cerbi Gateway
Choose in-process or OTLP-boundary enforcement
Deploy CerbiShield and Gateway into your Azure tenant
Keep existing loggers, collectors, dashboards, and alerts
AI is optional; core enforcement is deterministic
92.8K+ NuGet downloads30 published packagesMicrosoft Marketplace

Cerbi governance lifecycle

One policy model across the telemetry path

01 - Scan

Discover before production

Source and CI scanning surfaces logging and policy issues.

02 - Govern

Define and target policy

CerbiShield manages profiles, validation, targets, deployment state, and evidence.

03A - Enforce

CerbiStream

Inside selected applications before the first network hop.

03B - Enforce

Cerbi Gateway

At the OTLP boundary for existing OpenTelemetry estates.

04 - Prove

Violations - evidence - audit - reporting - health

Choose the enforcement point

Govern in the application, at the OTLP boundary, or both.

Cerbi is not another observability backend. CerbiShield defines and distributes policy. CerbiStream can enforce it inside selected applications, while Cerbi Gateway can enforce it centrally for workloads that already emit OpenTelemetry.

Explore Cerbi GatewaySee the full architecture
Keep your existing logging and OpenTelemetry instrumentation
Keep Splunk, Datadog, Elastic, Azure Monitor, Sentinel, and other destinations
Run the control and enforcement plane inside your Azure tenant
Use AI only when you choose to; enforcement does not depend on it

Real Gateway UI

Follow the telemetry hookup.

CerbiShield Gateway governance traffic path release-preview capture
Real August release-preview traffic-path view. The preview was not connected to a live customer Azure workload; the hookup shown is the actual Gateway routing model.

Real product

See the control plane operate the governance lifecycle.

CerbiShield is more than a policy editor. The current cockpit brings posture, coverage, enforcement state, trends, workload risk, deployment activity, and readiness into one operating surface.

Hover, focus, or tap the numbered points to see what each part of the screen means.

Explore the Dashboard
CerbiShield governance cockpit release-preview screen
Real August release-preview capture. Preview data may be empty while customer Azure services are not connected.

The problem

Logs leak sensitive data before anyone notices.

Many enterprise logging pipelines rely on destination-side redaction — a filter that runs after telemetry has already crossed the trust boundary. Cerbi moves governance earlier, either inside selected applications or at the OTLP boundary.

Sensitive data leaks early

PII, tokens, secrets, and payloads enter telemetry before any downstream destination can protect them.

By the time a masking rule runs in Splunk or Datadog, the unsafe value may already be stored, indexed, and billed.

Masking later is too late

Once unsafe data reaches the destination, the risk, compliance exposure, and audit trail already exist.

Downstream filtering is a mitigation. Governance before destination storage moves the control earlier.

Log noise gets expensive

Verbose, inconsistent logging increases per-GB ingest cost and makes security investigations slower.

Earlier governance can reduce both risk and unnecessary ingest before telemetry reaches the sink.

Proof before access

See the finding before you install anything.

This is a sample from Cerbi's intentionally unsafe demo repository—not a staged dashboard and not customer data. Inspect the evidence, remediation, and optional build-gate behavior first.

Errorpassword

Forbidden secret field

UnsafeApi/Controllers/AuthController.cs:47

Structured field is forbidden by the active policy.

Fix: Remove the value; retain outcome and correlation context.

Would report
ErrorapiKey

API token may be logged

node-api/src/middleware/requestLogger.ts:32

Field matches the token rule through a configured alias.

Fix: Log token type and validation result, not the token.

Would report
WarninguserEmail

Email in structured field

python-api/app/orders.py:81

Field matches the email warning rule through an alias.

Fix: Prefer a non-sensitive reference or govern explicitly.

Would report

Selective adoption

Scan broadly. Govern selectively.

Cerbi does not need to run in every application or environment. Use the scanner for oversight, then add runtime governance only where findings and risk justify it.

Scanner only

Inventory risk without changing build behavior.

CI report-only

Publish findings for review while builds continue.

Optional policy gate

Fail only at the threshold your team selects.

Selected runtime governance

Add CerbiStream only to justified applications or environments.

Centralized governance

Use CerbiShield when shared policy and evidence are needed.

Don't take our word for it

Scan your own repo. Get a findings count in five minutes.

Cerbi Scanner performs read-only static analysis across C#, Go, Java, Node/TypeScript, and Python. Start in report-only mode to inventory risky log statements without changing build behavior. If your team chooses, the same free scanner can later apply an optional failure threshold in CI/CD.

Install once, scan anywhere

Marketplace extensionInstall once from the Marketplace, add the task to any pipeline YAML.
# Add via Azure DevOps Marketplace
# Search: Cerbi Scanner
# Task name: CerbiScannerTask@1

Report mode generates JSON, SARIF, and Markdown output without stopping anything. Use it for a first scan and demos.

mkdir -p scan-results
cerbi-scanner scan \
--path . \
--policy policies/cerbi-policy.yml \
--fail-on none \
--format json --output scan-results/findings.json \
--sarif scan-results/findings.sarif \
--summary scan-results/build-summary.md
ScansC#GoJavaNode/TypeScriptPython
Install the free Azure DevOps extension →

What the scanner finds

  • PII and secrets in log statements
  • Raw payload and object dumps
  • Unsafe structured fields
  • High-cardinality fields that inflate ingest cost
  • Read-only by default - never modifies your source
  • Outputs JSON, SARIF, and Markdown

Try it without installing anything

The demo repo ships intentionally unsafe logging in all five languages plus a working policy. Open it in Codespaces, run one scan, and read real findings in about five minutes.

Open in CodespacesView Demo Repo

GitHub account required. Codespaces usage may count against your GitHub quota.

Findings become governance evidence

JSON for automation, SARIF for GitHub code scanning, Markdown for build summaries. When findings matter across teams, CerbiShield adds centralized policy, scoring, audit history, and runtime enforcement.

See CerbiShield

The control Cerbi adds

Govern sensitive telemetry before the destination stores it.

Apply policy inside selected applications with CerbiStream or centrally at the OTLP boundary with Cerbi Gateway. In either model, existing observability destinations remain downstream.

Without a governance boundary

Raw values continue downstream

email="jane@company.com"PII
password="SuperSecret123"SECRET
token="abc123xyz"TOKEN
ip="192.168.1.42"IDENTIFIER

Splunk, Datadog, Elastic, Azure Monitor, or another destination receives and indexes the exposed values.

With Cerbi policy active

Governed values continue downstream

email="[REDACTED]"Removed
password="[BLOCKED]"Blocked
token="[REDACTED]"Removed
ip="[MASKED]"Masked
Policy version, service, environment, decision, and bounded evidence can be recorded in CerbiShield.

Choose in-process or centralized OTLP enforcement.

CerbiStream for selected apps · Gateway for existing OpenTelemetry estates

Compare the PathsRequest a Pilot

Where Cerbi fits

Scan broadly. Choose the right enforcement boundary.

Start with repository evidence. Govern inside selected applications, at a central OTLP boundary, or at both. CerbiShield controls policy and evidence across the platform.

ARCHITECTUREREV. 02

What this means

Route selected OpenTelemetry workloads through a tenant-hosted governance boundary while keeping existing SDKs and destinations.

No required progression
Cerbi ScannerRead-only assessment of repository logging patterns.
CI / pull requestOptional report or team-defined failure threshold.
CerbiStreamIn-process enforcement for selected applications.
Cerbi GatewayTenant-hosted OTLP governance boundary for existing estates.
CerbiShieldSigned policy, deployment, evidence, scoring, and audit.

Your existing destinations remain

Cerbi governs before logs reach them; it does not replace them.

SplunkDatadogAzure MonitorOpenTelemetryElasticSIEM / APM

Choose environments independently

Selection illustrates scope; it is not a required rollout order.

CerbiShield receives bounded governance evidence and operational metadata such as policy version, service, environment, decision, score, and remediation context. It is not a Cerbi-hosted raw-log relay.

Why Cerbi

Stronger protection. Consistent logs. Evidence you can prove.

One authoritative way to define and enforce application logging standards before unsafe telemetry reaches downstream systems.

Canonical control

One policy model

Canonical governance across frameworks and boundaries

Define logging policy once through an authoritative governance model. Scanners, in-process runtimes, Gateway enforcement, scoring services, and reporting tools consume versioned contracts instead of maintaining separate interpretations of the standard.

One governance model across supported runtimes, selected applications, and OpenTelemetry estates.

01

Stronger protection before the sink

Detect, block, sanitize, or flag sensitive fields at the enforcement boundary you choose: in-process with CerbiStream or centrally on selected OTLP traffic with Cerbi Gateway.

02

Consistent, higher-quality logs

Apply shared requirements for field names, schemas, severity levels, data types, required properties, and prohibited content so downstream systems receive telemetry they can search, correlate, and trust.

03

Compliance and audit readiness

Create versioned evidence showing which policies were active, what violations occurred, what was blocked or sanitized, and how governance behavior changed over time.

04

Adopt without replacing your stack

Start with Scanner, add CerbiStream only to selected applications, or route existing OTLP workloads through Gateway. Keep your current loggers, collectors, dashboards, alerts, and observability destinations.

Products

Find risk. Choose the enforcement boundary. Prove governance.

Cerbi is not an all-or-nothing replacement. Scan first, enforce inside selected applications or at a centralized OTLP boundary, and manage both through CerbiShield.

Free

Cerbi Scanner

Find exposure in minutes.

A local and CI scanner for finding unsafe logging patterns in source code. One command, no account, no code upload.

Scanner quickstart
Open source

CerbiStream

Govern inside selected apps.

In-process enforcement for applications that need the earliest possible validation, masking, redaction, or blocking before telemetry leaves the process.

Runtime overview
Preview

Cerbi Gateway

Govern OTLP centrally.

A tenant-hosted OpenTelemetry governance boundary for existing estates. Keep current SDKs and destinations while applying signed policy before the sink.

Explore Gateway
Azure

CerbiShield

Control policy and evidence.

A customer-hosted Azure governance control plane for policy authoring, signed deployment, violation scoring, findings review, audit history, and enterprise rollout.

View CerbiShield

Compatibility

Works with your existing logging stack.

Cerbi sits before your sinks, not instead of them. Alerting rules, dashboards, and retention policies remain unchanged.

Runtimes

GA support across five ecosystems

.NETJavaNode.jsGoPython

Logging frameworks

One governance model across all 12

MELSerilogNLogLog4j2LogbackWinstonPinoZapZerologslogPython loggingstructlog

Observability sinks

Governed data flows to your existing stack

SplunkDatadogAzure MonitorOpenTelemetrySIEM platformsElasticLokiSeqGrafana

Security & trust

Your governance plane stays in your infrastructure.

The scanner runs locally or in CI, CerbiStream runs in-process, and CerbiShield plus Gateway run in your Azure tenant. Cerbi does not operate a hosted raw-log relay.

Customer-hosted control planeCerbiShield and Cerbi Gateway deploy into the customer's Azure subscription. Cerbi does not operate a hosted raw-log relay between your workloads and observability destinations.
Path-specific enforcementCerbiStream enforces in-process for selected applications. Cerbi Gateway applies signed policy to selected OTLP traffic inside the customer tenant before governed telemetry continues downstream.
Signed, versioned policyCerbiShield manages policy state, targeting, validation, and signed runtime bundles so enforcement can be tied back to a specific version and deployment decision.
  • No source code upload required for the scanner
  • DPA available for controller/processor engagements
  • Subprocessors list maintained and publicly available
  • EU SCCs, UK IDTA, and Swiss SCCs supported
  • Azure Marketplace listing for procurement workflows
  • Security overview available in the Trust Center
Inspect sample findingsReview Scanner data flowTrust Center

Scanner, CerbiStream, and Gateway have distinct data flows. Review the path-specific trust boundary before choosing an enforcement model.

Start with one workload

Choose the governance boundary that fits your stack.

Use CerbiStream inside selected applications, Cerbi Gateway at the OTLP boundary, or both. Keep existing observability destinations while CerbiShield controls signed policy, rollout, evidence, and audit.

01

One non-production workload

02

Existing destination retained

03

Evidence before expansion

Request a PilotExplore GatewayRun the Free Scanner

Customer-hosted in Azure. AI is not required. No Cerbi-hosted raw-log relay.

[ cerbi ] · Choose the boundary

Choose where Cerbi governs telemetry.

Use CerbiStream inside selected applications, Cerbi Gateway at the OpenTelemetry boundary, or both. CerbiShield controls signed policy, rollout, evidence, and audit across either path.

Request a PilotRun the Free Scanner
One initial workload/Customer-hosted in Azure/No raw-log relay