DEV Community: Hello Cerbi

Cerbi Scanner: Find Risky Log Calls Before They Ship

Hello Cerbi — Wed, 03 Jun 2026 00:36:47 +0000

I’m building Cerbi Scanner because I think most teams have a blind spot in their DevSecOps process.

We scan dependencies.

We scan containers.

We scan secrets.

We scan infrastructure.

But we rarely scan the thing that quietly spreads operational, customer, and security data everywhere:

logger.info(...)
console.log(...)
LogInformation(...)
logger.error(...)

Logs start as debugging help.

Then they become searchable data.

Then they show up in dashboards, alerts, SIEM tools, storage accounts, incident exports, support screenshots, and audit trails.

By the time someone asks, “Why did we log that?”, the data has already moved.

Cerbi Scanner is meant to make that risk visible earlier.

Not after production.

Not after ingestion.

In the repo.

What Cerbi Scanner is

Cerbi Scanner is a repo-level logging governance scanner.

The goal is simple:

Show teams where risky logging behavior already exists.

It looks for patterns like:

requestBody near log calls
token near log calls
password near log calls
authorizationHeader near log calls
email or customer data near log calls
unstructured log messages
missing correlation fields
inconsistent event names
missing governance profiles

The first version is focused on visibility.

Not rewriting your code.

Not forcing a migration.

Not making every developer stop and attend a governance ceremony.

Just scan the repo and show the risk.

What it is not

Cerbi Scanner is not a replacement for Snyk, Trivy, GitHub Advanced Security, Sonar, or secret scanning.

Those tools matter.

They answer questions like:

Do we have vulnerable dependencies?
Did we commit a secret?
Is this container risky?
Does the code have known security issues?

Cerbi Scanner asks a different question:

Are we about to ship risky logging behavior?

That is a smaller question, but it matters.

Because a clean dependency scan does not mean your app is safe to log a request body.

A passing build does not mean your structured logs are actually structured.

A green dashboard does not mean the data feeding it is safe.

Why this matters

Most teams have logging standards.

Somewhere.

Maybe in Confluence.

Maybe in a platform guide.

Maybe in a security checklist.

The standards usually say things like:

Do not log secrets.
Do not log PII.
Use structured logging.
Include correlation IDs.
Use consistent event names.

All reasonable.

But standards are only useful if teams can see whether code is following them.

That is the gap.

A developer can search a repo for logger, token, password, or requestBody and often find suspicious patterns manually.

That is exactly why a scanner should exist.

If the risk is visible enough to find with search, it should be visible enough to report consistently.

The first win is seeing the risk

Cerbi Scanner is not meant to start with enforcement.

The first win is this:

Pick a repo. Run a scan. See where logging risk lives.

That alone is useful.

You can answer practical questions:

Which files have risky log calls?
Which services log request bodies?
Which logs are missing correlation IDs?
Which events are unstructured?
Which apps do not have a governance profile?
Which fields look sensitive near logging statements?

That changes the conversation.

Instead of saying:

“We should probably improve logging someday.”

You can say:

“This service has three high-risk logging findings, no governance profile, and inconsistent correlation fields.”

That is actionable.

CLI first

The CLI is the easiest way to try the idea.

The goal is a low-friction workflow:

dotnet tool install -g Cerbi.Scanner

Then scan a repo and review the report.

The scanner is intended to support outputs that fit real workflows:

JSON for automation
SARIF for code scanning workflows
HTML for human review

A useful finding should be easy to understand:

Finding: Possible token logged
File: AuthController.cs
Severity: High
Why it matters: Tokens should not be emitted into logs.
Suggested action: Remove the field, redact it, or govern it explicitly.

That is the type of output I want.

Not a wall of noise.

Not “everything is critical.”

Not a report that requires a security team to decode it.

Just clear logging risk.

Azure DevOps extension

The CLI is good when someone remembers to run it.

The Azure DevOps extension is for making the signal repeatable.

The idea is to add logging governance checks into the delivery path.

A pipeline already asks:

Does it build?
Do tests pass?
Did dependency scanning pass?
Did secret scanning pass?
Can this deploy?

Cerbi Scanner adds another question:

Are we shipping risky logging behavior?

The extension should support a gradual rollout.

Start in audit-only mode:

Show findings.
Do not fail the build.
Let teams learn where risk exists.

Then move toward enforcement when the rules are trusted:

failOnViolation: true

That matters because governance tools lose developer trust when they show up and immediately break everything.

The better path is:

Observe first.
Guide next.
Enforce when ready.

Where CerbiShield fits

Cerbi Scanner is the discovery step.

It helps answer:

Where is the logging risk?

The Cerbi governance packages help answer:

How do we enforce rules when the app emits logs?

CerbiShield helps answer:

How do we manage profiles, scoring, reporting, RBAC, deployment history, and audit evidence across teams?

That path is intentional.

I do not want Cerbi adoption to start with:

“Install the whole platform and change every logging workflow.”

I want it to start with:

“Scan one repo and see what your logs are doing.”

If the scanner finds nothing interesting, great.

If it finds risky fields, missing standards, or messy log shapes, also great.

Either way, the team stops guessing.

Why I am building this

I have seen the same pattern in enterprise systems too many times.

Logging standards exist.

Developers are expected to remember them.

Code review catches some issues.

Production catches the rest.

Then everyone acts surprised when sensitive fields or messy event shapes show up downstream.

Cerbi Scanner is meant to move that discovery earlier.

Before the log ships.

Before it spreads.

Before someone has to ask which system received the data.

Current direction

The scanner work is focused on:

CLI-based repo scanning
Azure DevOps pipeline integration
Readable risk reports
JSON, SARIF, and HTML output
Governance profile awareness
Multi-language scanning
Easy first-run experience

The goal is not to make logging governance feel heavy.

The goal is to make the risk obvious enough that teams can decide what to do next.

If this sounds useful

I am looking for feedback from people who have dealt with:

PII or secrets showing up in logs
Inconsistent event names
Missing correlation IDs
Unstructured logs everywhere
Observability bills inflated by noisy logs
Logging standards that exist but are not enforced

The question I care about most is simple:

Would you run a scanner against one repo just to see how risky your logging is?

That is the starting point.

Not a sales call.

Not a platform migration.

Just a scan.

Because bad logs are easiest to fix before they become production data.

Logs Are Not Breadcrumbs. They Are Evidence.

Hello Cerbi — Tue, 02 Jun 2026 02:10:17 +0000

I do not understand why we still log blindly.

We govern infrastructure.

We govern identity.

We govern CI/CD.

We govern vendors.

We govern production access.

Then we let applications spray passwords, access tokens, payment data, session cookies, API keys, chat transcripts, environment variables, and private signing keys into logs and diagnostic artifacts like those things are harmless.

They are not harmless.

They are evidence.

They are regulated data.

They are operational cost.

They are incident scope.

And too often, they are the part of the system nobody clearly owns until something breaks.

Then the room gets weird.

