Hace poco Google dio a conocer mediante una publicación de blog el proyecto ClusterFuzzLite, que permite organizar pruebas fuzzing de código para la detección temprana de vulnerabilidades potenciales en la etapa de operación de sistemas de integración continua.

Actualmente, ClusterFuzz se puede utilizar para automatizar las pruebas fuzz de solicitudes de extracción en GitHub Actions, Google Cloud Build y Prow, pero se espera que en el futuro sea compatible con otros sistemas de CI. El proyecto se basa en la plataforma ClusterFuzz, creada para coordinar el trabajo de los clústeres de pruebas fuzzing, y se distribuye bajo la licencia Apache 2.0.

Cabe señalar que después de la introducción del servicio OSS-Fuzz por parte de Google en 2016, se aceptaron más de 500 proyectos importantes de código abierto en el programa de pruebas de fuzzing continuo. A partir de las comprobaciones realizadas, se han eliminado más de 6.500 vulnerabilidades confirmadas y se han corregido más de 21.000 errores.

Sobre ClusterFuzzLite

ClusterFuzzLite continúa desarrollando mecanismos de prueba fuzzing con la capacidad de identificar problemas antes en la fase de revisión por pares de los cambios propuestos. ClusterFuzzLite ya se ha introducido en los procesos de revisión de cambios en proyectos systemd y curl, y ha hecho posible identificar los errores que no se detectaron en los analizadores estáticos y linters que se utilizaron en la etapa inicial de verificación de código nuevo.

Hoy, nos complace anunciar ClusterFuzzLite, una solución de fuzzing continua que se ejecuta como parte de los flujos de trabajo de CI / CD para encontrar vulnerabilidades más rápido que nunca. Con solo unas pocas líneas de código, los usuarios de GitHub pueden integrar ClusterFuzzLite en su flujo de trabajo y solicitudes de fuzz pull para detectar errores antes de que se cometan, mejorando la seguridad general de la cadena de suministro de software.
Desde su lanzamiento en 2016, más de 500 proyectos críticos de código abierto se han integrado en el programa OSS-Fuzz de Google , lo que ha dado como resultado la corrección de más de 6.500 vulnerabilidades y 21.000 errores funcionales. ClusterFuzzLite va de la mano con OSS-Fuzz, al detectar errores de regresión mucho antes en el proceso de desarrollo.

ClusterFuzzLite admite la validación de proyectos en C, C ++, Java (y otros lenguajes basados ​​en JVM), Go, Python, Rust y Swift. Las pruebas de fuzzing se llevan a cabo utilizando el motor LibFuzzer. Los AddressSanitizer, MemorySanitizer y UBSan (UndefinedBehaviorSanitizer) herramientas también pueden ser llamados para detectar errores de memoria y anomalías.

De las características clave de ClusterFuzzLite destaca por ejemplo la verificación rápida de los cambios propuestos para encontrar errores en la etapa anterior a la aceptación del código, asi como tambien la descarga de informes sobre las condiciones de ocurrencia de choques, la capacidad de pasar a pruebas de fuzzing más avanzadas para identificar errores más profundos que no aparecieron después de verificar el cambio de código, tambien la generación de informes de cobertura para evaluar la cobertura del código durante las pruebas y la arquitectura modular que le permite elegir la funcionalidad requerida.

Grandes proyectos, incluidos systemd y curlya están usando ClusterFuzzLite durante la revisión del código, con resultados positivos. Según Daniel Stenberg, autor de curl, “Cuando los revisores humanos asienten y han aprobado el código y sus analizadores de código estático y linters no pueden detectar más problemas, el fuzzing es lo que lo lleva al siguiente nivel de madurez y robustez del código. OSS-Fuzz y ClusterFuzzLite nos ayudan a mantener curl como un proyecto de calidad, durante todo el día, todos los días y en cada compromiso «.

Debemos recordar que las pruebas de fuzzing generan un flujo de todo tipo de combinaciones aleatorias de datos de entrada cercanos a los datos reales (por ejemplo, páginas html con parámetros de etiquetas aleatorias, archivos o imágenes con encabezados anormales, etc.) y corrigen posibles fallas en el proceso.

Si alguna secuencia falla o no coincide con la respuesta esperada, es muy probable que este comportamiento indique un error o vulnerabilidad.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.