Blog/Artigos · Segurança
Top 10, ASVS como régua, SAMM como maturidade e a segurança de aplicação como programa, não como varredura de véspera.
Os sábios da Mishná mandaram fazer uma cerca ao redor da Torá: não basta ter a lei, é preciso proteger o acesso a ela com uma barreira construída de propósito, antes que alguém tropece. AppSec é essa cerca ao redor da aplicação. A maioria dos ataques hoje não arromba a rede, entra pela porta da frente do software, por uma falha de código que ninguém protegeu. A OWASP existe para que ninguém construa essa cerca no escuro, e o Top 10 é o mapa das brechas por onde o inimigo entra.
A OWASP, Open Worldwide Application Security Project, é uma fundação sem fins lucrativos que publica o material de referência de segurança de aplicação, e o Top 10 é o mais famoso: a lista das dez categorias de risco mais críticas em aplicações web, revisada periodicamente a partir de dados reais. Broken Access Control, falhas criptográficas, injeção e configuração insegura lideram porque são o que de fato derruba sistemas, não o que assusta em teoria.
O Top 10 é conscientização, não checklist de conformidade, e confundir os dois é o primeiro erro. Ele diz onde olhar primeiro, mas passar no Top 10 não significa estar seguro. O valor está em usá-lo como linguagem comum entre desenvolvedor e segurança: quando o time inteiro sabe o que é Broken Access Control, a conversa sobre a falha acontece no code review, não no relatório de pentest três meses depois.
Se o Top 10 diz onde olhar, o ASVS, Application Security Verification Standard, diz o que exigir. É um catálogo estruturado de requisitos de segurança verificáveis, organizado em três níveis: L1 para o básico de qualquer aplicação, L2 para aplicações que lidam com dado sensível, L3 para o que exige o máximo, como sistema financeiro ou de saúde. Cada requisito é uma afirmação testável, não um conselho vago.
A virada que o ASVS traz é tornar segurança um requisito de produto, escrito antes, e não um parecer de véspera. Em vez de perguntar ao fim se está seguro, o time define no início que a aplicação atende ao ASVS L2, e cada requisito vira critério de aceite e caso de teste. A cerca deixa de ser improvisada na entrega e passa a ser especificada junto com a funcionalidade, que é a única forma de ela ficar em pé.
Uma aplicação segura num mar de aplicações inseguras é sorte, não programa. O OWASP SAMM, Software Assurance Maturity Model, mede a maturidade de AppSec da organização em cinco funções, governança, desenho, implementação, verificação e operação, cada uma com práticas que evoluem por níveis. Ele responde à pergunta que separa time reativo de time maduro: não estamos seguros neste sistema, e sim temos um processo que produz software seguro por padrão.
Na prática, o programa vive numa plataforma que orquestra o AppSec do dia a dia. A Conviso Platform, brasileira e forte no mercado nacional, centraliza a gestão de vulnerabilidades, o acompanhamento de requisitos e a evolução de maturidade num lugar só, ligando o achado do scanner ao requisito do ASVS e à prática do SAMM. A ferramenta não faz o programa, mas sem uma o programa vira planilha que ninguém mantém.
O antipadrão que ainda domina é o pentest de véspera: constrói-se o sistema por meses e, na semana do lançamento, contrata-se um teste que acha vinte falhas sem tempo de corrigir. A cerca de véspera não protege ninguém; ela vira lista de risco aceito por pressa. AppSec maduro distribui a segurança pelo ciclo inteiro: requisito no início, threat modeling no desenho, teste automático no build, e o pentest como validação final, não como descoberta.
Isso conecta AppSec ao SSDLC e ao DevSecOps: os requisitos do ASVS viram testes de SAST e DAST na pipeline, o threat modeling diz o que testar, e a Conviso ou equivalente acompanha o defeito até fechar. A cerca deixa de ser um evento e vira uma propriedade do processo. É assim que, na Creditas e no PicPay, eu tratei segurança como requisito de primeira classe desde o design, e não como parecer que chega quando já é tarde para mudar a planta.
A cada release, o ciclo se repete. A segurança é propriedade do processo, não um evento antes do lançamento.
AppSec é a cerca construída ao redor da aplicação, no código e no processo: o Top 10 mostra por onde o inimigo entra, o ASVS transforma isso em requisito testável, o SAMM amadurece o programa e a plataforma, como a Conviso, sustenta a operação. A cerca que protege é a que se constrói junto com o sistema, não a que se improvisa na véspera. A IA revisa pelo Top 10, mede a distância do ASVS e prioriza o defeito, mas construir segurança como requisito de primeira classe continua sendo decisão de arquitetura.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Segurançaצְרַפְתַּנִי
Segurança testada só no fim é cara e tardia. O SSDLC prova o código em cada etapa: análise estática, dinâmica, de dependências e de IaC, com gate na pipeline e as ferramentas que o mercado usa.
Segurançaהַנּוֹלָד
Corrigir vulnerabilidade em produção é caro; prevê-la no desenho é barato. Threat modeling é o exercício de antecipar o ataque antes do código, com STRIDE, árvores de ataque e o método de Adam Shostack.
