O open source não morreu

• Cal.com está tornando seu código principal fechado por causa da ameaça de detecção de vulnerabilidades baseada em IA, mencionando que vivemos uma era em que “transparência é exposição”
• Strix é um projeto open source que desenvolve agentes autônomos de segurança com IA e trabalhou com a Cal.com em um processo responsável de divulgação de vulnerabilidades
• A Strix argumenta que fechar o código não é a solução para as ameaças de segurança impulsionadas por IA e, ao contrário, bloqueia oportunidades de revisão de boa-fé
• Ataques com IA podem penetrar em modo caixa-preta mesmo sem acesso ao código, e a estratégia de fechar o código continua vulnerável a ataques automatizados
• A verdadeira solução é integrar defesas com IA ao processo de desenvolvimento e manter a transparência e a colaboração do open source por meio de validação automática contínua

---

A mudança da Cal.com para código fechado e o debate sobre segurança no open source

• A Cal.com anunciou que vai mudar sua base de código principal de open source para fechada
  • O CEO Bailey Pumfleet afirmou que chegamos a uma era em que a IA automatiza a detecção de vulnerabilidades em larga escala e em que “transparência é exposição”
  • Como motivo, citou o fato de que a IA agora consegue fazer varredura de código e exploração a um custo praticamente “zero”
• A Strix é um projeto open source que desenvolve agentes autônomos de segurança com IA e recentemente passou de 24 mil estrelas no GitHub
  • Processa mais de 15 bilhões de tokens de LLM por dia para detectar vulnerabilidades de software
  • Trabalhou com a Cal.com em um processo responsável de divulgação de vulnerabilidades usando a Strix, e não divulgou detalhes de bugs que ainda não foram corrigidos
  • Reconhece que a decisão da Cal.com partiu da intenção de proteger os usuários
• No entanto, a Strix enfatiza que “fechar o código não é a solução para ameaças de segurança baseadas em IA”
  • Concorda que a IA mudou a segurança de forma fundamental, mas se opõe a abandonar o open source

IA de caixa-preta consegue atacar até código fechado

• A suposição de que, ao fechar o código-fonte, atacantes não conseguirão lê-lo não se aplica ao modelo moderno de ataques com IA
  • Isso funcionava com ferramentas antigas de análise estática, mas agentes autônomos de IA conseguem atacar mesmo sem acesso ao código
• Ferramentas como a Strix são especializadas em testes de caixa-preta e caixa-cinza
  • Interagem com endpoints reais e realizam manipulação do estado do navegador, análise de tráfego de rede e detecção de vulnerabilidades na lógica de negócio
• Fechar o código apenas bloqueia a oportunidade de revisão por desenvolvedores bem-intencionados, enquanto a superfície de ataque exposta a invasores, como APIs e webhooks, continua a mesma

A estratégia de “segurança por obscuridade” é vulnerável a ataques automatizados

• Código fechado depende da equipe interna de segurança e de testes manuais periódicos de invasão
  • Mas os atacantes usam bots de IA que operam sem parar para procurar vulnerabilidades 24 horas por dia
• Isso parte da suposição de que a equipe interna conseguirá encontrar falhas mais rápido do que ataques externos com IA, o que na prática é impossível
• No passado, a “segurança por obscuridade” (Security through obscurity) já falhou, e na era da IA a velocidade desse fracasso tende a aumentar de forma exponencial

A solução real: usar IA para defender contra IA

• É verdade que a velocidade de desenvolvimento de software já ultrapassou a velocidade da revisão humana de segurança
  • Mas a solução não é esconder o código, e sim integrar defesas com IA ao processo de desenvolvimento
• É necessária uma validação contínua baseada em IA (continuous validation)
  • Quando o desenvolvedor abre um Pull Request, a IA tenta atacar imediatamente
  • Quando há mudanças na infraestrutura, a IA valida automaticamente a superfície de ataque
• Os testes de segurança precisam ser automatizados dentro do pipeline de CI/CD, respondendo com automação interna melhor do que a automação dos ataques

O open source continua válido

• O princípio tradicional de que “muitos olhos tornam os bugs superficiais” pode estar enfraquecendo, mas o open source em si não morreu
• A Strix mantém o open source com a convicção de que a transparência cria força
  • As ferramentas de segurança da próxima geração precisam ser tão acessíveis e abertas quanto as ferramentas de ataque
• Esconder o código não impede hackers com IA, mas dar aos desenvolvedores agentes autônomos de segurança aumenta a possibilidade de defesa
• A Strix oferece uma experiência gratuita de testes contínuos de segurança com IA

[GN⁺]

Comentários no Hacker News

• Eu mantenho um projeto open source e, nos últimos meses, o número de relatórios de vulnerabilidades de segurança explodiu
  A maioria era de casos triviais, mas havia problemas reais também, e corrigi todos
  Software fechado não receberia esse tipo de relatório, mas há o risco de exploração com IA
  Por isso concordo totalmente com a mensagem deste texto

  • Mesmo sendo fechado, não dá para rodar scanners de IA internamente?
    Só é fechado para fora; para os desenvolvedores internos não é
  • Você não receberia relatórios de scanners automatizados de repositório, mas programas de bug bounty ainda geram muitos relatórios
    Só que, com a chegada das ferramentas de IA, surgiu também o problema de iniciantes enviarem relatórios fantasiosos gerados por IA
    Empresas de software fechado também precisam fazer auditorias de segurança por iniciativa própria
  • Do ponto de vista do atacante, vale muito mais a pena usar IA para atacar repositórios open source
    Entendo a mudança da Cal.com para fechado, mas no fim isso parece mais marketing da Strix
    Para empresas open source, o prejuízo de continuar tudo público só tende a aumentar
  • Eu também configurei testes automatizados de intrusão noturnos no meu projeto open source
    Acho que publicar esses relatórios periodicamente pode ajudar a comprovar a confiança na segurança
    Só que, em projetos já existentes, há um acúmulo de questões médias e leves, então resolver tudo deve levar tempo
  • Na nossa empresa, usamos internamente scanners de IA e testes manuais de intrusão em paralelo
    Ou seja, aproveitamos ao mesmo tempo detecção de vulnerabilidades com IA e defesa em camadas com o código fechado

