A segurança costuma ser a ovelha negra dos testes. Em muitas organizações, os testes funcionais têm suporte e financiamento contínuos durante todo o ciclo de vida do aplicativo, mas quando o foco muda para a segurança, geralmente há apenas uma varredura antes do lançamento.

O teste de segurança deve ser considerado como um cidadão de primeira classe e com um suporte de ciclo de vida útil semelhante aos demais testes. Isso envolve a análise de tecnologias que se integram perfeitamente ao pipeline de CI/CD moderno, explicando por que são importantes e apresentando os argumentos de custo-benefício que podem ajudar a convencer a gerência a fazer a coisa certa.  

Por fim, para obter o melhor impacto, você precisa adotar testes contínuos e introduzir testes de segurança nas fases iniciais do pipeline de testes contínuos usando três ferramentas: SAST (testes estáticos de segurança de aplicativos), DAST (testes dinâmicos de segurança de aplicativos) e SCA (análise de composição de software).     

  Abrace os testes contínuos

Uma das fraquezas na maioria das estratégias de teste de segurança é a natureza de última hora da maioria dos testes. As organizações investem em uma variedade de ferramentas e técnicas de teste, reúnem os dados e analisam os resultados apenas pouco antes do lançamento da release. 

Por outro lado, uma organização de controle de qualidade estabelecida fornece feedback frequente aos desenvolvedores na forma de relatórios constantes de erros e resultados de testes automatizados. Além disso, se os desenvolvedores estão seguindo as práticas recomendadas, elementos de teste de unidade e teste de integração leve são incorporados ao processo de criação automatizado, fornecendo feedback sobre cada criação.  

Informalmente, os esforços dos desenvolvedores e da organização de controle de qualidade começam a lançar as bases para testes contínuos e entrega contínua. 

Os testes contínuos geralmente são considerados como testes automatizados em todas as etapas do desenvolvimento para inovar rapidamente sem comprometer a qualidade. A aplicação disso à segurança é fundamental hoje, porque mesmo sem o código alterar uma única linha, novas vulnerabilidades são descobertas e divulgadas diariamente.

Isso significa que, para entender o quão vulnerável é o seu software, você precisa de algum tipo de teste de segurança e os resultados devem ser relatados quase todos os dias – mesmo em códigos que já podem ser implantados. 

  Virar à esquerda na segurança

Você pode começar a teorizar como mudar a segurança olhando para três ferramentas comuns de teste de segurança: SAST, DAST e SCA.

A ideia é pegar o enorme relatório estático gerado logo antes do lançamento por essas ferramentas e transformá-lo em algo acionável pelos desenvolvedores toda semana, toda noite ou até mesmo toda compilação.  

   1. Teste estático de segurança de aplicativos

Um dos motivos pelos quais o SAST pode ser um candidato inicial para testes de segurança contínuos é a proximidade com o código. SAST é uma varredura literal do código fonte que pode acontecer no momento da compilação. Se o seu código já estiver passando por um pipeline de CI / CD, você terá a maioria da infraestrutura necessária para criar uma estrutura de teste automatizada para aplicar o SAST ao seu código-fonte.

Como em todas as ferramentas de segurança, para acompanhar as divulgações, deve haver um processo automatizado para manter a análise de vulnerabilidades atualizada sobre a própria verificação. Em seguida, você pode aproveitar as ferramentas automatizadas de compilação existentes ou o mecanismo de IC (Jenkins, Bamboo etc.) para chamar uma verificação de código-fonte paralelamente à compilação. 

Uma vez que as verificações ocorram automaticamente, elas produzirão uma enorme quantidade de dados.

Os resultados dessa varredura automatizada devem produzir dois artefatos. Primeiro, para tornar os dados úteis, os resultados da verificação precisam ser resumidos e colocados em um painel exibido no mecanismo de IC. 

Segundo o relatório detalhado deve ser organizado de maneira rastreável à compilação original para fins de conformidade, relatórios e pesquisa. Com um investimento relativamente baixo, você pode obter uma avaliação inicial e constante de seu aplicativo.  

   2. Análise de composição de software

