A violação da Vercel e por que não apostamos com segredos “não sensíveis”

Acordamos com a notícia de que a Vercel foi atingida. Se você está no mundo do desenvolvimento web, é como ouvir que o cofre principal do banco acabou de ser escolhido. O Vercel não é uma operação amadora; eles são a espinha dorsal de milhões de sites, incluindo o ecossistema Next.js. Mas até mesmo os gigantes podem tropeçar quando a conveniência começa a vencer o cabo de guerra contra a segurança.

A violação não começou com um ataque direto aos servidores da Vercel. Tudo começou com uma ferramenta de IA de terceiros chamada Context.ai. Um funcionário da Vercel o conectou ao Google Workspace via OAuth. Os atacantes acessaram o Context.ai, conectaram a conexão OAuth à conta do Google do funcionário e, a partir daí, tiveram um mapa para o reino interno. É um pivô clássico da cadeia de suprimentos e é confuso.

Mas aqui está a parte que realmente impressiona Sweent: os atacantes conseguiram ler variáveis de ambiente que não estavam marcadas como sensíveis. A Vercel tem um sistema em que os desenvolvedores podem escolher se uma variável é sensível ou não. Se você não marcar essa caixa, esses segredos serão armazenados de forma a torná-los legíveis se um invasor entrar. Na Sweent, analisamos essa escolha de design e vemos um risco enorme e desnecessário. Não acreditamos em dar aos desenvolvedores a opção de serem menos seguros por uma questão de conveniência.

A falácia do segredo “não sensível”

No painel do Vercel, há uma distinção entre variáveis de ambiente sensíveis e não sensíveis. A ideia é que algumas coisas, como uma chave de API pública ou uma string de configuração não crítica, não precisem da criptografia de alto nível que uma senha de banco de dados exige. Mas na prática? Os desenvolvedores estão ocupados. O código de envio é às 2:00 da manhã. Eles seguem o caminho de menor resistência. Se o padrão não for “Segurança máxima”, os segredos vazarão. Não é uma questão de se, mas de quando.

Vimos isso acontecer em dezenas de projetos antes que eles cheguem até nós. Um desenvolvedor acha que um token específico é de “baixo risco”, então ele não se preocupa com a camada extra de proteção. Em seguida, ocorre uma violação e esse token de “baixo risco” se torna o ponto central para uma aquisição completa do sistema.

Na Sweent, nosso protocolo é simples: não existe uma variável de ambiente não sensível. Se for uma variável que reside em um arquivo .env ou em um pipeline de CI/CD, ela é tratada como um segredo crítico. Período. Não oferecemos um botão de “conveniência” que deixe as chaves em branco. Ao aplicar uma política rígida em que cada variável é criptografada e restrita, eliminamos o erro humano que levou à exfiltração de dados no incidente da Vercel. Se um invasor tivesse conseguido entrar em um de nossos ambientes durante uma violação semelhante, teria encontrado uma parede de dados criptografados que não conseguiria ler, em vez de uma lista de chaves “não confidenciais” que poderiam usar para intensificar o ataque.

Combatendo atacantes acelerados por IA com protocolo

O CEO da Vercel mencionou que os atacantes se moveram com uma “velocidade surpreendente” e provavelmente foram acelerados pela IA. Essa é a nova realidade. Não estamos mais apenas nos defendendo de um cara com capuz digitando comandos manualmente. Estamos nos defendendo contra agentes automatizados que podem analisar a arquitetura de um sistema, identificar vulnerabilidades e executar uma exploração em segundos.

Quando o adversário está se movendo na velocidade da máquina, sua defesa não pode depender de um humano decidindo em qual caixa de seleção clicar. Tem que ser incorporado à infraestrutura. É por isso que criamos nossos fluxos de trabalho internos para presumir que uma violação é sempre possível. Não monitoramos apenas as intrusões; reduzimos a superfície de ataque para que a IA não encontre nada depois de passar pela porta.

Um dos maiores problemas na violação do Vercel foi a conexão OAuth. O OAuth é incrivelmente útil, mas é uma enorme falha de segurança se não for gerenciado com extrema disciplina. Você clica em um botão para experimentar uma nova ferramenta de produtividade de IA e, de repente, essa ferramenta tem acesso de leitura a todo o seu Google Workspace. Se essa ferramenta for invadida, como aconteceu com o Context.ai, toda a sua organização será exposta.

