Security Hotspots en SonarQube

Los Security Hotspots son un nuevo tipo de evidencia en SonarQube y tienen ciertas particularidades que te ayudan a mejorar la seguridad de tu aplicación.

Como ya sabrás, SonarQube detecta 3 tipos principales de issues o evidencias: Bugs, Vulnerabilidades y Code smells.

Y si no lo sabías, pues puedes revisar el post que escribí con lo más destacable de SonarQube 😉

Pues bien, desde la versión 7.8, y por supuesto en la última LTS, cuenta también con la detección de Security Hotspots.

Security Hotspots

Si no sabes lo que son, es fácil que quieras traducirlo… y algo así como «puntos calientes de seguridad» tampoco te diría.

Por eso hoy quiero hablarte de qué son los Security Hotspots y qué papel juegan en la seguridad

Qué son los Security Hotspots de Sonarqube

Los Security Hotspots, diferencia de las vulnerabilidades, no son necesariamente vulnerabilidades que permitan atacar a la aplicación.

Lo que hacen es destacar fragmentos de código relacionados con la seguridad, que deben ser manualmente revisados.

Una vez revisados, se podrá confirmar si es una Vulnerabilidad, y por lo tanto hay que corregirla para proteger esa parte; o, por el contrario, que no es necesario realizar ninguna acción.

En este caso, quien debería revisar las evidencias de este tipo y deberían confirmar lo anteriormente dicho, serían especialistas o auditores de seguridad.

Así que, aunque SonarQube lo muestre como una evidencia más, en mi opinión no lo es hasta que un experto en seguridad lo confirme.

Y no solo por la experiencia en ese campo, sino más bien por las políticas de seguridad que se aplican en cada organización, que, obviamente, no son iguales para todas.

SonarQube Security Hotspots

¿Por qué son importantes los Security Hotspots?

Si algo se puede destacar de esta nueva característica de SonarQube, es que ayudan a enfocarse en su trabajo a los desarrolladores, quienes, aunque deben tener unos conocimientos básicos de seguridad, estamos hablando de casos dónde no tiene por qué suponer un riesgo ese Security Hotspot y, por lo tanto, es mejor que lo revise un tercero.

Hasta ahora, este tipo de issues no se mencionaban, lo que implicaban una revisión manual del código.

(Modo irónico activado) Y eso supone una de las tareas más gratificantes y enriquecedoras a nivel profesional para programadores y técnicos de seguridad (Modo irónico desactivado) 🙂

Como indica SonarQube en su documentación, los Security Hotspots permiten:

  • Solucionar problemas de seguridad: Detectando vulnerabilidades y asegurando que se solucionan antes de llegar antes de hacer un pull request o un merge.
  • Aprender sobre seguridad: Gracias a la explicación que ofrecen sobre por qué ese fragmento podría convertirse en un agujero de seguridad. Lo que te ayuda también a evitar futuros problemas, aunque ellos no lo mostraran como tal.
Security Hotspots SonarQube

El ciclo de vida de un Security Hotspot

Los Security Hotspots tienen un ciclo de vida particular y deben revisarse, por si aún no lo he dicho bastante 🙂 ) por alguien de seguridad.

Para poder hacerlo, esa persona debe contar en SonarQube con el permiso de «Administer Security Hotspots».

Estados

Estos issues pueden estar en alguno de estos tres estados:

  • To review o A revisar: Es el estado por defecto cuando se detecta esta evidencia. Un Security Hotspot se ha reportado y tiene que revisarse.
  • In review o En revisión: En este estado ya se encuentra alguien revisando el issue para confirmar si es una vulnerabilidad o no
  • Reviewed o Revisado: En este caso, ya se ha revisado y se ha confirmado que no supone un riesgo de seguridad para la aplicación.

Hay que tener en cuenta, que un Security Hotspot solo se cierra si el código que lo contiene se elimina o la regla que lo detecta se ha desactivado.

Acciones

Sobre ellos, podemos realizar las siguientes acciones:

  • Resolve as Reviewed (Resolver como «Revisado»): Con ello, se confirman que no existe ninguna vulnerabilidad en el código.
  • Set as In review (Establecer como «En revisión»): Se está realizando una revisión para comprobar si es una vulnerabilidad.
  • Reset as To review (Devolver a «A revisar»): Es necesario que se revise de nuevo.
  • Open as Vulnerability (Abrir como «Vulnerabilidad»): Se confirma que existe una vulnerabilidad en ese fragmento y debe corregirse.

Flujo de trabajo

Cuando SonarQube detecta un Security Hotspot, se establece como «A revisar» de forma predeterminada. Desde entonces, puedes realizar las siguientes acciones sobre él:

  • Abrir como «Vulnerabilidad», si detectas que lo es y debe solucionarse.
  • Resolver como «Revisado», cuando confirmes que no es una vulnerabilidad, y por lo tanto, no se debe realizar ninguna acción sobre él.
  • Establecer como «En revisión», en el caso que desees marcar ese Security Hotspot para mostrar que se está revisando para confirmar si es una vulnerabilidad. Este paso es opcional.

Si marcas un Security Hotspot como «En revisión», a continuación, podrás marcar cualquiera de los otros dos:

  • Abrir como «Vulnerabilidad»
  • Resolver como «Revisado»

Cuando confirmes que es una Vulnerabilidad, seleccionando dicha acción, el estado cambiará automáticamente de «A revisar» o «En revisión» a «Abierto» (estado por defecto en el que aparecen las evidencias cuando se detectan)

Cuando esto ocurre, el último desarrollador que trabajó con ese fragmento de código recibirá una notificación de «Nueva evidencia» (por supuesto, siempre que estén las notificaciones correctamente configuradas)

Una vez que una Vulnerabilidad se ha abierto en la localización de un Security Hotspot, ocurrirá lo siguiente:

  1. El Security Hotspot se asigna al desarrollador oportuno, quien lo solucionará.
  2. El desarrollador entonces marcará la Vulnerabilidad «Resuelta como revisada» a través de la interfaz de SonarQube, que moverá la Vulnerabilidad de vuelta para ser un Security Hotspot.
  3. El Security Hotspot se marcará entonces como «Revisado» y su estado pasará a ser «Solucionado».

Por último, hay que tener en cuenta que un Security Hotspot puede ser reabierto como una Vulnerabilidad en cualquier punto si se confirma que se trata de un verdadero problema.

Así que ya sabes, tienes una nueva forma de mejorar la seguridad de tus desarrollos, y aprender sobre ello.


De todas formas, recuerda que si tienes algún problema, y te encuentras a este equipo, quizá puedas contratarlos….

Equipo de seguridad

Si no has tarareado la canción de esta serie cuando has visto la imagen… ¡lo harás enseguida! 😉

Fuentes:

Lectura recomendada

11 blogs DevOps que no deberías perderte Cada vez existen más blogs DevOps, y aquí te muestro una pequeña lista para que empieces a seguirlos.

Deja un comentario