A component advisory is only the beginning of the CRA workflow. Teams need to identify affected releases, assess exploitability and risk in product context, coordinate upstream and internal remediation, release security updates where needed and preserve the decision trail.
Start With a Release-Linked Dependency Map
Vulnerability tracking works only if the manufacturer knows which dependency versions appear in each supported product release. Link SBOM and inventory records to release identifiers so that a newly disclosed component issue can be mapped quickly to affected products.
Monitor More Than One Vulnerability Source
Use supplier advisories, upstream project notices, vulnerability databases and ecosystem-specific feeds where relevant. No single source is complete for every software ecosystem, so monitoring should reflect the technologies actually used in the product.
Separate Component Presence From Product Exploitability
A vulnerable component version may be present without the affected function being reachable in the product, while another vulnerability may be highly exposed. CRA handling therefore needs product-context analysis rather than treating every vulnerability identifier as the same level of risk.
Track Direct and Transitive Exposure
Transitive dependencies can create product risk even when they are not selected directly by the development team. Dependency analysis should preserve enough graph information to determine which top-level package or component introduces the vulnerable element.
Record the Affected Product Versions
Document which released and supported versions are affected, not only the dependency version. This supports corrective action, user communication and security-update planning and prevents a remediation decision from being detached from the actual products in the market.
Coordinate With the Component Maintainer
Where the manufacturer identifies a vulnerability in an integrated component, Article 13 requires communication to the component manufacturer or maintainer. Upstream information can clarify affected versions, available fixes and coordinated disclosure timing.
Track Remediation Through Closure
A vulnerability record should show triage, risk decision, owner, fix or mitigation, test evidence, target release and closure status. The process should remain connected to the product support period so unresolved component vulnerabilities do not disappear when a development sprint ends.
Preserve Evidence for Technical Documentation
Keep enough records to show how component vulnerabilities were identified, assessed and handled. This supports the CRA vulnerability-handling evidence set and makes later authority or audit questions easier to answer.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.