Free · read-only · no accountCerbi Scanner 1.1.0

Find risky loggingbefore it ships.

Scan source on infrastructure you already control. Cerbi Scanner finds sensitive fields, credential-like logging, unsafe structured fields, high-cardinality fields, debug/dynamic logging, and exception or object-state exposure without changing runtime behavior.

Run in GitHub Actions Scanner quickstart

GitHub + Azure DevOps MarketplacesLocal CLI · .NET 10 LTSJSON · SARIF · Markdown

Interactive proof

Select a case

Source

logger.LogInformation("User {Email}", email)

Scanner decision

Finding

user.emailFinding

Potential email address written to application logs

Proof before access

See what Scanner reports before you install it.

The sample below is taken from the checked-in Scanner 1.1.0 output in Cerbi's intentionally unsafe public demo repository. It is demo data, not customer telemetry.

Verified sample findings

From cerbi-log-risk-demo/examples/findings.json

Scanner 1.1.0

CERBI003Highpassword

Structured log field is not allowed

src/dotnet/UnsafeApi/Program.cs:20

Fix: Remove the password field from the log call or apply an approved redaction path.

CERBI001Highemail

Sensitive data in log

src/dotnet/UnsafeApi/Program.cs:20

Fix: Review whether email is required; mask, hash, or omit it when it is not needed for diagnostics.

CERBI004WarningsessionId

High-cardinality logging field

src/dotnet/UnsafeApi/Program.cs:24

Fix: Keep sessionId out of indexed dimensions unless it is explicitly required for correlation.

Verify the data flow

Local CLI, GitHub Actions, and Azure DevOps

Local Scanner

Read-only static analysis; source files are not modified.
No Cerbi account or Azure deployment is required.
No Scanner telemetry or analytics sink is enabled.
JSON, SARIF, Markdown, HTML, and console output stay local unless you move or publish them.
CerbiShield upload is opt-in, never the default scan path.

GitHub Marketplace Action

Runs on the GitHub Actions runner in your repository workflow.
Uses the same Cerbi Scanner engine as the local CLI.
Source snippets and CerbiShield upload are disabled by default.
SARIF goes to GitHub Code Scanning only when explicitly enabled.
Report-only mode is the default before any build gate is enabled.

Azure DevOps extension

Runs on your existing Azure DevOps build agent.
Uses the same Cerbi Scanner engine as the local CLI.
Source snippets are disabled by default in shared pipeline artifacts.
CerbiShield upload is disabled by default.
Report-only mode can be adopted before any build gate is enabled.

GitHub Marketplace Azure DevOps Data handling

Choose how to run Scanner

GitHub Marketplace, Azure DevOps Marketplace, or local CLI. Same Scanner engine.

GitHub teams can add Zeroshi/cerbi-scanner-action@v1 directly from GitHub Marketplace. Azure DevOps teams can add CerbiScan@1 from Visual Studio Marketplace, and local users can install the .NET 10 CLI. All three paths use the same Scanner findings and policy model.

Using GitHub Actions?

Available in GitHub Marketplace

Add the published Cerbi Scanner Action to an existing workflow. It sets up the supported runtime, runs Scanner on the GitHub-hosted runner, generates JSON/SARIF/Markdown reports, and does not upload source code or findings to Cerbi by default.

Open GitHub Marketplace

Choose your distribution

GitHub Marketplace, Azure DevOps Marketplace, or local CLI.

GitHub Marketplace · Action v1

Use the published GitHub Marketplace Action. It sets up .NET 10, runs Cerbi Scanner 1.1.0 by default, generates CI-friendly reports, and keeps Cerbi upload opt-in.

- uses: actions/checkout@v7

- name: Cerbi logging governance scan
  uses: Zeroshi/cerbi-scanner-action@v1

View Cerbi Scanner in GitHub Marketplace

Generate review artifacts without failing the build because findings exist. This is the recommended first scan.

mkdir -p scan-results
cerbi-scanner scan \
  --path . \
  --fail-on none \
  --format json --output scan-results/findings.json \
  --sarif scan-results/findings.sarif \
  --summary scan-results/build-summary.md

