A surprising share of critical findings are not clever exploits — they are shortcuts the developer left in and thousands of users never changed.

Static secrets scale the attack for you

When a project ships a hardcoded session-signing key in its default docker-compose.yaml, every default install shares it. That is what we found in Dify: combine the static SECRET_KEY with a default Postgres password, read the admin's id from the database, and forge a valid admin session token with a few lines of Python — authentication bypassed entirely. Full write-up: Dify auth bypass.

The key point we argued to the maintainers: this is not "a secret leaked in a repo." It is an insecure default (CWE-1188). The software never forces a unique key at setup, so it leaves everyone vulnerable by design.

Example code becomes production code

Developers copy examples. So when an SDK example logs a wallet master seed and API secrets in plaintext, ships a pa$$w0rd default, and includes a validator that approves every signing request, those become real production risks. See the Lightning-SDK secret-exposure write-up.

What to do

• Generate unique secrets on first boot; refuse to start with the documented default.
• Never log secret values — redact and log only a byte count.
• Require passwords via environment; fail closed when they are missing.
• Keep "approve everything" test validators out of production paths.

Boring, yes. But boring defaults are what keep attackers out.