Admin
AVM をどのように運用し、継続的に改善していくか
AVM の管理機能は、初期設定のためだけのものではありません。 参照データの同期、インベントリの確認、Canonical coverage の改善、 Alerts の再生成、そしてシステムの挙動を見える形で保つための 運用面そのものです。
AVM が利用する参照データ
AVM は、Canonical linking と脆弱性評価を支えるために 外部の参照データを利用します。
CVE Feed
AVM は National Vulnerability Database (NVD) から 脆弱性レコードを取り込みます。
このデータには、CVE ID、説明、深刻度、公開日・更新日、 そしてマッチング時に用いられる affected CPE 条件が含まれます。
AVM では、このデータは Admin の CVE sync workflow から取得され、 vulnerability records と affected CPE records として保存されます。
CPE Dictionary
AVM は、NVD の Official CPE Dictionary を vendor / product identity の canonical reference として利用します。
この辞書は、観測された software name を正規化し、 raw inventory data を安定した canonical identity に結び付けるために使われます。
AVM では、このデータは CPE sync workflow から取得され、 canonical vendor / product reference data として保存されます。
KEV Information
AVM は CISA の KEV Catalog から、 KEV (Known Exploited Vulnerabilities) 情報も取り込みます。
KEV は、現実に悪用が確認されている脆弱性を示すもので、 優先度付けの補助に使えます。
AVM では、このデータは KEV sync workflow から取得され、 vulnerability records に追加の運用コンテキストとして付与されます。
AVM でこれらのデータがどのように使われるか
AVM は raw software inventory を脆弱性に直接突き合わせるわけではありません。 代わりに、次のような構造化された流れで評価します。
-
Canonical linking
import された software（vendor, product, version）は、 CPE Dictionary をもとに canonical vendor / product identity にリンクされます。
このステップは Run Linking を実行して行います。 -
Vulnerability evaluation
リンク済み software は、affected CPE 条件と version-aware logic を使って CVE data と照合されます。
このステップは Generate Alerts を実行して行います。 -
Prioritization context
KEV data は vulnerability に付与され、 実際に悪用されていることを示す補足情報として使われます。
これらのステップは分かれているため、参照データを更新しただけでは alert results はすぐには変わりません。
重要:
- CPE Dictionary を更新した後 → Run Linking を実行
- CVE Feed または KEV を更新した後 → Generate Alerts を実行
AVM がこれらのデータをどのように取得・更新するか
AVM は、専用の admin sync jobs を通じてこれらのデータセットを取得します。
各 sync process は前回取得した内容のメタデータを記録するため、 変更がないデータはスキップでき、後から Admin 画面で実行履歴を確認できます。
参照元:
AVM の運用モデル
AVM には、参照データ側と運用側の両方を維持するための管理ワークフローがあります。 具体的には、脆弱性や辞書の同期、staged import review、 canonical / unresolved mapping workflows、alias / synonym の管理、 alert generation、run history、system settings、user management、 security audit visibility などです。
これらの admin areas は互いにつながっています。実運用では、 import したデータのうち解決できなかったものを確認し、 reference coverage を改善し、canonical links を backfill し、 その後 alert state を再計算する、というループで使われます。
Key idea: AVM における管理機能は、 単なる裏方のメンテナンス画面ではなく、 製品の運用モデルそのものの一部です。
運用フロー
Reference sync、settings、users、audit は このループの外側にあるのではなく、このループを支える機能です。
AVM における software linking の流れ
AVM は、import された software inventory を、 構造化された半自動ワークフローによって canonical vendor / product identity に結び付けます。
1. インベントリを import する
まず assets と software を import します。
Asset import は管理対象システムを登録し、 Software import は vendor、product、version などの観測された software を登録します。
AVM はこれらの raw values を observed evidence として保持します。
2. 候補を自動準備する
import 時に、AVM は normalization、aliases / synonyms、 dictionary matching を使って candidate matches を準備します。
ただしこの段階では、すべての画面で review 可能な形に candidates が完全に materialize されているわけではありません。
3. 初回の linking を実行する（必須）
candidates を review する前に、 Run Linking を実行する必要があります。
このステップでは、データセット全体に対して candidate matches を評価し、 linking results と candidates を materialize し、 Unresolved view で candidate display を有効にします。
この処理を実行しないと、Unresolved Mappings の Resolve column に candidates は表示されません。
4. linking 結果を確認する
linking 実行後、software は fully linked、vendor only、 resolvable、unresolved などの状態に分かれます。
Fully linked は vendor と product の両方が識別された状態です。 Vendor only は部分一致です。Resolvable は有力な candidate が存在する状態、 Unresolved はまだ信頼できる candidate がない状態です。
全体の coverage を把握するには Review Product Mappings 画面を使います。
5. linking 結果を調整する
初回の Run Linking の後、必要に応じて結果を調整します。
正しい link はそのまま残し、誤った link は Disable Link を使います。 より良い candidate がある場合は、Unresolved Mappings で選択して適用します。
ここで operator の判断が入ります。
6. unresolved mappings を処理する
Unresolved Mappings では、candidate vendor / product suggestions を確認し、 正しい mapping を手動で選択して、 あいまいまたは未解決の links を解消できます。
この画面が十分に機能するのは、 Run Linking 実行後です。
7. 次回以降の linking を改善する
将来的な手作業を減らすには、vendor aliases、product aliases、 synonyms を整備します。
これらを改善していくことで、自動 linking の精度が上がり、 今後の import で unresolved items を減らせます。
Key idea: AVM の linking は二段階のプロセスです。 Run Linking で candidates を materialize し、 自動マッチを適用したうえで、 その後に手動で disable や修正を行います。 これにより、自動化と operator control の両方が可視化されます。
Reference sync
AVM には、後続のマッチングや優先度付けに使う参照データを 取得・更新するための admin workflows があります。 これには vulnerability data と、 product dictionary のような canonical reference data が含まれます。
Vulnerability sync
後続の評価と alert generation に使う vulnerability intelligence を更新します。
Dictionary sync
canonical linking と matching に使う vendor / product の reference data を更新します。
なぜ sync が重要か
matching quality は inventory quality だけでなく、 reference model の品質と鮮度にも左右されます。
Import review
AVM の import は staged かつ reviewable です。 管理画面の import screens では、何がアップロードされたか、 何が validation を通過したか、何が通らなかったか、 そして何が main inventory tables に入ろうとしているかを確認できます。
これにより、「データがシステムに入ったこと」と 「そのデータがすでに十分に正規化され、match-ready であること」を 区別しやすくなります。
確定前に preview できる
staged rows は最終 import 前に確認できます。
Import run の可視性
import actions は run records と結び付いているため、 後から review する際にも文脈を保てます。
evidence を保持する
raw imported values は、 import 完了後も重要な evidence として残ります。
Canonical review と unresolved review
Canonical status の意味
Canonical view では、各 software row に linking workflow の進み具合を示す status が付与されます。
これらの status は、 現在の linkage state と 信頼できる candidate が存在するかどうか の二つの軸を組み合わせたものです。
Fully Linked
vendor と product の両方が canonical references にリンクされています。
理想的な状態であり、信頼性の高い vulnerability evaluation が可能です。
Vendor Only Linked
vendor はリンク済みですが、product は未リンクです。
これは通常、vendor は正しく識別されたものの、 product name の review やよりよい normalization がまだ必要な状態です。
Not Linked
vendor と product のどちらもリンクされていません。
この software を識別するための情報が、まだ十分にそろっていない状態です。
Linked (Valid)
link が存在し、現在も有効と見なされています。
これは、その link が disable されておらず、 matching に実際に使われていることを示します。
Linked (Stale)
link は存在するものの、現在は有効と見なされていません。
典型的には、link が disable または置き換えられた後も、 履歴上の traceability のために保持されている状態です。
Fully Resolvable
まだ fully linked ではありませんが、 vendor / product の両方に高信頼な candidate が存在します。
多くの場合、Run Linking によって自動解決できるか、 最小限の review で確定できます。
Vendor Resolvable
vendor には信頼できる candidate がある一方で、 product にはありません。
部分的に解決可能な状態であり、linking 後には Vendor Only Linked になることが多いです。
Unresolvable
信頼できる candidate を特定できませんでした。
aliases を追加したり、 Unresolved view で mapping を選ぶなどの手動対応が必要です。
Not Normalized
raw software name が、 matching に適した形へ正規化されていません。
これは、入力品質の問題や、 normalization / synonym rules の改善が必要であることを示す場合があります。
Key idea: Canonical status は、すでに linked されているものだけでなく、 自動で link 可能なものと、 人手での review が必要なものも示します。
AVM の管理ワークフローの中でも特に重要なのが、 canonical coverage の review です。 import された software は、canonical vendor / product identity に 結び付くことで、より有用になります。 その linkage が不十分な場合、AVM は unresolved mappings を可視化したまま保持します。
canonical 画面と unresolved 画面は、 この問題を異なる角度から補完的に見るためのものです。 何がすでに linked されているか、 何が部分的にしか linked されていないか、 何が明示的な review を必要としているかを確認できます。
Canonical view
software inventory 全体における vendor / product linkage の現在状態を表示します。
Unresolved view
canonical review や aliases / synonyms の補助がまだ必要な software rows を強調表示します。
なぜ重要か
canonical coverage が高いほど、 downstream の matching と alert generation の信頼性が高まります。
Unresolved Mappings から学習される Alias
Unresolved Mappings で link を作成すると、 AVM はその1行を解決するだけでは終わりません。
選択された Row Vendor / Product から Canonical Vendor / Product への対応は、 alias としても保存されます。
次回以降の import が楽になる
一度この alias が登録されると、 同じ raw vendor / product values は 後続の import で自動認識されるようになります。
実際には、同じ software を次回 import したとき、 同じ手動 review を繰り返さずに自動で linked できるようになります。
手動 review が自動化の改善につながる
Unresolved Mappings での手動 link は、 その場限りの修正ではありません。
将来の matching behavior そのものを改善します。 これは、AVM が review 作業を再利用可能な canonical knowledge に変える方法の一つです。
Aliases は JSON で export できる
AVM は、登録済み aliases を JSON として export できます。
これにより、そのデータを単一環境の中だけに閉じ込めず、 再利用可能な mapping dataset として保持できます。
Alias Seed として再 import できる
export した alias JSON は、 Alias Seed として AVM に再 import できます。
これにより、過去に学習した mapping knowledge を引き継ぎ、 環境をまたいで、あるいは将来の deployment でも 手作業の繰り返しを減らせます。
Key idea: Unresolved Mappings の row を解決することは、 現在の dataset を直すだけではありません。 export / import / 蓄積が可能な、 再利用可能な alias knowledge を構築することでもあります。
Canonical backfill と alert generation
AVM は、canonical linkage の改善と alert state の評価を分けています。 これにより、ワークフローを理解しやすくしています。
aliases、synonyms、または手動 review によって canonical coverage が改善した後、 operators は canonical backfill を実行し、 その後 generate alerts を行うことで、 新しい linkage state を運用結果に反映できます。
このループは、AVM の inspectable operating model を最もよく示す例の一つです。
Runs と履歴
AVM の管理アクションは run-oriented views と結び付いており、 sync、import、その他の処理で何が起きたかを確認できます。
run visibility は、トラブルシュートや監査だけでなく、 システム状態の変化が、新しいデータによるものなのか、 resolution の改善によるものなのか、 明示的な generation によるものなのかを理解するうえでも重要です。
なぜ runs が重要か
後から review するための execution context を残せるからです。
何に役立つか
validation、トラブルシュート、 そして運用上の順序関係の理解に役立ちます。
System settings
AVM には、matching と review behavior に影響する settings があります。 これらの settings は、重要なトレードオフを コードの中や属人的な運用習慣に埋もれさせず、 見える形で保つのに役立ちます。
実際には、settings は normalization behavior、candidate display、 candidate scoring、auto-link policy、 explainability-related behavior に影響し、 canonical / review workflows 全体に関わります。
Normalize policy
raw vendor / product text を alias lookup、dictionary search、 candidate generation、canonical auto-link resolution の前に どう整形するかを制御します。
Candidate display
dictionary-based search や suggestion UI で vendor / product candidates をどう返すかを制御します。
Candidate scoring
candidates が存在する段階で、 それらをどう順位付け・フィルタ・説明するかを制御します。
Auto-link policy
raw software values を canonical vendor / product identity に どの程度積極的に自動解決するかを制御します。
Explainability
canonical decision process を UI 上でどこまで見せるかを制御します。
Canonical Mapping - Normalize policy
Normalize policy は、raw vendor / product text を alias lookup、dictionary search、candidate generation、 canonical auto-link resolution の前にどのように前処理するかを制御します。
この段階は candidate ranking より前にあるため、 UI 上の review quality と background workflows における自動 linking の両方に影響します。
Extract vendor from DN publisher
有効にすると、証明書風の DN 文字列のような publisher value から、 よりきれいな organization name を抽出できます。
これにより、
CN=..., O=Microsoft Corporation, ...
のような raw vendor values を alias lookup 前に正規化しやすくなります。
Remove vendor common phrases
canonical vendor の識別に役立たない、 vendor 側の一般的な filler phrases を除去します。
実際の vendor 名以外に、 法人格表記や組織表現が多く含まれる noisy な publisher strings に有効です。
Remove vendor legal suffix
vendor normalization の過程で、Inc、Ltd、LLC などの corporate suffix を除去します。
これにより、vendor keys を canonical CPE naming style に近づけます。
Remove product architecture suffix
(x64)、(64-bit)、(arm64)
のような architecture / bitness 表記を除去します。
これにより、見た目は違っていても意味的には同じ product names を 同じ normalized key に寄せやすくなります。
Remove product locale tag
en-us のような locale markers や
類似の language-region tags を product text から除去します。
locale が canonical product identity の一部ではなく、 packaging noise に過ぎない場合に有効です。
Remove Java update suffix
Update 321 のような Java 特有の update decorations を除去します。
これにより、Java 系 product names を canonical dictionary entries とより安定して対応付けやすくなります。
Remove trailing product version
normalized lookup key を作る前に、 product name の末尾に付いた version text を除去します。
canonical product identity 自体は変わらないのに、 installed version の違いで product grouping が分断されることを防ぎます。
version 情報は別途保持され、 後段の vulnerability evaluation で使用されます。 この設定は normalized product lookup key のみを変更します。
Canonical Mapping - Candidate display
Candidate display は、dictionary-based search や suggestion UI において vendor / product candidates をどう返すかを制御します。
これらの settings は主に、 review workflows で canonical vendor / product candidates を選ぶ際の 見え方に影響します。
Minimum characters
vendor / product suggestions を返す前に必要な、 normalized query の最小長を定義します。
値を小さくすると早い段階で suggestions が出ますが、 noisy matches が増えることもあります。
Exact candidates limit
exact-match candidates を最大何件返すかを定義します。
exact vendor / product hits を先に見せたい画面に影響します。
Other candidates limit
prefix / contains 系の fallback candidates を 最大何件返すかを定義します。
候補を広く見たい場合は増やし、 ノイズを減らしたい場合は小さく保ちます。
Unresolved candidate cap
unresolved mapping 向けの flows で表示する candidate rows の上限を定義します。
値を小さくすると、unresolved review screens を見やすく保てます。
Canonical Mapping - Candidate scoring
Candidate scoring は、 Vulnerability detail、Unresolved Mappings、 その他の suggestion panels において、 vendor / product candidates をどう採点・順位付け・フィルタ・説明するかを制御します。
これらの settings は normalization 自体を変えるものではありません。 候補が存在した後で、どの候補が上位に来るかに影響します。
Maximum displayed rows
Vulnerabilities > Detail に表示する unresolved mapping candidates の 最大件数を定義します。
値を低くするとパネルは絞り込まれ、 値を高くすると手動 review のためにより多くの候補を見せられます。
Vendor exact score
unresolved vendor が affected CPE vendor と完全一致したときに加算する score です。
Vendor partial score
vendor names が完全一致ではないが、部分的に整合している場合に加算する score です。
Product exact score
unresolved product が affected CPE product と完全一致したときに加算する score です。
Token overlap score
product names が複数の意味ある token を共有している場合に加算する score です。
exact equality では厳しすぎる長い product names に有効です。
Partial match score
より弱い類似性しか見つからなかった場合に使う、 小さめの fallback score です。
Only active unresolved rows
有効にすると、suggestion panel は まだ active な unresolved mappings のみを考慮します。
inactive や historical rows も含めたい場合にのみ無効化します。
Show reasons
各 candidate にどのような理由でその score が付いたかを表示します。
これにより、ranking behavior の理解や調整がしやすくなります。
Canonical Mapping - Auto-link policy
Auto-link policy は、raw vendor / product values を resolve、import、backfill などの自動処理で canonical CPE vendor / product IDs にどう解決するかを制御します。
一部の options はすでに現在の実装で有効ですが、 一部は将来の strict-mode wiring に向けて保存されているものです。
Use alias mapping
有効にすると、direct canonical lookup の前に alias normalization を用いて resolution を行います。
software canonical linking の resolve、import、backfill に影響します。
Use token fallback
有効にすると、direct product matching だけでは不十分な場合に、 token-based fallback logic を再試行できます。
短縮された product names や少しノイズのある product names からの回復に役立つ一方、 matching behavior が広がりすぎることもあります。
Allow contains match
将来的な canonical auto-link logic において、 より広い substring-style matching を許可するための想定設定です。
現時点では保存されますが、 現在の resolve path の主要スイッチではありません。
Require unique vendor hit
vendor resolution が一意な場合にのみ automatic linking を許可するための想定設定です。
recall より precision を重視する stricter matching modes に向いています。
Require unique product hit
resolved vendor の下で product resolution が一意な場合にのみ automatic linking を許可するための想定設定です。
将来 stricter auto-link criteria を導入しても settings schema を変えなくて済むよう、今のうちに保存されています。
Skip disabled rows
canonical-link-disabled とされた rows を automatic canonical resolution から除外します。
これにより、ユーザーが明示的に disable した判断を resolve や backfill でも維持できます。
Minimum score
将来的に score-based acceptance rule を導入するための 予約済み threshold です。
後から schema changes なしで score-based acceptance rule を追加できるよう、今のうちに保存されています。
Canonical Mapping - Explainability
Explainability は、 canonical resolution が成功・失敗・スキップされた理由を UI でどこまで見せるかを制御します。
これらの settings は、 matching result 自体よりも user-facing transparency に関するものです。
Show decision reason
なぜその row が matched、vendor-only、unresolved になったのかといった canonical decision の human-readable reason を表示します。
Show score breakdown
canonical decision の背後にある score components を より詳細に表示する将来 UI のための予約設定です。
値は保存されますが、現行画面ではまだ十分には表面化していません。
Show skip reason
canonical linking が disabled であった、 usable な normalized key がなかった、 といった resolution skip の理由を表示します。
Key idea: これらの settings はすべて同じ形で matching を変えるわけではありません。 現在の resolve path に直接影響するものもあれば、 主に見せ方だけを変えるものもあり、 また、将来より厳密で explainable な workflows を settings model を変えずに導入するために保存されているものもあります。
Users と roles
AVM には administrative user management と role-aware access control があります。 これは、特に管理変更が reference data、import behavior、 alerting outcomes に影響する環境で、安全に運用するための重要な要素です。
User management
管理者ユーザーは、application users と account state を管理できます。
Roles
roles は、どの部分のアプリケーションを利用できるか、 どの変更が許可されるかを決定します。
Security audit visibility
AVM には、重要な管理イベントやアカウントイベントを確認できる security-audit-oriented visibility があります。 これは traceability を支え、データ変更だけでなく、 security-relevant system activity の理解にも役立ちます。
特に、管理操作が reference data、user state、 system-wide matching behavior に影響する場合、 audit visibility は重要です。
運用ループの例
operator が新しい inventory source から software を import したとします。 一部の rows は問題なく linked されますが、 naming variation のため unresolved のまま残る rows もあります。 operator は unresolved mappings を review し、 vendor / product aliases を追加し、 canonical backfill を実行し、 その後 alerts を再生成して newly resolved software を正しく評価できるようにします。
AVM では、この流れは例外的な復旧作業ではありません。 ふつうの運用そのものです。
AVM が避けようとしていること
見えないメンテナンスロジック
reference improvement や generation は、 見える形で操作できるべきです。
一方向の ingestion
canonical coverage や alert quality を 後から改善できないのであれば、 import だけでは不十分です。
不透明な administration
settings、runs、review surfaces、audit visibility は 理解可能な状態で保たれるべきです。
まとめ
AVM の admin side は、 プラットフォームを正確に、理解可能に、そして運用上有用な状態に保つ場所です。 そこでは reference sync、import review、canonical improvement、 alert generation、system settings、user control、audit visibility が 一つの maintainable workflow としてつながっています。
そのため、AVM の administration は 単なる setup screens の集まりではなく、 review と improvement のループとして理解するのが適切です。