Hify Agendar demonstração

Encontre falhas de segurança nas suas aplicações e mudanças de código.

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.

  • Você autoriza o que é testado
  • Um pesquisador confirma cada risco
  • Relatório pronto para o conselho
Attack
app.example.com/invoicesIlustrativo
Requisição · conta de teste A
GET /api/invoices/demo-02
Host: api.example.com
Cookie: session=test-account-a
Resposta200 OK
{ "invoice": "demo-02",
  "owner": "another test account"}
Fatura de outra conta foi devolvida
A requisição, a resposta e os passos para reproduzir ficam registrados.
Esperado depois da correção do seu time: 403
Reproduzido e revisado por um pesquisador antes de ser reportado.Revisão humana
Defense (escopo proposto)
Revisão da mudança · services/billing/invoices.tsEscopo propostoIlustrativo
Mudança de códigoinvoices.ts
  export async function getInvoice(req, res) {
+   const invoice = await invoices.find(req.params.id)
+   return res.json(invoice)  }
Contexto do serviço
aplicação webserviço de cobrançaarmazenamento de faturas
Sugestão: confira se a fatura pertence à conta autenticada antes de devolvê-la.Orientação para os seus desenvolvedores revisarem

Nosso time já reportou vulnerabilidades para

  • Google
  • Microsoft
  • Amazon
  • Vercel
  • Atlassian
  • Apple
  • Dropbox
  • HubSpot
  • Uber
  • Snapchat
  • Spotify
  • Yahoo
  • Epic Games
  • PayPal
  • Stripe
  • Coinbase
  • Bybit
  • Booking.com
  • BMW Group
  • Hostinger

Hify Attack

Prova que você consegue reproduzir.

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.

  • Sites e APIs autorizadosAlvos, exclusões e contas de teste são combinados no escopo.
  • Evidência reproduzívelCada achado inclui a requisição, a resposta e os passos.
  • Revisão humana e retesteUm pesquisador revisa cada achado. Retestamos depois da correção do seu time.
Acesso
Alvos e contas de teste combinados, confirmados no escopo.
Código-fonte
Não é necessário para o teste externo.
Achado · fatura devolvida a outra contaIlustrativo
  1. Entre como a conta de teste A.
  2. Envie GET /api/invoices/demo-02.
  3. Observe uma fatura que pertence a outra conta de teste.
Revisado por um pesquisadorEsperado depois da correção do seu time: 403

Hify Defense Escopo proposto

Mudanças de código, lidas em contexto.

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.

  • Análise da mudança de códigoOlha o que uma mudança faz nos serviços ao redor.
  • Contexto entre serviçosO contexto de serviço que você compartilha ajuda a explicar o risco.
  • Orientação que os seus desenvolvedores revisamOs seus desenvolvedores decidem e fazem cada mudança.
Entrada
Mudanças de código e o contexto de serviço que você escolhe compartilhar.
Saída
Uma explicação direta do risco e orientação de correção.

Só orientação. Não bloqueia tráfego nem altera código por conta própria.

Contexto do serviço · consulta de faturaEscopo propostoIlustrativo
aplicação webserviço de cobrançaarmazenamento de faturas
O que o contexto mostra

Cada fatura pertence a uma conta, e a sessão carrega essa conta.

Orientação de correção

Compare o dono da fatura com a conta autenticada antes de devolvê-la.

Para revisão dos desenvolvedores

Cadência

Um pentest por ano não acompanha o que muda.

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.

  • Último teste, por aplicaçãoO painel mostra quando cada aplicação foi testada e o que mudou desde então.
  • Roadmap por ordem de riscoSeu time define a ordem. A aplicação mais exposta entra primeiro e volta com mais frequência.
  • Exposição mês a mêsAchados novos, corrigidos e em reteste por ciclo, para ver 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.

Um ano de deploys · aplicações A, B e CIlustrativo
Pentest anual

Testadas uma vez, nas três primeiras semanas. Depois, 49 semanas sem teste.

Hify

Ciclos pela ordem de risco, e um teste direcionado na semana da mudança.

0semanas de espera. O teste sai na semana do deploy.
9 de 10mudanças relevantes saem sem teste no pentest anual.
49semanas sem teste depois da janela anual.

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

Um achado com o qual o seu time consegue agir.

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.

Achado de exemplo · fatura devolvida a outra contaIlustrativo
Ler o relatório de exemplo completo

Evidência

Autenticados como a conta de teste A, pedimos uma fatura que pertence à conta de teste B.

Requisição
GET /api/invoices/demo-02
Host: api.example.com
Cookie: session=test-account-a
Resposta200 OK
{ "invoice": "demo-02",
  "owner": "test account B"}

Reprodução

