7 obstáculos surpreendentes no caminho para a maturidade em DevSecOps

Como parte da elaboração e do lançamento recente do DevSecOps Maturity Framework, a Snyk realizou uma ampla pesquisa de mercado sobre o cenário atual da segurança de desenvolvedores em empresas focadas em software. Mais de 300 organizações forneceram dados para nos ajudar a entender como avaliam a própria maturidade em DevOps, segurança de aplicações, gerenciamento de vulnerabilidades, priorização, adoção pelos desenvolvedores e governança de programas.

De modo geral, nossas descobertas mostram que a maioria das empresas entende o valor de práticas maduras de DevSecOps e trabalha ativamente para desenvolver uma cultura de segurança moderna e um programa de segurança de aplicações voltado à melhoria contínua. No entanto, nem todas seguem a mesma abordagem. Na verdade, dentro do objetivo amplo de aumentar a maturidade, vimos bastante diversidade na forma como as organizações descreveram aspectos essenciais de suas práticas de segurança, o que indica lacunas significativas na busca por um objetivo comum: a maturidade em DevSecOps. Vamos conferir algumas descobertas que apontam possíveis áreas de melhoria.

Redução de riscos e fadiga de segurança estão entre os KPIs que as equipes de segurança menos medem, mas também estão entre os cinco principais indicadores que gostariam de acompanhar.

Entre todas as métricas de segurança monitoradas pelas equipes que pesquisamos, as duas menos medidas foram “Redução de riscos decorrente das ações dos desenvolvedores” e “Redução da fadiga de segurança (tempo gasto com triagem manual, builds interrompidos e retrabalho de segurança)”. Ainda assim, esses dois KPIs também ficaram entre os primeiros da lista quando perguntamos aos mesmos participantes quais métricas eles idealmente gostariam de apresentar se todos os dados relevantes estivessem disponíveis.

É evidente que ainda existe uma grande desconexão entre os dados que as ferramentas de segurança conseguem apresentar facilmente — como o número de vulnerabilidades encontradas e corrigidas, as pontuações CVSS, o tempo para correção etc. — e as perguntas que os profissionais de segurança querem responder, como “Quanto risco está sendo reduzido por determinado tipo de ação?”, que definem a eficácia e o ROI de seus programas. Isso destaca a importância de agregar e correlacionar dados de vulnerabilidades de várias fontes para eliminar silos e entender os riscos de forma holística, considerando todo o contexto das aplicações, dos negócios e das vulnerabilidades. Ferramentas de gerenciamento da postura de segurança de aplicações (ASPM), como o Snyk AppRisk, podem ajudar atuando como um hub interno e uma fonte única de informações confiáveis para insights de segurança baseados em risco.

Entre todos os perfis incluídos no estudo, os desenvolvedores de software foram os mais interessados em medir a fadiga de segurança, também conhecida como trabalho operacional repetitivo. Essa categoria abrangente busca medir o custo de deslocar a segurança para o início do ciclo de desenvolvimento em termos de perda de produtividade dos desenvolvedores, que precisam dedicar tempo a tarefas de segurança difíceis de automatizar. Como a maioria das ferramentas de verificação de vulnerabilidades é desenvolvida para profissionais de segurança, muitas vezes elas não levam em conta o impacto sobre os desenvolvedores, o que impossibilita entender o grau de ineficiência nos processos de detecção e correção integrados ao SDLC. Essa dificuldade para medir o trabalho operacional de segurança é parcialmente responsável pelos altos níveis de atrito entre as equipes de desenvolvimento e segurança, que continuamos observando até mesmo em organizações com alto grau de maturidade em DevSecOps.

Medir com precisão a postura de segurança com base nos riscos é o principal objetivo de DevSecOps para as equipes de segurança e engenharia.

É um mito persistente na segurança de aplicações que os desenvolvedores não se importam com os riscos do software. A realidade fica clara mais uma vez: a principal prioridade de DevSecOps para os desenvolvedores era entender com precisão a postura de segurança baseada em riscos — o mesmo objetivo apontado por seus colegas de segurança de aplicações (as equipes de engenharia de plataforma o classificaram em segundo lugar). Em outras palavras, os desenvolvedores querem contribuir para reduzir os riscos da organização, mas sentem que não têm os dados necessários para tomar decisões melhores de priorização.

