Skip to main content

Cómo prioriza Snyk Code las vulnerabilidades con su Priority Score

Escrito por

Frank Fischer

blog feature snyk code priority score

9 de noviembre de 2021

0 minutos de lectura

Si todas las vulnerabilidades parecen igual de críticas, los ingenieros pueden sentirse abrumados y probablemente perder tiempo en los problemas equivocados. Por eso es importante que las herramientas de seguridad para desarrolladores ofrezcan una funcionalidad de priorización clara y sencilla. Como seguramente ya notaste, Snyk Code muestra un Priority Score en la esquina superior derecha del panel de resumen. Al pasar el cursor sobre la puntuación, se muestra una explicación de cómo se calculó. Además, para priorizar rápidamente, puedes ordenar por Priority Score en la esquina superior derecha.

Vista de un problema en Snyk Code que muestra una vulnerabilidad de secuencias de comandos entre sitios (XSS) de gravedad alta, con el código JavaScript vulnerable resaltado.

Pero un Priority Score es más que un simple número. En este artículo, quiero explicarte el razonamiento detrás de la puntuación y darte algunos consejos prácticos para usarla de forma óptima.

Nota: Como verás, tomamos decisiones específicas sobre cómo calcular la puntuación. Quizás tú lo habrías decidido de otra manera, ¡y no hay problema! No existe una respuesta perfecta y siempre nos interesa recibir comentarios constructivos.

Conceptos básicos del Priority Score

Para empezar, un Priority Score es un número entero entre 1 y 1000. Cuanto más alto sea el número, más recomienda Snyk Code corregir la vulnerabilidad. Es muy importante tener en cuenta que, aunque los Priority Scores de Snyk Open Source o Snyk Container se vean similares, no recomendamos comparar puntuaciones entre productos. Compara únicamente las puntuaciones de Snyk Code con otras puntuaciones de Snyk Code.

El Priority Score te ayuda a mejorar la seguridad de tu aplicación de manera eficaz. Para Snyk, esto se traduce en impacto y capacidad de acción. Si bien la gravedad de una vulnerabilidad es importante, debemos analizar más a fondo. Al evaluar el impacto, comprobamos si una corrección podría resolver varias vulnerabilidades. Si es así, el Priority Score aumenta. Al evaluar la capacidad de acción, Snyk Code determina qué tan fácil es corregir una vulnerabilidad. Si la corrección es rápida y sencilla, el Priority Score aumenta.

Con este análisis más profundo, podemos priorizar las correcciones de manera que aprovechemos al máximo el tiempo del equipo de ingeniería.

Cómo se calcula el Priority Score

Como función matemática, el Priority Score se calcula sumando puntos en función de los datos del problema. La puntuación se vuelve a calcular cada vez que se genera una instantánea y se ejecuta un análisis. Los Priority Scores pueden variar, incluso si las instantáneas se generan con poca diferencia de tiempo (más adelante veremos por qué). Snyk proporciona todos los datos utilizados para calcular el Priority Score en un archivo JSON.

Nota: A continuación se describe cómo se calcula a septiembre de 2021. Investigamos y aprendemos constantemente, y el ámbito de la ciberseguridad evoluciona rápidamente. Es posible que decidamos cambiar el cálculo en el futuro. En Snyk, siempre evaluamos la lógica detrás de los Priority Scores para mantener una eficacia líder en la industria frente a un panorama de amenazas en constante evolución.

Gravedad

La gravedad que el motor de análisis asigna al problema representa el 50 % de la puntuación total. Si el motor asigna una gravedad `High`, este parámetro suma 500 puntos; `Medium`, 250 puntos; y `Low`, 100 puntos. Es importante tener en cuenta que el motor ya usa una heurística para asignar el nivel de gravedad. Como nuestro motor tiene en cuenta el contexto, considera distintos aspectos del mismo. Por ejemplo, si el problema se encuentra o se origina en un archivo de prueba, la gravedad se ajusta.

El otro 50 % de la puntuación se basa en varios datos:

Ocurrencias

