コンテンツにスキップ

実行時証拠の網羅性の検証

  • 状態: ローカル環境で計測済み（権限・負荷・実運用環境での確認は実行時証拠の観測環境の検証で扱う）
  • 開始日: 2026年9月19日
  • 最終更新: 2026年9月23日

目的

実行時証拠を修正優先順位の判断に採用する前に、パッケージの利用状況をどれだけ網羅できるかを評価する。

  • これまでの調査で確認したこと

  • 今回評価すること

    • 実際に使った全パッケージを名前とバージョンの単位で捉え、利用確認の網羅性を測る
    • 使わなかったパッケージを誤って利用確認済みにしないかを調べる
    • 見逃したパッケージが修正優先順位に与える影響を比較する

方針

  • 独立した正解データを確定する

    • 評価対象の収集ツールとは別の手段で、パッケージの利用状況を記録する
    • その記録をもとに、同梱されたすべてのパッケージについて、ワークロードで実際に使われたかどうかを確定する
    • 脆弱性の検出結果がないパッケージも網羅性の評価に含める
    • 同じ正解データに対して各観測方式の再現率と偽陽性を測る

  • 各方式と組み合わせた場合の網羅性を比較する

    • 実行中のファイルと読み込み済みライブラリを従来のルールでOSパッケージへ紐づけるサンプリングを評価する
    • プロセスが開いたままのJavaアーカイブの特定と、Python拡張のパッケージへの対応付けを行う読み取り専用の追加手法を評価する
    • 実行とファイルオープンを記録するeBPFのイベント証拠を評価する
    • 同じパッケージを重複して数えず、方式ごとの寄与と組み合わせた場合の網羅性を示す

  • 証拠は優先順位を上げるためだけに使う

    • 利用の証拠は修正優先順位の引き上げに使う
    • 証拠がないことや未使用という判定を理由に、優先順位を下げたり安全を示唆したりしない
    • ファイルへのアクセスや読み込みと、パッケージのコードの実行を区別する
    • Goの静的バイナリは埋め込みモジュール全体を実行中のバイナリの使用として扱うため、パッケージ単位の網羅性評価の対象にしない

検証項目

  1. 使ったパッケージ全体の網羅性
    • 各方式とその組み合わせについて、使ったパッケージのうち利用を確認できた割合を測る
  2. 誤った利用確認
    • 独立した正解データで未使用と確定したパッケージを、利用確認済みにしていないかを調べる
  3. パッケージ区分による違い
    • 常駐プロセスが使うOSパッケージ、短命処理が使うOSパッケージ、言語パッケージを比較する
  4. 観測条件による違い
    • 観測の開始時刻、観測窓の長さ、サンプリング間隔を比較する
  5. 見逃しの原因
    • 短時間の利用、観測開始前の利用、対応付け未対応、収集の取りこぼし、その他の原因を分ける
  6. 修正判断への影響
    • 見逃したパッケージの検出結果も含め、「今すぐ対応」と「監視」の件数と順位の変化を比較する

今回の対象外

  • Goの静的バイナリの網羅性

    • 実行中のバイナリの埋め込みモジュール全体を使用として扱う
    • 使用の判定がバイナリの実行と一致するため、パッケージ単位の網羅性評価の対象にしない

  • 脆弱なコードの実行証明

    • パッケージの利用は、脆弱な関数の実行や攻撃の成立を示さない
    • 攻撃検知とネットワーク到達可能性の評価は本調査の対象外とする

  • 実運用全体での成立性

    • 本計画ではDocker Engine上の制御されたワークロードを評価する
    • 最小権限、運用時の負荷、利用者の許容範囲、本番環境全体での有効性は別途検証する課題とする