• O motivo dado pelo CEO, de que “a IA detecta vulnerabilidades automaticamente em escala”, soa como desculpa
  O motivo real provavelmente é que é difícil construir um modelo de negócios sustentável com open source

  • Concordo. Entendo migrar para fechado para garantir rentabilidade, mas usar a segurança como desculpa não é honesto
  • Nós mantivemos 300% de crescimento e lucratividade por 5 anos com open source
    Migrar para fechado seria até pior para o negócio, mas decidimos que proteger os dados dos clientes era mais importante
  • Hoje em dia existe uma tendência de culpar a IA por tudo
    Seja corte de pessoal ou mudança de licença, “foi por causa da IA” virou uma desculpa conveniente
  • Agora ficou fácil demais não usar o código open source diretamente e extrair só as partes necessárias para remontar tudo
    Lugares como o npmjs talvez logo virem sites de referência
  • Deixar o ‘cal.diy’ aberto e fechar a parte corporativa é uma estratégia típica de open core
    Culpar scanners de IA por isso é só embalagem de PR

• Este texto é praticamente um manual de content marketing

  1. chama atenção com um título provocativo
  2. conquista a simpatia do leitor ao empatizar com a posição da Cal.com
  3. propõe uma solução séria para o problema
  4. e no fim conecta isso naturalmente à promoção do próprio produto
     É um caso em que sinceridade e marketing se misturam de forma muito habilidosa
  • Eu também li assim. A empresa que escreveu isso vende um serviço de varredura de vulnerabilidades com IA, então no fim é para induzir cadastro
    De fato a Strix escaneou o código da Cal.com, mas deixou passar muitas vulnerabilidades
    Nenhuma plataforma é perfeita, e só um scanner de IA não basta
  • É uma pena que este texto tenha recebido tantos votos. A densidade do conteúdo é de um comentário só
  • Pessoalmente não uso IA. Neste momento, embarcar na onda da IA é fácil do ponto de vista de marketing, mas duvido que haja valor real nisso

• “Security through obscurity” (segurança por obscuridade) só é um problema quando usada sozinha
  Como camada de dissuasão que aumenta o custo para o atacante, é uma estratégia válida
  No fim, segurança é uma disputa de quem consegue investir mais recursos
  A IA é apenas mais eficiente que humanos; a equação fundamental entre aberto e fechado não muda

• Fico me perguntando se a Cal.com está realmente preocupada com segurança, ou se isso é uma desculpa para encobrir as dificuldades de um SaaS open source
  Essa lógica já foi considerada errada décadas atrás

• Não acredito que “segurança por obscuridade” seja o motivo real
  Eles apenas acharam que fechar o open source daria mais lucro

  • Exato. O produto é deles, então podem fazer o que quiserem
    Um dos lados feios do open source é que as pessoas tratam trabalho gratuito como algo garantido
    Em vez de agradecer aos desenvolvedores que trabalharam de graça por anos, ficam irritadas quando eles decidem não continuar fazendo isso
    Sendo que elas mesmas não trabalhariam sem salário

• Pelo texto, parece que a Cal.com estava recebendo testes de vulnerabilidade com bots de red team
  Como os bugs estavam sendo encontrados rápido demais, é possível que o CEO tenha sentido o peso do custo de correção e fechado o código
  Na prática, isso soa quase como uma declaração pública de que “o código da Cal.com tem muitas vulnerabilidades”

  • Ou talvez o problema tenha sido o número excessivo de falsos positivos (false positives) gerados pelo scanner
    Ajustar isso faz você correr o risco de deixar escapar vulnerabilidades reais, e no fim o custo de verificação cresce
    No open source, esses relatórios ficam públicos e causam dano reputacional, mas no software fechado isso não acontece
    Então essa também pode ter sido a razão da mudança para fechado

• O risco real não é a detecção de vulnerabilidades, e sim a capacidade de um LLM reescrever projetos open source em outras linguagens para contornar licenças

  • Em projetos fechados, em teoria, a mesma coisa também é possível, mas há muito mais limitações
  • Na prática isso acontece com frequência. A IA regenera o código quase igual e cria projetos clone
    Juridicamente isso é nebuloso. Se uma pessoa estuda e reescreve do zero, tudo bem; mas quando a IA faz isso, vira na prática um copiar e colar complexo
    Nesses casos, não está claro como a licença deve ser aplicada
  • Muitas licenças open source permitem fork e revenda
    Só abrir o código não sustenta um negócio; a capacidade de operação é mais importante

• Concordo com a afirmação de que testes de segurança devem ser automatizados no pipeline de CI/CD
  Mas isso não prova a necessidade do open source

• O equilíbrio do open source já foi quebrado há muito tempo
  Há anos existe uma estrutura em que empresas usam código open source para criar produtos pagos sem contribuir de volta
  Linguagens como PHP, usadas no mundo inteiro mas com orçamento insuficiente, são um exemplo disso