Asset-Vuln-Manager (AVM)

AVM Docs

Documentation

AVM documentation is organized around practical operations: getting the application running, understanding the core concepts, importing inventory data, linking canonical references, and reviewing alerts.

Try AVM

Live Demo

Explore AVM with a preloaded environment. No setup required.

Open Demo →
Read-only demo: changes such as imports, edits, or administrative updates are disabled.
🔒 Access credentials are shared via official announcements.

Recommended reading path

If you are new to AVM, read these pages in order. This sequence moves from basic usage to the core model and then to operational workflows.

1. Getting Started

Run AVM locally, open the UI, and understand the first workflow from asset to alert.

2. Concepts

Learn the main ideas behind AVM: assets, software, aliases, canonical linking, vulnerabilities, and alerts.

3. Matching

See how AVM turns raw software inventory into reviewable findings through normalization, canonical linking, and version-aware evaluation.

Documentation map

The docs are divided into setup, concepts, operations, and structure.

Getting Started

The quickest path to running AVM and understanding the first operational flow.

Concepts

The core mental model of the project and why AVM is designed to avoid black-box matching.

Matching

A step-by-step explanation of how AVM correlates software records with vulnerability data.

Import

How CSV and JSON inventory enter the system through staged, previewable workflows.

Admin

Sync jobs, unresolved review, alias maintenance, recalculation, and operational settings.

Data Model

The structural view of AVM: assets, software, canonical references, vulnerabilities, alerts, and runs.

Choose by task

I want to understand why an alert exists

Read Matching.

I want to ingest inventory

Read Import.

I want to maintain the system

Read Admin.

What to expect from these docs

Operational focus

These docs are written for using and understanding the system, not only for reading code.

Inspectable logic

AVM aims to make aliasing, canonical linking, and alert generation understandable.

Incremental growth

The documentation can expand page by page without needing a full redesign.

Open-source friendly

The structure is intended to help contributors, evaluators, and operators understand the project quickly.

Documentation principles

Inspectable

AVM should explain what it matched, why it matched it, and where review is needed.

Operational

Docs should help operators use the system, not just describe implementation details.

Structured

Concepts, workflows, and data structures should connect clearly across pages.

Practical

The most important pages should answer real usage questions first.

Next Getting Started