DevSecOps: injetando segurança em pipelines de CD

Saiba como o DevSecOps afeta o pipeline de CD e o comportamento quanto à segurança das equipes de desenvolvimento ágil.

Juni Mukherjee Juni Mukherjee

O que é o DevSecOps?

O termo DevSecOps é usado para descrever um ciclo de vida do desenvolvimento de software de entrega contínua focada em segurança (SDLC). O DevSecOps se desenvolve com base em aprendizados e práticas recomendadas de DevOps em geral. A aplicação de valores de DevOps à segurança de software significa que a verificação de segurança se torna uma parte ativa e integrada do processo de desenvolvimento. Tradicionalmente, e muitas vezes, infelizmente, a segurança é tratada como um sistema secundário. InfoSec geralmente interage com equipes de desenvolvimento mais para o fim do SDLC. Por mais nobres que sejam suas intenções, pode ser frustrante descobrir vulnerabilidades de segurança no fim do SDLC.

O DevSecOps promove o engajamento da segurança tradicional a um processo ativo de SDLC. O DevOps geral introduziu processos como integração contínua (CI) e entrega contínua (CD). Esses processos garantem testes ativos e a verificação da correção do código durante o processo de desenvolvimento ágil. De modo semelhante, o DevSecOps introduz auditorias de segurança ativas e testes de intrusão no desenvolvimento ágil. DevSecOps defende que a segurança deve ser incorporada ao produto, em vez de aplicada aos produtos acabados.

Tudo pronto | Atlassian CI/CD

Por que usar o DevSecOps?

Para resumir: segurança. A necessidade de softwares muito seguros é essencial. Sem eles, a continuidade das empresas impulsionadas por tecnologia é colocada em risco. Violações de segurança são uma das maiores ameaças que organizações e governos enfrentam hoje. Diversas grandes organizações foram violadas nos últimos tempos, causando enormes consequências econômicas e demissões abruptas de executivos. Executivos que falharam aparecem nas notícias à medida que os consumidores continuam a perder a confiança nos provedores de serviços que tiveram a segurança comprometida.

Princípios de DevSecOps incentivam a colaboração e evitam entregas com atraso aos profissionais de segurança. O valor é óbvio quando você revisa tempos de ciclo antes e depois. Antes de DevSecOps, seu produto pode ser considerado inseguro no último minuto, causando múltiplas iterações dispendiosas. Depois de DevSecOps, os padrões de ouro da segurança são inseridos em seu produto. É possível que você possa encontrar problemas inesperados no último minuto, porém, a probabilidade é muito menor.

Então, a questão mais relevante é menos “Por que usar o DevSecOps?” e mais sobre como manter as operações bem-sucedidas nesta era de DevSecOps. Para aqueles ainda presos em medidas de segurança tradicionais, o DevSecOps representa uma novidade bem-vinda. As soluções podem variar de acordo com a pilha de tecnologia e arquitetura usadas; não se trata de mandamentos únicos para todos criados por alguma organização centralizada.

No geral, a postura quanto à segurança aumenta a credibilidade no mercado e gera confiança nos consumidores. Levar essa ideia em consideração é ótimo para começar a discussão sobre como o DevSecOps se conecta ao paradigma continuous everything.

DevSecOps e continuous everything

Pode haver vulnerabilidades de segurança em bibliotecas de OSS (software de código aberto) que importamos tanto quanto no código que escrevemos. Muitos desenvolvedores estão programando todos os dias, e as revisões de código manuais não são dimensionadas. É aqui que está o verdadeiro poder do DevSecOps.

O DevSecOps e o continuous everything são como dois lados da mesma moeda. O DevSecOps trabalha ao lado do paradigma continuous everything e traz continuidade para a segurança dos produtos de software.

Os pipelines de entrega contínua são implementações do paradigma continuous everything e auxiliam na validação de cada commit que as equipes fazem. Integre verificações de segurança automatizadas ao pipeline para disponibilizar avisos com antecedência e monitorar vulnerabilidades de segurança que precisam ser evitadas. As abordagens integradas de segurança contínua têm escalabilidade de acordo com a expansão da empresa.

Os testes unitários e a análise de código estático operam mais próximos do código-fonte e executam verificações sem executar o código. É importante lembrar que o custo dos defeitos é baixo no teste, médio no staging e alto na produção. Faça o investimento em testes de unidade de segurança e analisadores estáticos, já que são baratos e rápidos e podem reduzir problemas mais adiante no pipeline.

Implementando a segurança contínua: testes unitários

Sua primeira implementação de segurança contínua deve ser em testes de unidade de segurança.

No pipeline de entrega contínua 101, a gente definiu os componentes como as menores unidades testáveis e distribuíveis. Eles podem ser validados por testes unitários. Os testes de unidade de segurança são tão importantes quanto os outros testes unitários escritos, mas algumas equipes ainda negligenciam essa categoria por completo.

SAST

Em conjunto com detecção de violações nas melhores práticas de codificação, os analisadores de código estático detectam vulnerabilidades de segurança em bibliotecas no código existente (com potencial de risco) e nas bibliotecas importadas. Isso é chamado SAST (teste de segurança de análise estática) e as ferramentas modernas se integram bem com o pipeline de entrega contínua. Escolha um scanner SAST compatível com a linguagem de programação usada.

Atenção: o SAST com frequência pode relatar falsos positivos e planejar alguma camada de persistência que auxilia os pipelines a “lembrar”. Os falsos positivos podem atrapalhar a equipe ao ponto de ela parar de responder a notificações de pipeline violado, o que é perigoso. Uma vez que as equipes conseguiram identificar o erro como falso positivo com a justificativa adequada, não deixe o pipeline continuar com a marcação do erro repetidas vezes. Isso pode levar as equipes a desabilitar o SAST ou permitir que os pipelines ignorem todos os erros do SAST.

DAST

Componentes fracamente acoplados compõem um subsistema. Subsistemas podem ser implementados e testados quanto a vulnerabilidades de segurança usando DAST (teste de segurança de análise dinâmica). Diferentemente de SAST, DAST examina um aplicativo de fora em seu estado de execução, de modo muito semelhante ao que um invasor faria. Scanners de DAST podem não ter uma dependência de linguagens específicas, uma vez que interagem com o aplicativo de fora.

O importante é incluir o SAST e o DAST na estratégia de segurança, já que cada um traz benefícios exclusivos. Integre ambas as abordagens com o pipeline de CD para ter feedback com antecedência.

DevSecOps é o futuro da segurança

No mundo atual, assim como a qualidade, a segurança é trabalho de todos. Não deixe sua visão ser limitada por um silo de supostos parceiros. Executivos e corporações reativas que já fizeram essa escolha enfrentaram consequências terríveis e agora estão renovando as estratégias de segurança com um novo orçamento.

Profissionais de segurança tradicionais operam no silo em que a capacidade é limitada pelo número de funcionários de segurança nesse silo. Em vez disso, adote a abordagem ágil descentralizada do DevSecOps e treine de novo as equipes para que tenham controle sobre os resultados. E também faça com que as equipes de desenvolvimento de produtos sejam responsáveis para que não haja tensão entre elas e o departamento de InfoSec.

Com a comunidade DevSecOps prosperando, a segurança não é apenas a prioridade de negócios, mas também é o melhor e mais recente elemento a integrar com o Pipeline de entrega contínua! A continuidade, armada com segurança, garante que os melhores dias da entrega de software estejam por vir.