I don’t understand why we still log blindly.

#security #programming #codequality #tooling

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.