検証方法（計画）

  • 対象ワークロード3種

    • PythonのWebアプリに30前後のパッケージを同梱し、起動時の読み込みとリクエストで初めて行う読み込みによって一部だけを使う
    • Node.jsのWebアプリで同梱パッケージの一部だけを使い、起動時と必要になった時点の両方で読み込む
    • Javaのアプリではクラスパスに複数のアーカイブを置き、起動時に読むもの、後から読むもの、読まないものを含める
    • 各アプリのコンテナ内で、OSのコマンドを使う運用処理を定期的に実行する
    • 常駐プロセスが使うOSライブラリも対象に含める

  • 観測条件

    • ワークロードより先に観測を始める条件と、稼働中のワークロードに途中から観測を始める条件を比較する
    • 観測窓は5分と15分、サンプリング間隔は30秒と10秒とする
    • イベント収集のバッファは512ページとし、取りこぼし0件を基本条件とする
    • 実際の取りこぼしを計測ごとに記録する
    • 各条件を1回以上、主要条件を2回計測する

  • 独立した正解データ

    • 同梱された全パッケージを名前とバージョンの単位で列挙する
    • 正解データ取得専用の実行では、eBPFの収集とは独立したシステムコールの追跡によって、実行とファイルオープンを全件記録する
    • 記録したファイルをOSパッケージの所有者情報と言語パッケージのメタデータでパッケージへ変換する
    • Pythonではアプリ終了時に読み込み済みモジュールとそのファイルを取得する
    • Node.jsではランタイムの読み込み済みモジュールのキャッシュに残るモジュールを取得する
    • Javaではクラスの読み込み記録から使ったアーカイブを特定する
    • ファイルの記録とランタイムの記録を合わせて、使ったパッケージを確定する
    • 同梱パッケージは、記録の完全性と所有者を確認でき、両方の記録に利用が現れない場合に限り、定めたワークロードでは未使用とする
    • 使用・未使用を確定するための根拠を確認できない対象は不明とする
    • 記録の不足や所有者の曖昧さを解消してから、正解データを全件確定済みとして扱う

  • 実行の再現性

    • 追跡によって実行速度が変わるため、正解データの取得と各方式の計測は別の実行に分ける
    • 両者で同じイメージ、同じ発火手順、同じ観測窓を使う
    • アプリへのリクエストと運用処理の順序を固定し、両者で同じ処理を実行する
    • 稼働中に観測を始める条件でも、起動時の活動の記録を保持する
    • 観測開始前の利用と観測中の見逃しを区別できるようにする

  • 指標

    • 再現率は、独立して利用を確定した全パッケージ数に対する、正しく利用確認できたパッケージ数の割合とする
    • 偽陽性は、未使用と確定したのに利用確認済みとしたパッケージの件数とする
    • 偽陽性の件数と併せて、未使用パッケージの総数を示す
    • 各評価区分では同じ名前とバージョンのパッケージを1回だけ数える
    • ワークロード、観測条件、方式ごとに結果を示す
    • 常駐プロセスが使うOSパッケージ、短命処理が使うOSパッケージ、Python・Node.js・Javaそれぞれのパッケージを分ける
    • 見逃しは短時間の利用、観測開始前の利用、対応付け未対応、収集の取りこぼし、その他の原因に分けて示す

  • 受け入れ基準

    • 各パッケージ区分で再現率80%以上を求める
    • サンプリング、読み取り専用の追加手法、イベント証拠を合わせた結果にこの基準を適用する
    • 合算した結果と併せて方式別の内訳を示す
    • 偽陽性は0件を求める
    • 全体の合計で不足が隠れないよう、条件別の結果も示す
    • 証拠がないことや未使用という判定を理由に優先順位を下げない原則を維持する

  • 修正判断の比較

    • イメージの識別情報、スキャン結果、KEVとEPSSのスナップショットを固定する
    • 実行時情報なし、サンプリングのみ、読み取り専用の追加手法込み、さらにイベント証拠込みの4通りを比較する
    • 4通りについて「今すぐ対応」と「監視」の件数と順位を比較する
    • 見逃したパッケージに属する検出結果のうち、「今すぐ対応」または「監視」に相当するものを数える
    • パッケージの網羅性と脆弱性の検出件数を分けて報告する

結果

結論

  • startupの言語パッケージは全対象で基準を達成し、短命OSは両開始条件で全件確認
  • attach_runningのPython・Node.jsの言語パッケージと、両開始条件のNode.jsの常駐OSは基準未達
  • 全条件・全方法で偽陽性0件
  • 網羅性の未達を残しつつ、修正優先順位の判断への条件付き採用を決定