La cantidad relativa de ocurrencias de la vulnerabilidad en cuestión se traduce en puntos. Por ejemplo, imagina que tu programa tiene 10 problemas de tres tipos: 5 de tipo A, 2 de tipo B y 3 de tipo C. Así que C obtendría 30 puntos. La idea es agrupar los tipos de problemas y promover correcciones que los resuelvan todos a la vez. Si puedes corregir una ocurrencia, puedes corregirlas todas.

Archivos clave

Los archivos clave son archivos responsables de varios problemas. Snyk Code asigna 100 puntos de la puntuación a los archivos clave, 50 puntos cuando el flujo de código pasa por uno y 0 puntos si no los toca (por ejemplo, se excluyen los archivos que el motor identifica como archivos de prueba). La idea es que te enfoques en las áreas críticas de la aplicación para reducir el cambio de contexto entre varios archivos. También se tiene en cuenta que corregir un problema podría resolver otros problemas cercanos.

Ejemplos de correcciones

Si Snyk Code encuentra buenos ejemplos de cómo se corrigió anteriormente un problema en proyectos de código abierto, esto suma 200 puntos. Lo hacemos porque creemos que así el problema es mucho más fácil de abordar. Las correcciones anteriores te ayudan a resolver los problemas de forma rápida y sencilla y, para ser sinceros, las soluciones rápidas son excelentes para mantener motivados a los equipos.

Correcciones frecuentes en OSS

Este aspecto es interesante. Si el motor detecta una vulnerabilidad en más de 1,000 repositorios de nuestro conjunto de entrenamiento de código abierto, asigna 100 puntos. Esto se debe a varias razones:

  1. Si la vulnerabilidad es tan frecuente, aumentan las probabilidades de que se explote —incluso por parte de aficionados que usan scripts—, lo que la hace más peligrosa.

  2. Si la vulnerabilidad ya se corrigió cientos de veces, existe una práctica recomendada para corregirla que se puede aplicar.  

Prácticas recomendadas para usar Priority Score

Como viste, Priority Score es una herramienta poderosa que puede guiar tus esfuerzos de corrección. Te recomendamos usarla. Antes de terminar, te compartimos otras prácticas recomendadas para usar Priority Scores:

  1. En la interfaz de Snyk, puedes filtrar el conjunto de resultados por un límite mínimo y uno máximo de Priority Score.

  2. Como el Priority Score se vuelve a calcular cada vez que ejecutas un análisis y los cambios en el código influyen en él, te recomendamos usar siempre el valor más reciente. En lugar de ejecutar un análisis y crear 10 tickets de Jira a partir de los 10 problemas principales detectados, corrige un problema y vuelve a ejecutar el análisis. Usa el nuevo problema con el Priority Score más alto, que podría ser distinto tras las correcciones anteriores.

  3. No compares Priority Scores de distintas soluciones de Snyk. Describen cosas diferentes y se basan en lógicas distintas que no son comparables.

  4. Pasa el cursor sobre tu puntuación y revisa las razones que determinaron el Priority Score. A veces, buscar un poco una corrección sencilla para empezar puede ayudarte a lograr algunos avances iniciales. ¡La motivación es clave!

Comienza con Capture the Flag

Aprende a resolver desafíos de Capture the Flag con nuestro taller virtual 101 a pedido.

Leer más

blog feature ai lilac
Blog

Convierte tu backlog de vulnerabilidades en pull requests con la remediación agéntica

Evo Remediation Agent ya está disponible en Open Preview e incorpora la resolución automatizada de dependencias a Evo Agentic AppSec. Ahora, los equipos de AppSec pueden ejecutar campañas de remediación continuas

AI Background min crop
Blog

La IA activa todos los riesgos que has aceptado: siete ideas del panel de seguridad de IA sin filtros

La IA hace que los ataques sean más baratos y rápidos, y deja al descubierto riesgos que las organizaciones ya enfrentan. Cuatro líderes de seguridad explican por qué la defensa a velocidad de máquina y la corrección más rápida son esenciales.

blog feature ai violet
Blog

VulnBump: ¿Pueden los agentes de IA corregir dependencias vulnerables sin romper la compilación?

VulnBump prueba agentes de IA con 307 actualizaciones reales de dependencias. Una corrección cuenta solo si elimina la vulnerabilidad y la compilación y las pruebas siguen pasando.