Skip to main content
Corgea utiliza IA para analizar posibles vulnerabilidades y determinar si es probable que sean falsos positivos. El análisis de falsos positivos tiene en cuenta varios factores, como el contexto del código, la naturaleza de la vulnerabilidad y los patrones de programación o las buenas prácticas pertinentes. A continuación, el modelo indica si es probable que la vulnerabilidad sea “válida” o un “falso positivo” y explica el razonamiento de su evaluación. Cuando el modelo determina que una vulnerabilidad es un falso positivo, el razonamiento proporciona una explicación para esta evaluación. Al proporcionar este análisis de falsos positivos junto con la explicación de la vulnerabilidad y la solución propuesta, Corgea pretende ayudar a los desarrolladores a identificar y priorizar rápidamente vulnerabilidades genuinas, evitando esfuerzos innecesarios en falsos positivos.

​
Ejemplos populares de falsos positivos que puede detectar Corgea

Estos son algunos de los falsos positivos que Corgea puede detectar:
  • Cross-site scripting: Comprueba si la entrada del usuario se sanea o codifica correctamente antes de reflejarla en la página web mediante bibliotecas o frameworks consolidados.
  • Inyección SQL: Comprueba si las consultas a la base de datos utilizan parámetros o sentencias preparadas y no incorporan directamente entradas manipulables proporcionadas por usuarios o fuentes externas.
  • Exposición de la información: Comprueba si la información sensible divulgada es genérica o ocurre en un entorno de desarrollo.
  • Excepción no controlada: Comprueba si la condición o el estado inesperado se gestiona por otros medios, como los logs o la monitorización, en partes no críticas de la aplicación.
  • Contraseña escrita directamente en el código: Comprueba si la contraseña está destinada a un entorno que no es de producción o se utiliza en pruebas automatizadas.
  • Contraseña en el archivo de configuración: Comprueba si el almacenamiento de la contraseña en texto plano está protegido mediante medidas de seguridad alternativas como almacenamiento cifrado o controles de acceso.
  • Clave criptográfica escrita directamente en el código: Comprueba si la clave solo se utiliza para pruebas.
  • Falsificación de solicitudes entre sitios: Comprueba si los tokens anti-CSRF están implementados y validados en el lado del servidor, o si el código es una API donde la protección CSRF no es aplicable.
  • Falta soporte para la verificación de integridad: Comprueba si la verificación de integridad se implementa mediante medios alternativos como firmas digitales o validaciones hash.
  • Credenciales escritas directamente en el código: Comprueba si las credenciales solo se utilizan para pruebas.
  • Inyección de código: Comprueba si el punto de inyección de código está limitado a un entorno controlado o si se aplican la validación de entrada y la codificación de salida.
Y muchos más…