Skip to main content

Como a Mulesoft promove uma cultura centrada nos desenvolvedores e de segurança antecipada com a Snyk

Escrito por
Headshot of Gerald Crescione

Gerald Crescione

feature snyk appsec blue

30 de abril de 2024

0 minutos de leitura

Embora antecipar a segurança no desenvolvimento seja um tema em alta há cerca de uma década, muitas organizações ainda enfrentam dificuldades para transformar essa ideia em realidade. Há muitos equívocos sobre o que significa antecipar a segurança e como as equipes de desenvolvimento podem assumir a responsabilidade por ela sem prejudicar os fluxos de trabalho existentes. Por exemplo, muitas equipes encaminham problemas de segurança aos desenvolvedores mais cedo no ciclo de vida de desenvolvimento de software (SDLC), mas sem fornecer o contexto ou as ferramentas necessárias para que eles resolvam esses problemas de forma prática.

A equipe da Mulesoft queria fazer algo diferente de simplesmente despejar alertas de segurança nos desenvolvedores. Acreditava que o verdadeiro sucesso em DevSecOps começa com a priorização da experiência do desenvolvedor. Mas, para transformar esses objetivos em realidade, a Mulesoft precisava iniciar uma jornada com as soluções e os processos certos.

Em uma conversa recente, Clinton Herget, Field CTO da Snyk, e Martin Adolfi, gerente sênior de engenharia da Mulesoft, falaram sobre a jornada da Mulesoft em DevSecOps. Eles exploraram o verdadeiro significado de segurança para desenvolvedores em organizações que precisam acompanhar o ritmo acelerado de hoje e abordaram os desafios e as conquistas da Mulesoft na busca por antecipar a segurança.

O desafio da Mulesoft para antecipar a segurança

Quando Adolfi e sua equipe começaram a se aprofundar nas iniciativas de DevSecOps, tinham uma visão clara sobre antecipar a segurança — e sobre o que isso não significava. A equipe percebeu uma desconexão entre as expectativas da área de segurança e a perspectiva típica dos desenvolvedores. Adolfi descreveu a situação como “jogar os problemas para a esquerda”, em vez de antecipar a segurança: enviar alertas e relatórios aos desenvolvedores sem contexto ou orientação suficientes e, depois, esperar que eles resolvessem os problemas. Essa abordagem acaba consumindo o tempo e a capacidade mental dos desenvolvedores, obrigando-os a mudar de contexto e interrompendo seu estado de concentração e produtividade. Isso os afasta do que gostam de fazer — programar e inovar —, reduz a satisfação no trabalho e cria tensão entre as equipes de desenvolvimento e segurança.

Para incentivar os desenvolvedores a ter sucesso em segurança e, em última análise, se tornarem referências em segurança, é preciso oferecer a eles um caminho simples de seguir. Segundo Adolfi, o segredo é capacitar os desenvolvedores para corrigir problemas dentro dos ciclos de feedback que já fazem parte do trabalho. Ele disse: “Se o problema chega a um chamado, já é tarde demais… você quer criar ferramentas que façam parte do ciclo de trabalho do desenvolvedor, em vez de dizer: ‘Temos um novo painel ou relatório, e você precisa consultar essa ferramenta para encontrar as informações de que precisa’… [Como desenvolvedor], sou constantemente interrompido enquanto tento fazer o que quero e o que me interessa. Preciso consultar sete fontes de dados diferentes para fazer meu trabalho.”

A equipe sabia que queria integrar os ciclos de feedback de segurança aos fluxos de trabalho já usados pelos desenvolvedores, mas precisava superar alguns desafios para isso.

Primeiro, precisava responder ao feedback dos desenvolvedores de que havia “burocracia demais” no processo de segurança de aplicações. As equipes de desenvolvimento da Mulesoft sentiam a pressão de manter os projetos existentes com aplicações regulares de patches e, ao mesmo tempo, cumprir os requisitos de conformidade e os SLAs das novas aplicações. Precisavam de uma abordagem de segurança que não aumentasse essa burocracia.

Além disso, os pipelines das equipes de desenvolvimento eram muito diferentes entre si, mas os desenvolvedores valorizavam essa liberdade e não queriam abrir mão dela. Essa variedade de linguagens, frameworks e microsserviços dificultava a implementação de um processo de segurança consistente em toda a organização.

As conquistas da Mulesoft em DevSecOps

Para superar esses desafios, a Mulesoft precisava de um parceiro de segurança que priorizasse os desenvolvedores. A equipe escolheu a plataforma da Snyk por sua forte sintonia com os objetivos de DevSecOps da empresa.

Adolfi disse: “A Snyk está alinhada à nossa visão de antecipar a segurança, gerar mais valor e oferecer insights, além de mostrar aos desenvolvedores como corrigir os problemas, reunindo todas as informações necessárias para entender o impacto e a criticidade — tudo isso.”

Como a Snyk se integra aos diferentes ambientes nativos dos desenvolvedores e oferece feedback imediato e sugestões de correção, Adolfi e sua equipe conseguiram simplificar o processo de identificação e correção de vulnerabilidades para os desenvolvedores da Mulesoft.

Adolfi disse: “O principal motivo para a equipe de experiência do desenvolvedor ter se concentrado na Snyk, e não no restante da nossa pilha tecnológica, é que a Snyk está mais próxima do desenvolvedor.”

Snyk + Mulesoft: próximos passos

À medida que a equipe da Mulesoft continua protegendo o SDLC com uma mentalidade DevSecOps, seguirá adotando o princípio de antecipar a segurança por meio da capacitação dos desenvolvedores. Isso significa oferecer às equipes de desenvolvimento as ferramentas e os processos necessários para corrigir vulnerabilidades com sucesso e em tempo real, evitando ao máximo as mudanças de contexto.

Na próxima etapa de sua jornada de desenvolvimento, a equipe da Mulesoft planeja incorporar mais ferramentas de IA aos pipelines. Ela vê oportunidades de usar IA tanto para escrever quanto para revisar código.

Para saber mais sobre a jornada da Mulesoft em segurança para desenvolvedores e suas conquistas em DevSecOps, ouça a conversa completa de Adolfi e Herget.

How Mulesoft Achieved Developer Security at Scale