Platform · Components
A bill of materials for every asset.
Every library an asset ships and every service it runs on, versioned, scoped, and end-of-life aware, in the same record that holds the asset's vulnerabilities, dependencies, and continuity plan.
Why it matters
An inventory says what you have. A bill of materials says what you are exposed to.
When the next Log4Shell lands, the only question that matters is where that version runs. Most teams answer it with a spreadsheet and a lost week, because the list of what each system is actually built from lives in a scanner export nobody has joined back to the asset.
Alvor records components on the asset itself. A software bill of materials (SBOM) captures the libraries each asset ships, by ecosystem and version, with scope and end-of-life dates. Technical components capture the databases, caches, gateways, and other infrastructure an application runs on. Both sit on the same record as the asset's vulnerabilities, dependencies, and continuity plan.
One asset record, one parts list. Blast radius for a CVE, an end-of-life date, or an unsupported dependency becomes a query, not a fire drill.
On every asset
Open an asset. See what it is made of.
A software bill of materials and the infrastructure it runs on, side by side on the asset record. No scanner export, no separate tool.
app.example.com
PostgreSQL 14.2
Database
Redis 7.0
Cache
NGINX 1.25
Load Balancer
S3 n/a
Storage
Capabilities
Know what every system is built from.
Software and infrastructure components, versioned, classified, and cross-linked across the platform.
A software bill of materials per asset
Every library an asset ships, recorded by name, version, and ecosystem: npm, Maven, PyPI, Go, NuGet, OS, and generic packages.
Version and scope on every entry
Each component carries its exact version and its scope (prod, dev, or test), plus the source it was discovered from and an optional purl or CPE.
End-of-life awareness
Components carry an end-of-life date and an EOL flag, so unsupported, no-longer-patched software is visible before it becomes an incident.
Technical components for applications
Map the infrastructure an application runs on: databases, caches, queues, gateways, load balancers, storage, and compute, with technology, endpoint, and environment.
Impact analysis for the next CVE
Ask where a vulnerable version runs and read the answer off a screen. Components connect to the findings that affect them, so blast radius is a query.
Live on the asset, not in a scanner export
Components sit on the asset record alongside dependencies, vulnerabilities, continuity, and data governance. One record, every dimension.
Where it fits
A parts list the rest of the platform reads from.
Questions
Common questions about
components and SBOM.
Every asset in Alvor carries a software bill of materials: the libraries and packages it ships, recorded by name, exact version, and ecosystem. Open an asset's Software tab and you see each component, its version, the scope it runs in (prod, dev, or test), where it was discovered, and whether it is end-of-life. Because the SBOM lives on the asset record, it sits alongside that asset's vulnerabilities, dependencies, continuity plan, and data governance rather than in a separate scanner export.
Get started
See how Alvor works for your role
Whether you lead security, run IT, manage compliance, or sit in the C-suite - we'll show you your view.