Vendors should develop and test remediations step by step. First, decide on the remediation: whether the vulnerability can be fixed completely, whether the impact of exploitation can be limited, or whether exposure can be cut, weighing speed against the testing needed so users are not harmed by quality problems. If the vulnerability is high risk because it is easy to exploit or already being exploited, a temporary mitigation or workaround, or a partial fix that works in most situations, may be required. Second, support customers in dealing with vulnerabilities until the product's end of service, offering a reasonable upgrade route where not every supported version is fixed. Third, produce the remediation, which may take the form of a patch, fix, upgrade, documentation or configuration change, and can include taking vulnerable web pages down or asking a publisher to withdraw a vulnerable application. Fourth, test it on every supported platform to confirm it resolves the issue without creating new vulnerabilities, quality issues or compatibility problems, and repeat if a test fails.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.