Cal.com migra de open source para código fechado devido a ameaças de segurança com IA

• A Cal.com, operada como open source por 5 anos, decidiu migrar para código fechado devido ao aumento das ameaças de segurança baseadas em IA
• Com a chegada de uma era em que a IA analisa automaticamente bases de código para encontrar vulnerabilidades, o código público passou a se tornar uma pista direta para atacantes
• A empresa escolheu priorizar o risco de segurança em vez de manter o open source para proteger os dados dos clientes
• Para manter o espírito open source, lançou o projeto Cal.diy sob licença MIT, oferecendo uma versão auto-hospedável para a comunidade
• À medida que a IA avança em uma velocidade que supera os sistemas de segurança existentes, a Cal.com afirmou que pretende voltar ao open source quando a segurança estiver estabilizada

---

Decisão da Cal.com de encerrar o open source e as ameaças de segurança com IA

• A Cal.com operou como open source por 5 anos, mas decidiu migrar para código fechado (Closed Source) devido ao aumento acentuado das ameaças de segurança baseadas em IA
  • A proteção dos dados dos clientes foi colocada como prioridade máxima, e a empresa concluiu que manter o open source já não era mais seguro
  • Afirmou que “não foi uma escolha fácil”
• No passado, explorar vulnerabilidades de uma aplicação exigia tempo e esforço de hackers experientes, mas o cenário mudou para uma era em que a IA escaneia automaticamente a base de código para encontrar falhas
  • O código open source foi descrito como “equivalente a fornecer a planta de um cofre” aos atacantes
  • Com startups de segurança em IA comercializando esse tipo de capacidade, diferentes vulnerabilidades são detectadas por ferramentas distintas, tornando difícil estabelecer um único padrão de segurança confiável
• A Cal.com afirmou que precisava escolher entre duas opções
  • manter o open source e aceitar o risco sobre os dados dos clientes, ou
  • migrar para código fechado para reduzir o risco
  • Não é uma solução perfeita, mas foi considerada uma decisão inevitável para proteger os usuários
• Para manter o espírito open source, a empresa lançou um projeto separado chamado Cal.diy sob a licença MIT
  • O Cal.diy é uma versão aberta para desenvolvedores e usuários entusiastas, uma versão centrada na comunidade e auto-hospedável
  • A base de código do serviço principal foi amplamente modificada em sua estrutura central, incluindo autenticação e sistemas de processamento de dados, e está tecnicamente separada do Cal.diy
• A IA está mudando rapidamente o ambiente de segurança, e também foi citado um caso em que uma IA encontrou em poucas horas uma vulnerabilidade de 27 anos no kernel BSD e gerou um exploit
  • Essa velocidade e precisão superam os sistemas tradicionais de resposta em segurança
  • A Cal.com afirmou que está tomando todas as medidas possíveis para proteger clientes, aplicações e dados sensíveis, e expressou a intenção de voltar ao open source quando o ambiente de segurança se estabilizar

Direção futura e mensagem

• No momento, a mitigação dos riscos de segurança e a proteção dos usuários são as principais prioridades
• A relação com a comunidade open source será mantida por meio do Cal.diy
• No longo prazo, a empresa deixa em aberto a possibilidade de retorno ao open source conforme o ambiente de segurança evoluir
• Esta decisão mostra como a realidade da segurança na era da IA está afetando diretamente os modelos de distribuição de software

[GN⁺]

Opiniões no Hacker News

• Drew Breunig chegou à conclusão oposta no texto que publicou ontem
  Agora que vulnerabilidades de segurança se tornaram um recurso que pode ser encontrado com tokens, o open source passa a ter ainda mais valor
  No open source, vários projetos podem compartilhar o custo de auditoria, enquanto no closed source cada um precisa encontrar todas as vulnerabilidades sozinho

  • Esse texto foi repostado aqui. O título é Cybersecurity looks like proof of work now
  • O motivo real parece ser impedir que a IA faça lavagem de copyright (copyright-wash) do produto. A segurança soa como pretexto
  • Essa conclusão parece mais convincente. Faz só algumas semanas que o Mythos apareceu, então é estranho mudar de princípios tão rápido. Provavelmente houve um motivo de negócio, e agora parece que encontraram uma justificativa fácil de vender ao público
  • Também é uma conclusão economicamente plausível. No fim, é preciso ou gerar valor suficiente para bancar o custo dos tokens, ou reduzir o ganho econômico de encontrar vulnerabilidades
    Isso pode ser feito reduzindo o escopo de implantação ou diminuindo os privilégios do sistema.
    Daqui para frente, parece provável uma evolução para o formato “especificação aberta + geração de código baseada em modelos”. Segurança e governança devem acontecer na camada do modelo
  • A ideia de que “para fortalecer o sistema, você precisa gastar mais tokens do que o atacante usa” soa estranha. Em software estável, a superfície de ataque diminui, e o Mythos não produz novas vulnerabilidades. Os defensores deveriam ter vantagem em termos de tokens

