Zaid Al Hamani, CEO e Fundador da Boost Security – Série de Entrevistas

Zaid Al Hamani, CEO e Fundador da Boost Security, é um líder em segurança cibernética e DevSecOps com mais de duas décadas de experiência em construir e escalar operações de tecnologia globais. Desde a fundação da Boost Security em 2020, ele se concentrou em modernizar a forma como as organizações protegem o desenvolvimento de software, aproveitando funções anteriores, incluindo VP de Segurança de Aplicativos na Trend Micro e Co-Fundador/CEO da IMMUNIO. Anteriormente, ele ocupou cargos de liderança sênior na Canonical, liderando iniciativas de produto, engenharia e suporte global, e na SITA, onde gerenciou operações de TI em larga escala e críticas. Sua carreira reflete um forte histórico de construir equipes, otimizar sistemas e avançar práticas de segurança modernas.

Boost Security é uma empresa de segurança cibernética focada em proteger a cadeia de suprimentos de software moderna por meio de uma plataforma de DevSecOps orientada a desenvolvedores. Sua tecnologia se integra diretamente aos pipelines de CI/CD para detectar, priorizar e remediar automaticamente vulnerabilidades, reduzindo a sobrecarga manual enquanto mantém a velocidade de desenvolvimento. Ao unificar a segurança de aplicativos e da cadeia de suprimentos em um único sistema, a plataforma fornece visibilidade completa sobre código, dependências e infraestrutura, ajudando as organizações a fortalecer a resiliência em ambientes complexos e nativos em nuvem.

Você liderou anteriormente a segurança de aplicativos na Trend Micro e co-fundou a IMMUNIO. O que o levou a fundar a Boost Security, e qual foi a lacuna no mercado que você estava posicionado para identificar cedo?

A IMMUN.IO foi uma das primeiras empresas de RASP a ser fundada – e nossa experiência até então foi que os WAFs como tecnologia de segurança em tempo de execução eram impossíveis de manter e não muito eficazes. Nós imaginamos uma forma de os WAFs serem substituídos por uma solução mais precisa, mais fácil de manter – instrumentando o aplicativo.

Isso foi em 2012, o DevOps ainda era um conceito inicial, a maioria das equipes não era Ágil, e o Kubernetes ainda não era uma coisa.

A Trend Micro adquiriu a IMMUN.IO em 2017. Naquela época, havia mais práticas de DevOps: pipelines de CI/CD, práticas de desenvolvimento Ágil, iterações e ciclos de lançamento mais rápidos, nuvem, etc. As equipes de desenvolvimento de software estavam melhorando na construção de software e no envio mais rápido. A segurança ainda estava quebrada, no entanto:

• As varreduras são muito lentas, ou os resultados chegam muito tarde
• Os resultados são muito complexos para os desenvolvedores agirem
• Havia uma taxa de falsos positivos geralmente inaceitável
• Muitos novos tipos de artefatos não eram verificados: infraestrutura como código, contêineres, APIs, por exemplo

Produzir software rapidamente era mais fácil. Produzir software seguro rapidamente ainda era difícil.

Esse foi o problema original que nos propusemos a resolver. Fazer o DevSecOps funcionar no mundo real; você consegue fazer uma equipe de desenvolvimento de software adicionar facilmente segurança ao SDLC, em uma velocidade que atenda aos novos padrões de velocidade? Você consegue tornar a cobertura ampla – onde uma plataforma é tudo o que você precisa? Você consegue fazer com que os desenvolvedores, não apenas adotem a tecnologia, mas a abracem e vejam os benefícios? Você consegue fazer com que isso escale para que você não precise de exércitos de profissionais de segurança para acompanhar a quantidade de código escrito…

