Javier Jerónimo

Calidad del código de proyectos de código abierto

12 May 2017 » secdevops

Estamos emocionados con los proyectos de código abierto. Tanto, que en ocasiones ni miramos la licencia, pero ese es otro tema de debate…

¿Has comprobado alguna vez la calidad del código de un proyecto de código abierto que usas? ¿De alguna de las decenas de dependencias que instala tu npm o maven de turno? ¿De al menos la más importante? (dejo a tu elección la definición de “importante”).

Yo no.

Pero…

Desde hace unos meses trabajo en un equipo de ciberseguridad, y entre lo que estoy aprendiendo y los boletines de seguridad a los que me estoy suscribiendo, cada vez tengo más miedito en el cuerpo.

Miedito porque absolutamente todos los proyectos que conozco dependen de otros de código abierto, y porque aporreamos el teclado programamos a una velocidad que nos hace pasar por alto muchas cosas, entre ellas la seguridad. No pienso siquiera en “programación segura”, es decir, que seas un verdadero Ninja de la programación (no un Ninja-postureo) y que no te hagan un overflow… o seamos más actuales, que no te hagan una inyección de SQL (es muy triste que en 2017 todavía estemos hablando de esto)… o te ejecuten código JavaScript en el servidor Node.js de tu API REST molona (porque te envíen un JSON malicioso que no sanitizas)…

Y lo peor de todo es que si nos tomamos la seguridad como se merece, con un buen modelo de madurez encima de la mesa (lo hay, ya haré otro artículo al respecto), pasar de cero a “algo” es casi trivial.

Repito, pasar de “no hacemos ninguna comprobación de seguridad de nuestro código” a “pasamos comprobaciones básicas en nuestro sistema de integración casi-continua” es… TRI-VI-AL.

Mal de muchos, consuelo de tontos

Las barbaridades que se oyen sobre cómo trabajan en startups y no-tan-startups… vamos a ser positivos, vayamos a cómo hacerlo.

Programar es un arte y ahora viene una máquina a decirte tal o cual…

Pero atención, usar analizadores estáticos de código, que es de lo que voy a hablar en el artículo, que son herramientas que buscan patrones en el código, que buscan la adhesión a convenciones… puede hacer algo de daño al principio. Siempre existen falsos positivos, hay reglas con las que no todos los ingenieros estamos de acuerdo (por eso debemos tener criterio), y algunas, aun cuando están justificadas, incluso escuecen.

No puedes suponer que después de varios años escribiendo código de una forma, vayas a aceptar las recomendaciones con alegria y gozo. Algunas no te gustarán. Otras incluso harán que te aflore un sentimiento de vergüenza sobre el código que has podido escribir en el pasado. Creo que eso es positivo, significa que estás aprendiendo de los errores, pero sólo lo consigues con la mente abierta. No hay nada más objetivo que la crítica (constructiva) de un algoritmo basado en evidencias y el conocimiento de muchos ingenieros.

Comprobaciones básicas on-premise

