A modo introductorio y como para ponernos en sintonía, el software de código abierto (OSS) (Open-Source Software) es desarrollado y mantenido a través de la colaboración abierta, permitiendo su uso, modificación y redistribución sin restricciones significativas, por desarrolladores en distintas partes del planeta.
Aunque su transparencia ofrece beneficios en términos de seguridad y calidad -según su espíritu y definición-, también introduce riesgos que pueden afectar la seguridad del software y la infraestructura donde se implemente.
Punto para reflexionar: Como agile testers debemos tener muy en cuenta estos primeros aspectos ya que en algún momento deberemos tener en cuenta qué controles aplicar sobre las aplicaciones en las que estemos participando. Mucho hay para leer, investigar, explorar, ensayar, compartir con colegas en esta área de conocimiento que no debemos dejarla pasar. Espero que puedas comenzar a entender su alcance y sino, sigue leyendo por fa.
Beneficios del OSS en Seguridad
El OSS tiene varias ventajas en términos de seguridad:
- Código accesible: Al ser público, permite auditorías por parte de la comunidad, lo que facilita la identificación y corrección de vulnerabilidades.
- Corrección rápida de fallos: La comunidad de desarrollo OSS tiende a responder rápidamente a las vulnerabilidades, reduciendo la ventana de exposición a ataques.
- Reutilización de código confiable: Muchas soluciones OSS son revisadas y utilizadas en múltiples proyectos, lo que genera un ecosistema de calidad.
Riesgos del OSS en Seguridad
A pesar de sus ventajas, el OSS presenta riesgos que pueden impactar la seguridad del software:
1. Modificación de Código por cualquier persona
Cualquier usuario puede modificar el código de un proyecto OSS, lo que abre la posibilidad de que un atacante:
- Inserte puertas traseras intencionales.
- Agregue código malicioso disfrazado de una mejora.
- Realice cambios inseguros sin control de calidad adecuado.
🔍 Ejemplo: Un atacante que obtiene permisos de contribuidor en un proyecto OSS puede insertar código que filtra información sensible.
2. Propagación de Vulnerabilidades
El OSS es ampliamente reutilizado en múltiples proyectos, lo que significa que una vulnerabilidad en una librería popular puede afectar un ecosistema completo.
- Un fallo en una librería OSS puede extenderse a miles de aplicaciones que la utilizan como dependencia.
- La falta de gestión de versiones seguras puede permitir la ejecución de código vulnerable.
🔍 Ejemplo: La vulnerabilidad Log4Shell en Apache Log4j comprometió miles de aplicaciones a nivel mundial.
3. Explotación Rápida de Fallos
Una vez que se publica una vulnerabilidad en OSS, los atacantes pueden explotarla antes de que los desarrolladores implementen un parche.
- Los cibercriminales monitorean repositorios públicos en busca de vulnerabilidades recién descubiertas.
- Si los equipos de desarrollo no actualizan rápidamente, los atacantes pueden aprovecharse de la brecha de seguridad.
🔍 Ejemplo: Un exploit de día cero en un framework OSS puede permitir acceso no autorizado antes de que la comunidad publique una solución.
Punto para reflexionar: Como agile testers debemos analizar cada requerimiento del proyecto para identificar en qué parte de la documentación funcional y técnica debemos aplicar un control por posibles (a) modificaciones de código, (b) propagación de vulnerabilidades, (c) explotación de fallos. Esta tarea la podemos llevar a cabo sin herramientas o utilizando un «prompt framework genérico» que pueda adaptarse a dicha situación como para acelerar y automatizar el proceso de análisis. Después estará en cada agile testers, con el conocimiento y experiencia que tenga en el dominio del negocio y del proyecto, adecuar la mejor práctica para implementarla durante el sprint.
Estrategias de Seguridad en OSS
Para mitigar estos riesgos, los ingenieros de pruebas de seguridad (Security Test Engineers – STE) deben:
✅ Realizar revisiones de código OSS antes de su implementación.
✅ Utilizar herramientas de detección de vulnerabilidades como las proporcionadas por OWASP y NIST.
✅ Aplicar análisis de composición de software (SCA) para identificar y actualizar dependencias vulnerables.
✅ Implementar estrategias de seguridad como Zero Trust, asegurando que cada componente OSS pase pruebas rigurosas antes de su uso.
🔍 Ejemplo de herramientas recomendadas:
- OWASP Dependency-Check (para detectar vulnerabilidades en librerías).
- Snyk (para análisis de código OSS).
- NIST National Vulnerability Database (NVD) (para revisar vulnerabilidades públicas).
Punto para reflexionar: Como agile testers estas tareas las deberíamos llevar a cabo de manera conjunta con los desarrolladores y el equipo de seguridad informática para estar debidamente alineados. Todo el equipo de proyecto debe estar al tanto de las tareas que se realizarán ya que deberían haberse estimado durante la Sprint Planning y siendo chequeadas en cada Daily y reuniones de equipo que se realicen durante el día. Hay varias de estas tareas que pueden realizarse de manera manual, con herramientas OSS y ahora con la ayuda de IA Generativa. Lo importante aquí es que todos estén al tanto de las actividades que necesariamente deben llevarse a cabo de manera conjunta, y que la gerencia correspondiente entienda que con solo aplicar las mejores prácticas de desarrollo seguro en particular dirigida por los desarrolladores de aplicaciones, no basta. Se debe complementar con las mejores prácticas de security testing y es ahí donde varias gerencias aún deben reconocer esta nueva área.
Fuente de inspiración: Programa de Estudios ISTQB STE
