SOLUTIONS · SBOM & VULNERABILITY MONITORING
SBOM and vulnerability monitoring with architecture context
Connect SBOM and vulnerability feeds to vehicle architecture — so vulnerabilities are prioritised against affected assets, threats, and risk treatment, not just raw scores.
WHO THIS PAGE IS FOR
This page is for automotive cybersecurity engineers and vulnerability-management owners responsible for post-production cybersecurity monitoring under ISO/SAE 21434.
THE PROBLEM
Post-production cybersecurity, covered by ISO/SAE 21434 Clause 8, requires continuous vulnerability monitoring across the vehicle's software. A Software Bill of Materials and vulnerability feeds — using industry identifiers and signals such as CVE, CPE, PURL, KEV, and EPSS where applicable — only become useful when they are connected to the vehicle architecture. Without that context, a vulnerability feed is a list, not a decision.
WHERE THE MANUAL WORKFLOW STRUGGLES
Why spreadsheets stop scaling
SBOM and vulnerability feeds without architecture context are noise, not signal
There is no link from a vulnerability to the affected assets, threats, and controls
Prioritising by raw severity score alone misses automotive exposure and exploitability context
Vulnerability response is disconnected from the original TARA decisions
Evidence that vulnerabilities were assessed is hard to reconstruct later
HOW AGNILE AND KAVACH HELP
An engineering workflow designed to support this
KAVACH is designed to connect SBOM and vulnerability feeds to affected components, assets, threats, and risk-treatment decisions
Vulnerability context is prioritised using architecture exposure and exploitability signals, where applicable, rather than raw scores alone
The vulnerability-to-TARA loop revisits affected threats, attack paths, and residual risk when new vulnerabilities appear
Vulnerability decisions stay traceable for review, audit, and post-development monitoring
Engineer-in-the-loop review at every stage; AI-assisted acceleration can be configured or disabled
REQUIRED INPUTS
- Software Bill of Materials for the system in scope
- Vulnerability feeds and identifiers, where available
- Architecture context linking components to vehicle functions
EXPECTED OUTPUTS
- Vulnerability-to-architecture mapping
- Prioritised vulnerability context for the affected programme
- Feedback into TARA — affected threats, attack paths, residual risk
- Traceable post-development monitoring evidence
Actual programme outputs depend on scope, architecture, and the engineering review process.
RELATED PAGES
Where to go next
COMPLIANCE
PROOF & WORKFLOW
FAQ
SBOM & Vulnerability Monitoring FAQ
See the SBOM & Vulnerability Monitoring workflow on your own architecture.
Bring a representative ECU, feature, or system architecture. We'll walk through how the workflow is structured — with honest answers on fit and integration effort.