• Sou responsável pelo projeto Thunderbird. Nossa ferramenta de agendamento Thunderbird Appointment sempre continuará open source
  Fica o convite para construir junto no repositório no GitHub. Vamos ajudar para que ela possa substituir o Cal.com

  • Seria bom adicionar capturas de tela no README ou na tela antes do login. A ferramenta parece boa, mas fiquei curioso sobre o preço da versão hospedada
  • Mas em notebooks Linux antigos o Thunderbird é pesado demais. Seria bom considerar também os usuários de baixo desempenho. Um pedido para manter a internet em um nível suportável
  • Entrei no site, coloquei meu e-mail, fui parar numa lista de espera e no fim ainda bloquearam meu e-mail. A experiência do usuário foi ruim
  • Em tom de piada, alguém respondeu ao “vamos construir juntos” com “então vou precisar marcar um appointment?”
  • Também houve reações positivas dizendo que parece uma boa alternativa

• Se LLM encontra vulnerabilidades de código tão bem assim, então não bastaria rodar um pentest interno com LLM antes de cada release?
  Dá a impressão de que a lei de Linus (link) finalmente virou realidade

  • Mas depois da release, o atacante pode analisar o código com tempo infinito e LLMs cada vez mais inteligentes.
    Para se defender, seria preciso fazer antecipadamente a cada release tudo o que o atacante faria
  • Com o avanço dos LLMs, a manutenção de FOSS passa a ter um aumento brusco de custo de tempo e de pessoal.
    Cresce o número de issues e PRs ruins gerados por IA, o que reduz o incentivo para manter projetos open source.
    Quando produtos comerciais se apoiam em um núcleo FOSS, esse tipo de transição deve se tornar mais comum
  • No closed source, dá para usar LLM internamente para reforçar a segurança.
    Mas também dá para entender a decisão de fechar para não deixar aberta a oportunidade de ataque ao exterior
  • Em ambientes com commits frequentes, seria necessário escanear toda a base de código com LLM toda vez, então o custo explode.
    Lugares como o GitHub já têm custo alto com análise estática
  • No fim, a opinião é que o melhor é escrever código simples e fazer testes de segurança com LLM também no nível do compilador

• Essa decisão parece ser mais um julgamento de negócio do que de segurança.
  Com a IA, o self-hosting ficou mais fácil, e a receita de hospedagem paga dos projetos open source está diminuindo

  • As pessoas usam LLM para implementar por conta própria “funções pro” ou descobrir pontos de extensão. Segurança é só fachada
  • Culpar a IA é desculpa. A IA já aprendeu a partir de código. Combinando algoritmos genéticos + fuzzing, ela aprende muito mais rápido que humanos
  • Hoje em dia tudo é jogado na conta da IA. Corte de pessoal, fim de produto, fechamento do código-fonte, tudo vira culpa da IA
  • O produto já está se tornando comoditizado, como a ferramenta de agendamento do Google Workspace
  • No fim, apareceu até a crítica de que se trata de um “sellout”

• Como cliente em potencial, fiquei decepcionado com a decisão do Cal.com.
  O open source pode conquistar confiança graças a um SSDLC transparente, enquanto no closed source só resta confiar no fornecedor
  Não concordo com o argumento de Drew Breunig. O número de bugs é finito, e se um modelo suficientemente forte escanear o código periodicamente, a probabilidade de vulnerabilidades remanescentes cai drasticamente

• “Se a IA pode escanear o código open source?” → então é só corrigir os bugs.
  Essa lógica não convence nem um pouco

• Dizer “vamos fechar porque a IA consegue acessar o código” é só desculpa

  • O motivo real não é IA nem segurança, e sim que há projetos clone demais e isso reduziu a receita

• No fim, esse tipo de decisão parece segurança por obscuridade (Security through obscurity).
  Fico me perguntando desde quando isso passou a ser o modelo certo

  • Obscuridade só funciona quando não é a defesa principal, mas um meio auxiliar de dissuasão
  • Reduzir a superfície de ataque não é obscuridade, e sim uma estratégia de minimização de vetores de ataque
  • Ainda assim, também houve a opinião de que isso é melhor do que “segurança sem obscuridade”
  • Um dos cofundadores chegou a dizer que “o garoto de 16 anos da casa ao lado consegue hackear em 15 minutos com 100 dólares”
  • Parece que esqueceram por que surgiu a ideia de “não fazer segurança por obscuridade”.
    Não foi porque as gerações passadas eram burras, e sim porque parecia bom à primeira vista, mas fracassou na prática

• A fala do Cal.com de que “nós acreditávamos em open source” soa vazia.
  Se fosse sincero, não teriam dado essa desculpa sem sentido

• Essa é uma desculpa que já podia ser usada antes da IA.
  Parece uma tentativa de proteger a receita porque o produto principal não conseguiu se diferenciar o suficiente.
  No fim, é só uma medida para proteger faturamento