🛡️Desmistificando SCA, SAST, DAST
Quando falamos em Desenvolvimento Seguro, logo vem em mente alguns termos técnicos, hoje vamos entender o que são, quando usar e como eles são importantes.
Para apoiar todo o processo de desenvolvimento seguro dentro de uma abordagem de DevSecOps, precisamos nos atentar em alguns termos técnicos, que são considerados boas práticas para DevSecOps, pois são processos que exigem maturidade e ajudam a garantir a segurança desde o começo do desenvolvimento (shift left).
Diariamente, surgem notícias sobre invasões de sistemas de computadores, muitas vezes por meio de diversas vulnerabilidades nas aplicações. Softwares inseguros podem:
- Liberar informações privadas/secretas (também conhecido como “perder a confidencialidade”)
- Perder ou corromper informações (também conhecido como “perder a integridade”)
- Perder o serviço (também conhecido como “perder a disponibilidade”).
Mas os problemas não param por aí. Qualquer um desses problemas pode causar perdas reais. Podem custar dinheiro, tempo, e muitos outros problemas. Vamos entender alguns conceitos que podem nos ajudar no dia a dia com desenvolvimento de apps, para assim garantir a segurança.
Software Composition Analysis (SCA)/Dependency Analysis
É uma etapa super importante dentro do ciclo de DevSecOps. Você provavelmente deve ter encontrado diversos nomes para SCA, incluindo análise de composição de software (SCA), análise de dependência e análise de origem. Não importa como seja chamada, ela é importante. Vamos primeiro analisar por que ela é importante logo abaixo.
Antigamente, os desenvolvedores de software escreviam a maior parte do software em seus aplicativos. Hoje, isso quase nunca acontece. Em vez disso, os desenvolvedores de software normalmente reutilizam pacotes de software que são, em sua maioria, escritos por outros e, então, escrevem apenas a funcionalidade especializada e o código de integração necessários para que tudo funcione da maneira desejada. Isso também se aplica a pacotes de software reutilizáveis; esses pacotes normalmente dependem de pacotes, que dependem de outros, e assim por diante. O mesmo vale para sistemas operacionais autônomos, imagens de máquinas virtuais e imagens de contêineres, eles geralmente incluem muito software escrito por outras pessoas.
Há vantagens claras em reutilizar software. Uma vantagem é que economiza muito tempo (e dinheiro), você não precisa desenvolver esse código. Outra vantagem é que um pacote reutilizado geralmente é especialmente bom nessa tarefa (já que alguém dedicou tempo especificamente para resolver esse problema); esses pacotes geralmente lidam com casos extremos que você poderia esquecer.
Mas quando você reutiliza software, existe uma desvantagem: esse software terá vulnerabilidades. Você deve tentar escolher um software que provavelmente tenha menos vulnerabilidades. Mas, em geral, vulnerabilidades serão encontradas no software que você usa, direta e indiretamente; essas vulnerabilidades serão anunciadas publicamente e atualizações para os componentes que as corrigem serão lançadas.
Security Code Scanners/Static Application Security Testing (SAST)
Análise estática é qualquer abordagem para verificar software (incluindo a descoberta de defeitos/vulnerabilidades) sem executá-lo. Isso inclui humanos que revisam código. Também inclui ferramentas que revisam código-fonte, código de bytes e/ou código de máquina.
Se você estiver iniciando um novo projeto, é importante ativar o máximo possível de ferramenta (incluindo os avisos do compilador) o mais rápido possível. Se você ativá-las cedo, verá alguns relatórios recomendando uma abordagem diferente e, em vez disso, simplesmente a usará. Se você tentar adicioná-las a um projeto existente, frequentemente verá muitos problemas para corrigir, mesmo que a probabilidade de qualquer um deles ser um problema sério seja pequena. Portanto, se você já tiver um projeto, normalmente precisará adicionar essas ferramentas lentamente, configurando-as para relatar apenas um subconjunto (como apenas relatórios acionados por uma alteração) e, em seguida, expandindo lentamente o que elas relatam. Aqui podemos citar SonarQube, Semgrep.
É claro que nem tudo o que é relatado por uma ferramenta é uma vulnerabilidade real. Todas elas apresentam algum risco de gerar um falso positivo, inclusive isso é um dos pontos de desafio quando estamos definindo a etapa de SAST, muitas ferramentas fornecem muitas informações de logs, eventos, métricas, mas é bem provável que nessas informações tenham falsos positivos. Utilizar o SAST é uma prática recomendada para fortalecer a segurança do software/produto e atender requisitos regulatórios e normativos, como ISO 27001, GDPR, OWASP.
Dynamic Application Security Testing (DAST)
Outra etapa importante dentro do desenvolvimento seguro, é o DAST, basicamente esse processo identifica vulnerabilidades de segurança por meio de ataques simulados. A análise dinâmica é qualquer abordagem para verificar software (incluindo a descoberta de defeitos/vulnerabilidades), executando software em entradas específicas e verificando os resultados. Todas as ferramentas de análise dinâmica têm uma limitação fundamental: é impossível avaliar todas as entradas possíveis em um período de tempo razoável. Nem mesmo é possível avaliar um subconjunto razoável.
Quando falamos em análise dinâmica de segurança, a forma mais tradicional que vem à mente é o bom e velho teste de software. A lógica é simples: você envia entradas específicas para o sistema e observa se ele responde como deveria. Isso pode ser feito em diferentes níveis, desde o teste unitário, que verifica partes isoladas do código como funções ou métodos, até o teste de integração, que avalia o comportamento do sistema como um todo em cenários mais realistas. No dia a dia, o ideal é combinar essas abordagens. Os testes unitários são rápidos e úteis para validar comportamentos específicos, mas geralmente não detectam problemas que só aparecem quando todas as peças do sistema interagem. Por outro lado, os testes de integração têm mais chances de revelar falhas reais de execução, aquelas que os usuários de fato enfrentariam. Com o avanço do poder computacional, hoje é perfeitamente viável priorizar testes de integração sem comprometer tempo ou performance. Ainda assim, cada tipo de teste tem seu valor, e o equilíbrio entre eles é essencial para uma estratégia de qualidade eficaz.
Do ponto de vista da segurança, é importante incluir testes para os requisitos de segurança. Em particular, teste tanto “o que deve acontecer” quanto “o que não deve acontecer”. Muitas vezes, as pessoas se esquecem de testar o que não deve acontecer (também conhecido como teste negativo). Por exemplo, onde aplicável, você deve ter um teste para verificar “Posso ler/escrever sem estar autorizado a fazê-lo?” (a resposta deve ser não) e “Posso acessar o sistema com um certificado inválido ou sem certificado algum?” (novamente, isso deve falhar). É muito comum que a segurança dos programas falhe porque eles não verificam adequadamente a autenticação (2017 OWASP Top 10 #2) ou a autorização (2017 OWASP Top 10 #5), então certifique-se de ter testes para isso!
Entender cada etapa de DevSecOps, e adicionar a segurança como item prioritário deve ajudar você a remediar as vulnerabilidades mais cedo, e asim garantir mais tempo & menos gastos no projeto. Fica ligado que nos próximos posts vamos falar das ferramentas. Tmj!
Originally published at https://amauryborgessouza.substack.com.
