Observed inventory
AVM stores software as it was observed, including source-side vendor, product, publisher, and version context.
Open-source asset-aware vulnerability management
Make software-to-CPE linking and vulnerability matching visible.
AVM helps you review how software is linked, how vulnerability conditions are evaluated, and why alerts are generated.
Review unresolved software
See candidate mappings instead of leaving gaps hidden.
Control product linking
Operators can confirm and refine mappings with support from
suggested candidates.
Generate explainable alerts
Understand why alerts were generated, uncertain, or not
generated.
Try AVM
LiveLive Demo
Explore AVM with a preloaded environment. No setup required.
Read-only demo: changes such as imports, edits, or administrative updates are
disabled.
🔒 Access credentials are shared via official announcements.
🔒 Access credentials are shared via official announcements.
What AVM enables
- Find vulnerabilities even when software is not fully linked Unlinked software is surfaced as candidate matches for vulnerabilities instead of being ignored.
- Control how software is linked to canonical vendor and product identities AVM suggests candidates based on dictionary, aliases, and synonyms, while keeping final linking decisions in the hands of the operator.
- Resolve software identity with canonical vendor and product references Alias support improves matching quality over time through explicit review workflows.
- Evaluate real applicability, not just name similarity Matching uses CPE relationships, structured criteria, and version-aware evaluation.
- Continuously improve coverage through visible review loops Unresolved mappings, suggestions, and backfill workflows are part of normal operation.
About
AVM treats inventory, identity, and matching as different things
Many environments can collect software inventory. The harder part is understanding what that software actually is, how reliably it maps to canonical references, and whether stored vulnerability conditions really apply.
AVM is designed around that distinction. It keeps observed software visible as raw evidence, resolves canonical identity explicitly, evaluates vulnerability applicability carefully, and preserves unresolved cases as part of the operating model.
Canonical identity
AVM links software to canonical vendor and product references so downstream matching does not depend only on unstable raw strings.
Operational result
AVM creates alerts as a distinct result of evaluating software against stored vulnerability conditions.
Target Use Cases
Designed for understanding before scaling
AVM emphasizes transparency and interpretability in vulnerability management:
Inspectable asset-to-CPE linkage
AVM keeps visible how assets and software are connected to CPEs instead of hiding the linkage behind opaque automation.
Explainable applicability decisions
AVM helps operators understand why vulnerabilities are considered applicable by separating identity resolution, criteria logic, and version-aware evaluation.
Visible uncertainty
AVM preserves unresolved mappings as reviewable work so gaps in canonical coverage remain understandable and improvable.
To support this, AVM is designed for small-scale environments, proof-of-concept deployments, and learning or research use.
This makes AVM a practical tool for understanding, validating, and refining vulnerability management logic before scaling to larger environments.
Vision
No environment left without a starting point
While AVM currently targets smaller environments, its longer-term goal is broader:
To eliminate situations where vulnerability management is left unaddressed due to cost or resource constraints.
In many organizations, especially those with limited budgets or personnel, introducing a full-scale commercial vulnerability management platform is not always feasible. As a result, vulnerability management may remain partially implemented—or in some cases, not implemented at all.
AVM aims to bridge this gap.
Lightweight and accessible
AVM provides a practical starting point for environments that need useful vulnerability management without large-scale platform overhead.
Clear matching visibility
Matching logic, review state, and uncertainty remain visible so operators can understand what the system is doing and why.
User-controlled linking
AVM allows users to control how software is linked to CPEs, making adoption safer and more understandable in smaller environments.
The goal is not to replace enterprise-grade platforms, but to ensure that:
“No environment is left without a viable starting point for vulnerability management.”
AVM exists to make vulnerability management accessible, understandable, and actionable — even in environments where traditional solutions are out of reach.
Why AVM is different
It is not just feed ingestion plus name matching
AVM is built for environments where software naming is imperfect, canonical coverage improves over time, and applicability decisions need to be understandable rather than hidden behind a black box.
Canonical references instead of raw strings alone
AVM uses canonical vendor and product references to stabilize matching across inconsistent source-side naming.
Structured matching instead of flat name comparison
AVM evaluates affected CPE relationships, criteria logic, and version conditions rather than treating similarity as proof.
Review loops instead of hidden cleanup
Unresolved mappings, aliases, synonyms, backfill, and recalculation are visible parts of normal operation.
Workflow
The normal operating loop
AVM is easiest to understand as a repeating workflow, not as a single import action or a single alert screen.
Import assets and software
→
Review unresolved mappings
→
Improve aliases and synonyms
→
Backfill canonical links
→
Generate alerts
This loop is part of normal operation. It is how AVM improves coverage over time without discarding raw inventory evidence.
Features
Core capabilities
AVM brings together inventory handling, canonical software identity, structured vulnerability evaluation, and review-oriented administration.
Asset-centered inventory
Software is tied to assets so inventory and alerting stay grounded in host context.
Staged import
Assets and software are validated into staging before becoming part of the main operational model.
Canonical vendor and product linking
Raw software names can be connected to normalized vendor and product references through reviewable resolution workflows.
Structured vulnerability matching
Matching uses affected CPE relationships, criteria structure, and version-aware evaluation.
Visible unresolved workflows
Incomplete canonical coverage remains visible through unresolved mapping and review surfaces.
Operational alert lifecycle
Alerts are created and recalculated as a distinct operational result, not as an invisible side effect.
Reference maintenance
Aliases, synonyms, settings, and sync workflows support ongoing improvement of system quality.
Administrative visibility
Runs, settings, user management, and audit-related records help keep operation understandable over time.
Architecture
From observed software to operational alerts
AVM separates raw inventory, canonical references, vulnerability logic, and operational results into distinct but connected layers.
Asset
→
SoftwareInstall
→
Canonical vendor/product
→
Criteria + version evaluation
→
Alert
Raw evidence is preserved
Import does not erase source-side naming or context. AVM keeps raw software values visible for later review.
Reference truth is separate
Canonical vendors, products, aliases, synonyms, and vulnerability conditions live in their own reference layer.
Results are explicit
Alerts are stored as operational results that can be reviewed, recalculated, and improved as coverage changes.
Docs
Where to go next
The docs are organized around how AVM actually works, not only around screen names.
Getting Started
Follow the first operational path through import, review, sync, recalculation, and alert inspection.
Concepts
Understand raw inventory, canonical identity, inspectability, and the review loop.
Data Model
See how assets, software, canonical references, vulnerability entities, alerts, and admin records are structured.
Matching
Learn how AVM evaluates affected software using canonical linkage, criteria, and version-aware logic.
Import
See how staged import works and why successful import is not the same as full canonical resolution.
Admin
Understand the maintenance loop behind sync, unresolved review, aliases, backfill, recalculation, and settings.
Roadmap
Current focus
AVM is already structured around canonical identity, staged import, structured matching, and operational review. Current work continues to improve the quality, visibility, and usability of that model.
Japanese UI
Improve the Japanese-language user interface so the product is easier to operate and explain in Japanese-speaking environments.
Docker delivery
Provide AVM through Docker so setup, evaluation, and self-hosted use are easier and more consistent across environments.
Scheduled operations and notifications
Add scheduling for Update KEV Catalog, CVE Delta Update (API), and Generate alerts, and add notifications for Generate alerts execution results.
Dashboard depth
Add more useful information to the dashboard so important operational state is visible earlier and with less navigation.
Documentation depth
Continue to strengthen docs around the real data model, matching behavior, import flow, and operating loop.
SBOM integration
Support SBOM formats (CycloneDX, SPDX) as an additional inventory source, aligning component data with AVM’s canonical model to extend vulnerability evaluation beyond host-level software.