Essa discrepância tem origem na complexidade de calcular os riscos das aplicações, o que exige contexto adicional (impacto nos negócios, acessibilidade, maturidade dos exploits e presença de controles compensatórios, entre outros fatores) além de uma simples contagem de problemas e suas respectivas gravidades. O software moderno é muito complexo, e os orçamentos para correções são sempre limitados. Por isso, o tempo para corrigir não deve ser alocado apenas com base nas vulnerabilidades de maior gravidade — que podem ou não ser realmente exploráveis e, mesmo que sejam, podem ou não causar um impacto significativo nos negócios —, mas sim em um sistema de pontuação personalizado e baseado em riscos, que considere várias fontes de contexto ao longo do SDLC.

A incapacidade de chegar a um consenso sobre um modelo de priorização baseado em riscos é uma das principais causas de atrito entre equipes de engenharia e segurança e pode levar ao fracasso das iniciativas de DevSecOps devido à falta persistente de confiança. Os desenvolvedores muitas vezes se sentem obrigados a dedicar tempo à correção dos problemas “errados” (ou seja, de menor risco). Já os profissionais de segurança sentem que muitos riscos reais chegam à produção porque não existe um mecanismo compartilhado e confiável de pontuação de riscos, acessível nos fluxos de trabalho de ambos os grupos. Por isso, fica claro que medir os riscos com precisão é a principal prioridade de ambos, mas a maioria das ferramentas de segurança ainda está evoluindo para atender a essa necessidade.

Apenas 50% das organizações afirmam investir em treinamentos de segurança para desenvolvedores no momento certo e em programas de Security Champions nas equipes de desenvolvimento.

A educação em segurança, especialmente para desenvolvedores de software, é um componente essencial de uma prática madura de DevSecOps. Para ser eficaz, ela precisa ser relevante, prática, contínua e estar totalmente integrada aos processos e às formas de trabalho das equipes. No entanto, a maioria dos treinamentos tradicionais de segurança não atende a esses objetivos, criando uma lacuna recorrente no entendimento dos desenvolvedores sobre os riscos de segurança de aplicações e as práticas de programação segura relacionadas.

Essa lacuna tem origem na forma de aprendizado preferida pelos engenheiros, baseada na resolução de problemas do mundo real. A enorme complexidade das técnicas modernas de desenvolvimento de software dificulta ensinar tudo o que um engenheiro precisa saber usando métodos tradicionais e hierárquicos. Em vez disso, os desenvolvedores aprendem na prática: encontram um problema e precisam solucioná-lo antes de seguir em frente. Esse tipo de aprendizado “no momento certo” comprovadamente gera resultados mais duradouros. Ainda assim, a maioria dos programas de treinamento em segurança adota a abordagem oposta, que é ineficaz. Investir em educação em segurança no momento certo — que permita ao desenvolvedor fazer uma microlesson para entender os riscos de uma vulnerabilidade específica e aprender a corrigi-la, por exemplo, ao resolver um problema encontrado no próprio código —, como o Snyk Learn, comprovadamente melhora os resultados de segurança. No entanto, apenas cerca da metade das organizações que estudamos usa essa abordagem.

Além disso, pesquisas têm demonstrado consistentemente a eficácia dos programas de Security Champions, que levam o conhecimento de segurança diretamente para as equipes de engenharia de software. Isso é feito preparando um desenvolvedor de cada equipe com treinamento aprofundado e direcionado, além de recursos para atuar como elo entre os colegas de desenvolvimento e a equipe de segurança de aplicações. Como os engenheiros preferem aprender com outros engenheiros e os colegas conseguem traduzir os requisitos de segurança de forma mais eficaz para o dia a dia da equipe, os Security Champions ajudam a reduzir o atrito com a equipe de segurança de aplicações e a melhorar os resultados. As organizações que ainda não implementaram um programa de Security Champions — metade do total — podem continuar enfrentando dificuldades em suas iniciativas de segurança para desenvolvedores sem esse componente cultural essencial.

