El código abierto no ha muerto
(strix.ai)- Cal.com cambió partes clave de su código a un modelo cerrado, citando las amenazas de detección de vulnerabilidades impulsadas por IA y señalando que vivimos en una era en la que “la transparencia equivale a exposición”
- Strix es un proyecto de código abierto que desarrolla agentes de seguridad de IA autónomos y colaboró con Cal.com en un proceso de divulgación responsable de vulnerabilidades
- Strix señala que cerrar el código no es la solución a las amenazas de seguridad impulsadas por IA y que, por el contrario, bloquea oportunidades de revisión de buena fe
- Los ataques con IA pueden penetrar incluso sin acceso al código, mediante enfoques de caja negra, por lo que una estrategia cerrada sigue siendo vulnerable a ataques automatizados
- La verdadera solución es integrar defensas de IA en el proceso de desarrollo y mantener la transparencia y colaboración del código abierto mediante validación automatizada continua
El cambio de Cal.com hacia código cerrado y el debate sobre la seguridad del código abierto
- Cal.com anunció que cambiará su base de código principal de código abierto a un modelo cerrado
- El CEO Bailey Pumfleet mencionó que hemos entrado en una era en la que la IA detecta vulnerabilidades de forma automática a gran escala y “la transparencia equivale a exposición”
- También argumentó que la IA ahora puede realizar escaneo de código y exploits a un costo casi “cero”
- Strix es un proyecto de código abierto que desarrolla agentes de seguridad de IA autónomos y recientemente superó las 24 mil estrellas en GitHub
- Procesa más de 15 mil millones de tokens de LLM por día para detectar vulnerabilidades de software
- Colaboró con Cal.com en un proceso de divulgación responsable de vulnerabilidades usando Strix y no reveló detalles de bugs que aún no han sido corregidos
- Reconoce que la decisión de Cal.com surge de una intención de proteger a los usuarios
- Sin embargo, Strix enfatiza que “cerrar el código no es la solución a las amenazas de seguridad basadas en IA”
- Coincide en que la IA cambió la seguridad de forma fundamental, pero se opone a abandonar el código abierto
La IA de caja negra también puede penetrar código cerrado
- La suposición de que, si se cierra el código fuente, los atacantes no podrán leerlo no aplica al modelo moderno de ataque con IA
- Podía ser válida para herramientas de análisis estático del pasado, pero los agentes de IA autónomos pueden atacar incluso sin acceso al código
- Herramientas como Strix están especializadas en pruebas de caja negra y caja gris
- Interactúan con endpoints reales y realizan manipulación del estado del navegador, análisis del tráfico de red y detección de vulnerabilidades en la lógica de negocio
- Cerrar el código solo bloquea las oportunidades de revisión de desarrolladores bien intencionados, mientras que la superficie de ataque expuesta a los atacantes, como APIs y webhooks, sigue ahí
La estrategia de ‘seguridad por ocultamiento’ es vulnerable a ataques automatizados
- El código cerrado depende del equipo interno de seguridad y de pruebas de penetración manuales periódicas
- Pero los atacantes exploran vulnerabilidades las 24 horas con bots de IA que pueden operar sin descanso
- Esto parte de la suposición de que el personal interno puede encontrar fallas más rápido que los ataques externos con IA, algo que en la práctica es imposible
- En el pasado, la ‘seguridad por ocultamiento’ (Security through obscurity) ya ha fracasado, y en la era de la IA la velocidad de ese fracaso se acelerará exponencialmente
La verdadera respuesta: defender la IA con IA
- Es cierto que la velocidad del desarrollo de software ya superó la capacidad humana de revisión de seguridad
- Pero la respuesta no es ocultar el código, sino integrar defensas de IA en el proceso de desarrollo
- Se necesita validación continua basada en IA (continuous validation)
- Cuando un desarrollador abre un Pull Request, la IA debe intentar atacar de inmediato
- Cuando cambia la infraestructura, la IA debe verificar automáticamente la superficie de ataque
- Las pruebas de seguridad deben automatizarse dentro del pipeline de CI/CD, y hay que responder con una automatización interna mejor que la automatización de ataque
El código abierto sigue vigente
- El principio tradicional de que “muchos ojos hacen superficiales los bugs” puede debilitarse, pero el código abierto en sí no ha muerto
- Strix mantiene su enfoque abierto con la convicción de que la transparencia genera fortalezas
- Las herramientas de seguridad de próxima generación deben ser tan accesibles y abiertas como las herramientas de ataque
- Ocultar el código no puede detener a los hackers con IA, pero darles a los desarrolladores agentes de seguridad autónomos puede aumentar la capacidad de defensa
- Strix ofrece una prueba gratuita de pruebas continuas de seguridad basadas en IA
1 comentarios
Opiniones en Hacker News
Yo mantengo un proyecto open source, y en los últimos meses se dispararon los reportes de vulnerabilidades de seguridad
La mayoría eran casos menores, pero también hubo problemas reales y los corregí todos
El software cerrado no recibiría este tipo de reportes, pero existe el riesgo de abuso con IA
Por eso coincido totalmente con el mensaje de este artículo
Solo está cerrado hacia afuera; no está cerrado para los desarrolladores internos
Aunque con la llegada de las herramientas de IA también surgió el problema de principiantes que envían reportes alucinados generados por IA
Las empresas de software cerrado también deberían realizar auditorías de seguridad por iniciativa propia
Entiendo que Cal.com haya pasado a cerrado, pero al final parece más bien marketing de Strix
Cuanto más tiempo sigan públicas las empresas open source, más salen perdiendo
Creo que publicar este tipo de reportes periódicamente podría demostrar confiabilidad en seguridad
Aunque en proyectos existentes ya se acumulan issues de severidad media y baja, así que resolverlos tomará tiempo
Es decir, aprovechamos al mismo tiempo la detección de vulnerabilidades con IA y la defensa en múltiples capas, manteniendo el código privado
La razón que dio el CEO, eso de que “la IA detecta vulnerabilidades automáticamente a gran escala”, suena a pretexto
Parece más probable que la razón real sea que con open source es difícil construir un modelo de negocio sostenible
Cambiar a cerrado incluso perjudicaría al negocio, pero decidimos que proteger los datos de los clientes era más importante
Ya sea recorte de personal o cambio de licencia, resulta muy conveniente decir que “fue por la IA”
Lugares como npmjs tal vez pronto se conviertan en sitios de referencia
Culpar a los escáneres de IA no es más que maquillaje de PR
Este artículo de verdad parece un manual de content marketing
Es un caso donde la sinceridad y el marketing se mezclan de forma muy hábil
De hecho, Strix escaneó el código de Cal.com, pero pasó por alto muchas vulnerabilidades
Ninguna plataforma es perfecta, y un escáner de IA por sí solo no basta
“Security through obscurity” (seguridad por ocultamiento) solo es un problema cuando se usa por sí sola
Como capa disuasoria que aumenta el costo para el atacante, sí puede ser una estrategia válida
Al final, la seguridad es una lucha de quién puede invertir más recursos
La IA solo es más eficiente que los humanos; la ecuación básica entre abierto y cerrado no cambia
Me pregunto si a Cal.com de verdad le preocupa la seguridad, o si solo es una excusa para tapar las dificultades del SaaS open source
Esa lógica ya se demostró equivocada hace varias décadas
No creo que la “seguridad por ocultamiento” sea la razón real
Simplemente pensaron que podrían ganar más dinero cerrando el código
Uno de los lados feos del open source es que la gente da por sentado el trabajo gratis
En vez de agradecer a los desarrolladores que trabajaron gratis durante años, se enojan porque ya no quieren seguir haciéndolo
Y eso mientras ellos mismos no trabajarían sin sueldo
Por lo que dice el artículo, parece que Cal.com estuvo recibiendo pruebas de vulnerabilidades con bots de red team
Como encontraron bugs demasiado rápido, es posible que el CEO haya sentido la carga del costo de corregirlos y por eso cerró el código
En la práctica, se ve casi como una declaración pública de que “el código de Cal.com tiene muchas vulnerabilidades”
Si ajustas eso, terminas dejando pasar vulnerabilidades reales, y al final sube el costo de validación
En open source esos reportes quedan públicos y eso daña la reputación, mientras que en software cerrado no pasa lo mismo
También por eso podrían haber cambiado a cerrado
El verdadero riesgo no es la detección de vulnerabilidades, sino la capacidad de los LLM de reescribir proyectos open source en otros lenguajes para eludir licencias
Legalmente es ambiguo. Si una persona estudia el código y luego escribe uno nuevo, está bien; pero si lo hace una IA, en la práctica es un copiar y pegar complejo
No está claro cómo se aplicarían las licencias en esos casos
Publicar el código por sí solo no hace viable un negocio; la capacidad operativa importa más
Estoy de acuerdo con la idea de que las pruebas de seguridad deberían automatizarse en el pipeline de CI/CD
Pero eso no demuestra la necesidad del open source
El equilibrio del open source ya se rompió hace mucho
Desde hace años existe una estructura en la que empresas usan código open source para crear productos de pago sin contribuir de vuelta
Un ejemplo es PHP: lo usa todo el mundo, pero sigue teniendo poco presupuesto