Nós ajudamos as empresas a injetar segurança no SDLC durante a era do DevOps. Isso foi ir de 1 a 10. Agora estamos na era da codificação agente – onde os agentes estão escrevendo uma enorme quantidade de código – mas é fundamentalmente o mesmo problema – a velocidade e o volume do código apenas mudaram de 10 para 100; e visamos continuar a mesma trajetória.

Você argumentou que o ciclo de vida de desenvolvimento de software (SDLC) mudou fundamentalmente para cima. Qual foi o momento em que você percebeu que as abordagens tradicionais de DevSecOps já não eram suficientes?

Foi observar como os atacantes estavam realmente entrando. Nós continuávamos vendo o mesmo padrão: um fluxo de trabalho do GitHub Actions exposto que ninguém havia revisado desde que o repositório foi bifurcado, um token com acesso de produção à nuvem incorporado em uma configuração de executor, um trabalho de CI legítimo sequestrado para implantar payloads de atacantes. Esses se tornaram conhecidos como ataques “vivendo do pipeline”, porque o adversário usa sua própria automação contra você, com credenciais que sua equipe de segurança já aprovou.

A pilha de DevSecOps que havíamos construído ao longo de uma década não tinha resposta para isso. A varredura SAST de código-fonte do aplicativo. A varredura SCA de dependências do aplicativo. Ambas presumem que o pipeline que as executa é confiável. Enquanto isso, o próprio pipeline é um arquivo YAML com comandos shell, acesso à rede e credenciais sensíveis, e quase ninguém o revisa.

Quando isso se torna o caminho de menor resistência, você pode enviar código perfeitamente limpo e ainda entregar aos atacantes sua nuvem.

Como as empresas devem repensar o SDLC em um mundo onde os agentes de IA estão gerando código continuamente, em vez de os desenvolvedores escreverem passo a passo?

Nós todos temos que parar de pensar no SDLC como uma sequência de pontos de verificação. Os agentes de IA colapsaram o tempo entre “alguém escreveu isso” e “isso está em produção” de semanas para minutos. O modelo antigo presumia um ritmo humano entre revisão de código, SAST, SCA e implantação, mas estamos além disso agora.

A segurança tem que viver onde o agente opera: na máquina do desenvolvedor, dentro do contexto do prompt, nas conexões do agente com servidores MCP e modelos externos. No momento em que o código atinge o pipeline, você já perdeu a chance de moldá-lo. O agente já puxou a dependência. O modelo já viu a credencial. Mova os controles para cima, para onde o trabalho realmente acontece.

Muitas organizações ainda tratam as ferramentas de codificação de IA como simples camadas de produtividade. Por que você acredita que elas representam uma superfície de ataque completamente nova, em vez de apenas uma extensão de fluxos de trabalho existentes?

Tratar uma ferramenta de codificação de IA como uma camada de produtividade é como tratar um desenvolvedor júnior com acesso root como uma camada de produtividade. A etiqueta é tecnicamente precisa, mas não fornece nenhum quadro útil para pensar sobre o que pode dar errado.

Um agente de codificação lê seu sistema de arquivos, raspa variáveis de ambiente para contexto, busca dependências em registros públicos, abre conexões de saída para provedores de modelos remotos e servidores MCP, e executa comandos shell. Cada uma dessas ações costumava exigir um humano no loop. Agora elas acontecem em milissegundos, com os mesmos privilégios do desenvolvedor que lançou o agente.

Esse colapso funde limites de confiança que costumavam ser separados: a autoridade do desenvolvedor, o que uma ferramenta externa pode buscar e o que o código não confiável pode executar. Isso cria novas oportunidades para atacantes e pontos cegos que os defensores nem podem ver, muito menos defender.

A Boost Security define o laptop do desenvolvedor como o novo plano de controle. Quais riscos existem no endpoint que as equipes de segurança estão atualmente ignorando?