What the current rules cover

Sensitive data in log messages or structured fields
Passwords, API keys, JWTs, connection strings, and other credential-like data
Structured fields disallowed by policy
High-cardinality fields that can increase observability cost
Debug, trace, or dynamically constructed logging in production-sensitive paths
Exception logging or object destructuring that may expose object state

Supported languages

C#GoJavaNode/TypeScriptPython

No policy file yet? That is fine.

Scanner can run with built-in defaults. Add cerbi-policy.yml later when you want explicit rule enablement, severity overrides, allowed/disallowed fields, or organization-specific sensitive-field patterns.

Full quickstart Policy & configuration

Detection coverage

What the current scanner finds.

Cerbi Scanner analyzes logging call sites statically. It does not instrument the application or inspect production telemetry at runtime.

Sensitive and credential-like data

CERBI001 · CERBI002

Sensitive field names plus password, token, API key, JWT, connection-string, and other credential-like logging paths.

Structured-field policy

POLICY FIELDS

Fields that violate an explicit allow-list or disallow-list in the active Cerbi policy.

Required-field gaps

REQUIRED FIELDS

Required governance fields that cannot be found or verified at a logging call site, including lower-confidence findings for dynamic templates.

High-cardinality fields

CARDINALITY

Structured fields likely to create unbounded cardinality and unnecessary observability ingest or indexing cost.

Debug, dynamic, and payload logging

DYNAMIC · PAYLOAD

Debug/trace paths, dynamically constructed templates, raw body or payload logging, and serialized logging patterns that are harder to govern safely.

Object-state exposure and bypasses

OBJECT STATE · RELAXATION

Risky object destructuring, exception-state exposure, and explicit governance-relaxation patterns that deserve review.

SCANNERStatic analysis

Cerbi Scanner analyzing source code and surfacing logging governance findings.

Static analysis → Runtime governance

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 Paths Request a Pilot

Scanner first. Runtime governance next.

Phase 1

Cerbi Scanner

Free - no account

Scan code

One CLI command

Find risky log calls

Detects sensitive fields

Generate report

Violation evidence

Phase 2

CerbiStream + CerbiShield

Paid - your Azure tenant

Add governance policy

cerbi.json rules

Enforce before emission

CerbiStream intercepts

Send governance evidence

CerbiShield dashboard

The scanner is free and proves the risk in your own repos - no account, no code upload. CerbiShield is what you deploy when the findings report lands in a security review and someone asks: “How do we keep this fixed?” Runtime governance enforces the same policy in-process, so sensitive fields never reach Splunk, Datadog, Azure Monitor, ELK, or any other sink again.

Scope

What Cerbi is not.

Clarity on scope is part of a credible product. Cerbi does one thing well: governs logging behavior at the source.

Not a SIEM

Cerbi does not collect, correlate, or alert on security events. It governs what is written to logs at the source. Your SIEM receives cleaner, more consistent data as a result.

Not a log storage platform

Cerbi has no log storage. Your existing destinations (Splunk, Datadog, Azure Monitor, Elastic, Seq) remain unchanged. Cerbi sits before them, not instead of them.

Not a replacement for your observability stack

Cerbi does not replace Datadog, New Relic, Grafana, or any observability vendor. It makes the data those platforms receive more accurate, consistent, and policy-compliant.

Not a log router or transport layer

Cerbi does not proxy or relay log traffic. There are no additional network hops on the hot path. CerbiStream is in-process; CerbiShield is async and out of band.

What it is

A runtime SDK that governs log events before emission
A governance control plane for policy management and audit
A source-side filter that reduces ingestion noise and cost
A compliance tool that enforces schema at the point of creation

Runtime governance is optional—and can stay selective.

Keep Scanner as a standalone assessment or CI control. If selected applications need continuous enforcement, CerbiStream governs logs in-process and CerbiShield adds centralized policy and evidence from inside your Azure tenant.

See optional CerbiShield details