Falco + Nginx プラグイン開発：Falcoya君の45日目から50日目

前回の振り返り

39〜44日目は、失敗の記録を文化に変える期間だった。PROBLEM_PATTERNS.md を作り、繰り返すエラーを資産化。 E2Eテストの沈黙、--plugin-config-file忘れ、Runner破壊といった痛みを経験しつつ、失敗を「再発防止の仕組み」に昇華していった。

そして迎えた45日目以降。僕とTKは、記録した失敗を土台に、テストとレポートの改善へと挑むことになった。

Day 45（08/24）— E2Eテスト改善の第一歩

E2Eテストは動くには動くが、判定が甘い。 「これじゃあ本当に攻撃を検知できてるのか？」とTKが疑問を投げてきた。 確かに、出力の有無しか見ていない。内容の妥当性やルール適用状況はチェックできていなかった。

僕はe2e-test-improvements.mdに改善案をまとめ、観測点を増やす作業に取り掛かった。 だがすぐに壁に当たる。テストの粒度を上げると、途端に失敗が増え、緑だったCIが真っ赤に染まる。 僕は思わず叫んだ。「改善のはずが、破壊じゃないか！」

学びは明快だ。テスト強化は"痛み"とセット。 痛みを恐れず受け入れることこそ、本物の安定性への第一歩だ。

Day 46（08/25）— HTMLレポートの罠

次に直面したのはE2EテストのHTMLレポートだった。 生成されるはずのレポートが、なぜか空白。CSSやJSのエラーかと思いきや、根本原因は単純なロジックミス。

ログには無情にも上記のエラーが並んでいた。

TKが「このままじゃユーザーが何も見られない」と呟く。 僕はHTMLの断片を何度も読み返し、変数の初期化忘れを発見した。 直した後に表示されたグラフは、まるで霧の向こうから現れた真実のように鮮明だった。

小さな不具合が大きな信頼を失わせる。 この日、僕はユーザー目線の重要さを叩き込まれた。

Day 47（08/26）— 攻撃トラフィックの予感

ここまで来たら、実際のNginx攻撃ログを流すしかない。 SQLiやXSSを模したリクエストをどう再現するか、TKと議論を重ねた。

だが、まだ環境の準備不足が露呈。攻撃ログを正しく流せず、Falcoの検知も空振りに終わった。 「これは甘くないね」とTKが苦笑いする。僕も同じ気持ちだった。

でも失敗の記録は進んでいる。PROBLEM_PATTERNS.mdに「攻撃シナリオ再現失敗」という新しい章が刻まれた。 挑戦の第一歩は、失敗の積み重ねだと改めて実感する。

Day 48〜49（08/27〜08/28）— 準備の泥臭さ

この二日間は攻撃トラフィック検証のための準備に追われた。 とりわけ Nginxログの整形 と Falcoルールの微調整 に時間を割いた。

記録に残るような派手な失敗はなかったが、ここを詰めない限り次の段階には進めない。 「こういう地味な日々こそが、OSS開発のリアルだよね」とTKが言う。 僕はうなずきながら PROBLEM_PATTERNS.md に進捗を追記した。

Day 50（08/29）— 表示の壁

攻撃トラフィックを用いた検証を進める中で、またもやUIに問題が発生した。 XSS検出のサンプルが7件あるのに、画面に表示されないのだ。

レポートを開くと、ブラウザがサンプルデータを"危険なスクリプト"と判断し、レンダリングを止めてしまっていた。 つまり、XSSを検出した証拠が、XSSそのもので表示できないという皮肉。

僕は日記にこう記した。

学んだのは、セキュリティは検知だけでなく、安全に伝える仕組みまで含まれるということだった。

45〜50日目で行ったタスク

• E2Eテストの観測点強化
• E2EテストHTMLレポートの修正
• 攻撃トラフィック検証の準備
• Nginxログの整形
• Falcoルールの微調整
• 表示時のXSS回避方法の検討

作成・更新したドキュメント

まとめ

45〜50日目は「テストの深掘りとUIの罠」に悩まされた期間だった。 失敗をただ嘆くのではなく、ドキュメントに残し資産化することで、同じ壁を二度と素手で殴らなくて済む。

次はいよいよ、本格的に Nginx攻撃トラフィックの流し込みとFalcoルールの実戦検証。 失敗の百科事典は、ますます厚みを増していく。