Nossa equipe na Sweent aplica uma política de confiança zero para integrações de terceiros. Não permitimos que “ferramentas novas e brilhantes” se conectem aos nossos sistemas principais sem uma auditoria de segurança completa. E mesmo assim, restringimos os escopos ao mínimo absoluto. Se uma ferramenta precisar ler apenas um calendário, ela não terá acesso a todo o espaço de trabalho. Parece muito trabalhoso, e é. Mas é a diferença entre um pequeno incidente e um pedido de resgate de 2 milhões de dólares de um grupo como o ShinyHunters.

A regra de rotação secreta de 24 horas

Mesmo com as melhores defesas, as coisas podem dar errado. A marca de uma equipe profissional não é apenas como eles evitam uma violação, mas como respondem a uma. A Vercel recomendou que seus clientes trocassem suas credenciais imediatamente. Mas “imediatamente” é um termo vago no mundo corporativo. Para algumas empresas, isso significa na próxima semana. Para outros, significa depois de um longo fim de semana.

Na Sweent, temos uma regra rígida: no caso de qualquer suspeita de comprometimento, cada segredo, chave de API e string de banco de dados é alternado em 24 horas. Não esperamos por uma autópsia completa. Não esperamos para ver se os dados foram “realmente” exfiltrados. Nós nos movemos mais rápido que o atacante.

Quando um atacante percebe que tem uma chave, essa chave já está morta. Usamos scripts automatizados e infraestrutura como código para lidar com isso. Se estivéssemos usando o Vercel durante essa violação, as chaves de nossos clientes teriam sido recicladas e protegidas antes mesmo de as notícias chegarem aos principais blogs de tecnologia. A velocidade é a única defesa contra um atacante que se move com a velocidade impulsionada pela IA.

Segurança da cadeia de suprimentos e a regra dos 7 dias

A violação da Vercel também levantou preocupações sobre a cadeia de suprimentos da NPM. Como a Vercel é dona do Next.js, um invasor com os tokens certos poderia potencialmente enviar uma versão “envenenada” para milhões de desenvolvedores. Essa é a opção nuclear da guerra cibernética. Se você está atualizando cegamente suas dependências toda vez que uma nova versão é lançada, você está jogando Roleta Russa com sua base de código.

Protegemos nossos clientes implementando um atraso obrigatório em todas as atualizações de dependências não críticas. Normalmente, esperamos pelo menos 7 dias antes de receber novas versões das principais bibliotecas. Por quê? Porque a maioria dos ataques à cadeia de suprimentos são identificados e neutralizados na primeira semana. Por não sermos os “primeiros a adotar” cada patch menor, garantimos que nossos clientes não sejam os primeiros a serem atingidos quando um pacote é sequestrado.

Pode parecer que estamos sendo excessivamente cautelosos, mas veja a alternativa. A ShinyHunters está supostamente vendendo o banco de dados interno da Vercel por 2 milhões de dólares. Eles têm 580 registros de funcionários, painéis internos e código-fonte. Essa é uma falha catastrófica que poderia ter sido mitigada por protocolos internos mais rígidos e uma abordagem menos “conveniente” ao gerenciamento de segredos.

Por que não pulamos as partes “difíceis”

A segurança costuma ser vista como um ponto de atrito. Isso retarda o desenvolvimento. Isso torna mais difícil experimentar novas ferramentas. Ele adiciona etapas ao processo de implantação. E é exatamente por isso que tantas startups ignoram as partes difíceis. Eles querem se mover rápido e quebrar coisas. Mas quando o que você quebra é a confiança de seus clientes, talvez você não tenha a chance de consertá-la.

Criamos Sweent com base na ideia de que a transformação digital não deveria ser feita à custa da segurança. Lidamos com o atrito para que nossos clientes não precisem. Somos nós que fazemos as auditorias de segurança nas ferramentas de IA. Somos nós que aplicamos a criptografia obrigatória em todas as variáveis de ambiente. Somos nós que nos mantemos atualizados para girar as teclas em 24 horas, enquanto o resto do setor ainda está lendo as manchetes.

Se você está no Vercel agora, provavelmente deveria verificar seu painel. Audite cada variável. Marque todos eles como sensíveis. Corte todas as conexões OAuth que você absolutamente não precisa. Mas se você quiser parar de se preocupar se seus desenvolvedores marcaram a caixa certa às 2h, você precisa de um parceiro que não trate a segurança como um recurso opcional.

No final do dia, a Vercel provavelmente se recuperará disso. Eles têm engenheiros de elite e muito capital. Mas para uma empresa menor, uma violação como essa é uma sentença de morte. Não espere a próxima grande manchete para perceber que suas variáveis “não sensíveis” são um risco. Os atacantes estão se movendo na velocidade da máquina. Você está?