Admin
How AVM is operated and improved over time
The administrative side of AVM is not only for setup. It is the operational surface where reference data is synced, inventory is reviewed, canonical coverage is improved, alerts are recalculated, and system behavior remains visible.
Reference data sources used by AVM
AVM uses external reference data to support canonical linking and vulnerability evaluation.
CVE Feed
AVM imports vulnerability records from the National Vulnerability Database (NVD).
This data provides CVE identifiers, descriptions, severity information, published and modified dates, and affected CPE conditions used during matching.
In AVM, this data is fetched through the CVE sync workflow in the Admin area and stored as vulnerability and affected CPE records.
CPE Dictionary
AVM uses the Official CPE Dictionary from NVD as the canonical reference for vendor and product identities.
This dictionary is used to normalize observed software names and connect raw inventory data to stable canonical identities.
In AVM, this data is fetched through the CPE sync workflow and stored as canonical vendor and product reference data.
KEV Information
AVM also imports KEV (Known Exploited Vulnerabilities) information from CISA’s KEV Catalog.
KEV identifies vulnerabilities that are known to be actively exploited in the wild and can be used to support prioritization.
In AVM, this data is fetched through the KEV sync workflow and attached to vulnerability records as additional operational context.
How this data is used in AVM
AVM does not directly match raw software inventory to vulnerabilities. Instead, it evaluates vulnerabilities through a structured pipeline:
-
Canonical linking
Imported software (vendor, product, version) is linked to canonical vendor and product identities based on the CPE dictionary.
This step is executed by running Run Linking. -
Vulnerability evaluation
Linked software is evaluated against CVE data using affected CPE conditions and version-aware logic.
This step is executed by running Generate Alerts. -
Prioritization context
KEV data is attached to vulnerabilities to indicate known exploitation in the wild.
Because these steps are separated, updating reference data alone does not immediately change alert results.
Important:
- After updating the CPE Dictionary → run Run Linking
- After updating the CVE Feed or KEV → run Generate Alerts
How AVM retrieves and updates this data
AVM retrieves these datasets through dedicated admin sync jobs.
Each sync process records metadata about the last fetched content so unchanged data can be skipped and later runs remain reviewable in the Admin area.
Reference sources:
How AVM is operated
AVM provides administrative workflows for maintaining both the reference side of the system and the operational side. That includes vulnerability and dictionary sync, staged import review, canonical and unresolved mapping workflows, alias and synonym maintenance, alert generation, run history, system settings, user management, and security audit visibility.
These admin areas are connected. In practice, operators use them as a loop: import data, review what did not resolve cleanly, improve reference coverage, backfill canonical links, and then recalculate alert state.
Key idea: administration in AVM is part of the product’s operating model, not just a hidden maintenance panel.
Operational flow
Reference sync, settings, users, and audit functions support this loop rather than sitting outside it.
How software linking works in AVM
AVM connects imported software inventory to canonical vendor and product identities through a structured, semi-automated workflow.
1. Import inventory
First, import your assets and software.
Asset import registers the systems you manage. Software import registers observed software such as vendor, product, and version.
AVM preserves these raw values as observed evidence.
2. Automatic candidate preparation
During import, AVM prepares candidate matches using normalization, aliases and synonyms, and dictionary matching.
However, at this stage, candidates are not yet fully materialized for review in all screens.
3. Run initial linking (required step)
Before reviewing candidates, you must run Run Linking.
This step is required because it evaluates candidate matches across the dataset, materializes linking results and candidates, and enables candidate display in the Unresolved view.
Without this step, the Resolve column in Unresolved Mappings will not show candidates.
4. Review linking results
After running linking, software will fall into states such as fully linked, vendor only, resolvable, and unresolved.
Fully linked means vendor and product are identified. Vendor only means a partial match. Resolvable means a strong candidate is available. Unresolved means no reliable candidate is available yet.
Use the Review Product Mappings screen to understand overall coverage.
5. Refine linking results
After the initial Run Linking, refine the results as needed.
If a link is correct, keep it. If a link is incorrect, use Disable Link. If a better candidate exists, select it in Unresolved Mappings and apply linking.
This step is where operator control is applied.
6. Handle unresolved mappings
In Unresolved Mappings, you can view candidate vendor and product suggestions, manually select the correct mapping, and resolve ambiguous or missing links.
This screen becomes fully functional only after Run Linking has been executed.
7. Improve future linking
To reduce manual work over time, maintain vendor aliases, product aliases, and synonyms.
Improving these will increase automatic linking accuracy and reduce unresolved items in future imports.
Key idea: linking in AVM is a two-phase process: Run Linking materializes candidates and applies automatic matches, then manual refinement is used to disable or correct links. This keeps both automation and operator control visible.
Reference sync
AVM includes admin workflows for loading and refreshing reference data used by later matching and prioritization. This includes vulnerability data and canonical reference data such as the product dictionary.
Vulnerability sync
Updates stored vulnerability intelligence used for later evaluation and alert generation.
Dictionary sync
Updates reference-side vendor and product data used in canonical linking and matching.
Why sync matters
Matching quality depends not only on inventory quality but also on the quality and freshness of the reference model.
Import review
Import in AVM is staged and reviewable. Administrative import screens allow operators to inspect what was uploaded, what passed validation, what did not, and what is about to enter the main inventory tables.
This helps distinguish “data entered the system” from “data is already fully normalized and match-ready”.
Preview before commit
Staged rows can be inspected before final import.
Import run visibility
Import actions are tied to run records so later review has context.
Evidence preserved
Raw imported values remain important even after the import is complete.
Canonical and unresolved review
Canonical status meanings
In the Canonical view, each software row is assigned a status that reflects how far it has progressed in the linking workflow.
These statuses combine two dimensions: current linkage state and whether a reliable candidate exists.
Fully Linked
Both vendor and product are linked to canonical references.
This is the ideal state. The software is ready for reliable vulnerability evaluation.
Vendor Only Linked
Vendor is linked, but product is not.
This usually means the vendor was identified correctly, but the product name still needs review or better normalization.
Not Linked
Neither vendor nor product is linked.
The system does not yet have enough information to identify this software.
Linked (Valid)
A link exists and is currently considered valid.
This indicates the link has not been disabled and is actively used during matching.
Linked (Stale)
A link exists but is no longer considered active.
This typically occurs when a link was disabled or replaced and is kept only for historical traceability.
Fully Resolvable
The software is not yet fully linked, but a high-confidence candidate exists for both vendor and product.
In most cases, this can be resolved automatically by running Run Linking or confirmed with minimal review.
Vendor Resolvable
A reliable candidate exists for vendor, but not for product.
This is a partial resolution state and usually leads to Vendor Only Linked after linking.
Unresolvable
No reliable candidate could be identified.
Manual intervention is required, such as adding aliases or selecting a mapping in the Unresolved view.
Not Normalized
The raw software name has not been normalized into a form suitable for matching.
This often indicates input quality issues or the need for improved normalization or synonym rules.
Key idea: Canonical status does not only show what is already linked. It also shows what can be linked automatically and what still requires human review.
One of the most important admin workflows in AVM is the review of canonical coverage. Imported software is more useful once it is linked to canonical vendor and product identities. Where that linkage is incomplete, AVM keeps unresolved mappings visible.
The canonical and unresolved screens support different but related views of this problem: what is already linked, what is only partially linked, and what still needs explicit review.
Canonical view
Shows the current state of vendor and product linkage across software inventory.
Unresolved view
Highlights software rows whose names still need canonical review or support from aliases and synonyms.
Why this matters
Better canonical coverage leads to more reliable downstream matching and alert generation.
Alias learning from Unresolved Mappings
When you create a link in Unresolved Mappings, AVM does more than just resolve that single row.
The selected Row Vendor / Product to Canonical Vendor / Product mapping is also stored as an alias.
Future imports become easier
Once this alias is registered, the same raw vendor and product values can be recognized automatically during later imports.
In practice, this means the same software can be linked automatically next time instead of requiring the same manual review again.
Manual review improves automation
A manual link in Unresolved Mappings is not only a one-time correction. It also improves future matching behavior.
This is one of the ways AVM turns review work into reusable canonical knowledge.
Aliases can be exported as JSON
AVM can export registered aliases as JSON.
This exported data can be kept as a reusable mapping dataset rather than remaining locked inside a single environment.
Alias Seed can be imported later
Exported alias JSON can be imported back into AVM as an Alias Seed.
This makes it possible to carry forward previously learned mapping knowledge and reduce repeated manual work across environments or future deployments.
Key idea: resolving rows in Unresolved Mappings does not only fix the current dataset. It also builds reusable alias knowledge that can be exported, imported, and accumulated over time.
Canonical backfill and alert generation
AVM separates the improvement of canonical linkage from the evaluation of alert state. This makes the workflow easier to reason about.
After aliases, synonyms, or manual review improve canonical coverage, operators can run canonical backfill and then generate alerts so the operational result reflects the new linkage state.
This loop is one of the clearest examples of AVM’s inspectable operating model.
Runs and history
Administrative actions in AVM are tied to run-oriented views so operators can see what happened during sync, import, or related processing steps.
Run visibility is important for troubleshooting, auditing, and understanding whether a change in system state came from new data, improved resolution, or explicit generation.
Why runs matter
They preserve execution context for later review.
What they help with
Validation, troubleshooting, and understanding operational sequence.
System settings
AVM includes settings that influence matching and review behavior. These settings help keep important tradeoffs visible instead of burying them in code or one-off operational habits.
In practice, settings can shape normalization behavior, candidate display, candidate scoring, auto-link policy, and explainability-related behavior across canonical and review workflows.
Normalize policy
Controls how raw vendor and product text is cleaned before alias lookup, dictionary search, candidate generation, and canonical auto-link resolution.
Candidate display
Controls how vendor and product candidates are returned by dictionary-based search and suggestion UIs.
Candidate scoring
Controls how candidates are ranked, filtered, and explained once possible matches already exist.
Auto-link policy
Controls how aggressively AVM should resolve raw software values to canonical vendor and product identities during automatic processing.
Explainability
Controls how much of the canonical decision process is exposed to users in the UI.
Canonical Mapping - Normalize policy
Normalize policy controls how raw vendor and product text is preprocessed before alias lookup, dictionary search, candidate generation, and canonical auto-link resolution.
This stage happens earlier than candidate ranking, so it influences both review quality in the UI and automatic linking behavior in background workflows.
Extract vendor from DN publisher
When enabled, publisher values such as certificate-style DN strings may be reduced to a cleaner organization name.
This helps normalize raw vendor values like
CN=..., O=Microsoft Corporation, ... before alias lookup.
Remove vendor common phrases
Removes broad vendor-side filler phrases that do not help distinguish the canonical vendor.
This is useful for noisy publisher strings that contain extra legal or organizational wording beyond the actual vendor name.
Remove vendor legal suffix
Removes suffixes such as Inc, Ltd, LLC, or similar corporate tail text during vendor normalization.
This keeps vendor keys closer to canonical CPE naming style.
Remove product architecture suffix
Removes architecture or bitness decorations such as
(x64), (64-bit), or (arm64).
This helps collapse visually different but semantically equivalent product names into the same normalized key.
Remove product locale tag
Removes locale markers such as en-us or similar
language-region tags from product text.
This is useful when locale is packaging noise rather than part of the canonical product identity.
Remove Java update suffix
Removes Java-specific update decorations such as
Update 321 when those create unnecessary fragmentation in
product matching.
This keeps Java-family product names aligned with canonical dictionary entries more consistently.
Remove trailing product version
Removes trailing version text from the product name before building the normalized lookup key.
This improves candidate grouping when the canonical product identity should not change across installed versions.
Version information is still preserved separately and used later during vulnerability evaluation. This setting only changes the normalized product lookup key.
Canonical Mapping - Candidate display
Candidate display controls how vendor and product candidates are returned by dictionary-based search and suggestion UIs.
These settings mainly affect what users see while selecting canonical vendor and product candidates during review workflows.
Minimum characters
Defines the minimum normalized query length required before vendor or product suggestions are returned.
Lower values show suggestions earlier, but they can also increase noisy matches.
Exact candidates limit
Defines the maximum number of exact-match candidates returned before stopping.
This affects screens where exact vendor or product hits should appear first.
Other candidates limit
Defines the maximum number of fallback candidates, such as broader prefix or contains-style results.
Increase this when users need to browse more alternatives. Keep it smaller when reducing noise is more important.
Unresolved candidate cap
Defines the upper bound for candidate rows shown in unresolved mapping-oriented flows.
A smaller value keeps unresolved review screens easier to scan.
Canonical Mapping - Candidate scoring
Candidate scoring controls how vendor and product candidates are scored, ranked, filtered, and explained across Vulnerability detail, Unresolved Mappings, and related suggestion panels.
These settings do not change normalization itself. They influence which candidates rise to the top once possible matches already exist.
Maximum displayed rows
Defines the maximum number of unresolved mapping candidates shown on Vulnerabilities > Detail.
Lower values keep the panel focused. Higher values expose more alternatives for manual review.
Vendor exact score
Score added when the unresolved vendor matches the affected CPE vendor exactly.
Vendor partial score
Score added when vendor names are not exact matches but still partially align.
Product exact score
Score added when the unresolved product matches the affected CPE product exactly.
Token overlap score
Score added when product names share multiple meaningful tokens.
This is useful for longer names where exact equality is too strict.
Partial match score
Smaller fallback score used when only a weaker similarity is found.
Only active unresolved rows
When enabled, the suggestion panel only considers unresolved mappings that are still active.
Disable this only when you intentionally want inactive or historical unresolved rows included.
Show reasons
Shows why each candidate received its score.
This helps users understand and tune ranking behavior.
Canonical Mapping - Auto-link policy
Auto-link policy controls how raw vendor and product values may be resolved to canonical CPE vendor and product IDs during automatic processing such as resolve, import, and backfill.
Some options are already active in the current implementation, while others are stored now for future strict-mode wiring.
Use alias mapping
When enabled, resolution first uses alias normalization before direct canonical lookup.
This affects software canonical linking during resolve, import, and backfill.
Use token fallback
When enabled, the resolver may retry with token-based fallback logic if direct product matching is not sufficient.
This helps recover matches from shortened or slightly noisy product names, but it can also broaden matching behavior.
Allow contains match
Intended to allow broader substring-style matching in future canonical auto-link logic.
This value is stored now, but it is not yet a primary active switch in the current resolve path.
Require unique vendor hit
Intended to restrict automatic linking to cases where vendor resolution is unambiguous.
This is useful for future stricter matching modes that prioritize precision over recall.
Require unique product hit
Intended to restrict automatic linking to cases where product resolution is unambiguous under the resolved vendor.
This is stored now so stricter auto-link criteria can be introduced later without changing the settings schema.
Skip disabled rows
Excludes rows marked as canonical-link-disabled from automatic canonical resolution.
This preserves explicit user disable decisions during resolve and backfill.
Minimum score
Reserved threshold for future score-gated auto-link acceptance.
This value is stored now so a score-based acceptance rule can be introduced later without schema changes.
Canonical Mapping - Explainability
Explainability controls whether the UI should expose more detail about why canonical resolution succeeded, failed, or was skipped.
These settings are mainly about user-facing transparency rather than the matching result itself.
Show decision reason
Displays a human-readable reason for the canonical decision, such as why a row matched, stayed vendor-only, or remained unresolved.
Show score breakdown
Reserved for a future UI that exposes more detailed score components behind a canonical decision.
This value is saved now, but it is not yet fully surfaced in the current screens.
Show skip reason
Displays why resolution was skipped, for example because canonical linking was disabled or no usable normalized key was available.
Key idea: these settings do not all change matching in the same way. Some affect the current resolve path directly, some mainly change what users see, and some are stored now so stricter or more explainable workflows can be introduced later without changing the settings model.
Users and roles
AVM includes administrative user management and role-aware access control. This is part of operating the platform safely, especially where administrative changes affect reference data, import behavior, and alerting outcomes.
User management
Administrative users can manage application users and account state.
Roles
Roles determine which parts of the application can be used and which changes are permitted.
Security audit visibility
AVM includes security-audit-oriented visibility for important administrative and account events. This supports traceability and helps operators understand not only data changes, but also security-relevant system activity.
Audit visibility is especially important when administrative operations influence reference data, user state, or system-wide matching behavior.
Example operational loop
An operator imports software from a new inventory source. Some rows link cleanly, while others remain unresolved because of naming variation. The operator reviews unresolved mappings, adds vendor or product aliases, runs canonical backfill, and then recalculates alerts so newly resolved software can be evaluated correctly.
In AVM, that sequence is not an exceptional recovery process. It is part of normal operation.
What AVM is trying to avoid
Hidden maintenance logic
Reference improvement and generation should be visible and operable.
One-way ingestion
Import alone is not enough if canonical coverage and alert quality cannot improve afterward.
Opaque administration
Settings, runs, review surfaces, and audit visibility should remain understandable.
Summary
The admin side of AVM is where the platform is kept accurate, understandable, and operationally useful. It connects reference sync, import review, canonical improvement, alert generation, system settings, user control, and audit visibility into one maintainable workflow.
That is why administration in AVM is best understood as a review and improvement loop, not merely as a collection of setup screens.