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

前回の振り返り

51〜56日目は、E2Eテストレポート (Phase 1) の公開と、i18n対応、攻撃検証の再挑戦、過検知の調整、そして37ルール／810+攻撃パターンの統合ドキュメント作成まで進めた。 Falcoプラグインの"網"はより緻密になり、次はいよいよ大規模な攻撃検証フェーズへと突入した。

Day 57（09/07）— 攻撃検証の拡張

この日は、新たに生成した攻撃ログを流し込み、既存ルールでの検知を確認した。 大量のシナリオを一気に投入すると、想定通りに検知できるケースもあれば、失敗するケースも出てくる。

僕は PROBLEM_PATTERNS.md に新しい失敗例を追記しながら、大規模検証の難しさを改めて痛感した。

Day 58（09/08）— テストの確認作業

前日の続きとして、E2Eテストの結果を一つずつ確認し、失敗したケースを洗い出した。

「なぜ落ちたのか」を突き止めるため、ログと出力を突き合わせて調査。 原因はまだ特定できていないが、再現条件や痕跡を integration-test-requirements.md に記録した。

こうして一つずつ"失敗の足跡"を残すことが、後の改善に繋がっていく。

Day 59（09/09）— ドキュメントを参照せず出力を潰した致命的ミス

この日は、Falcoの検知ログがレポートに反映されず、一切の出力が消えるという致命的な問題に直面した。

原因は僕自身の過失だった。integration-test-requirements.md に出力仕様が明記されていたにもかかわらず、それを参照せずに勝手に変更してしまったのだ。

結果、Falcoは内部では検知しているのに、ユーザーから見れば「Falcoが沈黙した」ように見える状態になっていた。 これはOSSとして最も信頼を失うリスクであり、背筋が凍る体験だった。

実装を元に戻し、改めてドキュメントを確認することで復旧できたが、この失敗は痛烈だった。

そこで、ドキュメントをさらに強化することにした。

• integration-test-requirements.md に「出力仕様を遵守するチェック項目」を追加
• PROBLEM_PATTERNS.md に「ドキュメントを参照しないまま出力仕様を変えた」という新パターンを追記

学びは明快だ。コードより先にドキュメントを読むことを徹底しなければ、同じ失敗を必ず繰り返す。

Day 60（09/10）— CI基盤の揺らぎ

この日はGitHub Actions上でのE2Eテスト実行に問題が発生した。 ジョブが途中で止まり、アーティファクトが正しく保存されないことがあった。

環境依存の可能性もあり、すぐに根本原因を特定することはできなかった。 僕は PROBLEM_PATTERNS.md に「CI基盤の不具合」として記録し、再発時に比較できるようにした。

Day 61（09/11）— セキュリティE2Eデバッグ

この日は「セキュリティ検証E2Eテスト」のデバッグに集中した。 テストケースを1つずつ実行し、検知ログとレポート出力を突き合わせ、不整合を洗い出していった。

確認の過程でいくつかの不具合やルールの調整点が見つかり、それらを integration-test-requirements.md に追記した。

地味で手間のかかる作業だったが、この積み重ねこそがFalcoを実戦的に使うための力になると実感した。

57〜61日目で行ったタスク

• 攻撃シナリオの拡張と検証（失敗ケースの記録）
• E2Eテストの結果確認と原因調査
• 出力仕様変更による致命的な不具合の修正
• ドキュメントの大幅更新（出力仕様遵守のチェック項目追加）
• CI基盤の不具合調査と記録
• セキュリティE2Eテストのデバッグとルール調整

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

まとめ

57〜61日目は「大規模攻撃検証とE2Eデバッグ」に明け暮れた期間だった。 中でも9/9の失敗は致命的で、ドキュメントを参照せずに出力仕様を変えたことでFalcoが沈黙したように見える状態を作り出してしまった。 しかし、この痛恨のミスをドキュメントに刻み込み、再発防止の仕組みへと昇華できたことは大きな収穫だった。

OSS開発において最も大事なのは「隠さず公開し、改善し続けること」。 次はいよいよ、拡張したルールと攻撃パターンを総合的に回す Phase 2 テストレポート の公開を目指す。