計測の規模と対象

  • 環境: ローカル環境のWSL2上のDocker Engine、管理者権限で計測
  • 対象: Python・Node.jsのWebアプリとJavaアプリの3種でcurl・git・opensslを周期実行し、脆弱性の検出結果がないパッケージも評価
  • 実行数: 正解データ取得専用3本、観測方式の計測30 run、最終集計の保留0本
  • 観測条件: 間隔10秒・30秒、窓300秒・900秒、バッファ512ページで、各対象・開始条件の30秒間隔・900秒窓は2回、他の組み合わせは各1回計測

用語

  • 正解データ: 評価対象の観測ツールと独立したシステムコール追跡と言語別の読み込み記録で使用・未使用を確定した記録
  • 言語パッケージ: Python・Node.js・Javaそれぞれの仕組みで配布・管理されるパッケージ
  • 常駐OS: アプリなどの常駐プロセスが使ったOSパッケージ
  • 短命OS: curl・git・opensslなど短時間で終了する処理が使ったOSパッケージ
  • 従来のルール: procfsで稼働中コンテナのプロセスをOSパッケージに紐づける方法のとおり、procfsを定期的に読んで実行ファイルと読み込み済みライブラリをOSパッケージに紐づける方法
  • 読み取り専用の追加手法込み: 従来のルールに、Trivyで検出した言語パッケージを実行時のファイル情報に紐づける方法による確認を追加したもので、procfsを読むだけで観測プログラムは入れない
  • イベント証拠込み: 追加手法込みに、bpftraceでコンテナの実行とファイルオープンを観測する方法で記録した証拠による確認を追加
  • startup: ワークロードより先に観測を始める条件
  • attach_running: 稼働中のワークロードに途中から観測を始める条件
  • 再現率: 正解データで使用を確定したパッケージのうち、利用を正しく確認できた割合
  • 偽陽性: 正解データで未使用と確定したのに、利用確認済みにしたパッケージの件数
  • 照合: 観測で得たファイルのパス（procfsで見えた実行ファイル・ライブラリや、イベントで記録したopenの対象）を、それを持つパッケージの名前とバージョンに結びつける処理で、「見逃しの内訳」の「対応付け未対応」はこの処理の制限を指す
  • 今すぐ対応（act-now）・監視（watch）: KestreLynxが脆弱性の検出結果に付ける修正優先度の区分で、CVEごとの優先度判定に従い、Act nowはCISA KEV掲載またはEPSSがしきい値（既定10%）以上、WatchはAct nowに該当せずEPSSが下側しきい値（既定1%）以上または深刻度がCRITICALという弱いシグナルを持つものを指し、この開発ログではそれぞれ小文字のact-now・watchと表記する

正解データ

コンテナの動作 同梱パッケージ 使用 未使用 不明
PythonのWebアプリと周期操作 152件 63件 89件 0件
Node.jsのWebアプリと周期操作 390件 109件 281件 0件
Javaアプリと周期操作 163件 49件 114件 0件
  • 数え方: パッケージは名前とバージョンの組み合わせを1件とし、同じ名前でもバージョンが違えば別の件として数える
  • 反復の扱い: 同じ条件を2回計測した場合も、同じパッケージを2件とは数えない
  • 区分の重なり: libc6のように常駐プロセスと短命処理の両方が使うOSパッケージは常駐OSと短命OSの両方に数えるため、2つの区分の件数は足し合わせられない
  • 短命OSの確認の意味: 短命OSのパッケージは常駐プロセス側の証拠でも確認済みと数えるため、短命OSの再現率は短命処理の実行そのものをどれだけ捕捉できたかを表さない
  • 未使用の内訳（OS／言語）: Pythonは78件／11件、Node.jsは80件／201件、Javaは111件／3件で、OSの未使用集合は両OS区分の偽陽性評価に共用
  • 不明の範囲: 不明0件は集計対象の一覧内の結果であり、Javaには別途バージョン未確定の配置が5件残る

パッケージ利用の網羅性

