まずは双方の言い分を書いてみましょう。ただし、私は双方の当事者ではないので、想像による「言い分」です。
まず、「ログファイルに書き込む前に絶対に手を加えるな」ですが、これはログの目的から考えるとわかりやすいです。ログの目的は、「なにかあったときに、ログから原因や影響範囲を特定するため」です。ログの内容に手が加えられていると、原因分析等に妨げになります。したがって、ログをとる以上は、「ありのまま」で取る必要があります。
ただし、一つだけ例外があります。それは、ログ中にパスワードやクレジットカード番号等の機微な情報を保存していると、ログからの情報漏えいになります。このため、これらはログには保存しないか、クレジットカード番号などは一部のみを保存する(マスク表示といいます)ことが行われます。
一方、「セキュリティ上問題がある」という言い分は、おそらくLog4j2の脆弱性などを元にしているのだと思います。この脆弱性はログの内容に特定文字列を入れておくと、外部からコード実行ができてしまうという恐ろしいものです。仮にログに書き込む前に、ログのデータをサニタイズする、たとえばログ中の文字列から英数字のみを取り出して保存すれば、この脆弱性の影響は受けません。
以上が私の想像に基づく「双方の言い分」です。
しかしながら、ログに書き込む際に英数字のみを取り出すと、どんな問題があったかどうかわかりません。たとえば、外部からSQLインジェクション攻撃があり、その内容が「item=';delete from users --&range=15」だったとすると、ログに書き込まれる内容は「itemdeletefromusersrange15」となり、これでは解析ができません。「deletefrom」があるこらSQLインジェクションっぽいことがわかるのではという疑問に対しては、「item=';delete/* Hello world */from users --&range=15」とMySQL形式のコメントを使うと、ログの文字列は「itemdeleteHelloworldfromusersrange15」とますますわけがわからなくなります。
であれば、Log4j2の脆弱性に使われる記号文字、$ や { を除去する(これをサニタイズと言いますが)アイデアが浮かびますが、それはLog4j2の脆弱性情報を予め知っていないとできないのでナンセンスです。
すなわち、ログ出力ライブラリの要件として、「すべての文字列をありのままに出力できる」というものがあり、それを満たさないソフトは欠陥品なのです。誰もそんな問題があるとは思っていなかったので、Log4jの脆弱性の影響が大きいわけです。
また、Log4jの教訓により、「やはりログ出力の前にサニタイズしよう」とはなっていません。前述のとおり、それではログの意味がないからです。一方、「ログ出力に色々な便利な機能をつけるのは危険だ、シンプルであるべきだ」という意見はよく見かけます。私もその意見に同意です。
なので、まとめると、
- ログファイルに書き込む前に絶対に手を加えるな、という意見は正しい
- ログデータをサニタイズすると、ログの要件を満たさなくなるので、サニタイズはすべきでない
- Log4j2の脆弱性問題からの教訓としては、ログ出力ライブラリ選定の際に、シンプルであること、余計な機能を有効にしていないことの確認が求められる
ということだと思います。