SDLC seguro e ferramentas SAST e DAST

O ciclo de vida seguro do desenvolvimento de software (SSDLC) integra atividades de segurança a todas as fases do desenvolvimento de software — desde os requisitos até o design, a codificação, os testes, a implantação e a manutenção. O SDLC tradicional trata a segurança como uma barreira na etapa final, o que é caro e ineficaz. A filosofia do SDLC seguro consiste em encontrar e corrigir vulnerabilidades o mais cedo possível, pois os defeitos identificados durante o design custam muito menos para corrigir do que aqueles encontrados em produção.

Antecipar a segurança significa colocá-la mais cedo (à esquerda na linha do tempo do desenvolvimento), em vez de adicioná-la apenas no final. Na prática, isso significa incluir requisitos de segurança nas histórias de usuário, realizar modelagem de ameaças durante o design, fazer revisão de código e SAST durante o desenvolvimento e executar DAST antes do lançamento. As equipes que antecipam a segurança descobrem vulnerabilidades quando é mais barato corrigi-las — durante o desenvolvimento, não em produção.

A modelagem de ameaças identifica e documenta sistematicamente as ameaças à segurança durante a fase de design. O modelo STRIDE categoriza as ameaças em: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service e Elevation of Privilege. PASTA (Process for Attack Simulation and Threat Analysis) é uma metodologia centrada em riscos que simula os objetivos de um invasor. Os modelos de ameaças geram medidas de mitigação priorizadas antes que uma única linha de código seja escrita.

SAST (teste de caixa branca) analisa o código-fonte, o bytecode ou os binários sem executar a aplicação, procurando padrões de codificação associados a vulnerabilidades conhecidas. As ferramentas SAST podem examinar toda a base de código rapidamente e relatar problemas como credenciais codificadas diretamente, pontos de injeção de SQL e desserialização insegura. Elas são executadas dentro do IDE ou do pipeline de CI e informam os resultados com os números dos arquivos e das linhas, facilitando a correção.

Uma limitação importante do SAST é sua tendência a produzir falsos positivos — sinalizando um código como vulnerável quando, na verdade, ele é seguro. Essa fadiga causada pelos alertas faz com que os desenvolvedores ignorem os resultados sem investigá-los. As ferramentas SAST também não conseguem detectar problemas de configuração em tempo de execução, falhas de autenticação que dependem do comportamento em tempo de execução ou vulnerabilidades em chamadas de API de terceiros. O SAST é mais eficaz quando combinado ao treinamento dos desenvolvedores, para que os resultados sejam avaliados e priorizados corretamente.

DAST (teste de caixa preta) testa uma aplicação em execução enviando cargas de ataque aos seus endpoints HTTP e analisando as respostas em busca de indicadores de vulnerabilidade. O DAST não exige acesso ao código-fonte — ele testa a aplicação como um invasor faria. É excelente para encontrar problemas em tempo de execução, como desvio da autenticação, XSS refletido nas respostas e configuração incorreta do servidor. As ferramentas DAST incluem OWASP ZAP, Burp Suite e Netsparker.

SAST e DAST são complementares, e não concorrentes. O SAST encontra problemas no nível do código antecipadamente e integra-se ao IDE, mas não tem visibilidade sobre o comportamento em tempo de execução. O DAST encontra vulnerabilidades em tempo de execução e não exige o código-fonte, mas não consegue examinar caminhos de código que não sejam acionados por suas sondas automatizadas. Usar ambos em conjunto — SAST no pipeline de CI e DAST contra um ambiente de homologação — maximiza a cobertura de vulnerabilidades em todo o SDLC.

IAST combina aspectos de SAST e DAST instrumentando a aplicação em tempo de execução. Um agente IAST é executado dentro da aplicação (no servidor), observando a execução do código enquanto o tráfego de teste passa por ela. Ele pode correlacionar entradas de usuário contaminadas ao longo dos caminhos do código até pontos de destino sensíveis, encontrando vulnerabilidades com taxas menores de falsos positivos do que o SAST puro. O IAST é particularmente eficaz em aplicações Java e .NET e integra-se naturalmente às execuções de testes funcionais.

Análise de composição de software (SCA) identifica bibliotecas de código aberto e dependências de terceiros em uma aplicação e verifica-as em bancos de dados de vulnerabilidades (NVD, OSV). Como as aplicações modernas podem incorporar centenas de dependências — muitas delas transitivas —, ferramentas SCA como OWASP Dependency-Check, Snyk e Renovate são essenciais para detectar CVEs conhecidas antes que os invasores as explorem na sua cadeia de fornecimento.

A integração de ferramentas de segurança aos pipelines de CI/CD garante que nenhum código chegue à produção sem passar pelos controles de segurança. Um pipeline típico de DevSecOps executa: SAST a cada commit, SCA quando há alterações nas dependências, análise de imagens de contêiner antes do envio ao registro, análise de IaC para Terraform/CloudFormation e DAST contra uma implantação de homologação. Verificações de segurança malsucedidas bloqueiam a compilação, promovendo uma cultura de segurança por padrão.

As ferramentas automatizadas não substituem a revisão de código humana focada na lógica de segurança. A revisão por pares deve verificar se: as verificações de autenticação e autorização estão nos locais corretos; o tratamento de erros não expõe informações confidenciais; as funções criptográficas usam algoritmos e parâmetros aprovados; e a lógica de negócio não pode ser contornada. Os responsáveis pela segurança nas equipes de desenvolvimento — desenvolvedores com treinamento em segurança — fazem a ponte entre a equipe de segurança e a engenharia.

Teste sua compreensão dos conceitos de CompTIA Security+ (SY0-701) desta lição.

Nesta lição, você aprendeu que: o SDLC seguro integra a segurança a todas as fases do desenvolvimento, em vez de adicioná-la apenas no final; o SAST analisa o código sem executá-lo, enquanto o DAST testa aplicações em execução; e o SCA identifica dependências de código aberto vulneráveis, enquanto os controles de segurança de CI/CD aplicam automaticamente os resultados. A seguir, exploraremos serviços de diretório com LDAP e Active Directory.