O maior deles é o inventário. A maioria das equipes de segurança não consegue dizer quais agentes de IA estão executando em quais laptops, quais servidores MCP esses agentes estão conectados ou quais extensões de IDE estão raspando o conteúdo do repositório agora. O EDR não tem visibilidade na camada do agente; o SIEM não consegue ver o que esses agentes fazem localmente também. É um problema de TI sombra com privilégios de execução de código.

Abaixo disso está a bagunça de credenciais. Nós construímos uma ferramenta de código aberto chamada Bagel em parte para tornar isso concreto. Um laptop de desenvolvedor típico contém tokens do GitHub com acesso de gravação a repositórios de produção, credenciais de nuvem que podem implantar infraestrutura, tokens npm ou PyPI que podem publicar para milhões de usuários e chaves de serviço de IA que os atacantes revendem. Nenhum deles é endurecido da maneira como um executor de CI é endurecido. A mesma máquina que contém essas credenciais também navega na web e instala extensões aleatórias do VS Code.

Combine os dois e você tem a superfície de ataque real. Uma extensão não confiável executando com privilégios de desenvolvedor em um ambiente cheio de chaves de nuvem é o alvo de maior alavancagem na empresa moderna. A maioria das equipes ainda não começou a procurar por isso.

Você destacou a “armadilha de contexto”, onde os agentes de IA podem acessar arquivos locais, variáveis de ambiente e configurações. Quão comum é o risco de vazamento de dados sensíveis por meio de prompts, e por que é tão difícil detectar?

Suficientemente comum para que o tratemos como o estado padrão de qualquer ambiente de desenvolvedor não gerenciado. Cada agente de codificação que inspecionamos puxa contexto local de forma agressiva. Eles lêem arquivos dot, variáveis de ambiente, arquivos recentes, às vezes árvores de diretório inteiras, e enviam esse contexto para um modelo remoto. As ferramentas são projetadas para funcionar dessa maneira; a captura de contexto agressiva é o que as torna úteis.

O problema de detecção começa porque o tráfego de um vazamento parece idêntico ao uso normal do produto. É TLS para api.openai.com ou api.anthropic.com. Ele vem de um aplicativo de negócios aprovado. O DLP padrão vê um desenvolvedor usando a ferramenta de IA que a empresa acabou de comprar uma licença. Ele não vê que uma das strings no prompt é uma chave secreta da AWS que o agente pegou de um arquivo .env meio esquecido em um diretório irmão.

Você só pega isso inspecionando prompts antes que eles deixem o laptop, o que é exatamente onde quase nenhuma pilha de segurança está atualmente posicionada.

Você menciona ataques de cadeia de suprimentos em velocidade de máquina. Pode nos levar por um cenário realista onde um agente de IA introduz uma vulnerabilidade mais rápido do que as ferramentas de segurança tradicionais podem identificá-la?

Aqui está um que vimos variações repetidamente. O desenvolvedor pede a um agente que adicione um recurso que precisa de uma biblioteca de retry HTTP. O agente sugere um nome de pacote. O pacote tem um som plausível, mas na verdade não existe no npm. Dentro de uma hora, um atacante registra, popula com lógica de retry funcionando, mais um script de pós-instalação que lê ~/.aws/credentials e posta o conteúdo para um webhook. O agente executa npm install sem verificar, porque os agentes não verificam reputação. A credencial some antes que o desenvolvedor sequer execute o código.

O ataque em si não é tecnicamente sofisticado, mas a segurança de cadeia de suprimentos tradicional é construída em torno de vulnerabilidades conhecidas em pacotes conhecidos: CVEs, SBOMs, varredura de licenças. Esse quadro não tem nada a dizer sobre um pacote que não existia quando a varredura foi executada pela última vez, foi criado especificamente para corresponder a uma alucinação de IA e é ingerido antes que qualquer feed de ameaças seja atualizado.

A janela de publicação para comprometimento agora é medida em minutos. Qualquer coisa que verifique após o fato está verificando tarde demais.

