Cal.com cambia de código abierto a código cerrado por amenazas de seguridad impulsadas por IA

• Cal.com, que operó como proyecto de código abierto durante 5 años, decidió pasar a código cerrado debido al aumento de las amenazas de seguridad basadas en IA
• Ha llegado una era en la que la IA analiza automáticamente la base de código para encontrar vulnerabilidades, lo que hace que el código público se convierta en una pista directa para los atacantes
• La empresa eligió priorizar la protección de los datos de sus clientes frente al dilema entre mantener el código abierto y asumir riesgos de seguridad
• Para mantener el espíritu del código abierto, lanzó Cal.diy bajo licencia MIT, ofreciendo una versión autohospedable para la comunidad
• A medida que la IA avanza a una velocidad que supera los esquemas de seguridad existentes, Cal.com expresó su intención de volver al código abierto una vez que la seguridad se estabilice

---

Decisión de Cal.com de abandonar el código abierto y las amenazas de seguridad con IA

• Cal.com operó como proyecto de código abierto durante 5 años, pero decidió cambiar a código cerrado (Closed Source) debido al fuerte aumento de las amenazas de seguridad impulsadas por IA
  • Señaló que la máxima prioridad es proteger los datos de los clientes y concluyó que mantener el código abierto ya no era seguro
  • Indicó que “no fue una decisión fácil”
• En el pasado, explotar vulnerabilidades en aplicaciones requería tiempo y esfuerzo de hackers experimentados, pero ahora hemos entrado en una era en la que la IA escanea automáticamente bases de código para encontrar vulnerabilidades
  • Describió el código abierto como “entregarle a los atacantes los planos de una bóveda”
  • A medida que startups de seguridad con IA comercializan estas capacidades, detectan distintos tipos de vulnerabilidades, lo que dificulta establecer un único estándar de seguridad confiable
• Cal.com explicó que tuvo que elegir entre dos opciones
  • mantener el código abierto y aceptar el riesgo sobre los datos de los clientes, o
  • cambiar a código cerrado para reducir ese riesgo
  • Aunque no es una solución perfecta, concluyó que era una decisión inevitable para proteger a los usuarios
• Para continuar con el espíritu del código abierto, publicó un proyecto separado llamado Cal.diy bajo licencia MIT
  • Cal.diy es una versión abierta para desarrolladores y usuarios entusiastas, una versión comunitaria autohospedable
  • La base de código del servicio principal ha cambiado de forma importante en estructuras clave como autenticación y procesamiento de datos, por lo que está técnicamente separada de Cal.diy
• La IA está transformando rápidamente el entorno de seguridad, y también se mencionó un caso en el que la IA encontró en pocas horas una vulnerabilidad de 27 años en el kernel BSD y generó un exploit
  • Esa velocidad y precisión superan los mecanismos tradicionales de respuesta en seguridad
  • Cal.com afirmó que está tomando todas las medidas posibles para proteger a sus clientes, la aplicación y los datos sensibles, y expresó su deseo de volver al código abierto cuando el entorno de seguridad se estabilice

Dirección futura y mensaje

• Por ahora, la mitigación de riesgos de seguridad y la protección de los usuarios son la máxima prioridad
• La relación con la comunidad de código abierto se mantendrá a través de Cal.diy
• A largo plazo, deja abierta la posibilidad de volver al código abierto según evolucione el entorno de seguridad
• Esta decisión muestra cómo la realidad de la seguridad en la era de la IA está afectando directamente los modelos de distribución de software

[GN⁺]

Comentarios en Hacker News

• Drew Breunig llegó a la conclusión opuesta en un post que publicó ayer
  Ahora que las vulnerabilidades de seguridad se han convertido en un recurso que puede encontrarse usando tokens, el open source tiene incluso más valor
  En open source, varios proyectos pueden compartir el costo de las auditorías, mientras que en closed source cada quien tiene que encontrar todas las vulnerabilidades por su cuenta

  • Volvió a publicar ese post aquí. El título es Cybersecurity looks like proof of work now
  • Parece que la razón real es impedir que la IA lave por copyright (copyright-wash) el producto. Da la impresión de que están usando la seguridad como pretexto
  • Esta conclusión suena más convincente. Apenas han pasado unas semanas desde que apareció Mythos, así que es raro cambiar principios tan rápido. Probablemente hubo una razón de negocio, y ahora solo están buscando una justificación que sea fácil de vender al público
  • También es una conclusión razonable en términos económicos. Al final, hay que generar suficiente valor como para cubrir el costo de los tokens o reducir el beneficio económico de descubrir vulnerabilidades
    Eso puede lograrse reduciendo el alcance del despliegue o bajando los privilegios del sistema.
    Hacia adelante, parece que evolucionará a una forma de “especificación abierta + generación de código basada en modelos”. La seguridad y la gobernanza probablemente ocurrirán en la capa del modelo
  • Suena raro decir que “para fortalecer el sistema hay que gastar más tokens que el atacante”. Si el software es estable, la superficie de ataque se reduce, y Mythos no produce nuevas vulnerabilidades. Los defensores deberían tener ventaja en términos de tokens