表はイベント証拠込みの再現率で、括弧内は「利用を正しく確認できた件数 / 正解データで使用を確定した件数」を示す。観測開始前だけに使ったパッケージも評価対象に含めた。

コンテナの動作 開始条件 言語パッケージの再現率（イベント証拠込み） 常駐OSの再現率（イベント証拠込み） 短命OSの再現率（イベント証拠込み）
PythonのWebアプリと周期操作 startup 100%（19/19 件） 89%（16/18 件） 100%（33/33 件）
PythonのWebアプリと周期操作 attach_running 37%（7/19 件） 83%（15/18 件） 100%（33/33 件）
Node.jsのWebアプリと周期操作 startup 99%（71/72 件） 75%（6/8 件） 100%（31/31 件）
Node.jsのWebアプリと周期操作 attach_running 0%（0/72 件） 75%（6/8 件） 100%（31/31 件）
Javaアプリと周期操作 startup 100%（9/9 件） 82%（9/11 件） 100%（31/31 件）
Javaアプリと周期操作 attach_running 100%（9/9 件） 82%（9/11 件） 100%（31/31 件）
  • 誤確認: 全30 runの従来のルール・追加手法込み・イベント証拠込みで偽陽性0件、同梱パッケージ一覧外の誤確認も0件
  • 条件による差: 対象・区分・開始条件が同じなら、間隔・窓・反復による再現率、偽陽性、イベント証拠込みでの見逃し件数・主因の差はなく、観測窓を長くしても間隔を短くしても観測開始前の利用は確認できないままだった
  • 言語パッケージの増分
    • 従来のルールでの確認は0件、追加手法込みでPython拡張を持つ7件とJavaの9件を確認
    • startupではイベント証拠込みでPythonの12件とNode.jsの71件を追加確認
    • 累積した方法間の増分であり、追加手法単独・イベント証拠単独の確認数と方式間の重複数は未集計

見逃しの内訳

イベント証拠込みでの見逃しはすべて次のいずれかに分類し、主因を重複させなかった。

  • 観測開始前の利用: 観測を始める前に実行や読み込みが済んでいて、観測を始めた後にはその利用の証拠が残っていない状態
    • attach_runningの言語パッケージは、開いたファイルが残らないPythonの純粋モジュール12件とNode.jsの全72件を見逃し
    • attach_runningの常駐OSは、全対象のタイムゾーンデータとPythonのbase-filesが該当
    • 追加手法込みでは、Python拡張の7件はメモリに読み込まれたままのファイルから、Javaの9件は開いたままのjarから、観測開始後でも利用を確認できた
  • 対応付け未対応: 観測ファイルを所有者情報・メタデータでパッケージ名とバージョンへ紐づける処理の制限
    • startupの常駐OSは、全対象でawkとタイムゾーンデータの所有パッケージを見逃し、正解データ取得側が解決したコンテナ内シンボリックリンクに照合側が未対応
    • attach_runningの常駐OSでは全対象のawkの所有パッケージが該当
    • Node.jsのstartupは、node_modules外のアプリ自身のパッケージ1件に未対応

照合の制限を解消した後の確認

  • リンク経由で使ったOSパッケージの確認

    • 従来はコンテナ内のシンボリックリンクをたどれず、awkやタイムゾーンデータへのアクセスを観測しても、所有するパッケージの名前とバージョンに結びつけられなかった
    • 正解データではリンク先のmawk・tzdataの使用を確認できていたため、この差を対応付け未対応による見逃しとして数えていた
    • コンテナ内のリンク一覧を収集することで、/usr/bin/awkから/etc/alternatives/awkを経由する場合や、/etc/localtimeからタイムゾーンデータを参照する場合も、リンクを最後までたどって所有パッケージを確認できるようにした
    • リンクとリンク先の所有者がそれぞれ1パッケージに確定し、互いに異なる場合は、正解データと同じく両方を使用と数える

  • Node.jsアプリ自身のパッケージの確認

    • 従来はnode_modulesの外にあるアプリ自身のpackage.jsonを、Trivyが検出したアプリのパッケージに結びつけられず、正解データでは使用済みの1件を見逃していた
    • アプリ自身のpackage.jsonを照合対象に加え、依存パッケージに加えてアプリ自身のパッケージも利用確認できるようにした

  • ディレクトリを開いた記録による誤確認の防止

    • 各ファイルがディレクトリかどうかも収集し、ディレクトリを開いただけの記録はパッケージの使用に数えない

  • 確認計測の範囲

    • リンク一覧とディレクトリ情報を保存する収集方法で、3アプリをstartup・30秒間隔・300秒窓で各1本計測した
    • 収集方法が異なるため、前の表にある元の30 runの主結果は変更しない
    • 今回の確認はstartupの1条件に限られ、attach_runningを含む全条件での達成を示すものではない

