Como a Snyk está priorizando a experiência do desenvolvedor

A alternância de contexto pode ser o pior inimigo da segurança. As práticas de segurança atuais dependem do engajamento dos desenvolvedores. Quando as equipes de segurança exigem que eles abandonem os fluxos de trabalho habituais para resolver problemas, a chance de adoção cai bastante.

Para realmente capacitar os desenvolvedores a encontrar e corrigir vulnerabilidades no código, as equipes de segurança precisam levar a segurança ainda mais para a esquerda. Não basta oferecer ferramentas fáceis de usar e treinamentos sobre elas. Se a ferramenta ainda exige que os desenvolvedores interrompam o fluxo de trabalho para realizar tarefas relacionadas à segurança, ela aumenta a carga cognitiva. Muitas vezes, os desenvolvedores não têm tempo nem recursos para incluir mais uma tarefa em uma agenda que já está cheia.

Para enfrentar esses desafios, a Snyk está lançando novos recursos que aprimoram nossas soluções que priorizam os desenvolvedores e ajudam as equipes de segurança a se adaptar às novas realidades dos ciclos de desenvolvimento atuais. Recentemente, demos aos usuários uma prévia desses recursos no SnykLaunch mais recente, já disponível sob demanda. Nesta publicação, vamos conhecer os novos lançamentos que melhoram diretamente a experiência do desenvolvedor e entender por que eles são importantes para as equipes de hoje.

O custo da alternância de contexto

Os desenvolvedores passam boa parte do tempo em três lugares: IDEs, CLI e SCM. Pode parecer simples receber um alerta de segurança sobre o projeto em andamento e acessar outra plataforma para resolver o problema, mas, na prática, nem sempre é. Essa mudança de contexto tira os desenvolvedores dos fluxos de trabalho que conhecem, acrescenta etapas ao desenvolvimento de software e interrompe o ritmo de produtividade. Além disso, obriga a alternar entre vários sistemas para realizar tarefas relacionadas à segurança.

A maior parte do código é escrita no IDE, seja à mão, criada por IA generativa ou uma combinação das duas. Os desenvolvedores criam branches ou forks do código e enviam as alterações gradualmente para o SCM. Quando tudo está pronto, abrem um "pull request" (PR). O pull request foi criado para facilitar a colaboração e a revisão de código. Interromper esse processo e obrigar os desenvolvedores a sair do fluxo de trabalho do SCM para resolver problemas de segurança acrescenta uma tarefa inesperada, quebra o ritmo e acaba com a eficiência do fluxo de PR. É como descobrir que adicionaram uma tarefa à sua lista justamente quando você achava que estava quase tudo pronto.

Essa desconexão entre as equipes de desenvolvimento e segurança prejudica os esforços de DevSecOps. As equipes de segurança muitas vezes se perguntam por que mais desenvolvedores não adotam suas ferramentas, enquanto os desenvolvedores podem resistir às interrupções no fluxo de trabalho causadas por tarefas inesperadas. No fim, todo mundo sai perdendo.

Dois pilares da experiência do desenvolvedor

Em vez de pedir que os desenvolvedores interrompam o que estão fazendo para resolver problemas de segurança, as equipes de segurança precisam encontrá-los nas ferramentas que já usam. Duas ideias fundamentais podem ajudar:

1. Capacitar os desenvolvedores com informações no contexto em que estão trabalhando

Para corrigir problemas de segurança no código, os desenvolvedores precisam de algumas informações básicas. Elas podem explicar por que determinada linha foi sinalizada como vulnerável e como alterá-la para eliminar a vulnerabilidade. No entanto, as equipes de segurança não podem esperar que os desenvolvedores consultem documentação genérica ou façam tutoriais em uma plataforma de segurança para resolver o problema. É preciso oferecer recursos educativos objetivos, com um breve contexto e orientações para a correção — nada além, nada aquém.

2. Reduzir o atrito e minimizar as interrupções nos fluxos de trabalho

A Snyk já ajuda os desenvolvedores a encontrar e corrigir vulnerabilidades de segurança diretamente nos seus IDEs. Como eles também passam bastante tempo trabalhando no SCM, a Snyk está expandindo ainda mais suas ferramentas voltadas aos desenvolvedores e integrando insights de segurança aos fluxos de PR no SCM. Assim, eles recebem feedback de segurança sem interrupções, nas ferramentas que já fazem parte do dia a dia.

Novos recursos de PR da Snyk para melhorar a experiência do desenvolvedor

Com base na experiência de trabalhar diretamente com equipes de desenvolvimento e ajudar os desenvolvedores a integrar a segurança aos IDEs, vimos que o melhor lugar para incluir a segurança é nas ferramentas que eles já usam. Agora, quando um desenvolvedor clica no botão "create PR", os PR checks da Snyk (disponíveis em geral para o Snyk Open Source e em acesso antecipado para o Snyk Code) podem realizar uma revisão de segurança do código diretamente nos fluxos de PR padrão.

Quando a verificação do PR termina, o novo recurso "resumo de problemas" publica um comentário no SCM com uma síntese dos problemas de segurança encontrados, diretamente no fluxo de PR dos desenvolvedores. Os resultados são organizados por gravidade e incluem links diretos para consultar e resolver cada problema.

Além disso, agora oferecemos modelos de PR personalizáveis, que permitem às equipes personalizar os PRs gerados pela Snyk. Os novos modelos personalizáveis de PR da Snyk alinham os pull requests gerados pela plataforma aos padrões, práticas e preferências de comunicação específicos da sua organização. Você pode definir o título e a descrição, escolher quais detalhes de segurança compartilhar e até incluir informações de tickets do JIRA, tudo de acordo com o que os desenvolvedores esperam encontrar nos PRs. Ao adaptar nossos recursos às necessidades da sua organização, você integra o fluxo de trabalho aos processos existentes dos desenvolvedores com ainda mais facilidade.

Para saber mais sobre esses novos recursos de pull request, assista à apresentação mais recente do SnykLaunch.