Segurança contínua no DevSecOps

O que é monitoramento contínuo de segurança?

O monitoramento contínuo de segurança é a evolução natural da segurança. O desenvolvimento de software moderno está adotando um modelo de continuidade em todas as etapas, da integração à entrega e implantação. As abordagens tradicionais de segurança se concentram em testar lançamentos de software após a produção, mas isso cria gargalos no desenvolvimento e pode fazer com que vulnerabilidades cheguem à produção. A segurança contínua, por sua vez, integra a segurança ao processo de desenvolvimento, reduzindo riscos e eliminando gargalos para acelerar os lançamentos.

Quais são os benefícios de usar segurança contínua?

O desenvolvimento moderno de software é marcado por arquiteturas complexas e camadas de infraestrutura. Abordagens como aplicações nativas da nuvem, microsserviços e conteinerização permitem que desenvolvedores testem e entreguem código com mais rapidez. Em geral, os lançamentos são pequenos e rápidos. Os ambientes podem receber implantações em produção várias vezes ao dia.

A segurança em DevOps exige uma nova abordagem para lidar com o rápido aumento no ritmo de mudanças do software. Os métodos de segurança tradicionais testavam o software no fim do ciclo de desenvolvimento ou depois que ele entrava em produção. Muitas vezes, equipes externas eram responsáveis pelos testes, o que gerava atritos entre desenvolvedores e profissionais de segurança.

Além disso, as abordagens tradicionais de segurança não são adequadas às arquiteturas e infraestruturas de software modernas. A infraestrutura em nuvem pode ser provisionada em minutos. A arquitetura não é bem definida. Isso é atraente para desenvolvedores modernos, mas amplia a superfície de ataque e dificulta a proteção. As abordagens tradicionais de segurança não estão preparadas para testar esses ambientes.

A segurança contínua é uma extensão natural das práticas de DevOps que integra a segurança ao pipeline de CI/CD. Ela está diretamente alinhada ao conceito de DevSecOps e à abordagem de deslocar a segurança para a esquerda. As equipes de desenvolvimento assumem a responsabilidade pela segurança do código, para que os problemas sejam detectados e corrigidos o quanto antes no processo de desenvolvimento. Em última análise, a segurança contínua acelera a entrega de funcionalidades e automatiza os requisitos de segurança, aprimorando a governança e a proteção.

Como a segurança contínua se integra aos pipelines de CI/CD?

A segurança contínua aplica políticas e testes diretamente ao pipeline de CI/CD, protegendo a infraestrutura e as aplicações em cada etapa do ciclo de vida de desenvolvimento de software:

Modelagem de ameaças

O ideal é que a modelagem de ameaças aconteça nas primeiras etapas do SDLC, quando os desenvolvedores modelam as mudanças que ocorreriam com a execução do código, sem executá-lo de fato. Isso proporciona feedback quase imediato e permite avaliar as implicações do código para a segurança.

A modelagem de ameaças pode se tornar complexa rapidamente. Uma abordagem, chamada STRIDE, inclui uma análise separada para cada um dos tipos de ataque mais comuns:

• S falsificação de identidade

• Tampering (adulteração)

• Repúdio

• Informação divulgada

• Denial de serviço

• Elevação de privilégio

Metodologias como STRIDE ajudam a avaliar o que você está desenvolvendo, o que pode dar errado, como mitigar os riscos e como avaliar seu processo de mitigação de ameaças.

A modelagem de ameaças também exige planejamento para se integrar bem à cultura de DevSecOps. Tradicionalmente, ela envolvia inúmeras reuniões iniciais entre desenvolvedores e especialistas em segurança. A segurança contínua aplica a abordagem de deslocar para a esquerda à modelagem de ameaças, antecipando-a no processo de desenvolvimento, e também estende a análise para a direita com ferramentas de terceiros, que detectam e mitigam ameaças automaticamente nas etapas posteriores do pipeline.

Revisão de código e design

Depois que o código é escrito, é hora de revisá-lo para garantir que faça o que foi projetado para fazer e identificar vulnerabilidades ou problemas de segurança. Esse processo deve incluir a higienização e validação de todas as entradas com uma biblioteca confiável, a aplicação de autenticação segura, a verificação de vulnerabilidades em dependências de software, entre outras verificações de segurança.

Para conhecer outras práticas recomendadas, confira este guia rápido de revisão de código que criamos.

Testes

Depois de validar o código quanto à segurança e aos requisitos de design, é hora de testá-lo. Nesta etapa, os desenvolvedores criam um ambiente de testes pronto para entrar em produção e testam o código nessas condições. Isso inclui testes automatizados de chamadas de rede, validação de entradas, autorização, registros e controle de acesso. A aplicação registra corretamente as métricas de segurança? O acesso está limitado às pessoas certas?

Os testes contínuos de segurança dessa forma permitem obter feedback rápido. Eles também podem incluir o provisionamento e o teste de recursos de infraestrutura. Por exemplo, em um ambiente de testes implantado na AWS, uma ferramenta chamada Managed Config Rules pode garantir que os recursos de nuvem sigam as práticas recomendadas de configuração de segurança.

Produção

A produção é o fim da linha para o código, mas não para a segurança. Os recursos podem ser modificados, adicionados ou removidos, por isso as aplicações em produção precisam de testes contínuos para verificar a conformidade com os padrões da organização, do setor ou do governo. A segurança em produção pode incluir aplicação automatizada de patches, gerenciamento de configuração e atualização automática de dependências.

