CERBI PRODUCT WALKTHROUGH - FULL NARRATION SCRIPT
Recommended length: 5-6 minutes
Steps: 10

=== STEP 1: THE PROBLEM ===
Every team needs logs to debug production systems. The problem is not the logging.
The problem is that logs carry sensitive fields by accident - and those fields spread.

A developer logs a payment event with full context. CardNumber ends up in Application Insights.
Support copies it to a Jira ticket. Security finds it three months later.

=== STEP 2: KEEP YOUR LOGGER ===
Cerbi does not replace Serilog, NLog, MEL, Pino, Winston, Log4j2, or Logback. It wraps them.
Your log calls stay exactly as they are.
No migration. No new log destinations. No infrastructure changes.

=== STEP 3: INSTALL ===
One NuGet package. Two lines of setup. Cerbi wraps the existing logger and applies the governance profile at runtime.

=== STEP 4: GOVERNANCE PROFILE ===
A governance profile is a JSON config checked in with your service.
It defines required fields, disallowed fields, and enforcement mode.
One profile per service. Teams own their profiles.

=== STEP 5: UNSAFE LOG ===
The developer is not doing anything unusual. Structured logging is the right approach.
But cardNumber is in the disallowed list - Cerbi will catch it before it leaves the app.

=== STEP 6: ENFORCEMENT ===
The governance check happens inside the process. No network hop. No agent.
The log is inspected, the risky field is redacted, and the governed event is forwarded to downstream tools.

=== STEP 7: DASHBOARD ===
Engineering, security, and platform teams see the same data - violations, redactions, governance scores,
and affected services. All in one place.

=== STEP 8: DEVELOPER FIX ===
Cerbi provides the field name, rule, severity, profile, and suggested remediation.
Security teams do not need to file vague tickets. Developers can act immediately.

=== STEP 9: ROLLOUT MODEL ===
Start in relaxed mode to build visibility without blocking teams.
Violations are recorded but not blocking. Move to strict when the team has fixed the top violations.
One config change.

=== STEP 10: CTA ===
Keep your logger. Add runtime logging governance.

cerbi.io

We talk a lot about security in code. But logs are where sensitive data often hides.

cardNumber ends up in Application Insights.
password ends up in Datadog.
authToken ends up in a Jira ticket.

Not because developers are careless. Because structured logging makes it easy to log full context
- and easy to accidentally log too much.

Cerbi is a runtime governance layer for structured logs. It checks the log event against a policy before it leaves the app.

Keep Serilog. Keep NLog. Add one package. Add two lines.

Worth a look: cerbi.io

We built Cerbi to solve a problem most teams have but few prioritize until it is too late.

Logs carry sensitive fields. Those fields spread to observability tools, support tickets, incident records, and dev workflows.

By the time someone notices, the data has already moved.

Cerbi enforces policy at the source - before the log leaves the app. Not after it lands in Datadog.

Try the demo: cerbi.io/demo

# Why Your Structured Logs Are a Security Risk (And What to Do About It)

You added Serilog three years ago. Your logs are structured, correlated, and flowing into Application Insights.

The problem? You are also logging cardNumber, password, authorizationHeader, and ssn
- not because you meant to, but because structured logging makes it easy to log full context.

Here is how Cerbi fixes that without making you replace anything.

# Runtime Logging Governance for .NET - Without Replacing Serilog

Most log governance advice is "don't log sensitive data." That is great advice. It is also not enforced anywhere.

Cerbi adds a runtime policy layer between your existing logger and your downstream observability tools.
One NuGet package. One JSON config file. No migration.

Here is what it looks like in practice.

RECORDING CHECKLIST - CERBI DEMO VIDEOS

BEFORE YOU RECORD
[ ] Open the walkthrough route directly - no query params needed
[ ] Set viewport to 1920x1080 or 1280x720
[ ] Hide bookmarks bar, extensions, and notifications
[ ] Close all other tabs
[ ] Set browser zoom to 100%
[ ] Test keyboard navigation: Arrow Right or Space = Next, Arrow Left = Back

DURING RECORDING
[ ] Pause on each step for at least 5 seconds
[ ] Use Arrow Right to advance steps
[ ] Do not scroll within steps (each step fits in viewport)
[ ] Record at 1x speed - do not speed up

AFTER RECORDING
[ ] Trim intro/outro silence
[ ] Add narration from voiceover scripts (or record live)
[ ] Add subtitles/captions for accessibility
[ ] Export at 1080p minimum

QUERY PARAMS REFERENCE
?step=N   - Start at step N (zero-indexed). Useful for recording specific steps.
(default) - No query params needed. Walkthrough pages are always clean for recording.

WALKTHROUGH ROUTES
/demo/walkthrough/log-redaction        - 7 steps, 3-4 min
/demo/walkthrough/developer-install    - 6 steps, 3-4 min
/demo/walkthrough/governance-dashboard - 6 steps, 3-4 min
/demo/walkthrough/relax-to-strict      - 6 steps, 3-4 min
/demo/walkthrough/full-product-demo    - 10 steps, 5-6 min

Cerbi checks structured log events against a governance profile at runtime
- before they reach Application Insights, Datadog, or any other downstream tool.

In this demo:
- Why normal structured logging can leak sensitive fields
- How a governance profile defines what a service can log
- How Cerbi redacts risky fields at the source
- What the dashboard shows after enforcement

No logger replacement needed. One package. Two lines of setup.

Try the demo: https://cerbi.io/demo
Documentation: https://docs.cerbi.io

#logging #dotnet #devops #security #observability

Cerbi wraps your existing logger. You keep Serilog, NLog, or MEL.
You add one NuGet package and a governance profile.

In this demo:
- Existing Serilog / NLog / MEL setup
- Install CerbiStream
- Add governance profile
- Keep all log calls unchanged
- Governed output flowing to existing destinations

Try the demo: https://cerbi.io/demo
Documentation: https://docs.cerbi.io

#serilog #nlog #dotnet #logging #security