Was it the app team?

The Splunk team?

The Datadog team?

Security?

Platform?

The vendor?

Leadership?

The answer is probably yes.

That is the problem.

Logs are treated like developer exhaust until they become breach evidence.

By then, the data has already left the application.

The cost has already started.

The audit problem already exists.

The meeting is already on the calendar.

And someone is about to say:

We need better logging standards.

No kidding.

This is not an unknown problem

MITRE has an entire weakness for this: CWE-532, Insertion of Sensitive Information into Log File.

The description is brutally simple:

The product writes sensitive information to a log file.

MITRE also points out the obvious failure mode: logs often become a less-protected path for attackers to acquire application data. Its mitigations are not complicated. Do not write secrets to logs. Remove debug logs before production. Protect log files from unauthorized access. [1]

OWASP says the same thing in developer language. Its Logging Cheat Sheet says session IDs, access tokens, sensitive personal data, authentication passwords, database connection strings, encryption keys, and payment card data should usually not be recorded directly in logs. They should be removed, masked, sanitized, hashed, or encrypted. [2]

NIST has treated log management as an enterprise discipline for years. SP 800-92 frames log management as infrastructure, policy, process, roles, retention, analysis, and operational support. Not just "buy a SIEM and hope." [3]

So this is not a knowledge gap.

It is an ownership gap.

Everybody knows bad logs are dangerous.

Nobody wants to own preventing them before they leave the app.

The part that makes me mad

Most companies already know how to define ownership when they care.

Infrastructure has owners.

Cloud subscriptions have owners.

Applications have owners.

Databases have owners.

Service accounts have owners.

Pipelines have owners.

Production changes have owners.

But logs?

Logs get hand-waved into a shared platform, a SIEM, an observability vendor, or a lakehouse.

Then everyone acts shocked when those logs contain data that should never have existed there in the first place.

That is backwards.

The first logging governance question should not be:

Where do we send this?

It should be:

Should this be emitted at all?

That question belongs at the source.

Before the log leaves the application.

Before it hits Splunk.

Before it hits Datadog.

Before it hits Azure Monitor.

Before it hits Elastic.

Before it hits OpenTelemetry collectors.

Before it hits CloudWatch.

Before it becomes vendor data.

Before it becomes audit evidence.

Before it becomes legal discovery.

Before it becomes the thing everyone regrets.

A small tally of preventable pain

This is not every logging failure.

This is not a courtroom damages model.

This is a practical sample of public incidents and vulnerability patterns where uncontrolled logging, unsafe diagnostic capture, exposed log stores, or sensitive runtime metadata created avoidable risk.

The cost numbers are intentionally conservative.

Some are confirmed.

Some are estimates.

Some use IBM's average breach-cost reporting as a proxy because companies usually do not publish the full cleanup bill. IBM's 2025 Cost of a Data Breach report reports the global average breach cost at roughly $4.44 million. [4]

The point is not fake precision.

The point is the pattern.

#	Incident	What went wrong	What source-level governance could have changed	Conservative preventable-risk range
1	Twitter plaintext password logging, 2018	Twitter disclosed that a bug caused passwords to be written to an internal log before normal hashing protection. Users were told to change passwords. [5]	A static analyzer blocks password fields in log statements. Runtime redaction catches credential-shaped values before emission. A governed schema rejects raw password fields.	$100K to $1M
2	SHEIN / Zoetop payment-card logging and breach response, 2016 to 2018	Public reporting and the NY settlement describe a major breach and a $1.9M settlement tied to the company's response and security failures. The supplied research notes attribute part of the failure pattern to payment data in debug logs.	Disallowed fields for PAN/CVV. Runtime masking. PCI-oriented governance profiles. Build failure when payment fields are logged.	$1.9M confirmed settlement
3	Microsoft Storm-0558 signing-key crash dump, 2021 to 2023	A private signing key ended up in a crash dump, was moved into a debugging environment, and was later used by China-backed attackers to access email accounts across 25 organizations, including government agencies. [6]	Diagnostic dump scrubbing. Secret/key detection before dump export. High-sensitivity classification for crash artifacts. Restricted access and evidence retention for sensitive diagnostic data.	$4.44M to $25M+ proxy
4	DeepSeek exposed ClickHouse logs, 2025	Researchers found an open ClickHouse database with more than one million log lines, including chat history, API keys, system logs, and internal metadata. [7]	Do not log raw prompts or chats. Redact API keys. Classify prompt/user text as sensitive. Emit references or hashes instead of raw content.	$100K to $2M
5	Vercel third-party OAuth incident and environment-variable exposure, 2026	Vercel disclosed unauthorized access to internal systems. Reporting says variables not marked sensitive could decrypt to plaintext and customers were told to rotate credentials. A threat actor reportedly sought $2M for stolen data. [8]	Treat deployment variables as sensitive by default. Redact env vars in logs and metadata. Enforce secret classification before build/deploy events are emitted.	$2M to $5M
6	Post SMTP WordPress email log exposure, 2025	A vulnerability allowed low-privileged users to access full email logs. Those logs could contain password reset emails and enable account takeover. TechRadar reported roughly 160,000 sites still at risk at the time. [9]	Do not store full reset emails in readable logs. Redact reset links and tokens. Enforce RBAC on log access. Apply retention limits for sensitive operational logs.	$500K to $5M aggregate exposure risk
7	Public API credential exposure across web assets, 2026 research	Researchers scanning 10 million web pages found 1,748 distinct API credentials across nearly 10,000 pages. Most came from JavaScript environments, but the lesson is the same: secrets escape through developer artifacts when source controls are weak. [10]	Secret detection before emission, publish, or artifact creation. Runtime and build-time classification of tokens, keys, and credentials.	Not included in total because it is a research sample, not one breach

Conservative tally

Using only the six main cases above and excluding the broader API credential research sample:

Incident	Low estimate	High estimate
Twitter plaintext password logs	$100K	$1M
SHEIN / Zoetop	$1.9M	$1.9M
Microsoft Storm-0558 diagnostic-key failure	$4.44M	$25M+
DeepSeek exposed log database	$100K	$2M
Vercel environment-variable exposure	$2M	$5M
Post SMTP email-log exposure	$500K	$5M
Total	$9.04M	$39.9M+

That is the conservative range.

And honestly, it still undercounts the Microsoft case.

A nation-state email compromise involving a signing key does not fit cleanly into a spreadsheet. You can write "$4.44M proxy" if you want to keep the model tidy, but that is not reality.

That is accounting theater.

The actual blast radius includes federal email compromise, internal investigations, customer concern, product hardening, emergency response, security reform, executive distraction, and years of reputation debt.

So the real takeaway is not:

Cerbi would have saved exactly $39.9M.

The real takeaway is worse:

A handful of logging and diagnostic mistakes can create eight figures of preventable risk before anyone even notices.

Falsehoods engineers believe about logs

Internal logs are safe.

Debug logs never reach production.

The SIEM team owns logging risk.

