Cerbi Scanner 1.1.0 - free, read-only, no account

Inspect the proof. Then scan on infrastructure you already control.

Preview a real demo report before granting access or installing anything. Enterprise teams can run the free Azure DevOps extension on an existing build agent; individual evaluators can use Codespaces or the local .NET tool. Every path starts in report-only mode.

Install the free Azure DevOps extension Open the Codespaces demo View sample findings

Inspect the demo repositoryStart report-only. Add policy gates only when your team is ready.

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 Codespaces View 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

Detection coverage

What the scanner finds.

Cerbi Scanner analyzes log call sites statically - no instrumentation, no runtime hooks. It surfaces patterns that developers miss during code review and that ingest-time masking never catches.

Sensitive fields

PII · PHI · CREDENTIALS

Passwords, tokens, SSNs, credit cards, PHI, PII, and other fields that should not land in logs.

Raw body or payload logging

RAW PAYLOADS

Request bodies, response bodies, webhook payloads, and serialized objects that may contain hidden sensitive data.

Risky object destructuring

OBJECT DUMPS

Patterns like {@user}, full DTO dumps, and object serialization that expose more than the developer intended.

Missing required fields

SCHEMA GAPS

Logs missing required governance fields such as service, environment, tenant, correlation ID, or event name.

Disallowed fields

POLICY VIOLATIONS

Fields explicitly banned by policy because they create security, privacy, compliance, or cost risk.

Dynamic templates and serialized logging

DYNAMIC PATTERNS

Logging patterns that make governance harder because the structure is unstable or hidden until runtime.

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

Watch the Demo Start Free Trial

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

Inspect the proof. Then scan on infrastructure you already control.

See the finding before you install anything.

Scan broadly. Govern selectively.

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

Install once, scan anywhere

What the scanner finds

Try it without installing anything

What the scanner finds.

Sensitive fields

Raw body or payload logging

Risky object destructuring

Missing required fields

Disallowed fields

Dynamic templates and serialized logging

Bad logs start in code. Cerbi governs them there.

Scanner first. Runtime governance next.

What Cerbi is not.

Runtime governance is optional—and can stay selective.

Govern logging before it leaves your application.