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.