Menos da metade (46%) das organizações afirma conseguir identificar com precisão suas aplicações essenciais para os negócios.

Em geral, o risco é calculado multiplicando-se a probabilidade pelo impacto. Embora as ferramentas de verificação de vulnerabilidades consigam medir a probabilidade de exploração com mais ou menos precisão — especialmente quando consideram contexto adicional, como acessibilidade e maturidade do exploit —, por definição, somente a empresa pode avaliar o impacto. Uma ferramenta de segurança não consegue distinguir entre um problema de alta gravidade em uma aplicação essencial para os negócios e a mesma vulnerabilidade em um serviço sem uso que dá suporte a um antigo site promocional. No entanto, os riscos associados a esses dois problemas são completamente diferentes.

Para alcançar a maturidade em DevSecOps, as organizações precisam entender o impacto nos negócios de seus ativos de software e incorporar essas avaliações à pontuação de riscos usada na priorização de problemas. Ferramentas como os bancos de dados de gerenciamento de configuração (CMDBs) são frequentemente usados para manter um inventário atualizado de repositórios de código, imagens de contêineres, implantações e outros artefatos. Eles também podem servir como fonte confiável para a pontuação de criticidade para os negócios, que pode então ser incorporada por plataformas de orquestração de segurança — especialmente soluções ASPM, como o Snyk AppRisk — e integrada a algoritmos de priorização baseada em riscos.

A maioria das organizações pesquisadas que têm dificuldade para identificar seus softwares essenciais para os negócios enfrenta dois problemas: pode estar permitindo que riscos demais cheguem à produção em aplicações de importância estratégica, o que causaria um impacto substancial nos negócios caso fossem exploradas. Além disso, essas organizações também têm processos de correção ineficientes em geral, pois não conseguem despriorizar com facilidade as correções de aplicações com pontuação de impacto muito baixa. Para alcançar a maturidade em DevSecOps, são necessárias ferramentas e processos que considerem o impacto nos negócios como um elemento fundamental em qualquer cálculo de risco.

Apenas 31% das organizações aplicam automaticamente requisitos de segurança em várias etapas do SDLC antes da produção.

Nossa pesquisa constatou que a maioria das organizações tem perfis de risco de software totalmente documentados e aplicáveis automaticamente. No entanto, para o maior grupo (40%), essa aplicação acontece somente no ambiente de produção/runtime. Um número comparativamente menor de organizações toma a iniciativa de aplicar políticas em vários pontos do SDLC, em ambientes de pré-produção. O mais importante é que isso significa que, mesmo em culturas maduras de DevSecOps, a maioria dos benefícios de corrigir problemas de segurança com rapidez e antecedência não está sendo aproveitada.

Há muito tempo, é um princípio conhecido em segurança que o custo de corrigir problemas aumenta à medida que o software avança no ciclo de desenvolvimento. Se apenas um subconjunto das políticas de segurança for implementado antes da produção (ou seja, em pipelines de CI/CD, verificações de PR ou ambientes de staging), a maioria dos problemas acabará exigindo o processo de correção mais caro possível.

Há um equilíbrio entre o custo da correção e a precisão da detecção. Identificar problemas mais cedo no SDLC torna a correção mais rápida e eficiente, pois os ciclos de feedback para os fluxos de trabalho dos desenvolvedores são mais curtos. No entanto, à medida que o software se aproxima da produção — quando é compilado, empacotado e implantado em ambientes de teste cada vez mais parecidos com os de produção —, fica mais fácil entender os riscos e as verificações de segurança se tornam mais precisas. Não existe um lugar “certo” para implementar testes de segurança em um SDLC orientado a DevSecOps. Em vez disso, o melhor equilíbrio entre precisão e eficiência é obtido com vários pontos de verificação de segurança leves, que aplicam políticas em cada etapa com base nas alterações feitas no software. As organizações que aplicam segurança em apenas uma etapa precisam abrir mão da precisão ou da eficiência das correções, o que acaba limitando seu avanço rumo à maturidade em DevSecOps.

