OWASP
O Top 10 é a porta de entrada, e o ASVS, o padrão de verificação de segurança de aplicação, é o que transforma o pedido genérico de fazer um teste em requisito verificável, com veredito por item. Quem contrata teste sem citar essa régua no contrato recebe relatórios que não se comparam entre fornecedores, e fica sem saber qual dos dois testou mais.
O OWASP, Open Worldwide Application Security Project, é uma fundação sem fins lucrativos, e todo o material dela é aberto e gratuito. A DM11 usa esse material como base metodológica dos testes de aplicação, escreve com você o requisito de segurança que vai para o contrato com o fornecedor de software, e mede o processo de desenvolvimento contra o SAMM. Quando o destino for uma certificação, a evidência produzida aqui entra inteira nesse projeto, e a página da norma escolhida explica o resto do caminho.
Quem conduz os testes
CEH, Certified Ethical Hacker pelo EC-Council
CPTE, Certified Penetration Testing Expert pela AcadiTI
SYCP e SYES, pentest e evasão pela Solyd
17 anos de governança, riscos e conformidades
O QUE É
O OWASP publica as referências de segurança de aplicação mais usadas do mundo, todas gratuitas. A mais conhecida é o Top 10 de aplicação web, hoje na edição 2025, a primeira revisão desde 2021. Ao lado dele estão o ASVS, que é a lista de requisitos verificáveis, o Top 10 de segurança de API, a interface pela qual seus sistemas conversam entre si, o MAS, de segurança de aplicação móvel, o Top 10 para aplicações com modelo de linguagem e o SAMM, que mede a maturidade do processo de desenvolvimento. O Top 10 é por onde quase todo mundo entra, e sozinho ele não responde se uma aplicação passou.
A quebra de controle de acesso continua em primeiro lugar, como em 2021. A configuração incorreta de segurança subiu do quinto para o segundo. Duas categorias são novas: falhas na cadeia de suprimento de software, que amplia o que em 2021 tratava só de componente vulnerável e desatualizado, e tratamento inadequado de condições excepcionais, que cobre erro mal tratado e falha que abre em vez de fechar. A edição analisou 589 CWEs, as categorias públicas de fraqueza de software, sobre dados de mais de 2,8 milhões de aplicações e com treze organizações contribuintes: oito categorias saíram do dado e duas da pesquisa com a comunidade.
O Application Security Verification Standard chegou à versão 5.0 em maio de 2025, com cerca de 350 requisitos em 17 capítulos e três níveis de verificação, do L1 ao L3. A diferença prática está na forma: cada requisito precisa terminar em passa ou não passa, e por isso ele cabe dentro de um contrato, de um critério de aceite e de um relatório de teste. É o documento que responde a pergunta que o Top 10 deixa em aberto, que é o que exatamente sua aplicação precisa atender para alguém dizer que ela está verificada.
Vale alinhar a expectativa cedo, porque isso muda o planejamento. O que o trabalho produz é um relatório de verificação com escopo declarado, nível de ASVS pretendido, veredito requisito a requisito e evidência anexada, incluindo os requisitos que não se aplicam ao seu caso e o porquê. A própria fundação é explícita quanto a esse ponto no texto do ASVS: ela não certifica fornecedor, verificador nem software, e recomenda cautela com selo de terceiro que se apresente como certificação OWASP oficial. Quando o seu cliente precisa de um documento emitido por organismo acreditado, quem responde é a ISO 27001 ou o SOC 2, e o teste feito aqui entra como evidência técnica nesse projeto.
O Top 10 de API, na edição 2023, trata do que a lista web não alcança, como autorização em nível de objeto e de propriedade, consumo irrestrito de recurso e inventário de endpoint. O MAS, Mobile Application Security, cobre aplicação móvel com dois documentos que trabalham juntos: o MASVS na versão 2.1.0, com oito domínios que vão de armazenamento e criptografia a privacidade e resistência a engenharia reversa, e o MASTG na versão 2.0.0, com os testes correspondentes a cada domínio. O Top 10 para aplicações com modelo de linguagem, edição 2025, é hoje a referência de segurança em IA generativa, com injeção de prompt em primeiro lugar. E o SAMM, Software Assurance Maturity Model, na versão 2, mede o processo em cinco funções de negócio e quinze práticas, com três níveis de maturidade em cada uma.
QUEM COSTUMA PRECISAR
Em nenhuma delas alguém está exigindo um certificado. O que está em jogo é conseguir comparar fornecedores, responder a um cliente com método, ou testar uma superfície que o teste tradicional não alcança.
A empresa terceiriza o desenvolvimento, o contrato fala de prazo, escopo funcional e garantia, e a palavra segurança aparece uma vez, num parágrafo genérico. Sem requisito escrito, cobrar correção depois vira negociação comercial em vez de execução de contrato. O ASVS resolve isso porque cada requisito tem veredito, e um anexo de nível declarado é exigível.
Quem vende software recebe due diligence com pergunta direta sobre o Top 10, sobre teste de aplicação e sobre correção de achados. Responder de memória custa credibilidade no primeiro pedido de evidência. Um relatório de verificação com escopo e nível declarados responde a maior parte do questionário, e responde da mesma forma para o próximo cliente que perguntar.
A empresa colocou um assistente com modelo de linguagem para conversar com cliente ou com base interna, e o teste tradicional continua olhando a aplicação ao redor dele. Injeção de prompt, vazamento do prompt de sistema e agência excessiva de ferramenta ficam fora desse escopo, e são exatamente os itens que o Top 10 para aplicações com modelo de linguagem organiza.
HISTÓRIAS
Trocamos os nomes dos clientes com o mesmo sigilo que vai proteger a sua empresa depois. Os nomes mudam, o padrão dos problemas se repete. Quando o cliente autoriza, mostramos referências com nome numa conversa.
Software como serviço
Havia teste anual de aplicação web, com relatório limpo, e o time confiava nele. O aplicativo móvel conversava com uma API que nunca constou de escopo nenhum, porque o pedido histórico dizia apenas teste do site. O produto tinha crescido pelo celular, e a maior parte do tráfego já passava por ali.
Refizemos o escopo a partir do inventário de aplicações, deixando de lado o texto do pedido histórico, e incluímos a API e o aplicativo. Testamos a API contra o Top 10 de API e verificamos os requisitos de autorização do ASVS, com credenciais de dois clientes distintos, que é o que revela problema de autorização em nível de objeto.
Trocar o identificador de um recurso devolvia dado de outro cliente, sem qualquer verificação de posse. A correção foi barata porque a autorização já existia na camada web e faltava na API. A mudança que ficou foi de processo: o escopo passou a sair do inventário de aplicações, revisado a cada trimestre.
Varejo e comércio eletrônico
O desenvolvimento era todo terceirizado e o contrato não trazia requisito de segurança. Cada achado de teste abria uma discussão sobre quem pagava a correção, e o time interno perdia mais tempo negociando do que corrigindo. Nenhuma entrega tinha critério de aceite ligado a segurança.
Escolhemos o nível 2 do ASVS como alvo, selecionamos os requisitos aplicáveis ao tipo de aplicação e escrevemos um anexo contratual com eles, incluindo a exigência de evidência por requisito. Definimos com o jurídico o que acontece quando um requisito reprova, e com o time técnico o que entra em reteste.
A discussão sobre quem paga acabou, porque o requisito passou a ser parte do que foi contratado. O efeito colateral foi maior que o esperado: o fornecedor começou a entregar corrigido antes da homologação, já que reprovar passou a custar retrabalho dele.
Seguros
Um assistente com modelo de linguagem atendia segurados e tinha acesso a uma base interna de documentos, além de permissão para consultar sistemas por meio de ferramentas. A avaliação de segurança anterior tinha olhado o servidor e a autenticação, e não o comportamento do modelo.
Testamos contra o Top 10 para aplicações com modelo de linguagem, começando por injeção de prompt direta e por injeção indireta, que chega escondida dentro de documento que o próprio sistema lê. Revisamos as permissões das ferramentas disponíveis ao assistente e o tratamento da saída antes de ela chegar ao segurado.
Um documento carregado na base conseguia alterar o comportamento do assistente para conversas seguintes, e uma das ferramentas tinha permissão de escrita sem necessidade. Reduzimos a permissão ao mínimo, separamos conteúdo de instrução e passamos a validar a saída, o que fechou os dois caminhos.
COMO CONDUZIMOS
A régua é escolhida antes do teste, e por escrito. Sem nível de ASVS declarado e sem escopo fechado, o relatório vira uma lista de achados soltos, que agrada na apresentação e não permite dizer se a aplicação atende ou não atende.
Levantamos o que existe de aplicação, API, aplicativo móvel e componente de IA generativa, com dono definido para cada item. A partir daí escolhemos as listas aplicáveis a cada ativo e o nível de ASVS alvo, junto com quem responde pelo produto.
Inventário de aplicações, APIs e aplicativos, com dono por item
Referência aplicável definida por ativo, do Top 10 web ao de modelo de linguagem
Nível de ASVS alvo acordado com o time de produto
Regras de engajamento, ambiente e janela de teste por escrito
Marco de entregaEscopo e nível de ASVS aprovados antes de qualquer teste começar.
As duas atividades convivem e cumprem papéis diferentes. O Top 10 orienta a busca pelo que costuma quebrar primeiro, e o ASVS entrega o veredito requisito a requisito. Trabalhamos com acesso a documentação e a código sempre que possível, porque é a forma recomendada pelo próprio padrão e é a única que alcança autorização e regra de negócio.
Veredito por requisito, com evidência anexada
Achados priorizados por risco real, com caminho de exploração descrito
Requisitos não aplicáveis identificados, com a justificativa de cada um
Relatório executivo separado do relatório técnico
Marco de entregaRelatório entregue com escopo, nível e todos os requisitos verificados declarados.
Sentamos com quem desenvolve para transformar achado em tarefa com responsável e data. Onde o desenvolvimento é terceirizado, o mesmo conteúdo vira texto de requisito para o contrato, com o nível de ASVS declarado e a evidência exigida por item, para a próxima entrega já nascer dentro da régua.
Plano de correção com responsável e data por achado
Texto de requisito de segurança para o contrato com o fornecedor
Critério de aceite ligado a requisito verificável
Reteste dos itens fechados, com evidência do antes e do depois
Marco de entregaAchados de maior risco corrigidos e confirmados em reteste.
Teste mede o produto num instante, e o SAMM mede o processo que produz esse produto. Avaliamos as quinze práticas nas cinco funções de negócio, definimos o nível alvo de cada uma com a liderança de tecnologia e combinamos a cadência de verificação que sustenta o resultado ao longo do tempo.
Medição SAMM por prática, com nível atual e nível alvo
Plano de evolução do processo, priorizado pelo que trava mais entrega
Verificação integrada ao pipeline, no que couber automatizar
Rotina de reteste e de revisão de escopo definida, com quem faz e quando
Marco de entregaNível atual e alvo definidos por prática, com plano aprovado pela liderança de tecnologia.
QUANTO TEMPO LEVA
Não publicamos prazo padrão, porque prazo publicado vira promessa. O que move o relógio aqui é quase sempre o escopo real, que costuma ser maior do que o pedido inicial descreve. Estes são os três fatores que mais pesam, e a primeira conversa já mostra em qual deles a sua empresa está.
Uma aplicação web com uma API e um aplicativo móvel somam três superfícies distintas de teste. Integração com terceiro, área autenticada com perfis diferentes e componente de IA generativa acrescentam caminhos que precisam ser percorridos com credenciais distintas para revelar problema de autorização.
O nível 1 é o primeiro passo e fecha a camada mais básica de defesa. O nível 2 é o que a maior parte das aplicações de negócio deveria buscar, e o nível 3 é para o que carrega risco alto. Quanto mais alto o nível, mais o trabalho depende de acesso a código, a documentação e às pessoas que desenvolveram.
Com time interno, correção e reteste andam no ritmo da agenda dele. Com fábrica de software, a correção depende de contrato, e às vezes a mudança contratual é o passo mais demorado do projeto inteiro. Essa conversa começa cedo, junto com a definição do nível alvo.
PERGUNTAS FREQUENTES
As dúvidas que aparecem em quase toda primeira reunião, respondidas sem rodeio.
A pergunta aparece bastante e a resposta ajuda a economizar dinheiro. A fundação não certifica fornecedor, verificador nem software, e diz isso no próprio texto do ASVS, o padrão de verificação de segurança de aplicação. Ela vai além e recomenda cautela com selo de terceiro que se apresente como certificação OWASP oficial, porque isso existe no mercado e não tem respaldo. O que o material do OWASP entrega é melhor para o seu caso do que um selo: uma régua pública que o seu cliente e o seu pentester reconhecem, com veredito requisito a requisito. E quando a exigência for mesmo um documento emitido por organismo acreditado, quem responde é a ISO 27001 ou o SOC 2.
Com escopo e nível de ASVS declarados, o relatório passa a dizer se a aplicação atende, e propostas de fornecedores diferentes passam a ser comparáveis. Serve tanto para quem precisa responder a um cliente quanto para quem vai colocar o requisito no contrato da próxima entrega.
Comparativos sobre este assunto
Ver os 13 comparativos