The CRA flaw trigger covers a flaw under active attack in the maker’s product. The flaw may start in a part from another firm. The maker of the final product must still run its own test. Does its product contain the flaw? Is that flaw under active attack in this product?
An attack on the same part in a different product does not prove the result. Treat it as an urgent alert. Then check your own product.
Prove the inclusion path
Name the part, supplier, version, and source used to build it. List each product release that includes it. Check if the weak code is present. Do not rely only on a package name. Keep build records, part proof, and vendor notes used for the choice.
Next, ask if the code can be reached and how it is set up. Is the weak task present, on, exposed, or held back in the shipped product? A claim of “not at risk” needs the same proof as a choice to report.
Use fixed release proof when it exists. A scan today may not show what an old image held. Keep the build list, source change, pack step, setup, and release that prove the result.
If the maker changed or split the part, test its own form. The vendor’s version name may not match the code that shipped.
Test the exploitation evidence
Keep a flaw ID, risk score, and list entry apart from proof of a real attack. State what was attacked, in which system, and how it links to the maker’s product. Record reports that clash and how much each source can be trusted.
Run the severe-event test on its own. A hacked supply chain or harmful code may need that review even if the flaw trigger is not yet met.
Manage one signal across several products
Open one shared proof file for the part. Then give each product family its own checks. Cover whether the part is present, can be reached, and is under attack. Also record the severe-event result, awareness time, and fix. Link to source proof. Do not copy one product’s result to another.
When vendor proof changes, find the product choices that rely on it. Reopen only those files. Keep the old choice and new source. A vendor’s change must not alter filed product scope with no record.
Keep each manufacturer accountable
A vendor’s report does not finish the next maker’s Article 14 duty. The final-product team needs its own awareness time, scope, trigger choice, and proof for each report stage.
Use one part case to link all products at risk. Give each product family a clear result. One broad vendor note is not proof for products with different versions, setups, or attack paths.
The handoff should name the legal maker and product versions. Add the part proof, attack check, severe-event check, awareness record, open points, and fix state. The vendor case stays linked proof. It is not the maker’s legal choice.
Continue this workflow with the product-version map and the maintainer handoff.