観測されたインベントリ
AVM は、source 側の vendor、product、publisher、version の文脈を含め、 観測されたままのソフトウェア情報を保持します。
オープンソースのアセット認識型 脆弱性管理
ソフトウェアとCPEのリンクと 脆弱性マッチングを可視化する
AVM は、ソフトウェアがCPEとどのようにリンクされるのか、 脆弱性条件がどのように評価されるのか、 そしてなぜアラートが生成されるのかを確認できるようにします。
CPEとのリンクをコントロール:
自動的に提案される候補を参考にしながら、オペレーターがソフトウェアとCPEのリンクを確認・調整できます。
未解決ソフトウェアをレビュー:
CPEとリンクされていないソフトウェアも放置されず、特定の脆弱性にマッチする可能性がある場合は提示されます。
説明可能なアラートを生成:
アラートがなぜ生成されたのか、またそのアラートの確実性を理解できます。
AVM を試す
Liveライブデモ
あらかじめデータが投入された環境で AVM を試せます。セットアップは不要です。
読み取り専用デモ: インポート、編集、管理系の更新などの変更操作は無効です。
🔒 アクセス用認証情報は公式アナウンスで案内します。
🔒 アクセス用認証情報は公式アナウンスで案内します。
AVMでできること
- ソフトウェアが完全にリンクされていなくても脆弱性を見つける CPEにリンクされていないソフトウェアも無視せず、 特定の脆弱性にマッチする候補マッチとして可視化します。
- ソフトウェアを canonical vendor / product identity にどう結び付けるかを制御する AVM はCPE辞書、alias に基づいて候補を提示し、 最終的なリンクの判断はオペレーターが行えます。
- canonical vendor / product reference に基づいてソフトウェア識別を解決する alias の活用により、明示的なレビューを通じて 脆弱性マッチングの品質を継続的に改善できます。
- 単なる名前の類似ではなく、実際の適用可能性を評価する 脆弱性マッチングは CPE の関係、構造化された criteria、 バージョン考慮型の評価に基づいて行われます。
- 可視化されたレビューのループを通じて継続的にカバレッジを改善する 未解決のソフトウェアのマッピング、リンク候補の提案、backfill のワークフローは 通常運用の一部として組み込まれています。
概要
AVM は、インベントリ、識別、マッチングを別のものとして扱います
多くの環境ではソフトウェアインベントリを収集できます。 しかし難しいのは、そのソフトウェアが実際には何なのか、 canonical reference にどれだけ信頼して対応付けられるのか、 そして保持されている脆弱性条件が本当に適用されるのかを理解することです。
AVM はその違いを前提に設計されています。 観測されたソフトウェアを生の証跡として保持し、 canonical identity を明示的に解決し、 脆弱性の適用可能性を慎重に評価し、 未解決ケースも運用モデルの一部として残します。
Canonical identity
AVM はソフトウェアを canonical vendor / product reference にリンクし、 後続の脆弱性マッチングが不安定な生文字列だけに依存しないようにします。
運用上の結果
AVM は、保持された脆弱性条件に対してソフトウェアを評価した結果として、 アラートを独立した結果データとして作成します。
想定ユースケース
いきなり拡張する前に、まず理解するための設計
AVM は、脆弱性管理における透明性と解釈可能性（Interpretability）を重視しています。
確認可能な asset-to-CPE linkage
AVM は、資産の software が CPE にどう結び付けられているかを見える形で保持し、 その対応付けをブラックボックスな自動処理の中に隠しません。
説明可能な applicability judgment
AVM は、identity resolution、criteria logic、 version-aware evaluation を分離することで、 なぜ脆弱性が適用対象と判断されたのかを理解しやすくします。
見える不確実性
AVM は CPE とのリンクが未解決なソフトウェアをレビュー対象とし、 canonical coverage の不足を理解しやすく、改善しやすい状態に保ちます。
AVM は、フルスケールのプロダクト導入が現実的でない小規模環境、PoC、学習・研究用途に最適です。
これにより AVM は、大規模環境へ拡張する前に、 脆弱性管理ロジックを理解し、検証し、改善するための実用的なツールになります。
ビジョン
すべての環境に脆弱性管理の出発点を提供する
AVM は現在は小規模環境を主な対象としていますが、 長期的な目標はそれより広いものです。
それは、コストやリソース制約のために 脆弱性管理が手付かずのまま残る状況を減らすことです。
多くの組織、特に予算や人員に限りがある組織では、 フルスケールの商用脆弱性管理プラットフォームを導入することが 常に現実的とは限りません。 その結果、脆弱性管理が部分的にしか実施されなかったり、 場合によっては全く実施されなかったりすることがあります。
AVM はこのギャップを埋めることを目指します。
軽量で導入しやすい
AVM は、大規模プラットフォームの負荷なしに、 実用的な脆弱性管理の出発点を必要とする環境に向けた現実的な選択肢を提供します。
明確な matching visibility
matching logic、review state、不確実性が見える形で残るため、 オペレーターはシステムが何をしているのか、なぜそうなったのかを理解できます。
ユーザー主導のリンク
AVM は、ソフトウェアを CPE にどうリンクするかをユーザーが制御できるため、 小規模環境でもより安全で理解しやすい導入が可能です。
目標は enterprise-grade platform を置き換えることではなく、 次の状態を実現することです。
「すべての環境に脆弱性管理の現実的な出発点を提供すること」
AVM は、従来のソリューションが手の届きにくい環境でも、 脆弱性管理を実行可能で、理解しやすく、行動につなげやすいものにするために存在します。
AVM のユニークな点
単なる feed ingestion と name matching ではない
AVMは、ソフトウェア名の表記揺れやバリエーションにより、観測された名前がそのままCPEに対応付けられない現実を前提とし、canonical coverage を継続的に改善しながら、脆弱性の適用判断をブラックボックスではなく理解可能な形で扱いたい環境向けに設計されています。
正規化されていないソフトウェア名だけに頼らない canonical reference
AVM は canonical vendor / product reference を用いて、 source 側の不揃いなソフトウェア名に対してもマッチングを安定化させます。
単純な名前比較ではない structured matching
AVM は similarity をそのまま根拠にせず、 affected CPE relationship、criteria logic、version condition を評価します。
見えない後処理ではなく review loop
未解決のソフトウェア対応や、名前の揺れを吸収するための調整、ソフトウェアと CPE の再リンク、脆弱性マッチングの再評価といった処理は、特別な作業ではなく、通常運用の一部として見える形で扱われます。
ワークフロー
通常運用のループ
AVM は、単発のインポート操作や単一のアラート画面ではなく、 繰り返されるワークフローとして理解するのが最も分かりやすい設計です。
asset と software をインポート
→
software と CPE の対応付けが未確定な項目をレビュー
→
alias を改善
→
正規化された vendor / software への紐付け
→
アラートを生成
このループは通常運用の一部です。 インポートされたままのインベントリ証跡を捨てることなく、時間とともに coverage を改善していく仕組みです。
機能
コア機能
AVM は、インベントリ管理、canonical software identity、 structured vulnerability evaluation、レビュー指向の administration を統合します。
asset 中心のインベントリ
software は asset に結び付けられるため、 インベントリとアラートがホスト文脈に基づいたものになります。
staged import
asset と software は、メインの運用モデルに入る前に staging で検証されます。
canonical vendor / product linking
生のソフトウェア名は、レビュー可能な resolution workflow を通じて、 正規化された vendor / product reference に結び付けられます。
structured vulnerability matching
matching は affected CPE relationship、criteria structure、 version-aware evaluation を用います。
見える unresolved workflow
canonical coverage が不完全な部分は、 unresolved mapping と review surface を通じて可視のまま保たれます。
運用上の alert lifecycle
alert は見えない副作用としてではなく、 独立した運用結果として作成・再計算されます。
reference maintenance
alias、synonym、setting、sync workflow が、 システム品質の継続的改善を支えます。
administrative visibility
run、setting、user management、audit-related record が、 時間がたっても運用を理解しやすく保ちます。
アーキテクチャ
観測されたソフトウェアから運用アラートへ
AVM は、生のインベントリ、canonical reference、脆弱性ロジック、 運用結果を、つながりは保ちつつ別レイヤーとして分離します。
Asset
→
SoftwareInstall
→
Canonical vendor/product
→
Criteria + version evaluation
→
Alert
生の証跡を保持
import は source 側の命名や文脈を消しません。 AVM は、後から見直せるよう raw software value を保持します。
reference truth は別管理
canonical vendor、product、alias、synonym、 vulnerability condition は独立した reference layer に存在します。
結果は明示的に扱う
alert は、coverage の変化に応じてレビュー・再計算・改善可能な 運用結果として保持されます。
Docs
次に見るべきところ
Docs は、単なる画面一覧ではなく、 AVM が実際にどう動くかに沿って整理されています。
Getting Started
import、review、sync、recalculation、alert inspection まで、 最初の運用フローをたどれます。
Concepts
raw inventory、canonical identity、inspectability、 review loop の考え方を理解できます。
Data Model
asset、software、canonical reference、vulnerability entity、 alert、admin record がどう構造化されているかを確認できます。
Matching
canonical linkage、criteria、version-aware logic を用いて、 AVM がどのように affected software を評価するかを学べます。
Import
staged import がどのように動くか、 そして import 成功が canonical resolution 完了と同じではない理由を確認できます。
Admin
sync、unresolved review、alias、backfill、recalculation、 settings を支える maintenance loop を理解できます。
ロードマップ
現在の重点項目
AVM はすでに canonical identity、staged import、 structured matching、operational review を軸に構成されています。 現在の作業は、そのモデルの品質、可視性、使いやすさをさらに高めることにあります。
Japanese UI
日本語環境でより使いやすく説明しやすいよう、 日本語UIを改善します。
Docker delivery
Docker で AVM を提供し、 セットアップ、評価、セルフホスト利用をより簡単で一貫したものにします。
Scheduled operations and notifications
Update KEV Catalog、CVE Delta Update (API)、Generate alerts の スケジュール実行と、 Generate alerts 実行結果の通知を追加します。
Dashboard depth
ダッシュボードにより有用な情報を追加し、 重要な運用状態をより少ない画面遷移で早く把握できるようにします。
Documentation depth
実際の data model、matching behavior、import flow、 operating loop に関する Docs をさらに充実させます。
SBOM integration
SBOM 形式（CycloneDX、SPDX）を追加の inventory source としてサポートし、 component data を AVM の canonical model に整合させることで、 host-level software を超えた vulnerability evaluation を可能にします。