If a field helps debugging, it belongs in the log.

We can redact it later.

Developers know what not to log.

Environment variables are safe unless someone marks them sensitive.

Session IDs are fine if they are only internal.

Crash dumps are just diagnostic data.

Email logs are harmless.

Prompt logs are not regulated data.

Logs are operational exhaust.

Logs are cheap.

Logs are someone else's problem.

All of these are wrong.

This is really about logging culture

The deeper problem is not that teams lack logging tools.

They have plenty.

Splunk.

Datadog.

Azure Monitor.

Elastic.

Grafana.

OpenTelemetry.

CloudWatch.

New Relic.

Seq.

Log analytics platforms are not the missing piece.

The missing piece is logging culture.

Most companies still treat logs as developer notes instead of enterprise evidence.

That creates a bad operating model.

Developers log whatever helps them debug.

Security reviews risk after the data already exists.

Observability teams inherit noisy, inconsistent, unsafe data.

Platform teams try to standardize after every app has already invented its own logging style.

Leadership sees the bill, the breach, or the audit gap only after the damage is done.

That is not a tooling gap.

That is a culture gap.

A better logging culture starts with different questions:

Should this field be logged?

Who owns this event?

What business process does it support?

Could this expose a customer, employee, credential, token, secret, or private key?

Is this useful evidence or just noise?

Would this log still be safe if it landed in the wrong place?

Can another team understand it without reading the source code?

Can security review the behavior before production?

Can architecture enforce the pattern without begging every team to read a wiki?

Those questions should not be optional.

They should be part of how software ships.

Culture alone does not scale

Here is the annoying truth.

A principal architect can write logging standards.

Security can publish guidance.

Platform teams can create templates.

Developers can attend training.

Everyone can nod in the meeting.

Then production breaks at 2 AM and someone logs the entire request object.

Not because they are reckless.

Because they are trying to fix production while people are asking whether we "have logs for that."

That is how bad logging happens.

One emergency.

One debug statement.

One copied pattern.

One "temporary" field.

One TODO that never gets removed.

One vendor sink that accepts anything.

One log pipeline that happily stores the evidence.

This is why logging culture needs guardrails.

Not to punish developers.

To protect them.

Good governance makes the safe path the easy path.

What source-level logging governance changes

Source-level governance moves the control point earlier.

It does not wait until the bad log is in the SIEM.

It does not wait until the data lake has copied it.

It does not wait until retention policies have preserved it for seven years.

It does not wait until legal asks what was exposed.

It checks before emission.

That means:

Static analyzers can catch unsafe logging during development.
Runtime governance can validate logs before they leave the process.
Disallowed fields can be blocked, masked, redacted, or tagged.
Required fields can make operational evidence consistent.
Sensitive data can be caught before it becomes vendor data.
Log ownership and policy metadata can travel with the event.
Audit rules can explain why a log was allowed, changed, or flagged.
Developers can follow rules without becoming compliance lawyers.

That last part matters.

Most developers are not trying to leak secrets.

They are trying to ship software.

A good logging governance system should help them do the right thing by default.

Where Cerbi fits

This is the problem I am working on with Cerbi.

Not another logging sink.

Not another dashboard.

Not another place to search bad logs after the damage is already done.

Cerbi is built around one simple idea:

Stop it at the source.

Before the log leaves the app.

Before it hits Splunk.

Before it hits Datadog.

Before it hits Azure Monitor.

Before it hits Elastic.

Before it hits OpenTelemetry.

Before it hits CloudWatch.

Before a secret becomes vendor data.

Before a debug field becomes breach evidence.

Before teams spend three weeks arguing over who owned the log.

The point is not to replace observability platforms.

Those tools have a job.

The point is to stop treating them as the first line of defense against bad application logging.

That is backwards.

Cerbi turns logging standards into executable controls:

Source-level rules.
Runtime redaction.
Static analysis.
Field governance.
Required and disallowed fields.
Ownership metadata.
Audit-ready evidence.
Safer defaults for developers.

This is not about telling teams to stop logging.

It is about helping teams log with ownership, structure, safety, and intent.

The culture shift I want

I want logging culture to change.

Not because logs are bad.

Because logs are powerful.

Good logs help teams debug faster.

Good logs support incident response.

Good logs create audit evidence.

Good logs help security understand behavior.

Good logs help leadership understand operational risk.

Bad logs do the opposite.

They leak data.

They increase cost.

They confuse incidents.

They create audit gaps.

They spread ownership across everyone and no one.

They turn observability into liability.

So yes, I am building Cerbi.

But the bigger goal is not another logging product.

The bigger goal is changing the default behavior.

Stop logging blindly.

Stop treating logs like exhaust.

Stop assuming the observability team owns whatever every app emits.

Stop waiting until the data lands downstream to decide whether it should have existed.

Logs are evidence.

Evidence needs ownership.

And ownership should start before the log leaves the app.

The line I keep coming back to

Evidence without governance is liability with timestamps.

That is what bad logging creates.

Liability with timestamps.

Searchable.

Retained.

Replicated.

Indexed.

Forwarded.

And very expensive to explain later.

Source notes

This article uses public reporting and security guidance. Some dollar amounts are confirmed. Some are conservative preventable-risk estimates because full incident costs are rarely public.

MITRE, CWE-532: Insertion of Sensitive Information into Log File

https://cwe.mitre.org/data/definitions/532.html
OWASP Logging Cheat Sheet

https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
NIST SP 800-92, Guide to Computer Security Log Management

https://csrc.nist.gov/pubs/sp/800/92/final
IBM, Cost of a Data Breach Report 2025

https://www.ibm.com/reports/data-breach
Time, Twitter advises users to change passwords after internal plaintext logging bug

https://time.com/5265244/twitter-all-users-change-passwords-leaving-unprotected/
Wired, The Comedy of Errors That Let China-Backed Hackers Steal Microsoft's Signing Key

https://www.wired.com/story/china-backed-hackers-steal-microsofts-signing-key-post-mortem
Reuters, Sensitive DeepSeek data exposed to web, cyber firm says

https://www.reuters.com/technology/artificial-intelligence/sensitive-deepseek-data-exposed-web-israeli-cyber-firm-says-2025-01-29/
Tom's Hardware, Vercel breached after employee grants AI tool unrestricted access to Google Workspace

https://www.tomshardware.com/tech-industry/cyber-security/vercel-breached-after-employee-grants-ai-tool-unrestricted-access-to-google-workspace
TechRadar, Post SMTP WordPress plugin flaw exposed email logs

https://www.techradar.com/pro/security/dangerous-wordpress-plugin-puts-over-160-000-sites-at-risk-heres-what-we-know
TechRadar coverage of research on exposed API credentials across 10 million web pages

https://www.techradar.com/pro/security/api-credentials-are-widely-and-publicly-exposed-on-the-web-experts-scour-10-million-web-pages-and-find-a-shocking-amount-of-security-info-just-lying-around

I don’t understand why we still log blindly.

