Um aplicativo local de notas pode passar nos testes unitários mesmo contendo duas falhas de segurança. A rota GET /notes/:id retorna a nota 42 sempre que um usuário autenticado a solicita, mesmo quando a nota 42 pertence a outra conta. Independentemente disso, o aplicativo aceita um termo de busca que chega a uma consulta de banco de dados sem ser tratado de forma segura. Um terceiro problema reside fora do código personalizado do repositório: uma versão de pacote que possui um alerta de segurança publicado. Um atacante precisa apenas de uma conta válida de baixo privilégio para a primeira falha, de um endpoint HTTP acessível para a segunda e de nenhum acesso ao código-fonte para o risco relacionado à dependência.
Essas falhas expõem a superfície de ataque do aplicativo, ou seja, todos os caminhos de código, interfaces de tempo de execução e limites de dependência pelos quais entradas não confiáveis ou comportamentos controlados por um atacante podem afetar o sistema. A questão para quem defende o sistema não é qual ferramenta de varredura é a melhor em termos gerais. Precisamos decidir quais evidências os testes estáticos de segurança de aplicativos (SAST), os testes dinâmicos de segurança de aplicativos (DAST) e a análise de composição de software (SCA) devem produzir para o mesmo aplicativo de notas e, em seguida, usar essas evidências para decidir se uma alteração pode ser implantada. Repositórios de código-fonte, o comportamento HTTP em execução e pacotes de terceiros revelam diferentes aspectos do risco.
O exemplo comparativo mais simples e útil é a solicitação para /notes/42. A análise de código-fonte pode identificar a condição de autorização que falha ao comparar a conta do usuário solicitante com a do proprietário da nota. A análise em tempo de execução pode enviar uma solicitação autorizada como um determinado usuário e observar se a resposta expõe a nota de outro usuário. A análise de dependências pode inspecionar o manifesto do pacote sem sequer invocar a funcionalidade vulnerável. Qual observador consegue comprovar cada constatação depende de onde a falha reside.
Os limites de confiança no aplicativo de notas indicam onde cada tipo de evidência começa e termina.
Este diagrama mostra por que nenhum scanner isolado analisa da mesma forma a entrada do navegador, a lógica da aplicação, a chamada de banco de dados e a fronteira de pacotes externos.
Como os três observadores precisam de um alvo comum, o curso utiliza um repositório contendo uma aplicação de notas de propriedade local, projetada intencionalmente com falhas. A aplicação aceita parâmetros HTTP e corpos JSON na fronteira da API web, utiliza uma identidade estabelecida pela rota de login local, retorna respostas em HTML ou JSON e envia operações de banco de dados por meio de sua camada de acesso a dados. Realizamos varreduras apenas nesta aplicação de laboratório local e em ambientes sob nosso controle. Testar serviços de terceiros sem autorização por escrito está fora do escopo do curso e pode violar leis como o Computer Fraud and Abuse Act nos Estados Unidos ou o Computer Misuse Act 1990 no Reino Unido.
O repositório apresenta dois comportamentos deliberados. Um deles é um caminho de busca suscetível a injeção, representativo da CWE-89 (Neutralização Inadequada de Elementos Especiais usados em um Comando SQL). O outro é uma falha de autorização em nível de objeto na rota GET /notes/:id — categoria de falha que a lista OWASP API Security Top 10 2023 denomina “API1: Broken Object Level Authorization” (Autorização Quebrada em Nível de Objeto). O manifesto de dependências também inclui um pacote deliberadamente desatualizado com uma vulnerabilidade conhecida. Esses casos são tratados separadamente porque uma descoberta no código, uma observação HTTP e um alerta de segurança de pacote não constituem provas intercambiáveis.
O snapshot do repositório identifica as rotas, o acesso a dados e a declaração de dependências sem executar qualquer varredura ou requisição.