Apenas 25% afirmam que os alertas de segurança são enviados somente às partes interessadas relevantes e incluem todo o contexto necessário para agir.

A fadiga de alertas é uma das principais causas de atrito na segurança. Um excesso de alertas ou notificações — especialmente quando parecem irrelevantes ou exigem esforço extra para serem interpretados — acaba sendo facilmente ignorado. Com o tempo, isso pode levar à perda de confiança na ferramenta de segurança que gera tanto ruído, mesmo que os alertas futuros sejam mais direcionados. Por isso, evitar a fadiga de alertas é essencial para amadurecer as práticas de DevSecOps.

Três quartos das organizações recebem notificações que não conseguem transformar em ações. Muitas vezes, elas não trazem o contexto necessário, não chegam às pessoas certas ou não incluem etapas claras e confiáveis para resolver o problema. Esse caos de alertas pode ser um efeito colateral de várias ferramentas de segurança isoladas, disputando a atenção dos mesmos stakeholders e reduzindo a disponibilidade para notificações que realmente exigem ação.

Resposta e correção é um dos seis pilares do Snyk DevSecOps Maturity Framework. No entanto, qualquer estratégia de resposta repetível precisa começar com um fluxo de alertas capaz de iniciar, com rapidez e confiabilidade, uma ação decisiva pelas pessoas certas. Organizações que não conseguem resolver o problema da fadiga de alertas logo percebem os limites da sua capacidade de implementar ciclos de correção confiáveis, que melhoram com o tempo.

Apenas 37% descrevem seu programa de DevSecOps como “transparente e self-service do ponto de vista dos engenheiros, facilitando a segurança e dificultando a introdução de riscos no software”. 

Talvez a maior desconexão no caminho para a maturidade em DevSecOps esteja na compreensão da experiência dos desenvolvedores. Inicialmente, a proposta do DevOps (antes do “Sec”) era facilitar a vida dos desenvolvedores, oferecendo ferramentas para que eles pudessem realizar tarefas que exigiam a ajuda de equipes centrais de TI. Empacotar software, implantar aplicações ou configurar a infraestrutura, por exemplo, passou a ser algo que os próprios desenvolvedores podiam fazer, simplesmente escrevendo código. Essa mudança para o self-service por meio de processos automatizados e repetíveis se tornou um pilar do desenvolvimento de software moderno e trouxe grandes avanços no tempo de lançamento no mercado.

No entanto, quando o assunto é segurança, o progresso não acompanhou esse ritmo. A ideia de “DevSecOps” existe há mais de uma década, mas muitas vezes ainda depende de ferramentas e processos legados de AppSec que não se alinham às práticas modernas de desenvolvimento de software. Essa incompatibilidade prejudica a experiência dos desenvolvedores. Embora engenheiros consigam gerenciar facilmente seus próprios contêineres, testes automatizados e serviços de nuvem, muitas vezes precisam esperar por análises de segurança executadas à parte, o que encarece as correções e gera tensão constante com as equipes de AppSec.

Essa falta de transparência e de self-service dificulta que os desenvolvedores gerenciem os riscos do software de forma eficaz. Em vez de prevenir problemas desde o início, eles muitas vezes precisam adivinhar qual é a opção segura e corrigir as falhas depois, quando a correção é mais cara. Em outras palavras, é fácil introduzir riscos e difícil manter a segurança. Um DevSecOps de verdade precisa romper esse ciclo e adotar princípios de “segurança desde a concepção”, criando caminhos seguros para que os desenvolvedores gerenciem riscos por conta própria e confiem que a opção padrão também é a mais segura.

O DevSecOps evoluiu muito desde que surgiu. Nossa pesquisa mostra que a maioria das organizações está avançando rumo à maturidade, mas ainda há muito a ganhar para concretizar a promessa de práticas de segurança confiáveis, automatizadas e centradas nos desenvolvedores.

Quer levar seu programa de DevSecOps adiante? Baixe o e-book hoje mesmo.