Free scanner - one command, no account

Most codebases log more than anyone realizes - PII, secrets, API keys, payload dumps. By the time a masking rule runs in Splunk, Datadog, or your SIEM, that data is already stored, indexed, and billed. Run one free command against your repo and get the number. Then fix it at the source.

Supports:.NETJavaGoPythonNode.js
Open in Codespaces Run locallyView demo repoWatch demo

No Azure required. No code upload. GitHub account required for Codespaces. Usage may count against your GitHub quota.

Local scanner

No account. No code upload. No Azure required.

Runtime governance

Block, mask, relax, or audit risky logs before they flow downstream.

Customer-hosted

Deploy through Azure Marketplace into the customer's own Azure tenant.

ExploreFree trialUse casesCerbiShieldPricingArchitecture
91.7K+NuGet downloads
30packages
<1msoverhead
alwaysgoverned at source
New Gateway previewFor existing OpenTelemetry estates

You do not have to install a new logger in every application.

Cerbi Gateway gives platform teams a centralized OTLP governance boundary. Route selected workloads through it, apply signed policy before the sink, and keep the observability stack already in place.

See Cerbi GatewayRequest a preview
Keep existing OpenTelemetry SDKs
Keep Splunk, Datadog, Elastic, Azure Monitor, and Sentinel
Apply signed policy inside the customer Azure tenant
Start with one non-production workload

Applications and services

Existing OTLP/HTTP or OTLP/gRPC clients

Cerbi Gateway

Verify policy · govern telemetry · forward

Your observability destinations

Existing dashboards, alerts, and retention remain

The problem

Logs leak sensitive data before anyone notices.

Most enterprise logging pipelines rely on downstream redaction — a filter that runs after the data has already been stored, indexed, and billed. The exposure happens at the source.

Sensitive data leaks early

PII, tokens, secrets, and payloads enter logs before any downstream tool can filter them.

By the time a masking rule runs in Splunk or Datadog, the unsafe log is already stored, indexed, and billed.

Masking later is too late

Once unsafe data reaches your log pipeline, the risk, compliance exposure, and audit trail already exist.

Downstream filtering is a mitigation. Source-side governance is a fix.

Log noise gets expensive

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

Governance at the source reduces both risk and ingest volume simultaneously.

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

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

One canonical governance model. Consistent enforcement across .NET, Java, Node.js, Go, and Python applications.

01

Stronger protection at the source

Detect, block, sanitize, or flag sensitive fields before logs leave the application. Reduce the chance that credentials, personal information, and restricted payloads are copied into downstream systems.

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

Easy to adopt

After CerbiStream is installed and configured, developers do not need to rewrite every logging call. Existing structured logging patterns continue to work while governance is enforced before logs leave the application.

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
Enterprise

CerbiShield

Control policy and evidence.

An Azure-hosted 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 data stays in your infrastructure.

Governance metadata, violation evidence, and scoring stay inside your infrastructure. Cerbi does not receive raw sensitive values.

In-tenant deploymentCerbiShield deploys into the customer's Azure subscription via Azure Marketplace. No Cerbi data plane sits between your logs and the governance control plane.
No raw data leaves the processCerbiStream enforces governance in-process. Violation evidence and scoring metadata are emitted. Raw sensitive values are blocked or redacted before any network call.
Policy-as-codeGovernance rules live in version control alongside your application code. They are reviewed in pull requests, tested in CI, and deployed with your normal release process.
  • 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 assessment and optional runtime governance have distinct data flows. Review the path-specific details before choosing either.

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