Um relatório com 147 achados não conserta nada
Você pagou a análise, recebeu o PDF, e nada mudou. O problema quase nunca é o seu time. É que o relatório foi escrito pra ser completo, e não pra ser resolvido.
A varredura roda, o PDF chega, e tem 147 achados dentro dele. Alguém abre, rola por um tempo, e faz a única pergunta que importa: quais desses realmente importam?
Ninguém responde. O arquivo vai pra uma pasta. Seis meses depois o app tem os mesmos buracos que tinha no dia em que o relatório foi escrito, mais o que entrou desde então.
Isso é tão comum que vale dizer com todas as letras: o problema não é que as pessoas são relaxadas com segurança. O problema é que uma lista de 147 itens sem ordem nenhuma não é um plano. É uma pilha.
Metade pode nem ser real
Um scanner não pensa. Ele dispara milhares de pedidos no seu app, olha o que volta, e marca tudo que parece suspeito. Parecer suspeito não é a mesma coisa que ser verdade. Um campo que parece injetável e não é. Um endereço marcado como aberto que na verdade exige um token que o scanner nunca teve.
Parte de toda varredura crua não sobrevive ao contato com alguém que confere. A armadilha é que você não consegue saber qual parte lendo a lista, porque o falso tem a mesma cara do verdadeiro. Mesmo selo vermelho, mesma frase segura de si.
Achado que ninguém conferiu é boato com nota de gravidade do lado.
A nota não é a prioridade
A maioria dos relatórios ordena por CVSS, um número de zero a dez. É uma língua comum útil, e tem um limite embutido: ele pontua a falha sozinha, sem ideia nenhuma de onde o seu app está nem de quem consegue chegar até ele.
Uma nota apavorante num serviço que ninguém alcança pela internet importa menos que uma nota mediana na sua tela de login. O número descreve a falha. A prioridade depende do seu app, e só quem está olhando pro seu app junta as duas coisas. As categorias por trás desses números são as do OWASP Top 10 sem jargão.
Como é um relatório que vira conserto
- Ele começa pelo que fazer primeiro, em ordem, e diz por que essa ordem.
- Cada item diz o que o atacante ganha com aquilo, na linguagem que você usaria pra explicar o prejuízo pra um cliente.
- Cada item foi conferido por alguém, então você não gasta a semana provando o relatório pra você mesmo.
- Cada item termina na mudança, concreta o bastante pra entregar pra quem, ou pro que, escreve o seu código.
Uma pergunta antes de contratar qualquer análise
Pergunte quem confere os achados antes do relatório sair, e peça pra ver como é a instrução de conserto. Se a resposta for "a ferramenta exporta", você está comprando uma pilha, e a pilha custa o mesmo preço do plano.
Por que a nossa é feita assim
O SecureDragon roda a análise, joga fora o que não se sustenta, escreve o que sobrou em português claro e te entrega o texto pra colar de volta na ferramenta onde você construiu o app. Essa última etapa existe por causa de tudo que está acima: conserto que você não consegue aplicar é indistinguível de conserto que ninguém ofereceu. Um achado como a chave do banco escrita na página leva duas linhas pra explicar e uma colada pra fechar, e é essa a forma que a gente persegue.
O primeiro teste é de graça, que também é o jeito honesto de fazer esse argumento. Leia o relatório e julgue se ele te diz o que fazer primeiro.
Será que isso está acontecendo no seu app?
O SecureDragon olha o seu app por fora, acha o que ficou aberto, explica em português claro e te entrega o texto que conserta. O primeiro teste é de graça, sem cartão.
Testar meu app de graça