Vendors should keep track of every upstream dependency and the vulnerabilities in it, so they can tell whether their own products or services are affected; get vulnerability information, remediation advice included, from the vendors upstream of them; and pass vulnerability information, again including remediation advice, on to their own customers and users downstream, in the way 7.1.5 and 7.1.6 describe (see also ISO/IEC 29147:2018 8.2). They should pass vulnerability reports to other vendors when those vendors need them to deal with the report, for example: a vulnerability reported in one product that actually stems from the operating system or hardware beneath it; a faulty standard or published algorithm that many products implement; a vulnerability introduced by widespread development practices; a flaw in a widely used library; or a component that no longer has an active maintainer. ISO/IEC 27036-3 and ISO 28001 say more.
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.