En este tutorial nos centraremos en tres identificar cómo SonarQube permite definir perfiles de calidad. Revisaremos los perfiles por defecto para entender los conjuntos de reglas que usa Sonar y cómo éstas son agrupadas en cuatro categorías que conforman un perfil. Además, veremos cómo interpretar las diferentes reglas.
En particular este tutorial tiene 6 secciones:
- Introducción
- Revisión de reglas de perfiles de calidad (por lenguaje)
- Reglas de mantenibilidad (Code Smells)
- Reglas de confiabilidad (Bugs)
- Reglas de seguridad parte 1 (Vulnerabilidades)
- Reglas de seguridad parte 2 (Security Hotspots)
Para este tutorial usaremos la herramienta https://sonarcloud.io/ disponible en línea. Es importante tener al menos una organización o los repositorios abiertos de Github sincronizados en Sonar Cloud para poder comenzar.
Con esa sincronización, estando en la organización podremos ver todos los repositorios analizados, así como algunas opciones:
Figura 1. Vista de Sonar
Si vamos a la opción Quality Profiles podremos ver una lista de perfiles por defecto para cada lenguaje de programación, así como el número de reglas asociadas a cada lenguaje, la última vez que se actualizaron y cuándo las usamos por última vez. En este tutorial vamos a concentrarnos en las reglas para Python.
Cuando se analiza un proyecto, las reglas del perfil de calidad se usan para determinar los problemas presentes en el mismo; se determina que hay un problema si las reglas son violadas por el código del proyecto.
Desde la opción de reglas en la barra superior o por el perfil, podemos revisar las reglas disponibles y filtrarlas de acuerdo a:
- Lenguaje: el lenguaje de programación para el que se aplica la regla.
- Tipo: a qué subconjunto pertenece (Bug, Vulnerability, Code Smell o Security Hotspot).
- Tag: etiqueta asociada a la regla definida por quien la creó.
- Repositorio: el motor o analizador que contribuye con las reglas para SonarQube.
- Severidad por defecto: la severidad original de la regla, definida por SonarQube.
- Estado: las reglas pueden tener tres diferentes estados: Beta (implementadas recientemente y en pruebas), Deprecated (ha sido reemplazada por otra regla más precisa) y Ready (está lista para usarse).
- Disponible desde: la fecha en que fue añadida la regla a SonarQube.
- Plantilla: las plantillas que permiten crear reglas personalizadas.
- Perfil: el perfil de calidad específico al que está asociada la regla.
Las reglas de mantenibilidad, cuando son rotas, permiten detectar elementos que de no ser corregidos, incrementarán la complejidad de realizar cambios en el código y corren el riesgo de introducir errores adicionales en futuros cambios.
Para revisar las reglas de mantenibilidad elegimos los filtros para el lenguaje Python y el tipo Code Smell.
Figura 2. Barra lateral para filtrar para el lenguaje Python por Code Smells.
Veremos varias de las reglas definidas para esta categoría. Podemos seleccionar, por ejemplo, ""<>" should not be used to test inequality".
Figura 3. Vista de detalle de un Code Smell
Podemos ver entonces las características de la regla, una explicación corta y ejemplos de código que no cumplen (noncompliant) y que cumplen (compliant) la regla.
Las reglas de confiabilidad permiten detectar elementos erróneos en el código, que aunque no estén presentando problemas en este momento, probablemente lo harán en el peor de los momentos. Los bugs deben ser resueltos.
Para revisar las reglas de mantenibilidad elegimos los filtros para el lenguaje Python y el tipo Bug.
Figura 4. Barra lateral para filtrar para el lenguaje Python por Bugs.
Veremos varias de las reglas definidas para esta categoría. Podemos seleccionar, por ejemplo, "=+" should not be used instead of "+=".
Figura 5. Vista de detalle de un bug.
Podemos ver entonces las características de la regla, una explicación corta y ejemplos de código que no cumplen (noncompliant) y que cumplen (compliant) la regla.
En SonarQube, las reglas de seguridad están divididas de tal manera que se detectan dos tipos de violaciones: vulnerabilidades (vulnerabilities) y Puntos de acceso de seguridad (Security Hotspots). Los primeros hacen referencia a problemas que puedan representar o dar la oportunidad a atacantes de comprometer la seguridad de la aplicación.
Para revisar las reglas de mantenibilidad elegimos los filtros para el lenguaje Python y el tipo Vulnerability.
Figura 6. Barra lateral para filtrar para el lenguaje Python por Vulnerability.
Veremos varias de las reglas definidas para esta categoría. Podemos seleccionar, por ejemplo, "JWT should be signed and verified".
Figura 7. Vista de detalle para una Vulnerability.
Podemos ver entonces las características de la regla, una explicación corta y ejemplos de código que no cumplen (noncompliant) y que cumplen (compliant) la regla.
Las violaciones de Puntos de acceso de seguridad hacen referencia a pedazos de código que son sensibles en términos de seguridad y que el desarrollador debe revisar. El resultado de esta revisión puede determinar que no hay amenaza o que se necesita realizar una corrección.
Para revisar las reglas de mantenibilidad elegimos los filtros para el lenguaje Python y el tipo Security Hotspots.
Figura 8. Barra lateral para filtrar para el lenguaje Python por Security Hotspot.
Veremos varias de las reglas definidas para esta categoría. Podemos seleccionar, por ejemplo, "Using weak hashing algorithms is security-sensitive".
Figura 9. Vista de detalle de un Security Hotspot.
Podemos ver entonces las características de la regla, una explicación corta y ejemplos de código que no cumplen (noncompliant) y que cumplen (compliant) la regla.
Para saber más sobre Perfiles de Calidad en Sonar Qube puedes visitar este enlace.
© - Derechos Reservados: La presente obra, y en general todos sus contenidos, se encuentran protegidos por las normas internacionales y nacionales vigentes sobre propiedad Intelectual, por lo tanto su utilización parcial o total, reproducción, comunicación pública, transformación, distribución, alquiler, préstamo público e importación, total o parcial, en todo o en parte, en formato impreso o digital y en cualquier formato conocido o por conocer, se encuentran prohibidos, y solo serán lícitos en la medida en que se cuente con la autorización previa y expresa por escrito de la Universidad de los Andes.
De igual manera, la utilización de la imagen de las personas, docentes o estudiantes, sin su previa autorización está expresamente prohibida. En caso de incumplirse con lo mencionado, se procederá de conformidad con los reglamentos y políticas de la universidad, sin perjuicio de las demás acciones legales aplicables.