Com IA, os ataques ficaram mais rápidos, mais sofisticados e mais difíceis de perceber. Attack testa os sites e as APIs que você autoriza, com agentes de IA, antes que outra pessoa faça isso. Um pesquisador confirma o que é risco real. Defense, em escopo proposto, revisa mudanças de código com o contexto dos serviços.
GET /api/invoices/demo-02 Host: api.example.com Cookie: session=test-account-a
{ "invoice": "demo-02",
"owner": "another test account"} export async function getInvoice(req, res) {
+ const invoice = await invoices.find(req.params.id)
+ return res.json(invoice) }
Hify Attack
Attack mapeia o que está exposto, testa com o contexto do seu negócio e entrega cada achado com prova. Reportamos a requisição, a resposta e os passos para o seu time ver por conta própria.
Hify Defense Escopo proposto
Defense lê uma mudança de código junto com os serviços que ela toca e sugere orientação de correção para os seus desenvolvedores.
Só orientação. Não bloqueia tráfego nem altera código por conta própria.
Cada fatura pertence a uma conta, e a sessão carrega essa conta.
Compare o dono da fatura com a conta autenticada antes de devolvê-la.
Cadência
Endpoints novos sobem e regras de acesso mudam a cada deploy. Na Hify, cada aplicação entra em ciclos pela ordem de risco, e uma mudança relevante dispara um teste direcionado. Você acompanha, mês a mês, se a exposição cai.
PCI DSS v4.0.1, req. 11.4 pede pentest ao menos a cada 12 meses e também depois de mudança significativa na aplicação ou na infraestrutura.
Testadas uma vez, nas três primeiras semanas. Depois, 49 semanas sem teste.
Ciclos pela ordem de risco, e um teste direcionado na semana da mudança.
Pentest anual: as aplicações A, B e C são testadas uma vez, nas três primeiras semanas do ano. Depois disso ficam 49 semanas sem teste, e 9 de 10 mudanças relevantes chegam ao ar sem teste. Ilustrativo: um ano fictício de deploys. A ordem de risco e a cadência são definidas pelo seu time.
O que você recebe
Cada achado traz a evidência, os passos para reproduzir, a revisão de um pesquisador e o que o reteste deve mostrar. Explore um exemplo ilustrativo.
Autenticados como a conta de teste A, pedimos uma fatura que pertence à conta de teste B.
GET /api/invoices/demo-02 Host: api.example.com Cookie: session=test-account-a
{ "invoice": "demo-02",
"owner": "test account B"}Passos que os seus desenvolvedores podem seguir para ver o problema por conta própria.
Um pesquisador confere o achado antes de reportá-lo.
Passos repetidos com as duas contas de teste. A conta A consegue ler a fatura da conta B pela API.
Depois da correção do seu time, repetimos a mesma requisição autorizada dentro do escopo.
403 Mesma requisição, mesma conta de teste, mesmo escopo.
O reteste confere este achado. Ele não certifica a aplicação inteira.
Comparação
O pentest anual aprofunda, mas vale para uma data. O scanner roda sempre, mas não conhece a regra do seu negócio. O bug bounty depende de quem aparece. A Hify testa em ciclos, com vários perfis, e cada achado chega revisado por um pesquisador.
| Critério | Pentest anualconsultoria, com data marcada | Scanner (DAST)varredura automática | Bug bountypesquisadores externos, pago por achado | Hifyagentes de IA e validação por pesquisador |
|---|---|---|---|---|
| Frequência | 1 vez por ano | a cada varredura agendada ou build | enquanto o programa estiver aberto | em ciclos, pela ordem de risco, e após mudança relevante |
| Falhas de autorização e lógica de negócio | sim dentro do período do teste | parcial não conhece a regra do negócio | parcial depende do pesquisador | sim com agentes de autorização e de regra de negócio |
| Testes autenticados com vários perfis | sim com as contas fornecidas | sim | parcial depende do acesso que o programa dá | sim cada perfil contra as rotas da matriz de autorização |
| Prova de exploração reproduzível | sim no relatório final | parcial alerta com a requisição, sem o caminho de ataque | sim no relato do pesquisador | sim requisição e resposta em cada achado |
| Quem filtra falso positivo | o consultor | seu time | a triagem do programa, depois seu time | pesquisador da Hify, antes de chegar ao seu time |
| Reteste da correção | parcial se estiver no contrato | sim na próxima varredura | parcial depende do pesquisador | sim no mesmo caminho de ataque, com o antes e o depois |
| Mostra o que não foi testado, e por quê | parcial depende do relatório | parcial mostra o que rastreou, sem o motivo | não | sim rota por rota, com o motivo |
| Encaixa no deploy | não | sim | não | sim um passo no pipeline dispara um teste direcionado |
| Previsibilidade de custo | valor fixo por projeto | assinatura | variável, pago por achado | por aplicação, conforme o plano. Não varia com o número de achados. |
| Rede interna, engenharia social e teste físico | sim quando contratado | não | não raramente no escopo | não fora do escopo da plataforma |
Comparação geral: contratos de pentest, scanners e programas de bug bounty variam. Para rede interna, engenharia social e teste físico, o pentest tradicional continua sendo o caminho.
Defense, em escopo proposto, revisa mudanças de código. Esta tabela compara o teste de aplicações em execução, o Attack.
Escopo
Você define hosts, rotas, contas de teste, janela e limite de requisições. Toda requisição fica registrada, e o que está fora do escopo é bloqueado pela política antes de sair.
O teste recorrente segue os alvos e a frequência que você combina. Nenhum teste pode prometer encontrar toda falha. AppSec monta o escopo, o CISO aprova e a infraestrutura libera os IPs no WAF.
dias combinados · 5 req/s · DELETE bloqueado
203.0.113.10 · 203.0.113.11
X-Hify-Run: run_0412
cada requisição fica registrada. Seu time pode pausar.
Dados e IA
Estas são as cinco perguntas que o questionário de segurança da Hify responde por escrito.
As cinco respostas vêm por escrito no questionário de segurança, entregue sob NDA.
Integrações
Ticket com dono e prazo, alerta no canal do time, link para o PR da correção e reteste quando o deploy sai. Sem planilha, sem PDF perdido no e-mail.
Ticket e alerta nascem quando o pesquisador valida. O backlog recebe achado reproduzido, não alerta bruto.
No projeto do time dono, com evidência, correção sugerida e o prazo da sua política. Ninguém redigita achado de PDF.
Jira · SEG-214time dono · prazo da sua políticaO time fica sabendo no dia da validação, não na reunião do mês. O alerta leva ao achado e ao ticket.
Slack ou Teamsachado validado · link do ticketO PR da correção aparece no achado. AppSec acompanha o andamento sem cobrar status em reunião.
GitHub ou GitLabfix/seg-214 para mainDepois do merge, o pipeline faz o deploy no ambiente combinado e chama a Hify para refazer o ataque. O achado só fecha com a prova no histórico.
Ilustrativo- name: hify
run: hify run --app api.example.com \
--scope changed-routes --wait
Depois do deploy no ambiente combinado, um passo no pipeline testa de novo só as rotas que mudaram. Os webhooks são assinados: seu sistema confere a origem de cada evento.
O achado validado chega ao Claude Code, ao Cursor ou ao Codex com a requisição, a resposta e a correção sugerida. O agente prepara o PR, um desenvolvedor revisa e a Hify refaz o ataque antes de fechar o risco.
Pelo servidor MCP da Hify, o agente lê o achado validado com a evidência, prepara a correção e pede o reteste.
Claude Code
Cursor
Codex
GitHub Copilot
WindsurfAbre no projeto do time dono, com evidência, correção sugerida e prazo. O estado do achado acompanha o ticket.
JiraAviso no canal do time quando um achado é validado e lembrete quando o prazo está perto de vencer.
SlackMicrosoft TeamsO pesquisador da Hify fala direto com o seu time: resumo de cada ciclo por e-mail, aviso imediato de risco crítico no WhatsApp e conversa no canal compartilhado do Slack.
E-mail
WhatsAppSlackO PR da correção fica ligado ao achado, com o check de reteste. Um passo no pipeline dispara um teste direcionado depois do deploy.
GitHubGitLabGitHub ActionsGitLab CIPDF executivo, técnico ou atestado para clientes. Achados em CSV e requisições da execução em HAR.
Papéis Admin, AppSec, Desenvolvedor e Leitura. Quem mudou escopo, estado ou acesso fica no log de auditoria.
SSO OIDCProcesso
A Hify testa e revisa. O seu time decide e faz a correção. A Hify então retesta a mesma requisição.
HifyTesta, revisa e retesta
GET /api/invoices/demo-02 Cookie: session=test-account-a
"owner": "test account B"200
A conta A consegue ler a fatura da conta B.
Reproduzido com as duas contas de testeRevisado por um pesquisador
Seu timeRecebe o achado revisado, decide e corrige
const invoice = await invoices.find(id)+ if (invoice.accountId !== req.session.accountId)+ return res.status(403).end() return res.json(invoice)
Os seus desenvolvedores decidem, fazem o merge e escolhem quando publicar.
Mudança de exemplo, não uma correção garantida. Opcional: a orientação proposta do Defense pode informar esta mudança.
GET /api/invoices/demo-02Mesma requisição, mesma conta de teste A
Quando reportado200
Esperado depois da correção do seu time403
Expectativa ilustrativa, não um resultado de teste.
Times
Desenvolvedores, times de segurança e liderança recebem o que precisam a partir do mesmo achado.
Reproduza o problema a partir da requisição, da resposta e dos passos, e então decida como corrigir.
Confira a evidência e a revisão do pesquisador, e então priorize o trabalho entre os times.
Veja o que estava no escopo, quais achados ainda estão abertos e o que acontece em seguida.
Time
Uma empresa de produto, com quatro cofundadores construindo a plataforma. Igor já levou uma startup do zero até a venda; Lucas Fonseca vem da consultoria em segurança de agentes de IA; Lucas Souza e João Costa são pesquisadores de segurança ofensiva, com mais de R$ 1 milhão em recompensas de bug bounty. Ao lado deles, como advisor, um membro do conselho de administração do Nubank.
Cofundador · Chief Executive Officer
Igor fundou a Hackr Ads em 2019 e levou a empresa a 41 mil clientes e R$ 380 milhões gerenciados por mês em anúncios. Em 2022, vendeu a Hackr Ads para a Conta Simples. Na Hify, aplica o que aprendeu construindo software usado todo dia por milhares de empresas.
Cofundador · Chief Product Officer
Lucas trabalha com segurança de agentes de IA e prestou consultoria nessa área para a Dreamer, cuja equipe depois foi incorporada pela Meta (Facebook). Na Hify, cuida dos agentes que atacam os sistemas dos clientes: o que cada um pode testar, como é controlado e como o resultado chega ao especialista.
Cofundador · Chief Offensive Security
Lucas faz pesquisa de segurança ofensiva voltada à capacidade técnica dos agentes de IA da Hify. Antes, trabalhou com Offensive Security na Via Varejo, PagBank e Mercado Pago. Foi top 3 da HackerOne no Brasil em 2025 e top 2 em 2026, acumulando mais de R$ 1 milhão em bug bounty, com falhas reportadas a Google, Microsoft, Apple, PayPal, Stripe, Amazon e Vercel, entre outras.
Cofundador · Chief Research and Development
João lidera pesquisa e desenvolvimento na Hify, sendo o idealizador da engine da plataforma. Antes, trabalhou com Application Security no PagBank e no Mercado Livre, com foco em pentest e revisão de segurança de código. Em bug bounty, reportou vulnerabilidades válidas para Google, Spotify, Bybit, Hostinger, entre outras.
Advisor e membro do conselho de administração do Nubank
Rogério é membro do conselho de administração do Nubank desde 2021 e preside o comitê de auditoria e riscos. Antes, foi sócio de auditoria da PwC e diretor financeiro da Bunge Brasil, do Unibanco, do Itaú Unibanco e do HSBC Brasil. Conhece de perto o que um conselho pergunta quando o assunto é risco.
Reconhecimento do time
Pesquisadores fundadores da Hify foram listados nos Halls of Fame da Apple e da Microsoft em abril de 2025.
São reconhecimentos de pesquisa do nosso time, não endosso de clientes.
Hall of Fame · abril de 2025
Hall of Fame · abril de 2025
Perguntas
Respostas curtas sobre como a plataforma testa, valida e guarda o que encontra. O detalhe do seu caso fica para a demonstração.
Agendar demonstraçãoNão, complementa. Scanner e DAST procuram padrões conhecidos, uma requisição por vez. A Hify segue caminhos de várias etapas com sessão real, como usar a sessão da conta de teste A para ler o registro da conta de teste B, usa a regra de negócio da aplicação (quem pode ver, aprovar ou transferir o quê) e entrega cada achado com a prova: requisição, resposta e impacto.
Em aplicações web e APIs, a plataforma testa com muito mais frequência que um pentest anual, e todo achado passa por um pesquisador antes de ser reportado. Rede interna, engenharia social e teste físico ficam fora. Para eles, o pentest manual continua no seu plano.
Attack testa sites e APIs em execução que você autoriza, sem precisar de código-fonte. Defense é um escopo proposto para revisar mudanças de código com contexto de serviço e sugerir orientação de correção. O escopo final é combinado com você.
Primeiro o agente reproduz o sinal com outros identificadores e outra conta. Depois um pesquisador confere a regra de negócio, avalia o impacto e descarta o falso positivo. Só é reportado o que foi reproduzido e revisado, e o achado registra quando o pesquisador revisou.
Nenhum achado não quer dizer ambiente seguro. O relatório registra o que foi testado, com quais acessos, e o que ficou de fora e por quê, como uma rota que exige MFA de hardware.
No ambiente que você define no escopo, com janela de horário, limite de requisições por segundo e métodos destrutivos bloqueados. Os exemplos desta página são ilustrativos, com dados fictícios.
Não para começar. Dá para partir da visão externa ou de duas contas de teste, que já mostram se uma conta consegue ler dados da outra. Código entra quando você autorizar, e o teste passa a enxergar mais. Confirmamos os alvos, o que fica de fora e as contas de teste no escopo.
Jira para tickets, Slack e Microsoft Teams para alertas, GitHub e GitLab para o PR da correção, e GitHub Actions ou GitLab CI para o reteste depois do deploy. Também há webhooks assinados, API REST, exportação em PDF, CSV e HAR, e acesso por SSO (SAML ou OIDC) com papéis e log de auditoria. O detalhe de cada uma está na seção Integrações.
Sim. Um passo no CI, como hify run --app api.example.com --scope changed-routes --wait no GitHub Actions ou no GitLab CI, dispara um teste direcionado nas rotas que mudaram. Os ciclos completos seguem a cadência de cada aplicação.
O seu time decide e faz cada correção. Depois retestamos o achado original dentro do escopo combinado.
Onde ficam, por quanto tempo e quem acessa são respondidos no questionário de segurança, sob NDA, antes de qualquer dado sensível. Na evidência, dados pessoais aparecem mascarados, como m***@example.com.
Não. Os achados ficam entre a Hify e o seu time, sob NDA. Nada que identifique sua empresa é publicado sem autorização por escrito.
Por aplicação, conforme o plano. O peso de cada uma depende da complexidade: quantas URLs, APIs e integrações ela envolve. Frequência e nível de acesso também contam. O valor do plano é definido depois da demonstração. Não há tabela pública. A proposta do plano sai em reais (BRL).
Contato
Conte a empresa e como falar com você. Na demonstração, você acompanha o ciclo inteiro, do escopo ao reteste: uma execução e um achado com prova, dono e prazo. A mensagem vai para a equipe Hify.