Hello Cerbi — Mon, 01 Jun 2026 22:06:08 +0000

Most companies have standards for code reviews, cloud infrastructure, identity, CI/CD, access, endpoint security, vendor contracts, and production change control.

But logs?

A lot of teams still let every application emit whatever it wants, in whatever shape it wants, with whatever fields the developer happened to think were useful that day.

Then the logs get shipped to Splunk, Datadog, Azure Monitor, Elastic, OpenTelemetry collectors, or another platform.

And when something goes wrong, ownership gets fuzzy fast.

Was it the Splunk team’s problem?

The platform team’s?

Security’s?

The developers’?

The vendor’s?

Leadership’s?

The uncomfortable answer is probably: all of them.

Logging is not just an observability concern. It is a shared enterprise control.

Leadership owns the business requirement.

Security owns the risk model: what cannot be logged, what must be protected, what needs audit evidence, and what needs review.

Architecture and platform teams own the standards, reusable patterns, approved fields, deployment paths, and operational model.

Developers own the implementation, but they should not have to guess what “good logging” means for every app.

Observability teams own usability, routing, indexing, retention, dashboards, and incident workflows.

Vendors provide storage, search, alerting, analytics, and visualization. But they should not be the first line of defense against bad logging behavior.

By the time a bad log reaches the sink, the damage may already be done.

Sensitive data may have been emitted.

Noise may have entered the system.

Storage and indexing costs may have already been created.

Incident response may have become harder.

Audit evidence may already be inconsistent.

That feels backwards.

OWASP warns that logs may contain personal and sensitive information and says logging mechanisms and collected event data need protection from misuse, tampering, unauthorized access, modification, and deletion.¹ Splunk’s own logging best practices say not to log sensitive data or PII, including Social Security numbers and credit card numbers.² NIST treats log management as a combination of infrastructure and organizational process, not just centralized storage.³ OpenTelemetry has semantic conventions because consistent names and structures matter across codebases, libraries, and platforms.⁴ IBM’s 2025 breach report puts the global average cost of a data breach at about $4.4 million.⁵

So why do we still let logging quality, safety, ownership, and structure vary wildly from app to app?

My view:

Logging governance should start at the source.

Before the log leaves the application.

Before it hits Splunk, Datadog, Azure Monitor, Elastic, or any other sink.

Before teams are stuck arguing over who owns the mess.

This is the problem I’m working on with Cerbi.

Not replacing observability platforms.

Not telling teams to stop logging.

Just making logging safer, more consistent, and more accountable before the data leaves the app.

Because logs are not just developer breadcrumbs.

They are operational evidence.

And evidence needs ownership.

Evidence notes

This argument is supported by several practical industry sources:

OWASP Logging Cheat Sheet

OWASP notes that logs may contain personal and sensitive information, and that logging mechanisms and collected event data must be protected from misuse, tampering, unauthorized access, modification, and deletion.
Splunk Logging Best Practices

Splunk explicitly says not to log sensitive data or PII, including Social Security numbers and credit card numbers.
NIST SP 800-92, Guide to Computer Security Log Management

NIST frames log management as more than collecting logs. It involves infrastructure, policy, procedures, and operational process.
OpenTelemetry Semantic Conventions

OpenTelemetry defines common names for telemetry data so signals can be standardized across codebases, libraries, and platforms.
IBM Cost of a Data Breach Report 2025

IBM reports the global average cost of a data breach at about $4.4 million.
CISA Secure by Demand Guide

CISA encourages organizations to make security expectations part of software purchasing and vendor evaluation, which supports the broader ownership point: security and governance requirements should be explicit, not assumed later.

References

OWASP, “Logging Cheat Sheet.” https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html ↩
Splunk Developer Documentation, “Logging best practices.” https://dev.splunk.com/view/logging-best-practices/SP-CAAADP6 ↩
NIST, “SP 800-92, Guide to Computer Security Log Management.” https://csrc.nist.gov/pubs/sp/800/92/final ↩
OpenTelemetry, “Semantic Conventions.” https://opentelemetry.io/docs/concepts/semantic-conventions/ ↩
IBM, “Cost of a Data Breach Report 2025.” https://www.ibm.com/reports/data-breach ↩

Adding Log Governance to Serilog in .NET — Without Rewriting a Single Call Site

Hello Cerbi — Mon, 01 Jun 2026 14:02:07 +0000

Adding Log Governance to Serilog in .NET — Without Rewriting a Single Call Site

If you've shipped a .NET application in the last few years, there's a good chance Serilog is already in your stack. It's battle-tested, flexible, and the sink ecosystem is massive. But here's the thing nobody talks about: Serilog doesn't care what you log. It will happily ship a patient's SSN, a raw JWT, or a credit card number to Elasticsearch without blinking.

That's not a Serilog problem — it's a governance problem. And it's one I ran into repeatedly while working on distributed .NET systems before I built Cerbi.

The Gap Between "Structured Logging" and "Safe Logging"

Structured logging is great. You get queryable fields, consistent shapes, and tooling that actually works. But structure doesn't mean compliance. A perfectly structured log event can still contain PII that violates HIPAA or GDPR. The structure just makes it easier to find during an audit — which cuts both ways.

The industry response has been to bolt on post-collection filtering: Datadog has sensitive data scrubbing, Splunk has masking rules, Elastic has field-level security. These all work after the data has already left your application. If your pipeline has any delay, misconfiguration, or side-channel (a dev environment, a debug sink, a shared log file) — the data escaped.

Governance before emission is the only way to guarantee containment. That's the design principle behind CerbiStream.

CerbiStream + Serilog: How It Actually Works

CerbiStream ships a dedicated Serilog package: Cerbi.Serilog.Governance. It hooks into Serilog's enricher/sink pipeline and enforces your governance profile before any sink receives the event.

Install both packages:

dotnet add package CerbiStream
dotnet add package Cerbi.Serilog.Governance

Then wire it up in your Program.cs:

using CerbiStream.Governance;
using Cerbi.Serilog.Governance;

var governanceConfig = new GovernanceProfileBuilder()
    .EnforceRequiredFields("CorrelationId", "ServiceName", "Environment")
    .RedactFields("SSN", "CreditCardNumber", "PatientId", "AuthToken")
    .BlockIfMissing("CorrelationId")
    .Build();

Log.Logger = new LoggerConfiguration()
    .Enrich.WithCerbiGovernance(governanceConfig)   // <-- governance hook
    .WriteTo.Console(outputTemplate: "[{Timestamp:HH:mm:ss} {Level}] {Message:lj} {Properties}{NewLine}{Exception}")
    .WriteTo.Seq("http://localhost:5341")
    .CreateLogger();

builder.Host.UseSerilog();

That's the entire integration. No changes to existing Log.Information(...) calls anywhere in your codebase. The enricher intercepts every log event, runs the governance checks, redacts what needs redacting, and either passes the event downstream or blocks it — all in under a millisecond.

What "Governance Before Emission" Looks Like in Practice