Voy a centrarme sólo en aplicaciones JAVA + MAVEN, pero con algo de Google se pueden encontrar alternativas para otros lenguajes para muchos de los puntos que listo a continuación (https://docs.sonarqube.org/display/PLUG/Plugin+Library).

Calidad del código: seguir convenciones

A estas alturas, no vamos a discutir este tema recurrente.

Opción 1 – “cero” esfuerzo (SonarQube)

Cómo: SonarQube / SonarJava, el plugin oficialmente soportado por SonarQube para JAVA hace este tipo de comprobaciones.

Si usas MAVEN, instala SonarQube y después: https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Maven

Qué: “Coding Convention” (https://www.sonarsource.com/why-us/products/codeanalyzers/sonarjava.html)

Resultado: Comprobaciones típicas de JAVA.

Opción 2 – Instalar otro plugin adicionalmente (SonarQube)

Cómo: SonarQube Checkstyle plugin (https://github.com/checkstyle/sonar-checkstyle)

Qué: Checkstyle para JAVA (http://checkstyle.sourceforge.net/)

Resultado: Las comprobaciones básicas de SonarJava y las de Checkstyle. Ooook.

Calidad del código: evitar malos olores

Las comunicaciones entre las personas que forman una organización imitan la estructura de la organización. Del mismo modo, el código huele según el estado de ánimo del programador en cada momento, o de sus hábitos.

Cómo: SonarQube / SonarJava

Qué: 218 reglas específicas de “Code Smells” (https://www.sonarsource.com/why-us/products/codeanalyzers/sonarjava/rules.html#Code_Smell_Detection)

Resultado: No sólo convenciones, si no estructuras y uso del lenguaje que tienen mala pinta… Oooooook.

Calidad del código: programación segura-qué?

Hay muchas fuentes de documentación sobre seguridad (errores típicos de programación, vulnerabilidades, etc). Un analizador estático de código es capaz de encontrar patrones de programación insegura (somos tan predecibles los programadores…), así que…

Opción 1 – “cero” esfuerzo (SonarQube)

Cómo: SonarQube / SonarJava

Qué: 212 reglas específicas que cubren recomendaciones de seguridad de los siguientes “estándares”

Resultado: Resulta que sólo con SonarJava ya tenemos unas cuantas comprobaciones de calidad… Ooooooooook

Opción 2 – OWASP Dependency Check (JAVA / .NET)

¿Usas alguna dependencia con vulnerabilidades conocidas? Lo primero es conocer la respuesta a esta pregunta, y lo segundo actualizar tus dependencias vulnerables a versiones sin esa vulnerabilidad CONOCIDA. Resalto lo de CONOCIDA.

Qué: OWASP Dependency Check

Cómo: herramienta integrable con MAVEN, ANT, sbt… https://www.owasp.org/index.php/OWASP_Dependency_Check

Resultado: Otro plugin más en el flujo de compilación de MAVEN, pero te obliga a mantenerte al día…

Comprobaciones básicas en-la-nube

Para proyectos de código abierto existen muchos recursos gratuitos en internet. Todas las startups están como locas captando usuarios, y las que ofrecen productos y servicios entorno al desarrollo de aplicaciones no son menos.

Así que si tienes un proyecto de código abierto, te puedes evitar instalar un SonarQube, un TeamCity y toda la parafernalia que los rodea. Simplemente podrás darte de alta, indicar cuáles son tus repositorios y darle al “play”:

  • SonarQube: ellos mismos ofrecen un servicio online gratuito para proyectos de código abierto, así que todas las comprobaciones de la sección anterior están disponibles.
  • CodeClimate: “Obtén revisiones de código automatizadas para cobertura de pruebas, complejidad, duplicación, seguridad, estilo y más, y mezcla con confianza”. Los filtros para navegar por los problemas encontrados son un poco pobres, pero es un primer paso.
  • Codacy: me da la impresión de que internamente usan SonarQube, la interfaz está muy cuidada y me ha gustado bastante.

Y con TravisCI completamos el ciclo…

Volviendo al tema…

Por tanto… todo software de código abierto que se precie, sin invertir un céntimo, tiene acceso a recursos que le permitirían revisar la calidad de su código, incluso desde el punto de vista de la seguridad.

Supongamos que alguien, por ejemplo yo, está evaluando soluciones de código abierto de un tipo concreto. Estas ofrecen versiones “enterprise” (EE) que aportan valor adicional a la versión “community” (OSS), que será las que contrates cuando tomes la decisión de cuál usar.

Al haber varias empresas ofreciendo soluciones de ese tipo, bajo ese mismo modelo de negocio OSS+EE, ¿no deberían todas ellas cuidar su código? ¿no deberían aprovechar todos los recursos que hubiera disponibles? ¿no deberían demostrar públicamente que su producto EE está sostenido por una solución de código abierto de calidad comprobable, de calidad de la buena…?

Pues no. Y es una pena.

Solución

Quieres evaluar una solución de código abierto porque te estás planteando contratar los servicios de la versión “enterprise”. Pues si ellos no han hecho bien su trabajo, al menos podrás:

  • Crear un “fork” de su repositorio community.
  • Darte tú de alta en los servicios.
  • Configurarlos hacia tus “forks”.
  • Analizar el código.
  • FIN.

 

Artículos relacionados