差分と履歴の判定

差分の比較単位

差分は、今回の検出結果と、前回までに保存できた履歴を比較して判定します。パッケージの比較単位は、タグなどを含むイメージ参照とパッケージ名の組み合わせです。

スキャン結果のグループが分かれていても、同じ参照・同じ名前のパッケージはまとめて比較します。実体、エコシステム、導入済みバージョン、修正状態の違いだけでは、別の履歴になりません。

通常の所見とEOLの所見は別々に記録し、同じ組み合わせで両方の履歴を持てます。通知を送るかどうかは、通知の送信条件で別に判定します。

パッケージの変化

通常側とEOL側で、それぞれ変化を判定します。同じ側で複数の変化が成立した場合は、優先順に従って1つの理由を選びます。

通常のパッケージの変化

次の順に判定し、最初に該当する変化を採用します。

通常側にもEOL側にも前回の履歴がなければ、新規検出とする
今回の最大優先度が比較基準より高ければ、優先度昇格とする
比較基準にないCVE IDが加われば、CVE追加とする
前回の通常側にfixedがなく、今回は1つ以上あれば、修正可能化とする
前回は通知オフで、今回はその条件を満たさなければ、通知再開とする

優先度とCVE IDの比較には、前回の通常側とEOL側の両方を使います。優先度は両側の高い方、CVE IDは両側を合わせた集合が基準になります。

優先度が保存されていない場合と、今回が縮退トリアージの場合は、優先度昇格と判定しない
優先度の低下だけでは変化とせず、保存後は下がった値を次回の基準にする
EOLから通常側へ戻っただけでは、新規検出やCVE追加としない

EOLから戻った際にfixedとなった場合は、修正可能化に該当することがあります。通知オフの条件と解除理由は、修正版がない所見の通知オフを参照してください。

トリアージ無効時も、新規検出、CVE追加、修正可能化、通知再開の判定は継続します。優先度を付けないため、優先度昇格は発生しません。

EOLパッケージの変化

EOL側は、前回のEOL履歴だけを基準に、次の順に判定します。

前回のEOL履歴がなければ、新たなEOL検出とする
保存済みのEOL側優先度からAct nowへ上がれば、Act nowへの昇格とする
前回のEOL履歴にないCVE IDが加われば、EOL側のCVE追加とする
新たなEOL検出には、通常側からの移動と、EOL解除後の再検出を含む
優先度が保存されていない場合と、今回が縮退トリアージの場合は、Act nowへの昇格と判定しない
LowからWatchへの昇格と、優先度の低下だけでは変化としない

トリアージ無効時も、新たなEOL検出とEOL側のCVE追加は判定します。

解消の判定

履歴の保持が必要ない回では、今回の通常側・EOL側に同じ組み合わせが残っているかで判定します。

前回の記録	今回の状態	判定
通常側に所見あり	通常側に残る	未解消
通常側に所見あり	通常側から消え、EOL側に残る	未解消
EOL側に所見あり	EOL側から消え、通常側に残る	EOL解除、脆弱性は未解消
通常側またはEOL側に所見あり	両側から消える	解消

一部のCVEが消えても、同じ組み合わせに所見が残っていれば、パッケージの解消にはなりません。

解消の意味

解消は、現在のスキャン対象から検出項目がなくなったことを示し、パッチ適用を証明しません。コンテナの停止やイメージ参照の変更で、以前の対象が観測されなくなった場合も含みます。

表示上の区別は、パッケージの変化とEOLの表示を参照してください。

ベースOSのEOL変化

ベースOSのEOLは、イメージ参照ごとに比較します。パッケージの変化とは独立した差分です。

前回の記録	今回の状態	判定
EOLの記録なし	EOLを検出	新たなEOL検出
EOLの記録あり	EOLを検出	継続
EOLの記録あり	EOLを検出せず、履歴の保持も不要	EOLの記録から消失

記録からの消失には、イメージ参照がスキャン対象からなくなった場合も含みます。ベースOSのEOLが記録されなくなっても、個々の脆弱性の解消を意味しません。

イメージの実体変更

同じイメージ参照について、Dockerから取得したconfig digestの集合を前回と今回で比較します。 :latestの内容の入れ替えなど、次の条件をすべて満たす場合に実体変更と判定します。

前回と今回に同じイメージ参照がある
前回と今回の両方に、確認できたconfig digestが1つ以上ある
両方の集合が異なる

初回の観測や、どちらかの集合が空の場合は対象外です。 Kubernetesのregistry digestだけでは、この実体変更の差分を判定しません。