Here's a realistic scenario. You have a service that logs user activity, and somewhere deep in a helper method, someone wrote this six months ago:

_logger.LogInformation("Processing request for user {UserId} with token {AuthToken}", userId, token);

Without governance, that AuthToken value goes straight into your log aggregator. With Cerbi.Serilog.Governance and RedactFields("AuthToken") configured, the emitted event looks like this:

{
  "UserId": "usr_8821",
  "AuthToken": "[REDACTED]",
  "CorrelationId": "f3a1c7b2-...",
  "ServiceName": "UserActivityService",
  "Environment": "production"
}

The field is still present (so your log schema doesn't break), but the value is gone before it hits any sink. No Elasticsearch index, no Seq stream, no debug console — nothing receives the raw token.

Schema Enforcement Alongside Redaction

The other half of the governance config is enforcement of required fields. This matters in microservices where teams are moving fast and log schemas drift over time. You add BlockIfMissing("CorrelationId") and suddenly every service that forgets to propagate the correlation ID will emit a governance violation instead of a silent gap in your trace.

You can configure this to either block the event entirely, emit a warning event with governance metadata, or — in development — throw an exception so the problem gets caught before it ever reaches staging. Configure the behavior per environment:

var governanceConfig = new GovernanceProfileBuilder()
    .EnforceRequiredFields("CorrelationId", "ServiceName")
    .RedactFields("SSN", "AuthToken", "CreditCardNumber")
    .OnViolation(isDevelopment 
        ? ViolationBehavior.ThrowException 
        : ViolationBehavior.EmitWarningAndProceed)
    .Build();

Using a Signature Pack Instead of Manual Config

If you're targeting a specific compliance standard (HIPAA, GDPR, PCI DSS, SOC 2, etc.), you don't have to enumerate fields manually. Cerbi ships pre-built Signature Packs that encode the relevant field patterns and rules:

dotnet add package Cerbi.Signatures.Hipaa
dotnet add package Cerbi.Signatures.Gdpr

var governanceConfig = new GovernanceProfileBuilder()
    .ApplySignaturePack(new HipaaSignaturePack())
    .ApplySignaturePack(new GdprSignaturePack())
    .Build();

The packs cover the field patterns, redaction rules, and required audit fields for each standard. You can stack multiple packs and add your own custom rules on top.

Overhead

CerbiStream adds less than 1ms per log event. I've run this under heavy load in ASP.NET Core services doing 10k+ requests/minute and the governance layer is invisible in profiling output. The enricher path is synchronous and allocation-minimal — no async overhead, no reflection per-event.

Try It

CerbiStream and all the governance packages are MIT-licensed and free forever. If you want centralized policy management, schema dashboards, and drift alerting across teams, that's CerbiShield — but the SDK works standalone without it.

📦 NuGet: dotnet add package CerbiStream / dotnet add package Cerbi.Serilog.Governance
🔗 GitHub: github.com/Zeroshi/CerbiStream
🌐 Docs & CerbiShield trial (14 days, no credit card): cerbi.io

If you're already on Serilog, this is a one-afternoon integration that closes a real compliance gap. Happy to answer questions in the comments.

— Thomas Nelson

We Keep Buying Better Observability Tools for Worse Logs

Hello Cerbi — Mon, 01 Jun 2026 13:34:06 +0000

Most teams do not have an observability problem.

They have a logging behavior problem.

That sounds like splitting hairs, but it is not.

An observability problem sounds like this:

“We need better dashboards.”

“We need better alerting.”

“We need better search.”

“We need better retention.”

“We need a better vendor.”

A logging behavior problem sounds like this:

“Why did someone log a token?”

“Why does every service use a different correlation field?”

“Why are half our logs unstructured strings?”

“Why are we paying to ingest data nobody can query?”

“Why did this debug log become permanent infrastructure?”

That second group is the one we avoid talking about.

Because it is not solved by buying another dashboard.

Bad logs are usually created by good developers

I do not think most bad logs come from careless developers.

They come from normal developers under pressure.

Production is broken.

The error is vague.

The customer is waiting.

The incident channel is getting louder.

Someone needs context fast.

So someone adds this:

_logger.LogInformation("User login failed: {@User}", user);

Or this:

console.log("payment request", requestBody);

Or this:

logger.info("Auth header: {}", authorizationHeader);

Nobody thinks they are creating risk.

They are trying to solve a problem.

That is what makes logging hard. The same instinct that helps debug production can also leak sensitive data, pollute dashboards, and create expensive garbage.

A wiki page is not a control

Most companies have logging standards.

Somewhere.

Maybe in Confluence.

Maybe in a platform engineering document.

Maybe in a security policy.

Maybe in a PDF last updated by someone who left three reorganizations ago.

The standards usually say reasonable things:

Use structured logging.
Include correlation IDs.
Do not log secrets.
Do not log PII.
Use standard severity levels.
Include service and environment metadata.

All good.

But here is the problem:

A document does not change behavior.

A tired developer at 2 AM is not going to stop and lovingly reread the logging policy.

They are going to log whatever helps them understand the issue.

That is not a character flaw. That is how real systems get operated.

So the question is not:

“Do we have logging standards?”

The better question is:

“Can developers accidentally bypass them?”

If the answer is yes, the standard is mostly a suggestion.

Dashboards cannot fix what the app already emitted

Observability tools are useful.

Search is useful.

Dashboards are useful.

Alerts are useful.

Retention policies are useful.

Pipelines are useful.

But most of those tools operate after the log already exists.

If the app emits a token, the token already moved.

If the app emits an email address, the email already moved.

If the app emits junk fields, your dashboard gets junk fields.

If every service names the same concept differently, your query layer becomes a crime scene.

{
  "correlationId": "abc-123"
}

{
  "corr_id": "abc-123"
}

{
  "trace": "abc-123"
}

{
  "requestThingy": "abc-123"
}

Congrats. You now have four standards.

Which is another way of saying you have zero standards.

We need to govern logs before they spread

I think logging needs to be treated more like an enterprise control.

Not in the annoying “please fill out this 47 step process before writing code” way.

I mean simple guardrails close to the developer workflow.

Things like:

{
  "requiredFields": [
    "correlationId",
    "eventName",
    "serviceName",
    "environment"
  ],
  "disallowedFields": [
    "password",
    "token",
    "ssn",
    "creditCardNumber",
    "authorizationHeader"
  ]
}

Now the policy is not just a paragraph.

It is something the system can check.

A log can be evaluated before it leaves the app.

A risky field can be blocked, redacted, warned on, or tagged.

A missing field can be detected.

A temporary exception can be tracked.

That last part matters.

Because enterprise systems need escape hatches. Sometimes teams need relaxed rules during a migration, rollout, or incident. Fine. But those exceptions should be visible.

Invisible exceptions become permanent architecture.

And permanent architecture is where temporary hacks go to buy furniture.

This is what I am building with Cerbi

This is the problem I am working on with Cerbi.

Cerbi is not meant to replace Serilog, NLog, Log4j, Logback, Pino, Winston, Zap, Datadog, Splunk, Application Insights, OpenSearch, or whatever else teams already use.

That would be a terrible sales pitch and an even worse migration plan.

The point is different:

Govern logs before they leave the application.

Cerbi’s tagline is simple:

We stop it at the source.

The idea is to put logging rules closer to where logs are created, not only after they land in a vendor.

What I think logging governance should include

The first piece is runtime governance.

Some logging behavior only exists when the app runs. Fields are dynamic. Context comes from middleware. Values come from requests. Static analysis can help, but it cannot see everything.

Runtime governance can tag violations like:

{
  "GovernanceProfileUsed": "payments-prod-v3",
  "GovernanceViolations": [
    "Missing required field: correlationId",
    "Disallowed field detected: token"
  ],
  "GovernanceRelaxed": false
}

Now governance becomes measurable.

You can see which apps follow the rules.

You can see which teams are drifting.

You can see which exceptions were allowed.

You can see which logs are safe enough to send downstream.

That is much better than hoping code review caught everything.

The next step is scanning repos

The next thing I want to push further is a repository scanner.

Because before you govern new logs, you probably need to know how bad the current state is.

A scanner could look for patterns like:

logger.info(user)
logger.error(requestBody)
console.log(token)
log.Debug("Customer data: " + customer)

It could also look for:

Unstructured log messages
Missing correlation IDs
Unsafe field names
Inconsistent event names
No governance profile attached
Sensitive data near log calls

That gives teams a simple starting question:

“What is our logging risk right now?”

Not in theory.

In the repo.

That matters for platform teams, security teams, architecture reviews, migrations, and audits.

AI can help, but it should not be in charge

I also think AI can help with logging governance.

But not as magic.

I do not want AI silently creating production policy like an intern with admin rights.

Useful AI assistance would look more like this:

Suggest required fields based on existing log patterns.
Detect fields that look sensitive.
Explain why a log violates policy.
Recommend safer structured log shapes.
Convert messy string logs into structured events.
Suggest starter governance profiles for a repo.

AI should recommend.

Humans should approve.

The system should enforce.

That is the boring version.

Which usually means it is the version that might actually survive contact with enterprise reality.

Multi-cloud makes this harder

Most teams do not send logs to one place anymore.

Some go to Azure.

Some go to AWS.

Some go to GCP.

Some go to a SIEM.

Some go to object storage.

Some go to a data platform.

Some go to an observability vendor.

That is normal now.

But logging rules should not disappear because the destination changed.

If a field is unsafe, it is unsafe before it reaches Azure.

If a field is required, it is required before it reaches AWS.

If a log is missing governance metadata, it is missing that metadata before it reaches GCP.

The destination should not define the discipline.

The application should emit governed logs from the start.

My question for other developers

This is the part I am genuinely curious about.

Do your teams actually enforce logging standards?

Not document them.

Enforce them.

Do you scan repos for unsafe logging?

Do you block or redact sensitive fields before logs leave the app?

Do you rely on code review?

Do you rely on your observability vendor?

Do you have a logging policy that everyone technically agrees with but nobody thinks about until something breaks?

I am building Cerbi because I think this is a real gap.

But I want to hear from people who have dealt with this in real systems.

Have logs ever saved you?

Have they ever lied to you?

And would you want logging governance in your developer workflow, or would it feel like one more enterprise control pretending to help?

Is Logging Governance Actually Needed?

Hello Cerbi — Mon, 01 Jun 2026 05:44:56 +0000

Most teams do not think about logging governance until something bad happens.

A customer ID gets logged in the wrong place.
A token shows up in a debug message.
A developer adds email, ssn, or authorizationHeader because they are trying to troubleshoot a production issue at 2 AM.
Six months later, nobody knows which apps log what, which teams follow standards, or whether the logs are safe to send into Splunk, Datadog, Application Insights, OpenSearch, or whatever else the company uses.

That is the problem Cerbi is trying to solve.

Cerbi is not another logging vendor.

It does not try to replace Serilog, NLog, Log4j, Logback, Pino, Winston, Zap, Application Insights, Splunk, or Datadog.

The goal is simpler:

Stop bad logs at the source before they become risk, cost, or garbage data.

The Problem With Logging Today

Most companies have logging standards.

Somewhere.

Usually in a wiki page.

Maybe in Confluence.

Maybe in a security policy nobody has read since 2021.

The policy usually says things like:

Do not log PII.
Do not log PHI.
Include correlation IDs.
Include timestamps.
Use structured logging.
Do not log secrets.
Follow severity standards.

All good ideas.

But here is the problem: a wiki page does not enforce anything.

Developers move fast. Production breaks. Teams are understaffed. Logs get added quickly. Logging libraries give you the power to write almost anything, but they usually do not know what your enterprise allows.

So the real question is not:

“Do we have logging standards?”

The real question is:

“Are those standards actually enforced before logs leave the application?”

For most teams, the answer is no.

Why Logging Governance Matters

Logs are not just text.

Logs can contain:

{ "userId": "12345", "email": "customer@example.com", "ssn": "123-45-6789", "token": "eyJhbGciOi...", "requestId": "abc-123", "severity": "Error", "message": "Payment failed" }

Some of that is useful.

Some of that is dangerous.

Some of it may be required for support, security, and analytics.

Some of it should never leave the app.

The hard part is that every organization has different rules. Healthcare, finance, SaaS, government, retail, and internal enterprise teams all care about different fields, different environments, different retention needs, and different audit requirements.

Logging governance matters because logs sit at the intersection of:

Security
Compliance
Observability
Developer experience
Cloud cost
Incident response
Audit evidence
Data quality

That is a weird intersection. It is also why the problem gets missed.

Security thinks observability owns it.
Observability thinks app teams own it.
App teams think platform owns it.
Platform thinks the logging vendor handles it.
The logging vendor says, “We ingest what you send us.”

And around we go.

What Cerbi Does

Cerbi adds a governance layer around logging.

Instead of only saying “developers should log this way,” Cerbi allows teams to define rules such as:

{ "requiredFields": ["correlationId", "traceId", "eventName"], "disallowedFields": ["password", "ssn", "creditCardNumber", "authorizationHeader"], "allowedTopics": ["Orders", "Payments", "Authentication"], "fieldSeverities": { "email": "Warning", "token": "Error" } }

Then those rules can be used before logs are emitted.

That means governance is not just documentation. It becomes part of the development flow.

Cerbi can help answer questions like:

Is this log missing required fields?
Is this app logging sensitive data?
Are teams using consistent event names?
Are severity levels being abused?
Are relaxed governance exceptions being tracked?
Which apps are following the logging rules?
Which teams are drifting from standards?
What evidence can we show during audit or review?

That is the real value.

Not prettier logs.

Governed logs.

What Makes Cerbi Different?

Most logging tools focus on capture, search, dashboards, alerting, or storage.

Cerbi focuses on what happens before the log reaches those tools.

That is the difference.

Cerbi is designed to sit closer to the application and developer workflow. The goal is to prevent bad logging behavior early instead of trying to detect it later after the data has already been shipped somewhere.

Source-Level Governance

Cerbi’s main idea is simple:

Govern logs where they are created.

Downstream detection is useful, but it is still downstream.

If a secret, token, or sensitive field already reached your observability platform, the blast radius already exists. You can mask it later. You can alert on it later. You can delete it later. But it already moved.

Cerbi’s approach is to stop or flag the issue before the log leaves the app.

That matters.

It Works With Existing Logging Tools

Cerbi is not trying to make every company rip out their current logging stack.

That would be silly. Also, good luck getting that approved by an architecture review board without someone aging five years in the meeting.

The better approach is to work with the tools teams already use.

Cerbi is being built around common logging ecosystems, including:

.NET logging
Serilog
NLog
Java Log4j2
Java Logback
Node Winston
Node Pino
Go Zap

The goal is not to replace the logger.

The goal is to add governance around the logger.

It Supports Runtime Governance

Static analysis is useful, but runtime behavior matters too.

Sometimes logs are built dynamically. Sometimes fields come from request context. Sometimes the actual data shape only exists at runtime.

Cerbi is designed to support runtime governance validation so logs can be checked against active governance profiles as they are emitted.

That allows teams to tag logs with metadata such as:

{ "GovernanceProfileUsed": "payments-prod-v3", "GovernanceViolations": ["Missing correlationId", "Disallowed field: token"], "GovernanceRelaxed": false }

This turns logging governance into something measurable.

You can report on it.
You can audit it.
You can improve it.

Relaxed Mode Is Tracked

Real enterprise systems need escape hatches.

Sometimes a team needs to temporarily relax governance during a migration, incident, or rollout.

The problem is when exceptions become invisible.

Cerbi supports the idea of relaxed logging, but the important part is that relaxed logs are still tagged.

That means teams can say:

“We allowed this exception, but we did not lose visibility.”

That is a much more realistic model than pretending every system can be perfectly governed on day one.

Governance Profiles Can Be Versioned and Deployed

Logging rules should not be random code scattered across every app.

Cerbi’s model is based on governance profiles that can be created, versioned, validated, deployed, and reviewed.

That matters for enterprise teams because standards change.

A rule that made sense last year may not make sense now. A new compliance concern may require a new disallowed field. A new platform standard may require a new correlation field. A new app team may need its own profile.

Governance should evolve without becoming tribal knowledge.

Current Roadmap

Cerbi is still early, but the roadmap is focused on making logging governance easier to adopt across real teams.

Repository Scanner

One planned area is a scanner that can inspect repositories and identify logging risk before runtime.

The scanner would look for things like:

Unsafe logging patterns
Missing required fields
Possible sensitive fields
Inconsistent event names
Unstructured log messages
Hardcoded secrets or risky values in log calls
Apps that do not have governance profiles attached

The idea is to let teams scan a repo and quickly understand:

“How bad is our logging posture right now?”

That could be useful during onboarding, audits, migrations, or security reviews.

It also gives teams a starting point. Instead of guessing which apps need cleanup, they can see the risk directly.

AI Assistance

Another roadmap item is AI-assisted governance.

Not “AI writes magic policies and everyone claps.”

That is not the goal.

A better use of AI is helping teams reason over logging patterns and suggest improvements.

For example:

Suggest required fields based on existing log patterns
Detect fields that look sensitive
Recommend governance profile changes
Explain why a log violates policy
Help convert messy logs into structured logs
Generate starter rules for a specific app or framework
Summarize governance drift across repositories

The important part is that AI should assist, not silently enforce.

For enterprise governance, humans still need approval. AI can help identify patterns, but admins should control what becomes policy.

Multiple Cloud Support

Cerbi is cloud-aware by design.

Logs do not live in one place anymore. Companies use Azure, AWS, GCP, hybrid networks, SaaS vendors, queues, blob storage, pipelines, and third-party observability tools.

The roadmap includes support across multiple cloud destinations and deployment models.

The goal is to let teams govern logs consistently regardless of where they eventually go.

That could include:

Azure-first deployment support
AWS support
GCP support
Queue-based routing
Blob or object storage targets
CI/CD integration
Client-hosted governance APIs
Dashboard-based policy deployment

The larger vision is simple:

Your logging rules should not disappear just because the destination changed.

Where Cerbi Fits

Cerbi is probably not needed for every small project.

If you have one app, two developers, no sensitive data, and simple console logs, Cerbi might be overkill.

But once you have multiple teams, multiple apps, multiple environments, and sensitive data, the problem changes.

At that point, logging becomes an enterprise control.

Not just a developer convenience.

Cerbi is aimed at teams that need to answer:

What are we logging?
Are we logging sensitive data?
Are logs consistent across teams?
Can we prove governance is being followed?
Can we stop bad logs before they hit vendors?
Can we reduce noisy or useless log ingestion?
Can developers still move fast without memorizing every policy?

That is where I think logging governance becomes necessary.

Why I’m Building It

I have worked around enterprise systems long enough to see the same pattern repeat.

Logging is treated as an implementation detail until it becomes a security, compliance, cost, or incident response problem.

Then everyone wants answers.

But by then the logs are already spread across systems. The standards are inconsistent. The data quality is questionable. And nobody is fully sure what every app is emitting.

Cerbi is my attempt to move that control earlier.

Before the sink.
Before the dashboard.
Before the audit panic.
Before the “why is there a token in Datadog?” meeting.

The Question

I think logging governance is needed.

But I am more interested in what other developers, architects, SREs, security engineers, and platform teams think.

Is logging governance a real problem in your environment?

Do your teams already enforce logging standards?

Are sensitive fields caught before logs are emitted, or only after they reach your logging vendor?

Would a repo scanner help?

Would AI-assisted policy suggestions be useful, or does that feel like one more noisy tool?

And most importantly:

Should logging governance live inside the developer workflow, or is downstream detection good enough?

I would genuinely like to hear how other teams handle this.

Because my suspicion is that a lot of companies have logging standards.

But far fewer have logging control.

Logging Governance in .NET: Enforcing Rules Before Your Logs Leave the Process

Hello Cerbi — Mon, 25 May 2026 22:10:15 +0000

I want to talk about a problem that I suspect is more common than teams admit: sensitive data leaking into logs.

Not because developers are careless. Because logging is ambient. You instrument something quickly, you log a request object for debugging, and somewhere in that object is a field you didn't mean to expose. It happens at 2am during an incident. It happens in a PR that got minimal review. It happens consistently, across every team I've talked to that handles sensitive data in .NET.

The standard answer is to handle it at the aggregation layer — write a Datadog pipeline rule, set up Splunk field extraction, redact in your SIEM. I understand why that's the default. It's centralized and doesn't require touching application code.

But it's too late.

By the time your log aggregator sees that event, it has already been serialized, handed off by your application, potentially written to a local file, shipped over the network to a collector. The data has left your process. Filtering it downstream doesn't undo the transit.

That's the problem I built Cerbi to solve.

The Core Idea: Intercept Before Emission

.NET logging frameworks — Serilog, NLog, Microsoft.Extensions.Logging — all have a pipeline. There's a point in that pipeline, before any sink or appender processes the event, where you can inspect and modify the log event. Cerbi sits at that point.

This means governance rules execute in-process, in memory, before the event goes anywhere. If a field needs to be masked, it's masked before serialization. If a required schema field is missing, the event can be flagged or blocked before emission. The enforcement is at the source.

Getting Started

Install the package for your logging framework:

# For Microsoft.Extensions.Logging
dotnet add package Cerbi.MicrosoftExtensions.Governance

# For Serilog
dotnet add package Cerbi.Serilog.Governance

# For NLog
dotnet add package Cerbi.NLog.Governance

For MEL (which is what most ASP.NET Core apps use by default), registration looks like this:

// Program.cs
builder.Services.AddLogging(logging =>
{
    logging.AddCerbiGovernance(options =>
    {
        options.MaskFields("email", "ssn", "creditCardNumber");
        options.EnforceSchema("OrderService", requiredFields: new[] { "orderId", "userId" });
        options.RouteByLevel(LogLevel.Critical, destination: "critical-alerts");
    });
});

That's it. You keep writing logs exactly as you do today. Cerbi intercepts them in the pipeline, applies the governance rules, and then lets them continue to your existing sinks.

No new logging framework. No changes to how your team instruments code. Just a governance layer on top of what you already have.

What Governance Actually Means Here

Three things right now:

PII Masking — You specify field names that should be masked. Cerbi finds them in structured log properties and replaces the value before emission. You can use built-in patterns (email, SSN, credit card) or define your own regex patterns for domain-specific sensitive fields.

Schema Enforcement — For structured logging to be useful at scale, log events need consistent fields. You can define required properties per service category, and Cerbi will flag or block events that don't meet the schema. This is especially useful in microservice environments where log consistency tends to decay over time.

Log Routing — Route log events to different destinations based on level, category, or custom predicates. Useful for separating audit logs from operational logs without plumbing that through your application logic.

Who This Is For

If you're building in a regulated environment — HIPAA for healthcare data, PCI DSS for payment data, SOC 2 for SaaS, GDPR for anything touching EU users — the "filter it later" approach puts you in a difficult position during an audit. You need to demonstrate that sensitive data wasn't logged, not just that you removed it from a dashboard.

Governance at the emission point gives you a defensible answer: the data never left the process in that form.

Where It Is Now

Cerbi launched about a week ago. The NuGet packages are live — Cerbi.Core, Cerbi.Serilog.Governance, Cerbi.MicrosoftExtensions.Governance, Cerbi.NLog.Governance. About 517 downloads so far, which is encouraging for week one.

It's early. I'm still working through edge cases in the field masking (deeply nested objects, arrays of sensitive items), and the schema enforcement API will evolve based on how teams actually use it. I'd rather ship something real and iterate with actual feedback than polish it alone.

Pricing is volume-based on log events per month. No per-seat fees — I think penalizing team growth is the wrong model for infrastructure tooling.

Try It

If you're working on a .NET project that handles sensitive data and you've been relying on downstream filtering, I'd genuinely encourage you to try Cerbi and see if the before-emission model fits your workflow better.

cerbi.io — GitHub: github.com/Cerbi-Dev

If you do try it, I'd love to hear what works, what doesn't, and what's missing. Drop a comment here or open an issue on GitHub.

Cerbi Update: Practical Logging Governance That Actually Runs in Your Tenant

Hello Cerbi — Wed, 14 Jan 2026 05:27:26 +0000

I’ve been heads-down building Cerbi, a logging governance layer for teams that are tired of discovering logging problems after production data is already on fire.

Cerbi isn’t a new log platform. It doesn’t replace Serilog, NLog, OpenTelemetry, or your existing sinks. It sits next to your logger and answers a very specific question:

“Are we logging the right things, the right way, without leaking data or creating chaos?”

What Cerbi Is (and isn’t)

Cerbi is a governance and enforcement layer for structured logging.

It gives you:

Compile-time validation (Roslyn analyzers)
Runtime validation (non-blocking, tag-and-score)
Centralized governance rules (JSON, versioned, deployable)
Per-tenant deployment (your infra, your data, your control)

It does not:

Proxy or ingest your logs
Phone home from the hot path
Charge per GB
Require replacing your existing logging stack

If your logs already go to queues, files, or sinks, Cerbi stays out of the way.

What’s working today

This isn’t a roadmap post — this is what exists and runs:

CerbiStream

Structured logging with built-in governance hooks
Async logging with backpressure handling
File fallback (including encrypted rotation)
Zero network dependency in the hot path

Governance Analyzer (compile-time)

Enforces required fields, forbidden fields, enums, encryption rules
Works in IDE + CI
Same JSON schema used everywhere (no drift)

Runtime Governance

Mirrors analyzer rules at runtime
Never drops logs
Redacts sensitive values and tags violations instead
Supports Relax() scopes (explicit, auditable rule bypass)

CerbiShield (Dashboard + APIs)

JSON governance profiles with versioning
RBAC, audit logs, and deployment history
Per-tenant deployment (Azure Container Apps right now)
Governance rules deploy to GitHub, filesystem, pipelines, etc.

Everything runs in the customer’s tenant. The only thing hosted centrally (later) is optional scoring and analytics.

Why I built this

Every enterprise team I’ve worked with eventually hits the same problems:

Logging standards exist… somewhere
Nobody enforces them consistently
PII sneaks into logs anyway
Cleanup happens after incidents
Governance lives in Confluence instead of code

Cerbi treats logging rules like code:

Defined once
Versioned
Validated early
Enforced continuously

No policy theater.

Current status

Core runtime + analyzers: stable
Dashboard + APIs: feature-complete for Phase 1
Marketplace prep: in progress
Multi-language logger plugins (Node / Python / Java / Go): next

CerbiStream and the analyzers are free. CerbiShield (the governance control plane) is the licensed piece.

If this sounds useful

I’m actively looking for:

Teams who care about logging quality and compliance
People who want to try governance without ripping out their stack
Feedback from folks who’ve been burned by log sprawl before

Docs and repos are public, and I’m sharing progress openly as this hardens.

Logging shouldn’t be exciting — but broken logging is always exciting in the worst possible way. Cerbi is about making the boring parts correct, predictable, and enforced.

More updates soon.

Logging Governance (2025-11-07)

Hello Cerbi — Sat, 08 Nov 2025 04:59:02 +0000

When dashboards break because fields renamed or types shift, pain spikes for everyone. Cerbi’s stable field names and types keep visualizations reliable sprint after sprint, saving time and keeping insights steady—even during hectic releases. www.cerbi.io