SBOM & Asset Management
One input that feeds everything.
Your software bill of materials is not the product; it is the shared inventory the product runs on. Correlens keeps it clean and current, then feeds it to vulnerability management and threat correlation, so a component is never just a line in a file.
| Component | Version | Origin | Provider | Licence | EOL | Vulns |
|---|---|---|---|---|---|---|
| gstreamer | 1.14.4 | OSS | upstream | LGPL-2.1 | 2027-01 | 29 |
| Adaptive AUTOSAR | R23-11 | proprietary | Tier-1 IVI | Commercial | – | 18 |
| wolfSSL | 5.6.3 | OSS | wolfSSL Inc. | GPL-2.0 | – | 6 |
| bluez | 5.66 | OSS | upstream | GPL-2.0 | 2027-03 | 9 |
| u-boot | 2021.10 | OSS | upstream | GPL-2.0 | 2026-12 | 4 |
| libexpat | 2.2.6 | OSS | upstream | MIT | – | 2 |
Validate & gate
A clean SBOM, or you find out why.
Every import is graded against NTIA minimum elements and EU CRA fields. A stale or incomplete bill of materials is caught at the gate, not months later in an audit.
- Graded on import with a pass threshold, per format.
- Field by field against the NTIA minimum elements.
- Exportable as a SARIF report for NTIA and quality.
312 components · threshold 30
Map the product
One row per node, the way the product is built.
Import builds the node topology: the controllers and compute units, each with components, open vulnerabilities and enrichment status. The same model holds a drone flight controller or an ITS roadside unit.
- Nodes are the compute units: gateways, domain controllers, IVI, telematics, zonal.
- Beyond cars: a flight controller or a charge controller maps the same way.
- Live counts of components and vulnerabilities per node.
Enrich continuously
Every component watched. Every vulnerability enriched.
Components are correlated to vulnerabilities continuously, not once at import. Each finding is enriched from correlated threat intelligence, so you see not just the CVE but whether it is exploited in the wild.
| Vulnerability | Component | CVSS | EPSS | Exploitation | Reachability | State |
|---|---|---|---|---|---|---|
| CVE-2026-4187 | gstreamer 1.14.4 | 9.8 | 0.89 | confirmed exploited (KEV) | reachable | under review |
| CVE-2026-3350 | wolfSSL 5.6.3 | 8.4 | 0.42 | exploit available | reachable | to validate |
| CVE-2026-0915 | bluez 5.66 | 7.5 | 0.18 | PoC published | adjacent | to validate |
| CVE-2026-2044 | u-boot 2021.10 | 6.2 | 0.05 | no known exploit | not reachable | suppressed (VEX) |
Diff releases
What changed between releases?
A software-defined product ships new software all the time. Compare any two releases and see exactly what was added, removed and changed, and how the vulnerability count moved, before it reaches the field. This is your R156 software-update trail.
| Change | Component | Version | Identifier |
|---|---|---|---|
| added | openssl | 3.0.14 | pkg:generic/[email protected] |
| changed | wolfSSL | 5.6.0 → 5.6.3 | pkg:generic/[email protected] |
| removed | openssl | 1.1.1w | pkg:generic/[email protected] |
| changed | bluez | 5.64 → 5.66 | pkg:generic/[email protected] |
Transportability
Your bill of materials is never trapped.
The SBOM is an exchange format before it is anything else. What you import here comes back richer, and what the platform learns about it ships in the formats your other tools already speak.
Import a bill of materials from any build. Take it back with vulnerabilities and VEX exploitability applied to every component, ready for the next tool in your chain.
e.g. a drone flight-controller SBOM in, an enriched bill with reachable CVEs out.
A confirmed incident or a watchlist leaves the platform as a portable object, so the team that runs your security operations picks it up without re-keying anything.
e.g. an ITS roadside-unit incident exported to your SOC and PSIRT.