Operational security

Secrets do not belong in build logs

A secret leak is not always a dramatic breach. Sometimes it is one helpful debug line in CI, copied into a ticket, indexed forever.

~5 minSecurity
scroll
01 · the leak

Logs are where secrets go to become public-ish

Build logs travel. They show up in CI, chat, screenshots, support tickets, artifacts, and observability tools. If a token lands there once, your cleanup job is now bigger than the original bug.

ci · bad debug

The leak is often accidental and very readable.

controls quiet

Security gets real when the trust boundaries light up. Poke it and see what has to hold.

02 · the rule

Config belongs in the environment, not the repo

The old rule still holds up: keep config that varies by deploy in the environment. Source code should name the secret it needs, not carry the secret itself. That makes rotation, review, and access control possible.

env.ts

Fail loudly on missing config. Never print the value.

03 · the controls

Masking helps, but rotation is the fix

CI masking is a guardrail, not a guarantee. Tools can detect common tokens, but they cannot understand every homegrown credential or every place a value gets transformed. If a secret may have leaked, revoke it, rotate it, and audit use.

security control lab
exposed
hardened0
exposed: the feature trusts too much and records too little

Flip the switches and watch the story turn into a tiny operating model.

0steps after exposure: revoke, rotate, audit
0source of truth for secret ownership
0secrets intentionally printed in logs
04 · the culture

Make the safe path boring

The durable fix is not yelling "be careful" in every PR. It is secret scanning, locked-down CI variables, short-lived credentials, clear runbooks, and tests that fail when code tries to log sensitive values.

source trail