Hello Cerbi

Posted on Jun 2

Logs Are Not Breadcrumbs. They Are Evidence.

#logging #cybersecurity #devsecops #observability

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.