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

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.

80.9K+NuGet downloads
30packages
<1msoverhead
alwaysgoverned at source

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.

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

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.

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

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.

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

Bad logs start in code

Bad logs start in code. Cerbi governs them there.

Most tools clean logs after they already exist. Cerbi applies policy while the log event is being created - redacting sensitive fields, tagging violations, and keeping existing sinks working.

Without Cerbi
01event="UserLoginFailed" email="jane@company.com"
02password="SuperSecret123" token="abc123xyz"
03ip="192.168.1.42" userId="usr_8472hx"
04level="ERROR" service="auth-api" ts="2025-01-14T09:41:02Z"
05// No governance record. Data is in Splunk, Datadog, and every sink.

All sensitive fields forwarded to Splunk, Datadog, and every downstream sink.

With Cerbi
01event="UserLoginFailed" email="jane@company.com"
02password="SuperSecret123" token="jane@company.com"
03ip="192.168.1.42" userId="jane@company.com"
04level="ERROR" service="auth-api" ts="2025-01-14T09:41:02Z"
05GovernanceViolations=["SensitiveField:email","SensitiveField:password","SensitiveField:token","SensitiveField:ip"]

Sensitive fields governed at emission. Violations recorded. Nothing sensitive leaves the process.

Govern logging behavior before bad logs are created.

14-day free trial · No credit card · One-line setup

Scan broadly. Govern selectively.

Start with repository evidence. Add CI controls, runtime enforcement, or centralized governance only where each is useful.

ARCHITECTUREREV. 01

What this means

Install CerbiStream only in applications that need in-process redaction and enforcement.

No required progression
Cerbi ScannerRead-only static assessment of repository logging patterns.
CI / pull requestOptional report or team-defined failure threshold.
CerbiStreamIn-process enforcement for selected applications.
CerbiShieldPolicy and evidence in your Azure tenant.

Your existing destinations remain

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

SplunkDatadogAzure MonitorOpenTelemetrySIEM / APM

Choose environments independently

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

CerbiShield receives governance metadata, violation evidence, scoring, profile version, service name, environment, and remediation context. Raw sensitive values are redacted or blocked in-process.

Start free. Scale when you need to.

Every path starts with the free scanner. Most teams adopt runtime governance next. The control plane completes the enterprise story.

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

Enforce governance at runtime.

A runtime governance layer that enforces logging rules before events are emitted — blocking, redacting, or flagging at the point of emission.

Runtime overview
Enterprise

CerbiShield

Control plane for the whole org.

An Azure-hosted governance console for policy management, violation scoring, findings review, and enterprise-wide rollout. Deploys into your tenant.

View CerbiShield

Works with your existing logging stack.

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

Languages

CerbiStream SDK available for each

.NETJavaNode.jsGoPython

Logging frameworks

No instrumentation rewrite required

SerilogNLogMELLog4j2LogbackWinstonPinoZapstructlog

Observability sinks

Governed data flows to your existing stack

SplunkDatadogAzure MonitorOpenTelemetrySIEM platformsElasticLokiSeqGrafana

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

Scanner assessment and optional runtime governance have distinct data flows. Review the path-specific details before choosing either.

Get started

Govern logs before the next bad one ships.

Pick one application. Add Cerbi, apply a governance profile, and see what changes before data reaches your observability stack.

14-day free trial. No credit card required. One-line setup.

[ cerbi ] · Start now

One NuGet package. No pipeline changes. Policy-as-code governance that runs in-process before sensitive data ever reaches Splunk, Datadog, or Azure Monitor.

14-day free trial/No credit card/Works with Serilog · NLog · MEL