Existem duas considerações importantes ao adicionar segurança a um pipeline DevOps existente. A primeira é a segurança no código, o que significa que, quando o código é desenvolvido, a segurança do próprio código deve ser continuamente revisada e avaliada. A segunda é a segurança como código, ou seja, os requisitos de segurança precisam fazer parte do processo desde o início. Vamos olhar para ambos os conceitos com um pouco mais de detalhes.

Segurança em Código

Muitas equipes iniciam seu caminho para a segurança, adotando diretrizes ou padrões de codificação, como MISRA, OWASP ou as diretrizes do CERT, o que é um ótimo começo, melhora a segurança do código desde o início. No entanto, apenas seguir um padrão de codificação por si só não necessariamente evita vulnerabilidades complexas de segurança. De acordo com um estudo recente da Microsoft, 70% das vulnerabilidades de segurança atuais são causadas por erros de acesso à memória.

As vulnerabilidades de memória aqui podem ser causadas por um simples erro de cálculo, que levou a uma gravação de buffer ou a um caminho mais complexo onde uma variável é contaminada através de entradas do exterior que é usada sem ser higienizada. Para encontrar esses problemas no código, é necessária uma análise mais sofisticada, como análise de fluxo de dados e execução abstrata fornecida por ferramentas avançadas de teste de segurança de aplicativos estáticos (SAST).

Igualmente importante é entender as implicações de segurança dos componentes de software que seus produtos dependem, como código aberto, código interno reutilizado e software comercial. Sem isso, seus melhores esforços serão em vão se houver vulnerabilidades no código de terceiros incluído em seu aplicativo.

As ferramentas de análise de composição de software (SCA) fornecem uma conta contínua de materiais de software (SBOM) que lista todas as bibliotecas de software em suas dependências e vulnerabilidades conhecidas associadas. Este SBOM é estabelecido no início do desenvolvimento e é atualizado continuamente à medida que as dependências evoluem tanto a partir de atualizações quanto de vulnerabilidades recém-descobertas.

Segurança como Código

Uma abordagem interessante que saiu da prática DevSecOps é o conceito de tratar a segurança da mesma forma que o código é; guiados por requisitos, o que leva à implementação de controles de segurança, depois à validação por meio de testes e, claro, documentação. É uma das principais maneiras de integrar a segurança nos DevOps e uma boa maneira de construir segurança na cultura de desenvolvimento e ter equipes de software se comunicando usando uma linguagem familiar.

Certamente, implementações de segurança que acabam como código real com testes associados podem ser automatizadas da mesma forma que outros códigos. Ferramentas de automação se aplicam aqui, assim como qualquer ferramenta que trabalhe com requisitos, testes, documentação, etc.

Cada iteração através de um processo contínuo requer uma revisão que inclua o backlog de problemas de segurança, mas também dados importantes sobre as mudanças necessárias aos controles e requisitos de segurança. Esse feedback no processo é uma parte fundamental e importante para fazer o sucesso do DevSecOps — repita, revise e refine.

Integrando SAST e SCA para mudar a segurança à esquerda

A automação é um dos principais princípios do DevOps. Nada deve depender de passos manuais, pois eles podem ser facilmente negligenciados, seja por acidente ou por intenção maliciosa. As ferramentas SCA podem ser usadas imediatamente para estabelecer um SBOM de linha de base para o aplicativo. Sem antes entender as vulnerabilidades e riscos associados à sua pilha de software, outras medidas serão em vão.

É igualmente importante manter este SBOM atualizado com cada iteração, uma vez que o cenário de ameaças pode mudar com o tempo, assim como a composição das dependências. Ferramentas que podem analisar binários de terceiros mesmo que a fonte não esteja disponível, podem limitar exposições.

O SAST é usado assim que o código está disponível em um projeto e automatiza a conformidade de codificação e a detecção automática de defeitos e vulnerabilidades. Na verdade, assim que for digitado por um desenvolvedor - quanto mais cedo melhor. As ferramentas SAST que se integram aos IDEs populares podem fornecer feedback imediato no ambiente do desenvolvedor, antes que ele se compromisse no repositório de origem.

O SAST vem em todos os tipos de formas e tamanhos, alguns focam em padrões de codificação, alguns, ferramentas mais avançadas, ultrapassam os padrões de codificação e exploram o fluxo de dados, o fluxo de controle e técnicas de execução abstrata para encontrar defeitos no código fonte que surgem de erros de programação ou lógica. Estes últimos ajudam a alcançar a segurança no código e ajudam na criação de segurança como código — cobrindo padrões de codificação, aplicação de controle de segurança e detecção de vulnerabilidades.

Processos contínuos de integração e implantação dependem da automação para realizar seus benefícios prometidos. Sem um progresso eficiente ao longo do ciclo, a natureza contínua dos processos amplifica ineficiências. Todo novo código tem vulnerabilidades, o desafio que as equipes enfrentam é removê-las o mais cedo possível com o mínimo de esforço possível. A SCA garante que a pilha de software seja segura, enquanto o SAST melhora a segurança e a qualidade do código personalizado no início do processo e ajuda os desenvolvedores a fazer isso da forma mais fácil possível, idealmente, integrado ao seu ambiente de desenvolvimento.

Resumo

As ferramentas SAST e SCA são uma parte importante da mudança de segurança deixada porque são usadas imediatamente nos estágios iniciais de um projeto. Eles também são fundamentais para ajudar a impor controles de segurança e padrões de codificação necessários para o aplicativo, enquanto isso, detectam novas, possivelmente complexas, vulnerabilidades de segurança à medida que surgem. As ferramentas SCA garantem que a pilha de software seja contabilizada com uma conta de software de materiais que mostram tanto o conteúdo quanto as vulnerabilidades de segurança existentes em suas dependências de software. Com o tempo, essas ferramentas fazem parte da parte regular do fluxo de trabalho da equipe, fornecendo melhores códigos, mas dados críticos sobre o progresso geral.

O movimento para integrar a segurança em um pipeline DevOps existente começa com a introdução de práticas recomendadas no início do ciclo de vida do desenvolvimento. As ferramentas SCA e SAST são ideais para facilitar essa transição. Além disso, o feedback para desenvolvedores e gerenciamento é crucial tanto para melhorar a segurança quanto para melhorar o processo de DevOps em geral.

Autor: Walter Capitani

Artigo Original