Paquetes de consultas y niveles de severidad

5 tareas · 40 min · Principiante

Un análisis semántico no corre «todas las consultas»: corre un paquete, y de cuál se elige depende cuánto ruido y cuánta cobertura recibe el equipo. Después, cada alerta llega con dos medidas de gravedad que no significan lo mismo. En esta sala comparas los paquetes sobre la misma base de datos de api-pedidos, lees las dos severidades de once alertas y decides con cuál se bloquea una fusión.

0 de 5 · 0%

Objetivo de la sala

CodeQL se entrega con paquetes de consultas llamados suites. El paquete default es el que corre por defecto en el análisis de código de GitHub y prioriza la precisión: pocos falsos positivos. El paquete security-extended incluye todo lo del anterior y suma consultas de menor severidad y precisión, así que encuentra más y se equivoca más. El paquete security-and-quality suma además consultas de mantenibilidad y fiabilidad; según la documentación, este último requiere la configuración avanzada.

Cada paquete incluye al anterior. Subir de paquete nunca quita alertas: añade.

Responde para continuar

Un equipo pasa de default a security-extended sobre la misma base de datos. ¿Qué espera encontrar?

Las mismas alertas que antes, pero con una puntuación de gravedad distinta calculada de otra manera distinta Menos alertas, porque el paquete ampliado descarta las de baja severidad Todas las alertas anteriores y algunas más, de severidad o precisión menores, con más falsos positivos

Un cambio de paquete se decide con números, no con intuición. Sobre la misma base, se cuentan las alertas de cada paquete y se resta. La diferencia es el trabajo extra de triaje que el equipo está comprando.

Abre el resumen por paquete de la base de datos de api-pedidos.

Responde para continuar

¿Cuántas alertas más da security-extended que default sobre esta base? Escribe solo el número.

Cada alerta de seguridad llega con dos medidas. problem.severity es la gravedad que declara la consulta: error, warning o recommendation, una escala de tres niveles. security-severity es una puntuación de 0.0 a 10.0 que solo traen las consultas de seguridad; GitHub la presenta como crítica, alta, media o baja, alineada con el sistema CVSS, y la documentación explica que se obtiene de la gravedad de vulnerabilidades conocidas asociadas a las debilidades (CWE) que la consulta detecta.

La segunda es más fina que la primera, pero no la sustituye: son dos medidas que pueden no coincidir.

Responde para continuar

Escribe el id de la alerta con la puntuación de security-severity más alta.

La política actual bloquea las alertas nuevas con problem.severity = error. Plataforma propone otra: bloquear las que tengan security-severity de 7.0 o más. Antes de aceptar, se simula sobre las alertas actuales para ver a cuántas afecta.

Cuenta las alertas que bloquearía la regla propuesta sobre la lista de security-extended.

Responde para continuar

¿Cuántas alertas de la lista bloquearía la regla de security-severity de 7.0 o más? Escribe solo el número.

Compara ahora las dos reglas sobre la misma lista: la propuesta bloquea alertas que la vigente deja pasar. Entre ellas hay una cuya consulta declara un nivel bajo (warning), pero cuya puntuación es alta.

Responde para continuar

¿Qué enseña esa alerta sobre cómo fijar el umbral que bloquea una fusión?

Que da igual qué medida se use, porque las dos escalas coinciden siempre Que conviene mirar la puntuación de security-severity, porque el nivel de la consulta puede quedarse corto Que el nivel warning es siempre el más fiable, porque la puntuación del 0 al 10 cambia con cada versión de la herramienta

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Los tres paquetes Lab

2 Cuánto añade subir de paquete Lab

3 Dos severidades en la misma alerta Lab

4 Qué bloquearía otra regla Lab

5 La alerta que la política vigente deja pasar Lab

Whoami-Labs Pro utiliza cookies