この判定はパッケージの検出やスキャン成否から独立しています。所見がない場合や、今回のスキャンが失敗した場合でも、条件を満たせば実体変更になります。

イメージ参照の更新

repo:sha-Aからrepo:sha-Bへの変更など、同じワークロードの参照更新を識別できる場合は、履歴を引き継ぎます。引き継ぎは、パッケージやEOLの差分を計算する前に行います。

履歴を引き継ぐ条件

次の条件をすべて満たす必要があります。

旧参照が前回のイメージ記録にあり、今回の観測から消えている
新参照が今回観測され、前回のイメージ記録にはない
旧参照と新参照が、同じリポジトリの有効なイメージ参照である
旧参照の記録と新参照の観測に、共通するワークロードがある
参照単位でも、共通する各ワークロード単位でも、旧参照と新参照の対応が1対1である
新参照のスキャンがすべて成功し、稼働するすべてのコンテナで単一の実体を確認できる
新参照に、所見・EOL・通知オフの既存履歴がない

リポジトリの比較ではタグとdigestを除き、レジストリのポートは区別します。 Docker Hubの省略表記を補い、appとdocker.io/library/appは同じリポジトリとして扱います。

ワークロードの照合には、次の情報を使います。

実行形態	照合する情報
Compose	プロジェクトとサービス
Kubernetes	ワークロードの種類・namespace・名前と、Pod内のコンテナ名
ワークロードを特定できない単独Dockerコンテナ	コンテナ名

1対1の対応を確認するときは、スキャン失敗や実体未確認の候補も数えます。失敗した候補を除外して、残った候補だけを引き継ぎ先にすることはありません。

引き継ぐ履歴

旧参照から新参照へ、次の履歴を引き継ぎます。

通常の所見の初回検出日、CVE ID、優先度、修正版の有無
EOLパッケージの初回EOL検出日、CVE ID、優先度
ベースOSの初回EOL検出日
通知オフの履歴

引き継いだ後は、新参照の今回の結果と比較します。追加CVEは通常のCVE追加として扱い、消えたパッケージは新参照で解消と判定します。

通知オフの条件は、新参照の現在の情報で再判定します。条件と解除理由は、修正版がない所見の通知オフを参照してください。

履歴を引き継がない場合

次のような場合は、参照更新として履歴を引き継ぎません。

ローリング更新中で旧参照と新参照が同時に稼働している
共有していた参照が複数の新参照に分かれる
複数の旧参照が1つの新参照に合流する
新参照のスキャンに失敗・部分失敗・実体未確認がある
新参照で複数の実体が動いている
過去の記録にワークロードの情報がなく、対応を確認できない

引き継がない場合は、各参照の履歴をそのまま比較します。履歴のない新参照の所見は新規となり、旧参照の所見は対象から消え、保持も不要になった時点で解消となります。

履歴の継続

履歴の比較と更新はdiffモードで行います。比較を継続するには、同じ環境の履歴を保持して利用します。

保存先・永続化・環境名の扱いは設定、配置方法はセットアップ手順を参照してください。送信成否による保存と再通知の扱いは、スキャン通知の再送に記載しています。

履歴の初期化

次の場合は、比較できる過去の履歴がない状態から開始します。

初回の実行
履歴が存在しない場合
履歴を読み取れない場合や、内容が破損している場合
履歴の形式バージョンが一致しない場合

現在のパッケージは新規検出、現在のEOLは新たなEOL検出として扱います。読み取り失敗や破損の場合は、警告をログに出します。

読み取れる古い履歴では、追加情報がないことだけを理由に全体を初期化しません。不足する情報は、次のように判定へ影響します。

不足する情報	判定への影響
優先度	比較基準がないため、その回の優先度昇格を判定しない
EOLパッケージの記録	今回のEOLパッケージを新たなEOL検出とする
イメージの実体情報	今回の実体を比較基準として記録する
ワークロードの記録	その旧参照からの履歴引き継ぎを行わない

保持中の履歴

スキャン失敗時の扱いにより保持する履歴は、今回確認できなかった所見として残します。保持は、通常側とEOL側の移動による処理より優先します。

保持対象の所見が今回の結果に見えなくても、解消と確定しない
保持対象のEOLが今回の結果に見えなくても、EOL解除と確定しない
保持した通知オフの履歴は、その回の失敗だけを理由に通知再開としない

保持は、成功したスキャンで確認できた新規検出やCVE追加まで止めるものではありません。保持していた所見の解消・EOL解除は、再確認できた結果に基づいて判定します。