Passos que os seus desenvolvedores podem seguir para ver o problema por conta própria.

  1. Entre em app.example.com como a conta de teste A.
  2. Envie GET /api/invoices/demo-02 com a sessão da conta A.
  3. Observe uma resposta 200 com a fatura da conta B.
  4. Repita como a conta B para confirmar que demo-02 pertence a B.

Revisão humana

Um pesquisador confere o achado antes de reportá-lo.

Nota do revisor

Passos repetidos com as duas contas de teste. A conta A consegue ler a fatura da conta B pela API.

  • Passos repetidos a partir de uma sessão nova
  • Respostas comparadas para as duas contas de teste
  • Impacto descrito em linguagem direta

Expectativa do reteste

Depois da correção do seu time, repetimos a mesma requisição autorizada dentro do escopo.

Quando reportado
Fatura de outra conta foi devolvida
200
Esperado depois da correção do seu time

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

Profundidade de pentest, no ritmo das suas mudanças.

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.

Arraste para comparar as quatro colunas.

Comparação entre pentest anual, scanner (DAST), bug bounty e a Hify
Pentest anualconsultoria, com data marcadaScanner (DAST)varredura automáticaBug bountypesquisadores externos, pago por achadoHifyagentes de IA e validação por pesquisador
Frequência1 vez por anoa cada varredura agendada ou buildenquanto o programa estiver abertoem ciclos, pela ordem de risco, e após mudança relevante
Falhas de autorização e lógica de negóciosimdentro do período do testeparcialnão conhece a regra do negócioparcialdepende do pesquisadorsimcom agentes de autorização e de regra de negócio
Testes autenticados com vários perfissimcom as contas fornecidassimparcialdepende do acesso que o programa dásimcada perfil contra as rotas da matriz de autorização
Prova de exploração reproduzívelsimno relatório finalparcialalerta com a requisição, sem o caminho de ataquesimno relato do pesquisadorsimrequisição e resposta em cada achado
Quem filtra falso positivoo consultorseu timea triagem do programa, depois seu timepesquisador da Hify, antes de chegar ao seu time
Reteste da correçãoparcialse estiver no contratosimna próxima varreduraparcialdepende do pesquisadorsimno mesmo caminho de ataque, com o antes e o depois
Mostra o que não foi testado, e por quêparcialdepende do relatórioparcialmostra o que rastreou, sem o motivonãosimrota por rota, com o motivo
Encaixa no deploynãosimnãosimum passo no pipeline dispara um teste direcionado
Previsibilidade de custovalor fixo por projetoassinaturavariável, pago por achadopor aplicação, conforme o plano. Não varia com o número de achados.
Rede interna, engenharia social e teste físicosimquando contratadonãonãoraramente no escoponãofora 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 o 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 agente só alcança o que está na allowlist, com as contas de teste que você cadastrou, dentro da janela e do limite. Seu WAF reconhece o tráfego pelos IPs fixos e pelo cabeçalho da execução, e o que está na denylist nunca é tocado.

  • Allowlist e denylist de hosts e rotasSó entra o que está na allowlist. O que está na denylist é bloqueado antes de sair.
  • Contas de teste e nível de acessoO método de login é confirmado no escopo. Alguns fluxos podem precisar de preparação extra ou ficar de fora.
  • Regras do negócioO que a aplicação precisa garantir fica registrado: quem pode ver, aprovar ou alterar um registro.
  • Janela, limite e pausaHorário, requisições por segundo e métodos destrutivos bloqueados. Se algo sair do previsto, seu time pausa a execução.
  • WAFIPs de origem fixos e o cabeçalho da execução, para a infraestrutura liberar o tráfego.

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.