表はイベント証拠込みの再現率で、括弧内は「利用を正しく確認できた件数 / 正解データで使用を確定した件数」を示す。

コンテナの動作 言語パッケージの再現率 常駐OSの再現率 短命OSの再現率 偽陽性
Python の Web アプリと周期操作 100%（19/19 件） 94%（17/18 件） 100%（33/33 件） 0件
Node.js の Web アプリと周期操作 100%（72/72 件） 100%（8/8 件） 100%（31/31 件） 0件
Java アプリと周期操作 100%（9/9 件） 91%（10/11 件） 100%（31/31 件） 0件
  • 残る見逃し
    • PythonとJavaの常駐OSに属するtzdataを各1件見逃した
    • /etc/localtimeを開いたのがコンテナ起動直後で、最初にファイル配置を読み取るより前だったため、その時点のリンク先と所有パッケージを確認できなかった
    • 最初の読み取りまでに配置が変わっていないことを証明できないため、後から取得した配置情報を使って過去の利用を対応付ける扱いは採用しない

受け入れ基準の判定

イベント証拠込みの各区分・開始条件に、既定の再現率基準と偽陽性0件を適用した。

コンテナの動作 パッケージ区分 startup attach_running
PythonのWebアプリと周期操作 言語パッケージ 達成 未達
PythonのWebアプリと周期操作 常駐OS 達成 達成
PythonのWebアプリと周期操作 短命OS 達成 達成
Node.jsのWebアプリと周期操作 言語パッケージ 達成 未達
Node.jsのWebアプリと周期操作 常駐OS 未達 未達
Node.jsのWebアプリと周期操作 短命OS 達成 達成
Javaアプリと周期操作 言語パッケージ 達成 達成
Javaアプリと周期操作 常駐OS 達成 達成
Javaアプリと周期操作 短命OS 達成 達成
  • 判定は全間隔・窓・反復で共通し、未達はすべて再現率によるもので、Node.jsが未達の常駐OSは区分全体でも達成としない

修正判断への影響

  • 比較した条件と順位

    • イメージごとにスキャン結果を固定し、脅威情報には2026年9月20日に取得したKEV/EPSSの全体キャッシュを全runに一律に適用した
    • 実行時情報なしを基準に、従来のルールとイベント証拠込みを合わせた3通りの順位を比較した
    • 対象は「今すぐ対応（act-now）」と「監視（watch）」の2区分で、各区分の保存された上位20件の範囲で順位の変化を調べた
    • 以下は30秒間隔・900秒窓の結果で、startupとattach_runningをそれぞれ2回計測した値は一致した

  • watchで順位が上がった検出結果

    • イベント証拠込みの上位20件では、Pythonがstartupで8件・attach_runningで9件、Node.jsが両条件で20件、Javaが両条件で2件だった
    • 従来のルールの上位20件では、両条件ともPythonが8件、Node.jsが7件、Javaが0件だった

  • act-nowで順位が上がった検出結果

    • Node.jsのattach_runningでイベント証拠込みの1件のみで、他は0件だった

  • イベント証拠込みでも見逃したパッケージに属する検出結果

    • startupでは、act-now・watchに該当する検出結果は全アプリで0件だった
    • attach_runningのPythonでは、urllib3・werkzeugにwatchが各1件あり、従来のルールでもイベント証拠込みでも両方が上位20件の外だった
    • attach_runningのNode.jsでは、lodashにwatchが2件あり、従来のルールでは1件が上位20件内で順位を下げて1件が圏外となり、イベント証拠込みでは2件とも圏外となった
    • attach_runningのNode.jsでは、qsにact-nowが1件あり、従来のルールでは上位20件内で順位不変、イベント証拠込みでは上位20件内で順位が下がった
    • attach_runningのJavaでは、act-now・watchに該当する検出結果は0件だった
    • Node.jsのact-nowで順位が上がった1件と、見逃したqsに属して順位が下がった1件は別の検出結果である

  • 未使用パッケージの誤確認による順位上昇

    • 未使用パッケージの誤確認が0件だったため、それによる順位上昇も全条件・全方法で0件だった

  • この比較では分からないこと

    • 上位20件の外の順位は保存されていないため、圏外の検出結果は順位の変化を判定できず、順位不変や順位が上がらなかった件数にも含めない
    • 読み取り専用の追加手法込みの順位は出力されないため、その段階での順位の変化は比較できない
    • 見逃したパッケージに属する検出結果の順位変化だけでは、見逃しが修正順序に与えた因果的な影響までは確定できない

