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.
Top comments (1)
Hi, I hope you are doing well. We are a software development team. We hunt for US jobs using Us job profile. So we are looking for a senior developer who can work with us.
Your role is to take part in the job interviews and pass the interviews. If your English is fluent, we can work together. If you are interested, please kindly send me message. I will explain more detail. Thank you!
Whatsapp: +1 (351) 234-6532
Telegram: @lionking06230810