Debido a que el descubrimiento continuo ve los cambios a medida que ocurren, es natural agrupar las API en función de su ciclo de vida y nivel de soporte. La mayoría de las organizaciones consideran que estos grupos comunes son un buen punto de partida: Las API «no administradas» o «no administradas» se utilizan activamente, pero no han sido revisadas ni aprobadas por el equipo de seguridad. Las API «prohibidas» o «vetadas» han sido revisadas por el equipo de seguridad y no están aprobadas para su uso dentro de la organización o desde su cadena de suministro. Las API «monitoreadas» o «compatibles» son mantenidas activamente por la organización y supervisadas por el equipo de seguridad. Las API «obsoletas» o «zombis» fueron admitidas por la organización en el pasado, pero existen versiones más nuevas que los consumidores de API deberían usar en su lugar. Cuantificación de los riesgos de las API Cuando la organización tiene un inventario de API que se mantiene sincronizado de manera confiable con sus API en tiempo de ejecución, el desafío final del descubrimiento es cómo priorizar las API entre sí. Dado que cada equipo de seguridad tiene recursos finitos, la puntuación de riesgos ayuda a concentrar el tiempo y la energía en las remediaciones que tendrán el mayor beneficio. No existe una forma estándar de calcular el riesgo de las llamadas a la API, pero los mejores enfoques son holísticos. Las amenazas pueden surgir desde fuera o desde dentro de la organización, a través de la cadena de suministro o por parte de atacantes que se registran como clientes que pagan o se apropian de cuentas de usuario válidas para organizar un ataque. Los productos de seguridad perimetral tienden a centrarse únicamente en la solicitud de API, pero inspeccionar las solicitudes y respuestas de API en conjunto brinda información sobre riesgos adicionales relacionados con la seguridad, la calidad, la conformidad y las operaciones comerciales.