Vendors should verify reported vulnerabilities through steps that may overlap. Initial investigation confirms whether the potential vulnerability exists in a supported product or service, continuing even for unsupported software until it is clear whether supported products are hit, and establishes severity. The process may end at this point: if the issue cannot be reproduced, the vendor asks the reporter for more detail and stops if none arrives (ISO/IEC 29147 covers explaining the reason to an external reporter); or it stops because the report duplicates another, relates to an obsolete unsupported product, has no security consequence, or cannot be exploited with techniques now known (exploitability can change, so vendors keep up with current techniques and may send such reports to routine maintenance); or it concerns another vendor's product and is forwarded using the ISO/IEC 29147 methods. Root cause analysis establishes the underlying causes, which products are affected and every way the vulnerability could be exploited, and again forwards the report if the cause lies with another vendor. Further investigation looks for the same kind of vulnerability in earlier and later versions and in other products. Prioritization ranks the vulnerability by the threat to affected users, using the severity found where possible under the most common deployment conditions and weighing likely impact, how probable exploitation is, and how many users are affected. Finally, the reporter is told the outcome.
The graph holds this control, the 0 it maps to, and the evidence behind each claim, over MCP and REST.