Audita tu open source antes de que te reviente producción

Cómo auditar un proyecto open source antes de que te arruine el sueño (literalmente)

Son las 3:07 de la mañana. Slack te despierta con la alerta más temida: "Build failed in production". Te frotas los ojos, abres el log y ahí está: una dependencia que metiste hace ocho meses ya no compila. El mantenedor principal borró su cuenta de GitHub, el repo lleva 14 meses sin un solo commit, y tú acabas de heredar un paquete con 2.000 líneas de código que no entiendes, cero tests y una issue abierta de hace dos años que dice "urgent: memory leak".

Bienvenido al club. Todos hemos estado ahí.

Hoy vamos a hablar de cómo evitar esa escena. No con magia, no con un SaaS milagroso: con una auditoría honesta antes de meter esa dependencia en tu package.json, go.mod o requirements.txt. Porque elegir una librería open source es como elegir compañero de piso: al principio todo es bonito, pero cuando las cosas se ponen feas, quieres saber si va a estar ahí.

Vamos al lío.

Por qué esto importa más de lo que crees

Tu proyecto no es tuyo. Es tuyo y de las 47 dependencias directas y las 300 transitivas que arrastras sin saberlo. Según varios estudios de seguridad de la cadena de suministro, más del 70% del código que ejecutas en producción viene de terceros.

Traducción: la mayor parte de tu aplicación la escribió gente que no conoces, que no te debe nada y que, en cualquier momento, puede decidir que se aburre.

No es alarmismo. Es aritmética.

Y ojo, que el open source es un regalo brutal de la humanidad a la humanidad. Yo lo defiendo a muerte. Pero defenderlo no significa ser ingenuo. Significa respetarlo lo suficiente como para saber en qué te estás metiendo.

Paso 1: Mira quién está detrás (el test del bus factor)

Empieza por lo básico. Abre el repo y pregunta: ¿cuántas personas mantienen esto de verdad?

No cuántas aparecen en la lista de contributors. Muchos repos tienen 400 contributors y en realidad hay una sola persona haciendo el 90% del trabajo. Eso se llama bus factor 1, y significa que si esa persona se atropella con un patinete eléctrico, tu dependencia se queda huérfana.

Cómo comprobarlo rápido:

• Commits por autor en los últimos 12 meses. Si el 85% es de la misma persona, tienes un problema.
• Releases recientes. ¿Hay una versión nueva cada mes o la última es de 2023?
• Respuesta a issues. Mira las issues abiertas: ¿hay respuestas del mantenedor en la última semana? ¿O el último comentario es "any update?" repetido cinco veces?
• PRs sin mergear. Si hay 60 PRs abiertos y el más antiguo tiene dos años, nadie está al timón.

Esto no es juicio moral. Es gestión de riesgo.

Paso 2: Lee la letra pequeña (sí, la licencia)

Aquí es donde muchos se saltan el paso y luego vienen los problemas legales que nadie quiere explicar en la reunión con el equipo de compliance.

No necesitas ser abogado. Necesitas saber tres cosas:

1. Qué licencia tiene. MIT y Apache 2.0 son las amigables. GPL puede obligarte a abrir tu código si distribuyes tu producto. AGPL es aún más estricta. Y si no hay licencia... no tienes permiso para usarlo, punto.
2. Si hay CLA (Contributor License Agreement). Un CLA agresivo puede indicar que la empresa detrás quiere poder cambiar la licencia cuando le convenga. Ha pasado. Varias veces.
3. Si la licencia ha cambiado en el pasado. Revisa el LICENSE en el historial de git. Un cambio de open a "open core" o a licencia restrictiva es una señal de alarma seria.

En serio, no te saltes esto. Un cambio de licencia te puede costar reescribir medio backend.

Paso 3: El historial de seguridad (o cómo no ser el titular de mañana)

Vamos a lo que de verdad quita el sueño: ¿esta dependencia ha tenido vulnerabilidades? ¿Y cómo las ha gestionado?

Lo que quieres ver:

• Un proceso claro de reporte de vulnerabilidades. ¿Hay un SECURITY.md? ¿Un canal privado para reportar fallos? Si la única forma de reportar un CVE es abrir una issue pública, mal vamos.
• Tiempo de respuesta a parches. Un proyecto sano publica el fix en días. Uno enfermo tarda meses o nunca.
• Dependencias transitivas actualizadas. Si la librería depende de una versión de lodash de 2019, eso te lo estás comiendo tú.

Herramientas que te ayudan aquí: los auditores de dependencias que ya vienen con tu gestor de paquetes, y cualquier escáner de composición de software (SCA) que tengas a mano. Pero la herramienta no piensa por ti: mira el historial y saca conclusiones.

Paso 4: Documentación, tests y CI (el termómetro de la salud)

Aquí aplico una regla que me funciona: si no puedo entender cómo usarlo en 10 minutos, no lo adopto.

Un proyecto sano tiene:

• README que explica qué hace, cómo se instala y con un ejemplo funcional. Si el ejemplo no funciona, mala señal.
• Tests. No hace falta 100% de cobertura, pero sí que existan y que se ejecuten en CI.
• Pipeline de CI visible. ¿Se ejecutan tests en cada PR? ¿Hay badge verde? Un repo sin CI en 2026 es un repo que vive en el pasado.
• Changelog. Saber qué cambió entre versiones no es un lujo, es supervivencia.
• Guía de contribución. Indica que el proyecto piensa en el futuro, no solo en el presente.

Si abres el repo y solo hay un index.js de 3.000 líneas sin un solo test... corre.

Paso 5: Alternativas y forks (el plan B que nunca usarás pero necesitas)

Aquí viene la parte que casi nadie hace y que salva vidas: ¿qué pasa si mañana esto muere?

Antes de adoptar, comprueba:

• ¿Hay forks activos? Un fork con actividad reciente es un salvavidas si el original se abandona.
• ¿Existe una alternativa mantenida? A veces la mejor decisión es no usar la librería más popular, sino la que tiene mejor gobernanza.
• ¿Cuánto costaría reemplazarla? Si la respuesta es "semanas de trabajo", necesitas estar muy seguro de que la dependencia es sólida.

No adoptes nada que no puedas quitarte en un fin de semana si hace falta. Esa es la regla de oro.

Paso 6: La prueba de fuego (adóptala en una rama, no en main)

Antes de meterla en producción, haz esto: crea una rama, intégrala, escribe tests, rompe cosas a propósito.

• ¿Qué pasa si le pasas datos raros?
• ¿Cómo se comporta bajo carga?
• ¿Qué tamaño añade al bundle?
• ¿Tiene dependencias que a su vez tienen dependencias sospechosas?

Una hora de prueba vale más que diez artículos de blog. Y sí, este también.

El veredicto: una checklist que puedes usar hoy

Resumiendo, antes de dar el sí a una dependencia, pregúntate:

• ¿Cuántos mantenedores activos hay de verdad?
• ¿Cuándo fue la última release?
• ¿La licencia encaja con mi proyecto?
• ¿Hay SECURITY.md y proceso de parcheo?
• ¿Tiene tests y CI funcionando?
• ¿Hay forks activos o alternativas mantenidas?
• ¿Puedo reemplazarla sin dramas si desaparece?

Si fallan tres o más, busca otra cosa. En serio.

Por qué esto te cambia la vida (aunque no lo parezca)

Auditar dependencias no es paranoia. Es respeto por tu tiempo futuro.

Cada hora que inviertes hoy en revisar un repo es una hora que no pierdes a las 3 de la mañana del próximo trimestre, peleándote con un build roto mientras maldices el día en que escrib