The CRA test needs more than a claim that a flaw is under attack. There must be sound proof that a bad actor used it in a system without the owner’s leave. A threat feed, user note, in-house alert, or public claim is just an input. It is not a result to copy.
This point matters when sources clash. Save each alert and test all of them in the same way. Record when the proof becomes sound enough for a choice.
Separate observations from interpretations
Create one row for each key alert. Record its source, receipt time, product, version or setup, and seen acts. Add the source file and any trust rating. Keep the source’s words apart from the maker’s view.
Then ask four questions. Is this proof about the maker’s product? Does it show real use, not just that use is possible? Was the act harmful? Did it occur without the system owner’s leave?
A lab test, approved security test, or flaw score may still need an urgent fix. It does not answer the same legal question.
Reconcile conflicts without averaging them
Two weak alerts do not make one strong result. Check if reports that seem separate repeat the same unchecked source. Compare times, attack signs, product prints, run logs, and user facts. A denial may rest on new proof or only on a lack of logs. State which.
Give each alert a short state. Mark it as backed, opposed, not tied to the product, allowed activity, or still open. Name the proof that would change the state. This keeps the clash clear without forcing an early yes or no.
Give the decision a controlled boundary
Name one choice owner and one backup. They need access to product, event, legal, and user proof. The owner records the proof checked, result, choice time, and next review event. Keep doubt and a peer’s dissent in the record.
If the test is met, record awareness and start the report path. Do not delay the early warning just to finish the cause review. If the test is not yet met, keep the case open. Name the next check and set a short time that fits the risk.
Reopen on changed facts
A sound “not proved” choice is not final. Reopen it when a user gives source files or new logs appear. Reopen it if a CSIRT backs the attack, a version link is proved, or a test turns out not to have leave.
The useful result is not a trust score. It is a clear account of what the maker knew and why the proof met or failed each part. It names who chose and which fact would cause a new choice.
Continue this workflow with the actively exploited vulnerability definition and the non-reportable decision record.