Very true. It is a constant battle between debuggability and not leaking credentials.
In Erlang for example, when processes crash they dump their state, their neighbours, links to other processes, and other such useful stuff. That's very helpful, however it means it could dump credentials as well.
Luckily there a custom function to format the state of a process http://erlang.org/doc/man/gen_server.html#Module:format_stat... which helps with that. But have to implement that each process which holds credentials.
Also some of those log ingesting services provide a pre-indexer credentials filtering. I know Splunk has it:
http://docs.splunk.com/Documentation/Splunk/6.4.3/Data/Anony...
Of course it is better if it is filtered out before that. But it could be a safety net perhaps.
And there are so many ways of getting bitten.
Another anecdote for you:
I recently found out that an API wasn't logging errors anywhere.
Easy enough to fix, plug in a library and bam, everything is nicely logged to the database.
Including the HTTP headers.
Headers that include API auth tokens.
Ouch.
Is there any way you can take the opposite approach and whitelist stuff to include?
That way you don't have to worry about stuff sneaking in in the future.
(not that blacklisting has ever bitten me in the behind before, no siree...)
What to do when the company is ignorant and continues to use something as stupid as that?