Resumo de escopo · example.comIlustrativo
Allowlist
app.example.comapi.example.com/v1
Denylist
/admin/*páginas de pagamento de terceiros
Contas
conta de teste Aconta de teste B
Janela

dias combinados · 5 req/s · DELETE bloqueado

WAF

203.0.113.10 · 203.0.113.11

X-Hify-Run: run_0412

Registro

cada requisição fica registrada. Seu time pode pausar.

Dados e IA

Antes de aprovar um agente, o time de risco quer saber para onde vão os dados.

Estas são as cinco perguntas que o questionário de segurança da Hify responde por escrito.

  1. Região de armazenamentoEm que país ficam evidências, registros e relatórios?
  2. Retenção de evidênciasPor quanto tempo ficam guardadas e como pedir a exclusão?
  3. Provedores de modeloQuais modelos de IA processam requisições e respostas?
  4. Uso dos seus dados para treinoSeu tráfego e seus achados treinam algum modelo?
  5. Guarda de credenciais de testeOnde ficam as senhas de conta-a e conta-b, e quem tem acesso?

As cinco respostas vêm por escrito no questionário de segurança, entregue sob NDA.

Integrações

O achado chega onde seu time já trabalha.

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.

Deslize para ver as 5 etapas.

  1. 01

    Só sai o que foi validado

    Ticket e alerta nascem quando o pesquisador valida. O backlog recebe achado reproduzido, não alerta bruto.

    HFY-0142 · ilustrativo

    GET /api/invoices/demo-02

  2. 02

    Ticket com dono e prazo

    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-214

    time dono · prazo da sua política

  3. 03

    Alerta no canal do time

    O 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 Teams

    achado validado · link do ticket

  4. 04

    Correção ligada ao achado

    O PR da correção aparece no achado. AppSec acompanha o andamento sem cobrar status em reunião.

    GitHub ou GitLab

    fix/seg-214 para main

  5. 05

    Reteste quando o deploy sai

    Depois 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.

    mesmo caminho

    200 quando reportado · 403 esperado

A correção sai no agente de código do seu time.

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.

Claude CodeCursorCodexGitHub CopilotWindsurf

Integrações e acesso

  • Tickets

    Abre no projeto do time dono, com evidência, correção sugerida e prazo. O estado do achado acompanha o ticket.

    Jira
  • Alertas

    Aviso no canal do time quando um achado é validado e lembrete quando o prazo está perto de vencer.

    SlackMicrosoft Teams
  • Comunicação

    O 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-mailWhatsApp
  • Código e CI

    O 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 CI
  • Agentes de código

    Pelo servidor MCP da Hify, o agente lê o achado validado com a evidência, prepara a correção e pede o reteste.

    Claude CodeCursorCodexGitHub CopilotWindsurf
  • Dados

    PDF executivo, técnico ou atestado para clientes. Achados em CSV e requisições da execução em HAR.

    API RESTWebhooks assinadosPDFCSVHAR
  • Acesso

    Papéis Admin, AppSec, Desenvolvedor e Leitura. Quem mudou escopo, estado ou acesso fica no log de auditoria.

    SSO SAMLSSO OIDC
.github/workflows/deploy.ymlIlustrativo
- 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.

Processo

Do achado a uma correção retestada.

A Hify testa e revisa. O seu time decide e faz a correção. A Hify então retesta a mesma requisição.

Achado demo-02Sequência ilustrativa

HifyTesta, revisa e retesta

1 · Teste

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.

2 · Revisão

  • Requisição
  • Resposta
  • Passos para reproduzir

Reproduzido com as duas contas de testeRevisado por um pesquisador

Seu timeRecebe o achado revisado, decide e corrige

3 · Corrigir

  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.

4 · A Hify retesta

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

Feito para o seu time.

Desenvolvedores, times de segurança e liderança recebem o que precisam a partir do mesmo achado.

  • Desenvolvedores

    Reproduza o problema a partir da requisição, da resposta e dos passos, e então decida como corrigir.

    Passos de reproduçãoRequisição e respostaOrientação de código Escopo proposto
  • Times de segurança

    Confira a evidência e a revisão do pesquisador, e então priorize o trabalho entre os times.

    Achados revisadosReteste depois da correção
  • Liderança

    Veja o que estava no escopo, quais achados ainda estão abertos e o que acontece em seguida.

    Escopo combinadoAchados abertosPróximos passos

Time

Quem está por trás da Hify.

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.

Igor Gontijo

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.

Lucas Fonseca

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.

Lucas Souza

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.

João Costa

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.

Advisors

Rogério Calderón

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

Pesquisa reconhecida pela Apple e pela Microsoft.

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.

Apple

Hall of Fame · abril de 2025

Microsoft

Hall of Fame · abril de 2025

Perguntas

Dúvidas antes da demonstração.

Respostas curtas sobre como a plataforma testa, valida e guarda o que encontra. O detalhe do seu caso fica para a demonstração.

A Hify substitui o scanner ou o DAST?

Nã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.

Substitui o pentest manual?

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.

Como Attack e Defense diferem?

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ê.

Em qual ambiente os testes rodam?

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.

Onde ficam os dados dos testes?

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.

Como um achado da IA é validado?

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.

Preciso fornecer credenciais ou código?

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.

Quais integrações existem?

Jira, com o ticket no projeto do time dono e o estado do achado acompanhando o ticket. Slack e Microsoft Teams, com aviso quando um achado é validado e lembrete de prazo. GitHub e GitLab, com o PR ligado ao achado e o check de reteste, além de GitHub Actions e GitLab CI. Também webhooks assinados, API REST e exportação em PDF, CSV e HAR. O acesso ao painel usa SSO (SAML ou OIDC), papéis Admin, AppSec, Desenvolvedor e Leitura, e log de auditoria.

Dá para disparar um teste a cada deploy?

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.

E se nada for encontrado?

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.

Vocês divulgam o que encontram?

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.

Como funciona o preço?

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).

Quem corrige os problemas, e quem retesta?

O seu time decide e faz cada correção. Depois retestamos o achado original dentro do escopo combinado.

Contato

Planejar um teste com escopo.

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.

Usamos seu e-mail só para responder esta conversa.