• Soy responsable del proyecto Thunderbird. Nuestra herramienta de gestión de citas Thunderbird Appointment siempre seguirá siendo open source
  Invita a construirla juntos en el repositorio de GitHub. Dice que ayudarán a que pueda reemplazar a Cal.com

  • Estaría bien agregar capturas de pantalla en el README o en la pantalla previa al inicio de sesión. La herramienta se ve bien, pero me da curiosidad el precio de la versión alojada
  • Pero en laptops Linux viejas Thunderbird es demasiado pesado. Ojalá también consideren a los usuarios de bajos recursos. Piden que mantengan internet en un nivel accesible
  • Entré al sitio, puse mi correo y me mandó a una lista de espera; al final terminé bloqueando sus emails. La experiencia de usuario fue mala
  • Como broma a eso de “constrúyanlo con nosotros”, alguien preguntó: “Entonces, ¿hace falta una cita (appointment)?”
  • También hubo reacciones positivas diciendo que parece una buena alternativa

• Si los LLM encuentran tan bien las vulnerabilidades de código, ¿no bastaría con correr un pentest interno con LLM antes de cada release?
  Da la impresión de que la ley de Linus (enlace) por fin se volvió realidad

  • Pero después del release, los atacantes pueden analizar el código con tiempo ilimitado y con LLM cada vez más inteligentes.
    Para defenderse, hay que hacer por adelantado en cada release todo lo que el atacante podría hacer
  • A medida que los LLM mejoran, el mantenimiento de FOSS dispara sus costos de tiempo y personal.
    Aumentan los issues y PR de mala calidad generados por IA, así que disminuyen los incentivos para mantener open source.
    Cuando productos comerciales se basan en un core FOSS, probablemente veremos más transiciones de este tipo
  • En closed source, se puede usar internamente un LLM para reforzar la seguridad.
    Pero también se entiende que quieran cerrarlo para no dejar abierta una oportunidad de ataque hacia afuera
  • En entornos con commits frecuentes, hay que escanear toda la base de código con un LLM cada vez, así que el costo se dispara.
    Lugares como GitHub ya tienen costos altos de análisis estático
  • Al final, la opinión es que conviene escribir código simple y hacer pruebas de seguridad con LLM incluso a nivel de compilador

• Esta decisión parece ser más de negocio que de seguridad.
  Gracias a la IA, el self-hosting se ha vuelto más fácil, y eso está reduciendo los ingresos por hosting pagado de proyectos open source

  • La gente usa LLM para implementar por su cuenta las “funciones pro” o para encontrar puntos de extensión. La seguridad no es más que fachada
  • Echarle la culpa a la IA es una excusa. La IA ya aprendió del código. Si combinas algoritmos genéticos + fuzzing, aprende muchísimo más rápido que los humanos
  • Hoy en día a todo le echan la culpa a la IA. Recortes de personal, descontinuación de productos y hasta cierre del código fuente: todo supuestamente es por la IA
  • El producto ya se está comoditizando, como la herramienta de citas de Google Workspace
  • Al final, también surgieron críticas llamándolos “sellout”

• Como cliente potencial, me decepcionó la decisión de Cal.com.
  El open source puede ganar confianza gracias a un SSDLC transparente, mientras que con closed source no queda otra que confiar en el proveedor
  No estoy de acuerdo con el argumento de Drew Breunig. La cantidad de bugs es finita, y si un modelo suficientemente potente escanea periódicamente el código, la probabilidad de vulnerabilidades restantes cae drásticamente

• “¿Y si la IA puede escanear el código open source?” → Entonces simplemente corrige los bugs.
  Esta lógica no convence para nada

• Decir “vamos a cerrar porque la IA puede acceder al código” es solo una excusa

  • La razón real no es la IA ni la seguridad, sino que hay demasiados proyectos clon y eso está reduciendo sus ingresos

• Este tipo de decisión al final parece seguridad por oscuridad (Security through obscurity).
  Uno se pregunta desde cuándo eso pasó a ser el modelo correcto

  • La oscuridad solo sirve cuando no es la defensa principal, sino un mecanismo disuasivo complementario
  • Reducir la superficie de ataque no es oscuridad, sino una estrategia de minimización de vectores de ataque
  • Aun así, también hubo quien opinó que sigue siendo mejor que “seguridad sin oscuridad”
  • Uno de los cofundadores dijo que “el chico de 16 años de la casa de al lado puede hackearlo en 15 minutos por 100 dólares”
  • Parece que olvidaron por qué surgió la idea de “no hacer seguridad por oscuridad”.
    No fue porque generaciones pasadas fueran tontas, sino porque era un enfoque que se veía bien por fuera pero fracasó

• Lo que dice Cal.com de “nosotros creíamos en el open source” suena vacío.
  Si fuera sincero, no habrían dado una excusa tan sin sentido

• Esta es una excusa que ya podían haber usado antes de la IA.
  Parece un intento de proteger ingresos porque el producto principal no logró diferenciarse lo suficiente.
  Al final, no es más que una medida para proteger ventas