Os dependências alucinadas estão se tornando um dos maiores riscos no desenvolvimento impulsionado por IA, e quais etapas práticas as organizações podem tomar para se defender contra elas?

Elas já são um dos maiores. Os atacantes monitoram ativamente as ferramentas de IA populares para alucinações e registram os nomes de pacotes sugeridos dentro de minutos. Pesquisadores há alguns anos, quando isso começou a acontecer, o chamaram de slopsquatting e o nome pegou. Uma vez que um nome de dependência é alucinado com frequência suficiente, sentar sobre ele é um ataque de cadeia de suprimentos passivo com esforço quase zero.

As defesas práticas parecem diferentes do que a maioria das equipes tem atualmente. Comece na ingestão. Bloqueie pacotes de typosquatting e novos registros no momento em que npm install ou pip install é executado, na máquina do desenvolvedor, antes que algo atinja o disco. A detecção pós-morte no CI não ajuda quando um script de pós-instalação já exfiltrou uma credencial. Em seguida, dê ao agente guardrails para operar dentro. Insira sua lista de dependências aprovadas diretamente no contexto do agente, para que o modelo veja o que é permitido antes de gerar uma sugestão. Pedir aos desenvolvedores que escrevam “prompts seguros” não é uma estratégia. Se você está sendo estratégico, significa que a segurança define a fronteira, o agente a herda. E comece a rastrear uma Lista de Materiais de IA. A maioria das equipes não consegue dizer quais agentes, modelos e pacotes estão tocando quais repositórios. Você não pode defender o que não pode inventariar.

Você disse que a segurança não pode mais começar no CI/CD. O que uma pipeline de segurança moderna parece quando a proteção precisa começar mais cedo no processo de desenvolvimento?

Se a segurança começa no CI/CD, você cedeu a fase pré-compromisso a um ambiente que você não controla. O agente já ingeriu contexto, sua credencial pode já estar nos logs de outra pessoa. Você está varrendo um cadáver.

Uma pipeline moderna começa no laptop. Isso significa inventariar os agentes e extensões que estão executando lá, validando quais servidores MCP e modelos eles estão autorizados a conversar, sanitizando o que deixa a máquina e bloqueando pacotes mal-intencionados antes que eles instalem. A partir daí, a política segue o trabalho para o IDE. Nós injetamos padrões de segurança diretamente na janela de contexto do agente, para que o código gerado permaneça dentro das guardrails desde o primeiro token. A pipeline ainda é executada, fazendo verificação final sobre controles que já foram aplicados upstream.

A pipeline em si não some. Seu papel se torna verificação: confirmar que os controles upstream foram mantidos.

À medida que as organizações continuam a adotar agentes de codificação de IA, quais são as mudanças mais críticas que elas devem fazer hoje para garantir que seus ambientes de desenvolvimento permaneçam seguros nos próximos anos?

O maior erro é proteger apenas o que é comprometido. O risco interessante agora vive nas oito horas antes de um comprometimento acontecer. Drama não visto pode se desenrolar no laptop, no prompt ou na instalação do pacote. Se suas ferramentas começam na PR, você está protegendo a metade errada do fluxo de trabalho.

Estreitamente relacionado: pare de tratar os agentes de codificação como software de produtividade. Eles são usuários não humanos com acesso shell, privilégios de gravação de repositório e conexões de rede de saída. Regule-os da maneira como você regula qualquer outra identidade privilegiada, com um inventário, capacidades aprovadas e logs de auditoria.

A última mudança é mais difícil culturalmente. A maioria das ferramentas de “segurança de IA” atuais surface achados e os roteia para humanos. Humanos não podem triar na velocidade que os agentes geram. Qualquer coisa que você adote tem que resolver problemas automaticamente dentro do fluxo de trabalho, com raciocínio rastreável, ou se torna mais um painel que ninguém lê.

Obrigado pela ótima entrevista, leitores que desejam aprender mais devem visitar Boost Security.