As implementações de SCA variam em comparação com o SAST. Como no SAST, o banco de dados do componente vulnerável deve ser automaticamente atualizado. O processo de construção chama algumas ferramentas para analisar todas as dependências de terceiros no momento da construção do código.

Outras ferramentas são configuradas como parte da infraestrutura de CI/CD para interceptar as dependências e criar a análise à medida que o processo normal de compilação é executado.

Com o primeiro método, você obtém um relatório posterior dos componentes vulneráveis em seu aplicativo. Com o último método, você pode bloquear dinamicamente componentes que não são de uma qualidade esperada e ter relatórios atualizados em tempo real e que representam quanto risco você deve assumir com base nos componentes de terceiros avaliados. 

Essa abordagem proativa é mais cara de implementar, mas causará falhas nas compilações, em vez de permitir a criação de um software inseguro. 

   3. Teste dinâmico de segurança de aplicativos

Se o seu pipeline do DevOps não incluir testes automatizados, o DAST será proibitivamente caro para ser utilizado.

Para implementar o DAST com um mínimo de esforço específico de segurança, você pode executar seus testes funcionais automatizados por meio de um ataque de proxy ou fuzz testing. Uma vez que você está executando o DAST como parte do conjunto de testes funcionais automatizados, isso é um pouco mais correto que o SAST ou o SCA, mas ainda é altamente automatizado.  

Algumas das principais vantagens dessa implementação são o teste de caminhos usados com frequência pelo aplicativo e a execução frequente, para que novos métodos de ataque possam ser usados para avaliar a segurança.  

  Obtenha o suporte da sua organização

Agora que você tem uma ideia geral de como implementar a segurança em seu pipeline de CI/CD, você precisa convencer os seus superiores para financiar as alterações necessárias.  

O primeiro estágio é garantir que seus stakeholders estejam cientes dos riscos de ter um longo tempo de atraso para encontrar as falhas. O longo tempo do ciclo de testes de segurança introduzido no final do ciclo de desenvolvimento é normalmente um bom ponto de discussão para começar.

Em seguida, é imperativo que você convença as partes interessadas de que pode obter valor aproveitando os recursos de CI/CD já existentes e introduzindo a segurança a um custo nominal.

Por fim, você precisa deixar claro que pode mostrar melhorias incrementais em um curto espaço de tempo. Selecionando cuidadosamente o conjunto inicial de automações de segurança, você pode realizar alterações incrementais em um curto espaço de tempo.   

Comece com o SAST acontecendo a cada compilação; em seguida, um sprint ou dois mais tarde o SAST produzirá um painel com os relatórios; em seguida, depois de mais alguns sprints, um painel pode aparecer com uma pesquisa detalhada que os desenvolvedores podem usar em tempo real, criando um ciclo de feedback mais curto.

Mostrar pequenos saltos incrementais de tendências de valor em direção à sua meta de segurança é mais fácil de avaliar. Isso permite que as partes interessadas comprem pequenos pedaços de segurança, em vez de tomar uma decisão do tipo tudo ou nada, aliviando parte da pressão. 

  Siga o fluxo

Sem um fluxo constante de informações sobre a segurança do seu software, você estará fadado a se tornar a próxima notícia de primeira página de violação de segurança. Para obter esse fluxo de informações, você precisa mudar a direção dos testes de segurança para a esquerda, juntamente com todos os outros testes.

Ao aproveitar SAST, DAST e SCA em seu pipeline de testes contínuos de maneira significativa, você pode se defender contra o cenário de segurança em constante mudança.

Este texto é uma adaptação livre do artigo publicado por Glenn Buckholz em:

https://techbeacon.com/app-dev-testing/shift-security-left-your-continuous-testing-3-key-focus-areas 

Clique aqui e veja como nós podemos te ajudar na implantação de processos de testes de segurança e vulnerabilidade.