Skip to main content

Software Component and Vulnerability Management

Software, component, and vulnerability management is the recurring practice of maintaining visibility of software, firmware, components, supplier inputs, affected products, vulnerability status, remediation, and status communication.

This practice is commonly driven by CRA, SBOM/VEX expectations, vulnerability handling duties, supplier assurance, customer assurance requests, and Software and Update-Chain Compromise.

What this practice is for​

This practice combines component visibility and vulnerability handling because component inventories are useful when they support affected-product analysis, remediation, and status communication. Detailed format and mechanism choices belong in Technology Options; reusable definitions, checklists, and templates belong in Resources. This page focuses on the operating practice.

Decisions this practice supports​

  • Component approval and continued use.
  • Affected-product analysis.
  • Vulnerability triage and remediation.
  • Supplier advisory review.
  • Customer status communication.
  • Risk acceptance or exception approval.

What can go wrong​

Teams may have SBOMs or component records but no operating workflow for affected-product analysis. Vulnerabilities may be discovered without product/component/version mapping. Supplier advisories may not reach the right product owners. Customers may receive unclear status because remediation, exploitability, and lifecycle scope were not tracked.

When component or vulnerability evidence is missing, stale, incomplete, inconsistent, or unverifiable, the practice should produce an exception, remediation plan, risk-acceptance decision, or customer status update rather than silently treating the status as known.

Core controls​

ControlPurposeEvidence produced
Component inventory maintenance
CRA Art. 13 §§ 3, 6
SSDF PW.4		Maintain current software, firmware, component, and supplier input visibility.SBOMs, xBOMs, component inventories, version records.
SBOM/version binding
CRA Art. 13 §§ 3, 6		Tie transparency artifacts to product, firmware, software, and lifecycle state.Version-bound SBOMs, product/component mappings.
Supplier component review
SSDF PO.1.3
SP 800-161 SR-6		Review supplier-provided software, firmware, and component records.Supplier advisories, supplier component records, review findings.
Vulnerability intake workflow
CRA Art. 13 §§ 6-10
SSDF RV.1		Capture vulnerability reports from internal, supplier, customer, and public sources.Vulnerability records, intake logs, disclosure records.
Affected-product analysis
CRA Art. 13 §§ 6-10
SSDF RV.2		Determine whether a vulnerability affects specific products, components, or versions.Impact assessments, affected-product lists, analysis notes.
Remediation tracking
CRA Art. 13 §§ 6-10
SSDF RV.2		Track fixes, mitigations, updates, accepted risks, and customer commitments.Remediation plans, patch records, risk acceptance records.
Vulnerability status communication
CRA Art. 14
SSDF RV.2		Communicate vulnerability status, scope, and remediation state where relevant.VEX-like status statements, customer notifications, advisory records.

What good practice looks like​

Good practice treats component visibility as an operating input, not a static document. Teams maintain inventories, bind them to product versions, receive vulnerability information, analyse affected products, coordinate with suppliers, track remediation, and communicate status with enough context for customers and auditors to rely on it.

An SBOM or xBOM does not by itself prove secure design, safe configuration, current integrity, authenticity, or vulnerability remediation. It is a transparency input that must be connected to decisions and actions.

Vulnerability records do not prove remediation unless connected to product versions, update records, and verification.

Useful status communication distinguishes unknown, not affected, affected, fixed, mitigated, and accepted-risk states where those distinctions matter.

Questions to ask​

Suppliers​

  • What software, firmware, component, and dependency records can you provide for the assessed product or service?
  • How will you notify us about vulnerabilities affecting supplied components or services?
  • Can you provide status statements, remediation plans, or supplier advisories tied to specific product versions?

Internally​

  • Which products, firmware versions, software versions, and supplier inputs are mapped to each component?
  • Who owns vulnerability triage, affected-product analysis, remediation, and customer communication?
  • What criteria decide remediation, mitigation, monitoring, or risk acceptance?

Assessors / auditors​

  • Can vulnerability status be traced to products, components, versions, lifecycle state, and remediation decisions?
  • Are accepted risks and unresolved findings visible?
  • Is status communication supported by evidence rather than generic claims?

Implementers​

  • What systems maintain component inventories and product/component mappings?
  • How are vulnerability sources, supplier advisories, and remediation workflows correlated?
  • How will status statements remain fresh and scoped?

Evidence this should produce​

This practice should produce SBOMs or xBOMs, component inventories, product/component mappings, supplier component records, vulnerability intake records, affected-product analysis, remediation plans, patch records, VEX-like status statements, customer notifications, and risk acceptance records.

Weak answer​

The organization has an SBOM or vulnerability scanner but cannot show how component data is used to decide product impact or remediation.

Stronger answer​

The organization maintains version-bound component records, uses them for affected-product analysis, tracks supplier advisories and remediation, communicates status with scope, and retains records for audit and customer assurance.

Verification considerations​

Reviewers should check whether component and vulnerability evidence is current, version-bound, scoped to the product or service, and tied to decisions. Evidence should distinguish unknown, not affected, affected, fixed, mitigated, and accepted-risk states where those distinctions matter.

Lifecycle stages​

This practice applies during design, sourcing, development, build, acceptance, deployment, update, operation, vulnerability response, renewal, and decommissioning.

Technology options​

Technology options may include SBOM tools, SPDX, CycloneDX, VEX-like formats, vulnerability databases, package and artifact repositories, supplier portals, advisory workflows, product/component mapping systems, and remediation tracking tools.