採用判断

実行時証拠を修正優先順位の判断に条件付きで採用する。

  • 理由
    • 証拠は優先度の引き上げにだけ使い、見逃しを未使用・安全という誤判定につなげない
    • 観測開始前の読み込みによる確認不足は、コンテナ起動前からの継続観測で避けられる一時的な状態
  • 条件
    • 観測プロセスを常駐させ、コンテナ起動前からの継続観測を基本とする
    • 観測前に起動したコンテナの言語パッケージは「判定不能(観測開始前に起動)」として確認済み・証拠なしと区別して保持・表示し、継続観測中の次回コンテナ再起動で解消すると示す
    • 証拠なし・未使用を理由に優先度を下げたり修正対象から外したりしない原則を、実装と表示の両方で守る
  • 完了した作業（採用の前提条件ではなく、採用後に進めた）
    • 照合側でコンテナ内のシンボリックリンクを解決した
    • node_modules外のアプリ自身のパッケージに対応した
    • 実行時情報の有無による順位差を比較した
  • 残る作業（採用の前提条件ではなく、採用後の実装で進める）
    • 最小権限、負荷、本番環境での動作を確認する

計測中の修正

保存入力で全30 runを同じ修正・規則により再処理し、主結果には再処理後の値だけを用いた。

  • 隣接記録の対応付けが一致する場合に、パッケージのファイル配置記録の隙間を補完
  • 識別子の再利用期間へ遡らず、登録前の起動直後イベントを正しいコンテナへ帰属
  • 時差のオフセットを保持してUTCへ変換し、数値への影響は0件
  • 計測後の判定規則を変更し、周期操作の成否1件の差だけではrun全体を保留にしない

結果の適用範囲

  • 各対象の正解run 1本を再利用しており、条件ごとに独立した正解取得を反復していない
  • 比較は保存した同一イメージに限定し、同じ構築手順での同一イメージ再生成を保証しない
  • 間隔・窓による差がない結果は今回のワークロードと操作手順に限り、別の利用周期・リクエスト構成、実際の利用経路の代表性、最小権限・負荷・本番環境は未検証

