Article 14 vulnerability notifications include general information, as available, about the product concerned. The 72-hour stage also covers corrective or mitigating measures taken and measures users can take.
A dependency finding becomes useful for that report only when the team can connect it to the manufacturer’s shipped product reality.
Build a version matrix
Create one row per product release and one column for component version, build source, vulnerable-code presence, configuration, reachability, supported state, distribution territory, and available mitigation. Record evidence links and the time each conclusion was checked.
Use immutable build and release identifiers where possible. Marketing names alone can group several materially different binaries, firmware images, or deployment modes. If products are assembled per customer, capture the configuration rule used to determine inclusion.
Reconcile conflicting inventories
Compare dependency scans with build manifests, source locks, release records, and product configuration. Record disagreements instead of selecting the newest tool output by default. A scan may observe the current workspace while the incident concerns an older shipped image.
For a forked or locally patched component, capture the source revision and patch set. The upstream version string alone may not establish vulnerable-code presence. Give the resolution to a reviewer who can trace it back to the released product.
Use explicit impact states
Give each product version one of five states: affected, not affected, investigation open, evidence unavailable, or superseded. Add a reason. Do not convert “not observed” into “not affected,” and do not mark an entire product family affected because one release contains the component.
Tie every mitigation to the versions for which it was tested. A configuration change may reduce exposure for one deployment while being unavailable or unsafe for another. Preserve that boundary in both the authority report and user notice.
Add a separate user-action state: no action identified, action under test, action approved, or correction available. Link the state to the product versions and deployment conditions. Do not present an engineering proposal as an instruction users can deploy.
Freeze the reporting snapshot
Before each Article 14 stage, export the matrix state used for the submission. Later engineering updates should append to the live record without changing what supported the earlier payload.
Assign an owner to every open cell that could change product scope or user action. The output should let a reviewer answer three questions quickly: which shipped releases contain the vulnerability, which are exposed under known conditions, and what each affected user can do now.
At each handoff, compare the matrix with the previous filed snapshot. Explain products or versions added, removed, or still unresolved. Preserve the evidence that justified the change so an auditor can distinguish better information from silent scope drift.
An SBOM or software-composition tool may supply evidence, but it is not the legal conclusion. Keep the human-reviewed product mapping and its provenance visible.
Continue this workflow with the component-trigger assessment and the stable identifier map.