Este ano, a pesquisa anual de profissionais de DevSecOps do GitLab revelou vários problemas relacionados à cultura organizacional que podem estar impedindo um alinhamento mais profundo entre as equipes de engenharia e segurança. A maioria (58%) dos entrevistados do setor de segurança disse que tem dificuldade em fazer a equipe de desenvolvimento priorizar a correção de vulnerabilidades, e 52% relataram que a burocracia muitas vezes retarda seus esforços para corrigir vulnerabilidades rapidamente. Além disso, os entrevistados do setor de segurança apontaram várias frustrações específicas relacionadas ao seu trabalho, incluindo dificuldade em entender as descobertas de segurança, excesso de falsos positivos e testes que acontecem no final do processo de desenvolvimento de software.
O DevSecOps promete uma melhor integração entre engenharia e segurança, mas é claro que as frustrações e as diferenças persistem. Essa questão é um sintoma de um problema maior relacionado com a forma como as empresas percebem a segurança, como as equipes colaboram e quanto tempo dedicam a ela.
Saindo do ciclo vicioso das vulnerabilidades
A análise de vulnerabilidades identifica todas as possíveis falhas. No entanto, o fato de um pacote de software ter uma vulnerabilidade ou exposição comum (CVE) não significa que ela seja acessível ou explorável. Equipes de segurança e desenvolvedores ainda estão filtrando e analisando vulnerabilidades, que cresceram exponencialmente ao longo dos anos, desde que a análise autenticada de vulnerabilidades se tornou padrão.
A transição para a análise autenticada melhorou a eficácia dos programas de segurança de várias maneiras, mas também colocou os desenvolvedores em um ciclo interminável de consertar elementos irrelevantes. Quando as equipes desperdiçam esforços em correções que não resolvem uma vulnerabilidade explorável, elas deixam de fazer tarefas mais críticas, como corrigir falhas vulneráveis e exploráveis. Essa é a origem de grande parte da divisão entre as equipes de segurança e engenharia hoje.
Então, como as empresas podem abordar a causa raiz desses problemas e promover uma melhor integração entre engenharia e segurança? Aqui estão três maneiras de evitar frustrações comuns de segurança desde o princípio.
1. Reduza o ruído e foque em sinais de alta precisão e ação prática
O excesso de falsos positivos foi a segunda maior frustração apontada pelos profissionais de segurança na nossa pesquisa. Falsos positivos são claramente um desafio, mas muitas vezes são um problema de gerenciamento de vulnerabilidades disfarçado.
Se uma empresa obtiver muitos falsos positivos, isso pode ser um sinal de que ainda não fizeram tudo o que poderiam para garantir que suas descobertas de segurança sejam de alta precisão. As empresas devem concentrar seus esforços de segurança no que realmente importa. Isso significa que as soluções tradicionais de Teste Estático de Segurança de Aplicações (SAST) provavelmente são insuficientes. O SAST é uma ferramenta poderosa, mas perde muito do seu valor se os resultados não forem gerenciáveis ou não tiverem o contexto apropriado. Para que o SAST seja mais eficaz, ele deve ser usado de forma integrada com outras ferramentas de segurança e desenvolvimento e estar acessível aos desenvolvedores.
Outro problema é que a maioria das ferramentas de análise tem uma visão muito limitada do contexto ao interpretar as descobertas de vulnerabilidades. Esta é uma das áreas em que a IA pode ajudar usando recursos com tecnologia de IA que explicam vulnerabilidades de segurança.
2. Minimize a pilha de tecnologia, minimize a superfície de ataque
Manter o foco no que é importante não se aplica apenas aos testes de segurança: deve começar com a forma como uma empresa cria software.
Embora a IA prometa ajudar a simplificar os processos de desenvolvimento de software, nossa pesquisa sugere que muitas empresas ainda têm um longo caminho pela frente. Na verdade, os participantes que usam IA demonstraram uma probabilidade significativamente maior, em comparação com aqueles que não usam IA, de querer consolidar sua cadeia de ferramentas. Isso sugere que a proliferação de diferentes soluções pontuais com modelos de IA distintos pode estar aumentando a complexidade, em vez de reduzi-la.
A complexidade cada vez maior das pilhas de tecnologia das empresas é um dos principais fatores que contribuem para os problemas de segurança. Algum nível de complexidade é inevitável ao construir sistemas de software grandes e multifacetados. No entanto, as empresas devem tomar medidas para evitar a complexidade causada por decisões de design inadequadas, como código difícil de manter e dependências redundantes. Essa complexidade desnecessária aumenta a superfície de ataque e gera mais resultados nas análises de segurança, exigindo que as equipes os classifiquem, priorizem e resolvam.
As empresas devem abordar o desenvolvimento com a perspectiva de minimização de software, ou seja, sendo intencionais em relação às ferramentas que adotam e ao que decidem incluir em seus codebases. Isso ajudará a minimizar as dependências, melhorar a segurança da cadeia de suprimentos de software, reduzir o ruído das análises e diminuir o trabalho dos desenvolvedores na correção de problemas não críticos.
3. Normalize os caminhos otimizados
A realização tardia de testes de segurança no ciclo de vida do desenvolvimento de software foi outra das principais frustrações apontadas pelos participantes da nossa pesquisa. As equipes podem se sentir frustradas quando querem lançar algo e o processo é atrasado porque uma vulnerabilidade foi detectada tardiamente. Porém, em muitos casos, pode não ter sido possível detectar essa vulnerabilidade antes. O que é possível, no entanto, é operacionalizar componentes de segurança facilmente implantáveis e reutilizáveis, limitando as variáveis e possíveis vulnerabilidades.
As equipes podem evitar surpresas em estágios mais avançados adotando padrões de design testados e comprovados com base em casos de uso replicáveis: a abordagem de "caminhos otimizados". Um caminho otimizado é uma rota recomendada, que inclui um conjunto de ferramentas, processos e componentes selecionados que as equipes podem seguir para construir aplicações seguras de forma mais eficiente. Por exemplo, usando GitOps para versionar e implantar uma Infraestrutura como Código bem arquitetada e testada, dimensionável para todas as cargas de trabalho.
A adoção de caminhos otimizados pode remover um pouco da flexibilidade, mas, em última análise, reduz o trabalho operacional e o retrabalho das equipes de engenharia e aumenta a segurança. Isso precisa ser um esforço colaborativo entre segurança e desenvolvimento. A segurança pode ajudar a projetar caminhos otimizados, mas a engenharia precisa estar envolvida para operá-los e mantê-los como parte do codebase.
A segurança é um domínio, não uma equipe
Já estamos observando a segurança como uma prática sendo incorporada nas equipes de engenharia, e podemos esperar que os limites entre as duas continuem a se tornar mais indefinidos. No entanto, com a rápida adoção da IA e a aceleração correspondente no desenvolvimento de software, 66% dos participantes da nossa pesquisa afirmaram que estão lançando software duas vezes mais rápido ou até mais do que no ano passado. Será fundamental que as empresas estabeleçam sistemas e estruturas que otimizem o máximo benefício em termos de segurança. É por isso que resolver a desconexão cultural entre desenvolvimento e segurança não resolve todo o problema. Promover uma cultura de colaboração é essencial, mas as equipes de segurança e engenharia também devem trabalhar juntas para repensar os aspectos fundamentais do desenvolvimento de software, como otimizar as bases de código atuais e criar soluções focadas na engenharia que possam ser dimensionadas e adotadas de forma transparente por equipes técnicas de toda a empresa.
Segurança de aplicações na era digital
Leia as descobertas da nossa pesquisa com mais de 5.000 profissionais de DevSecOps em todo o mundo para saber mais sobre como as empresas estão lidando com o aumento das superfícies de ataque e a mudança de atitude em relação à segurança e à IA.