Confira algumas práticas recomendadas para criar um programa eficaz de segurança contínua.

Quais são as práticas recomendadas para um processo de segurança contínua?

A segurança contínua exige planejamento

Não basta repassar os objetivos de segurança à equipe de DevOps e esperar que ela aplique e imponha os procedimentos. A responsabilidade pelas integrações não deve recair apenas sobre as equipes de desenvolvimento. As equipes de segurança devem se concentrar em aplicar a segurança contínua com o mínimo de interrupções, começando pela etapa de planejamento. Segurança e DevOps devem trabalhar juntos para incorporar funcionalidades e auditorias desde o início e colaborar durante todo o processo.

O planejamento começa com a modelagem de ameaças, na concepção inicial de um sistema, aplicação ou história de usuário. Os testes de segurança de aplicações devem ser executados automaticamente quando o código é alterado e após a integração. Qualquer possível problema deve ser sinalizado para revisão, e os resultados devem ser apresentados aos desenvolvedores nas ferramentas de desenvolvimento que eles já usam.

O processo deve ser automatizado o máximo possível. Por exemplo, a implantação deve depender das métricas de segurança e da segurança em tempo de execução.

A infraestrutura exige atenção especial

A flexibilidade da infraestrutura em nuvem exige que as políticas estejam definidas e sejam aplicadas. Isso pode incluir desativar serviços desnecessários, fechar portas que não são usadas, aplicar permissões e garantir que nenhuma ferramenta de desenvolvimento esteja instalada em produção.

O código deve ser criado em sistemas operacionais seguros e com versões atualizadas das aplicações. Também é necessário aplicar controles de segurança relacionados ao tamanho do cluster, às permissões da infraestrutura compartilhada e aos parceiros de infraestrutura ou plataforma.

Realize testes regulares (testes de intrusão e programas de recompensa por bugs)

Os testes são essenciais. Eles garantem que o código seja funcional e seguro antes do lançamento. Também podem ser automatizados para evitar atrasos causados por verificações manuais. Os testes podem revelar vetores de ataque, identificar possíveis vulnerabilidades de segurança e classificá-las de acordo com o impacto potencial.

Esse nível de teste também deve ser aplicado à infraestrutura, às redes e a tudo o que é representado como código. O objetivo é analisar todos os componentes de uma aplicação para garantir que a segurança adequada esteja implementada em toda a pilha de tecnologia.

Use ferramentas que promovam a segurança sem atrapalhar os desenvolvedores

As ferramentas modernas facilitam o aprimoramento da segurança pelos desenvolvedores diretamente no pipeline de CI/CD. Ferramentas de teste estático de segurança de aplicações (SAST) podem ser usadas durante a criação do software para encontrar problemas e vulnerabilidades no código atualizado. Por exemplo, as ferramentas SAST podem detectar se uma entrada do usuário pode acionar uma função relacionada ao banco de dados e introduzir uma vulnerabilidade de segurança (conhecida como vulnerabilidade de injeção de SQL).

Tradicionalmente, as ferramentas SAST eram usadas em um processo de CI separado. Hoje, elas podem ser usadas durante a criação do código-fonte para fornecer feedback rápido e prático aos desenvolvedores. Essas ferramentas têm uma baixa taxa de falsos positivos e também dão orientações sobre como corrigir os problemas. São desenvolvidas com foco nos desenvolvedores e se integram ao IDE, à CLI e a outras ferramentas que eles já usam.

As ferramentas de análise de composição de software (SCA) são outra tecnologia valiosa para a segurança contínua. Elas permitem que os desenvolvedores verifiquem se há vulnerabilidades relacionadas a dependências nas alterações do código-fonte antes de mesclá-las.

Mecanismos de políticas e ferramentas semelhantes a linters são outros tipos de ferramentas que podem ser executados sempre que um desenvolvedor entrega código. Ferramentas de gerenciamento de segredos, como o Vault, ajudam ainda mais a proteger o código em toda a infraestrutura de nuvem e nas aplicações.

Ferramentas da Snyk para segurança contínua

Há muitas ferramentas para encontrar e corrigir vulnerabilidades durante todo o ciclo de vida de desenvolvimento. A Snyk se diferencia pelo foco nos desenvolvedores e por sua plataforma de segurança de excelência.

Por exemplo, manter as dependências atualizadas é um obstáculo para os desenvolvedores. Como saber quando uma atualização é necessária? As mudanças serão úteis? Elas vão introduzir bugs ou impedir a compilação? Atualizações contínuas de dependências, com mudanças menores e mais frequentes, facilitam o gerenciamento desse desafio. Os desenvolvedores podem usar ferramentas para aprovar e mesclar atualizações automaticamente, desde que os testes sejam aprovados. Isso, em última análise, acelera as implantações e automatiza todo o processo, da solicitação de pull à produção.

As dependências de código aberto merecem atenção especial. O Snyk Open Source testa o código automaticamente por todo o pipeline de CI/CD para encontrar e corrigir vulnerabilidades antes que cheguem à produção. Quando o código está em produção, a Snyk monitora novas vulnerabilidades divulgadas usando um banco de dados proprietário de vulnerabilidades.

Em resumo, a análise de código é essencial para a segurança contínua. Se você não analisa o código, que vulnerabilidades ou bugs podem passar despercebidos?