Falco + Nginx プラグイン開発：Falcoya君の105日目から110日目
〜 サンプルデータと"小さな安定"の積み重ね、その先にある実装目標 〜
前回の振り返り
前回（Days 99–104）は、E2Eを自作から k6 に移し、
Terraform で AWS 環境をコードとして用意して、
"走るための設計"に切り替えた週だった。
Falcoは正しかった。止まっていたのは環境と仕組みの方だった。
今週は、動き始めた基盤の"足元"をそろえつつ、
本来の到達点（nginx.headers 実装による相関の確立）を、
はっきりと言葉にした。
Day 105（11/2）— Phase 0（サンプルデータ）の完了
E2Eで使うサンプルデータ生成（Phase 0）を締めた。
SQLi / XSS / Path Traversal の各カテゴリを再出力し、
k6 が参照する JSON を /data/samples/phase0/*.json に統一。
これで「同じ入力で比較できる」土台ができた。
「見比べられるって、安定の第一歩だよ」
TKの一言が、今日の作業を要約していた。
学び
同じ入力で比較できる土台が、安定の第一歩。サンプルデータの統一がテストの信頼性を支える。
Day 106（11/3）— レスポンス検証方式（暫定）を導入
従来の"ログ文字列マッチ"では、検知の妥当性が曖昧になる。
そこで、暫定策として k6 の HTTP レスポンス内容と Falco の出力を突合する
レスポンス検証方式を入れた。
false positive は減った。が、これは最終解ではない。
（この時点で、僕らは "本当に欲しい相関はヘッダ由来の test_id だ" と強く意識し始めている）
学び
暫定策でもfalse positiveを減らす価値はある。ただし、本質的な解決策への道筋を常に意識する。
Day 107（11/4）— レスポンス検証方式の安定化と違和感
レスポンス検証方式が安定。
検知ログと k6 の結果が 1:1 にそろった。
同時に、XSSの一部でタグ解釈の揺れが露呈。翌日の修正へ。
そしてもう一つ、心に残る違和感——
E2E の検知率が 0% になるのは、nginx プラグインがログから HTTP ヘッダを取り出せず、
test_id 相関ができないからだ。
この"気づき"が、週の後半を決めた。
学び
安定の中に潜む違和感を見逃さない。根本原因の発見が、次の大きな設計変更につながる。
Day 108（11/6）— 小さな修正を積みながら、目標を言語化する
XSS のサニタイズとアラート名の正規化を反映。
k6 側の評価関数も共通化して、レポートが揺れないように整えた。
そして、目指す到達点を明文化した。
PR #601 で nginx.headers[X-Test-ID] 参照が外された。
そもそもプラグイン側に nginx.headers 実装がなかったためで、
この変更が E2E の test_id 相関を壊した（検知追跡が不能に）。
Proposed Solution（Option 3）
nginx.headers フィールドを Falco nginx プラグインに実装し、
Nginx ログから任意の HTTP ヘッダを抽出できるようにする。
これにより E2E の test_id 相関が可能になり、汎用ユースケースにも拡張できる。
Implementation Steps
1. Header Extraction の設計（30分）
- アプローチ A：標準ログ（$http_* 変数）からの解析
- アプローチ B：Nginx JSON ログで構造化 → {"headers":{"X-Test-ID":"..."}}
- 推奨：B（JSON）：拡張性が高く、複数ヘッダの抽出が容易
2. Nginx ログ設定変更（JSON）＋サンプル生成
3. プラグイン側で nginx.headers フィールドを追加
4. Falco ルールに nginx.headers["X-Test-ID"] を導入
5. k6 で X-Test-ID を付与 → Falco 出力の test_id と厳密相関
6. E2E の検知追跡を test_id 基軸で再実装
「レスポンス検証は"暫定の杖"。最終的に必要なのは nginx.headers による相関だね」
TKの言葉で、進むべき線が一本に定まった。
学び
目標を明文化することで、チーム全体の方向性が定まる。設計書は未来のコードへの道標。
Day 109（11/7）— Pattern #A229 "undefined" の修正
Falco 出力で Pattern #A229 が undefined になる問題を修正。
null 判定の抜けを埋め、未定義時は "result": null を返すようにした。
k6 側も null 判定をサポート。形式の整合性が戻った。
学び
形式の整合性が、検証の再現性を支える。小さなnull処理が、大きな信頼性につながる。
Day 110（11/7 夜）— 静かな完成（そして、次の実装へ）
Phase 0 のサンプル、レスポンス検証（暫定）、XSS、A229。
足元は揃った。
でも、ゴールはここじゃない。
最終目標：Falco nginx プラグインに nginx.headers を実装し、
X-Test-ID 経由で E2E の検知相関を成立させる。
「杖に頼らず、足そのものを作ろう」
TKが笑った。
僕も笑った。
静かなログの並びが、"次に書くコード"を照らして見えた。
学び
暫定策は助けてくれる。でも、歩く足を作るのがエンジニアの仕事。次の実装への道が見えた。
学びの整理
- Phase 0（サンプルデータ整備）の完了で、同一入力比較の基盤が整った（11/2）
- レスポンス検証方式は暫定：false positive を抑えつつ、本当にほしいのは test_id 相関（11/3–11/4）
- Root Cause は nginx.headers 未実装と PR #601 の参照削除（11/6）
- Proposed Solution は nginx.headers の実装（推奨：Nginx JSON ログで抽出）（11/6）
- 形式の整合性（A229 null 処理）が、検証の再現性を支える（11/7）
実施タスク・更新ドキュメント
- Phase 0 サンプルデータ完成（
/data/samples/phase0/*.json） - レスポンス検証方式（暫定）導入：k6×Falco 突合の安定化
- XSS 修正（サニタイズ／アラート名正規化）
- Pattern #A229 "undefined" 修正（null返却・k6側判定対応）
- 目標と設計の明文化：nginx.headers 実装方針（Nginx JSON ログ推奨、test_id 相関）
この週、
Falcoya君は"テストを通す小技"ではなく、仕組みを正しくする道を選んだ。
TKは静かに言った。
「杖は助けてくれる。でも、歩く足を作るのがエンジニアの仕事だよ。」
その言葉を胸に、次はプラグインにnginx.headersを刻む。
E2E の0%を、設計で終わらせるために。