Encontrar harmonia entre desenvolvimento e segurança não é uma tarefa fácil e por isso vamos falar de ferramentas SSDLC! O equilíbrio depende de uma maior compreensão entre times, que precisam se comunicar e entender as dores de cada lado, provendo um ambiente robusto e seguro ao mesmo tempo em que mantém a fluidez na esteira do processo.
Pensando nisso, as ferramentas de segurança tem como objetivo facilitar a análise e testagem das aplicações do ponto de vista da segurança, fornecendo dados para tomada de decisões em relação à manutenção do projeto. Os tipos mais comuns de ferramentas utilizadas nas etapas do Security SDLC são SAST, DAST e SCA, as quais abordaremos mais abaixo.
SAST – Static Application Security Testing
Lembra quando você estava no ensino médio e precisava muito ir bem numa prova, então revisava tudo várias vezes antes de entregar a avaliação?! O SAST funciona de forma muito semelhante, pois, assim como no exemplo, faz uma revisão completa do código expondo possíveis vulnerabilidades.
Então, sua finalidade é identificar e auxiliar na correção de vulnerabilidades a nível de código. Esse tipo de ferramenta se popularizou por realizar um scan no código-fonte das aplicações, por meio de algoritmos de análise estática, de fácil implantação no pipeline CI (Continuous Integration) e baixo custo de correções.
Sua proposta é identificar issues com antecedência e executar a correção imediata, visto que esse tipo de análise é feita geralmente durante a fase de implementação, ou seja, a identificação rápida de vulnerabilidades enquanto ainda são simples de serem corrigidas.
Vantagens x limitações
As ferramentas SAST são extremamente úteis para o escalonamento da segurança dentro do SSDLC (Security System Development Life Cycle) e podem ser utilizadas em todas as fases do ciclo. Possuem diversas vantagens como:
- Auxilia na redução de riscos de segurança;
- Ganho de eficiência em code review de segurança;
- Maior assertividade na identificação de vulnerabilidades invisíveis para uma análise feita manualmente (por exemplo: Buffer Overflow);
- Auxilia no processo de desenvolvimento com informações detalhadas e recomendações.
Por outro lado, elas também possuem limitações que devem ser consideradas, como:
- Implementação em escala pode ser um desafio, devido a complexidade e particularidades de cada projeto;
- Incapacidade de identificar vulnerabilidades em outras camadas da aplicação, como nas bibliotecas de terceiros e integração com outros sistemas, uma vez que o scan SAST se restringe apenas ao código-fonte;
- É muito comum que ferramentas desse tipo apontem falsos positivos.
Caso tenha curiosidade de testar ferramentas SAST, pode começar pelas ferramentas:
DAST – Dynamic Application Security Testing
Vamos viajar no tempo mais uma vez e lembrar daquela empolgante sensação de construir seu primeiro projeto para a feira de ciências da escola. Ainda que fizesse seu trabalho com toda cautela do mundo, uma coisa era fato: algo poderia dar errado no dia da feira e você diria: ”mas eu testei e estava funcionando…”.
De forma muito semelhante acontecem imprevistos no dia a dia dos times de desenvolvimento, tendo em vista que todo mundo já deve ter visto ou passado (ou ainda vai passar) por aquela situação chata do: “não funciona?! Mas na minha máquina funcionava!“.
Nesse momento, o questionamento mais importante é se existe algum jeito de tentar evitar que isso aconteça e a resposta é sim. Enquanto o SAST faz uma análise estática (sem execução), as ferramentas DAST fazem uma análise do código em execução.
Elas atuam nas aplicações de uma forma mais dinâmica por meio da realização de testes automatizados. Em outras palavras, esse tipo de ferramenta possui características muito semelhantes aos chamados testes de penetração (Pentest) que tem por objetivo simular uma invasão em um sistema ou aplicação.
Ferramentas complementares
As ferramentas SAST e DAST se complementam e podem ser utilizadas em momentos diferentes do ciclo de desenvolvimento. O SAST pode e deve ser implementado desde as primeiras linhas de código e seguir por todas as etapas seguintes do SSDLC, enquanto o DAST geralmente será utilizado nas fases de homologação, testes e produção.
Profissionais da área de segurança fazem a utilização de ferramentas DAST antes de prosseguirem para uma análise manual devido a confiabilidade dessa ferramenta. Além disso, apesar de exigirem um nível maior de conhecimento em segurança, essas ferramentas são completamente customizáveis.
Essas características são extremamente úteis para encontrar erros de configuração e diversas outras vulnerabilidades de forma automática, mesmo sem acesso direto ao código-fonte.
Como ressaltado anteriormente, utilizar uma ferramenta DAST exige apoio técnico, uma vez que cada teste deve atender requisitos específicos em relação a cada ambiente e conforme a natureza da aplicação. Portanto, é muito importante solicitar apoio ao time de App Sec ou dos times de segurança para acompanhar de perto as configurações necessárias para uma utilização eficiente.
SCA – Software Composition Analysis
Se você já precisou checar a confiabilidade de uma fonte antes de fazer um trabalho de escola, então vai se identificar muito com o SCA.É muito comum a utilização de bibliotecas (libs) de terceiros em nossos projetos, pois elas ajudam muito na economia de códigos, na agilidade de desenvolvimento, na segurança e até na qualidade de entrega.
No entanto, muitas delas podem estar vulneráveis, sendo capazes de comprometer a aplicação ou mesmo projetos inteiros, como ocorreu recentemente nas libs Log4j e Spring (Spring4Shell). Nesse sentido, é necessário adotar medidas, processos e uma cultura de segurança em relação às bibliotecas e para isso existem as ferramentas SCA, ou Software Composition Analysis.
As ferramentas SCA têm como objetivo realizar a análise da composição dos softwares. Em outras palavras, elas buscam vulnerabilidades nas bibliotecas utilizadas no projeto fornecendo informações de criticidade e risco de cada uma delas, por meio de registros de vulnerabilidades (CVEs).
Além do apoio na identificação de vulnerabilidades e riscos, elas possibilitam que devs encontrem versões estáveis da biblioteca, de forma que seja possível evitar maiores complicações em uma possível refatoração de código.
O gerenciamento de políticas de segurança são particulares e podem variar conforme a cultura de cada organização ou risco de cada projeto.
Dessa forma, as soluções SCA permitem que os times possam calcular os riscos de, por exemplo, manter uma biblioteca que possui vulnerabilidades de criticidade baixa ao invés de atualizá-la para uma versão estável que poderia quebrar todo o funcionamento da aplicação, exigindo uma refatoração complexa e bastante trabalhosa.
Assim como as ferramentas anteriores, uma utilização eficiente de um SCA dentro do SSDLC está diretamente ligada à adoção de outras estratégias de segurança que otimizem a atuação deste tipo de ferramenta.
Arquitetura de software
A arquitetura de software é uma importante aliada no momento de definir quais libs utilizar, permitindo uma melhor gestão das bibliotecas e melhorando o aproveitamento de recursos, uma vez que o versionamento das aplicações geralmente corresponde a inclusão de novas bibliotecas que podem justificar a exclusão de outras, mas que acaba não ocorrendo devido a falta de uma gestão efetiva delas.
Portanto, a criação de um “inventário de bibliotecas” é uma vantagem enorme e extremamente útil no dia a dia dos times de desenvolvimento, se feita por meio de boas práticas de segurança.
Como fazemos na Zup
Construir uma cultura de desenvolvimento seguro é dever dos times de segurança e uma responsabilidade de cada profissional. Pensando nisso, aqui na Zup, os treinamentos do Security Champions possuem exatamente o propósito de criar pontos focais de segurança dentro dos nossos times e contribuir para o escalonamento da segurança dentro de todos os ambientes.
Por exemplo, para identificar vulnerabilidades com apenas um comando, usamos o Horusec, uma excelente ferramenta SAST de código aberto criada aqui na Zup. Além disso, durante o processo de desenvolvimento, ela também realiza análises estáticas de códigos e identifica falhas de segurança. Aproveite para testar em seus projetos!
Conclusão
As indicações de tratamento das vulnerabilidades oriundas dessas ferramentas são acompanhadas pelo time de AppSec e pelos outros times de segurança, juntamente aos times responsáveis pelo desenvolvimento do produto testado. O prazo para ajustes depende da classificação da criticidade de cada vulnerabilidade.
Integrar as ferramentas de acordo com a cultura Shift Left contribui para uma correção muito mais econômica e rápida (defensiva) do que quando a aplicação está em produção (ofensiva), uma vez que descobrimos vulnerabilidades altamente complexas durante os primeiros estágios de desenvolvimento e elas possuem versatilidade para que possam ser implementadas em outras etapas do ciclo de desenvolvimento.
Falando nisso, temos um episódio do Zupcast sobre Shift Left que vale a pena você ouvir!
O time de AppSec trabalha em conjunto aos times de desenvolvimento para encontrar as soluções mais assertivas e implementar as ferramentas de segurança com base nos requisitos e particularidades de cada projeto, segundo as melhores práticas de desenvolvimento seguro e recomendações OWASP.
Portanto, atingir maiores níveis de maturidade em segurança representa encontrar a harmonia necessária entre processos de segurança e desenvolvimento, sendo possível afirmar que a evolução crescente da tecnologia estará nivelada ao nível de segurança e, de modo consequente, no desenvolvimento de aplicações cada vez mais seguras.
Curtiu o conteúdo sobre ferramentas SSDLC? Conte pra gente nos comentários! Continue navegando na nossa Central de Conteúdos para estudar sobre Segurança da Informação e outros temas relacionados ao mundo tech.
*O artigo “Ferramentas SSDLC: SAST, DAST e SCA” foi produzido com contribuições do time de AppSec da Zup.
