Falco + Nginx プラグイン開発：Falcoya君の51日目から56日目
〜 テストレポート公開、UI修正と国際化、そして攻撃検証の再挑戦 〜
前回の振り返り
45〜50日目は、E2Eテスト強化とHTMLレポート修正、攻撃ログ検証の準備に追われた日々だった。 派手な成果よりも、Nginxログ整形やFalcoルール調整といった泥臭い改善が中心。 「失敗を記録し資産化する」という文化をさらに強めた期間だった。
そして迎えた51日目以降。僕は E2Eテストレポートの公開、UIの修正、i18n対応、攻撃検証の再挑戦 に進んでいった。
Day 51（08/30）— End-to-End テストレポート公開
この日、ついに End-to-End テストレポート (Phase 1) を公開した。 👉 テストレポート
全14件のシナリオを流し込み、12件で検知成功（SQLi: 5、XSS: 7）／2件は未検出という結果をそのまま公表した。 シナリオごとに「発火ルール・Falco出力・成功／失敗の判定」を並べ、どこを捉え、どこを落としているかを外からも確かめられるようにしている。
「成功だけでなく未検出も出す」。それは怖いけれど、OSSとしての誠実さだ。 Falcoプラグインは万能ではないが、透明性をもって改善を積み重ねる姿勢こそが強みだと実感した。
学び
OSSとしての誠実さは、成功だけでなく未検出も公表すること。透明性をもって改善を積み重ねる姿勢こそが真の強み。
Day 52（08/31）— 国際化の一歩
次の課題は i18n（国際化対応）。 日本語と英語の両方でレポートを表示できるようにする取り組みが始まった。
作業を進める中で、翻訳キーの不足や整理漏れが見つかり、画面表示に揺らぎが出てしまった。 不足を一つひとつ潰していきながら、UIを整えた。
学んだのは、国際化は翻訳作業だけでなく設計そのものだということ。 言語を切り替えても一貫した体験を提供するためには、最初から仕組みとして組み込む必要があるのだ。
学び
国際化は翻訳作業だけでなく設計そのもの。言語を切り替えても一貫した体験を提供するには、最初から仕組みとして組み込む必要がある。
Day 53（09/02）— 攻撃検証の再挑戦
再びSQLiやXSSのログを流し込み、Falcoの反応を試した。 だが結果は思うようにいかなかった。
一部は検知できたものの、過検知（false positive） や 未検出（false negative） が発生し、精度に課題が残った。 僕は PROBLEM_PATTERNS.md にその結果を記録し、改善すべきポイントとして整理した。
「検知できない失敗」と「余計に検知してしまう失敗」——どちらもユーザーにとっては致命的だ。 この二つのバランスをどう取るかが、次の大きな課題になった。
学び
過検知と未検出のバランスが重要。どちらもユーザーにとって致命的であり、この二つの調整が次の大きな課題となる。
Day 54〜55（09/03〜09/04）— 過検知調整
この二日間は、過検知をどう防ぐかに時間を割いた。 正規表現を緩めすぎれば攻撃を取り逃がすし、厳しすぎれば誤検知が増える。 条件の調整を繰り返し、その内容を integration-test-requirements.md に追記した。
次の検証に向けて、具体的な改善ポイントを整理できた。
学び
検知精度の調整は微妙なバランス。正規表現の厳密さと検知範囲のトレードオフを理解することが重要。
Day 56（09/04）— 多層の"網"と統合ドキュメント
この日は、これまでの調整を踏まえて ルールと攻撃パターンを一気に拡充し、さらにその全容をドキュメントにまとめた。
成果物は IMPLEMENTED_RULES_OVERVIEW.md。 ここには、
- 実装済みルール 37個 の完全リスト
- 810以上 の攻撃パターン詳細カタログ
- カテゴリ別の実装状況
- SQLi: 290
- XSS: 160
- CMD Injection: 150
- Path Traversal: 100
- Emerging Threats: 60
- 各ルールの検出能力とパフォーマンス指標
が整理されている。
Phase 1（6ルール・18パターン）から、わずか数週間で37ルール・810+パターンへ。 nginxログ用ルールを幾重にも重ね、緻密に設計した"網"で多種多様な悪意ある振る舞いを捕まえる。 これこそFalcoを使う真骨頂であり、OSSとして積み上げてきた最大の成果だった。
学び
Falcoの真骨頂は多層の"網"。37ルール・810+パターンの緻密な設計により、多種多様な攻撃を確実に捕捉できる。
51〜56日目で行ったタスク
- End-to-End テストレポート (Phase 1) の公開
- 6つのFalcoルールで18種類の攻撃パターンを検証
- 成功・未検出の両方を明示的に公開
- i18n対応（翻訳キー不足の修正と整理）
- 攻撃トラフィック検証の再挑戦（過検知と未検出の確認）
- 過検知の調整と integration-test-requirements.md への記録
- ルールと攻撃パターンの大幅拡充（37ルール・810+パターン）
- 統合ドキュメント IMPLEMENTED_RULES_OVERVIEW.md の作成
作成・更新したドキュメント
integration-test-requirements.md
→ 過検知対策の条件調整を追記
PROBLEM_PATTERNS.md
→ 「過検知問題」や「未検出シナリオ」などを新規追加
IMPLEMENTED_RULES_OVERVIEW.md
→ 37ルール・810+攻撃パターンの全容を記録
まとめ
51〜56日目は「OSSとしての透明性をどう示すか」が大きなテーマだった。 特にE2Eテストレポートの公開では、6ルール・18パターンの結果を成功と未検出を含めて公開し、OSSの誠実さを示せた。
そして9/4には、実装済みルールを 37個・810+パターン へと拡張し、その全容を統合ドキュメントにまとめた。 Falcoプラグインの真骨頂は、nginxログをベースに緻密なルールを幾重にも重ね、多様な攻撃を検知できる点にある。