完了した作業

  • 使ったパッケージ全体の網羅性

    • 各方式とその組み合わせについて、使ったパッケージのうち利用を確認できた割合を測った（従来のルール・追加手法込み・イベント証拠込みの累積比較）

  • 誤った利用確認

    • 独立した正解データで未使用と確定したパッケージを、利用確認済みにしていないかを調べた

  • パッケージ区分による違い

    • 常駐プロセスが使うOSパッケージ、短命処理が使うOSパッケージ、言語パッケージを比較した

  • 観測条件による違い

    • 観測の開始時刻、観測窓の長さ、サンプリング間隔を比較した

  • 見逃しの原因

    • 短時間の利用、観測開始前の利用、対応付け未対応、収集の取りこぼし、その他の原因を分けた

  • 修正判断への影響

    • 固定したスキャン結果と脅威情報で、イベント証拠込みでも見逃したパッケージに属する「今すぐ対応」と「監視」の検出件数と、未使用パッケージの誤った優先度引き上げを集計した
    • 実行時情報なし・従来のルール・イベント証拠込みの3通りについて、「今すぐ対応（act-now）」と「監視（watch）」の順位の変化と見逃しの影響を上位20件の範囲で比較した（2026年9月21日）

  • 照合の対応と採用判断

    • 照合側でコンテナ内のシンボリックリンクを解決し、mawk・tzdataの所有パッケージへの対応付けと誤確認の有無を再評価した（2026年9月21日）
    • node_modules外のアプリ自身のパッケージを照合対象に加えた（2026年9月21日）
    • 実行時証拠を修正優先順位の判断に3条件付きで採用すると判断した（2026年9月20日）

残る作業

  • 使ったパッケージ全体の網羅性

    • 読み取り専用の追加手法単独、イベント証拠単独、方式間の重複数を集計する

  • 修正判断への影響

    • 読み取り専用の追加手法込みを含む4通りの全体の分類件数を比較する

  • 照合の対応と適用範囲の確認

    • 起動直後の最初の配置読み取りより前に開いたファイルの扱いを整理する（2026年9月21日追加）
    • attach_runningで観測開始前の利用を後から確認できる範囲と確認できない範囲を仕様と表示へ反映する
    • 実行時証拠の観測環境の検証でローカル環境の権限候補と負荷を確認済み（bpftraceの負荷は実装の負荷ではなく上限の目安）であり、実運用環境での開始条件と実際の利用経路の確認、および今回の結果を適用できる範囲の評価は同ログの残る作業として扱う
    • 採用条件として、判定不能の状態の保持と表示、観測の常駐運用、証拠なしや未使用を理由に優先度を下げたり修正対象から外したりしない実装と表示を整える

更新履歴

2026年9月19日

  • 検証計画を記録
    • 目的、観測方式、対象ワークロード、独立した正解データ、指標、受け入れ基準、修正判断の比較方法を記録
    • 計測と採用判断は未実施

2026年9月20日

  • 開発環境での計測結果を記録
    • 正解run 3本と計測30 runの規模、正解データ、再現率、偽陽性、条件差、見逃しの内訳、受け入れ基準の判定を追加
    • 修正判断への影響、計測中の修正、結果の適用範囲を記録
  • 作業の実施状況を記録
    • 検証項目の完了分と、単独方式の集計、修正判断の件数・順位比較、照合の拡張、仕様への反映、本番環境での確認の未了分を記録
    • 基準はattach_runningの言語パッケージとNode.jsの常駐OSで未達のまま、3条件付きで採用すると判断した

2026年9月21日

  • 照合側のシンボリックリンクとアプリ自身のパッケージへの対応、ディレクトリを開いただけでは使用としない処理、3アプリの再計測結果と残る見逃しを追記した
  • 実行時情報なしを基準に、従来のルール・イベント証拠込みについて act-now と watch の保存された上位20件で順位差の比較を完了し、見逃したパッケージの検出結果への影響と比較の限界を記録した
  • 次の作業に照合対応と順位比較の完了を反映し、最初の配置読み取りより前に開いたファイルの扱いを未了として追加した
  • 目的から計測と採用判断が未実施という記述を削除し、用語に照合と修正優先度の区分を追加し、照合の制限の説明と修正判断への影響の節を読みやすく整理し、結果の見出しから日付を外し、採用判断の作業を完了分と残りに分け、次の作業を「完了した作業」と「残る作業」の章に分けた

2026年9月23日

  • 表記と状態の更新
    • 状態行を現状に合わせ、権限・負荷・実運用環境での確認を扱う実行時証拠の観測環境の検証への参照を追加した
    • 計測環境の表記を「ローカル環境」に統一した
    • 残る作業の実運用環境での確認を観測環境の検証へ移し、ローカル環境での権限と負荷の確認済み範囲を反映した
    • 英語版の題名から「Validation Plan」を外した

この記事は、KestreLynxの開発記録です。KestreLynxについて