Mesa-redonda Snyk e Intuit: rompendo silos e aproximando comunidades de segurança e desenvolvimento

Participei recentemente de uma mesa-redonda da Snyk com a Intuit. A conversa foi tão interessante que resolvi escrever este post para compartilhar algumas ideias e aprendizados — começando por esta ótima ilustração artística do encontro! Em resumo, estes foram meus principais aprendizados:

• Apresente as tarefas de segurança como uma forma de ajudar quem desenvolve a fazer seu trabalho, por exemplo, evitando retrabalho.

• Faça com que corrigir seja o caminho mais fácil para quem desenvolve, usando ferramentas que essas pessoas queiram usar.

• Não tente transformar todas as pessoas desenvolvedoras em especialistas em segurança. Foque em quem quer aprender mais.

• A participação em um programa de Security Champions deve ser voluntária. Recompensas, reconhecimento e benefícios são o que impulsiona o crescimento orgânico da comunidade.

• Meça as conquistas, não a ausência de violações.

• Compartilhe histórias de sucesso de equipes que fazem um bom trabalho para inspirar ainda mais conquistas.

Será que quem desenvolve realmente se importa com segurança?

A conversa começou com uma afirmação bombástica: quem desenvolve, em geral, não se importa com segurança. Muitas vezes, a segurança é vista como trabalho extra, sem o reconhecimento que alguém poderia receber, por exemplo, ao lançar um recurso. É claro que isso não significa que as pessoas desenvolvedoras não queiram fazer a coisa certa — na maioria das vezes, querem. Mas como podemos tornar a segurança mais atraente?

Outro fator que agrava a resistência de quem desenvolve à segurança é a terminologia usada. O uso de termos obscuros, como SCA, SAST, DAST e RASP — que a maioria das pessoas desenvolvedoras nunca ouviu falar — pode dificultar e confundir ainda mais as coisas. É importante explicar essas siglas de três e quatro letras, que fazem sentido para a equipe de segurança, de um jeito mais acessível para quem desenvolve.

Então, como podemos tornar a segurança mais atraente para quem desenvolve?

Estas foram algumas sugestões para melhorar a segurança no desenvolvimento:

• Apresente a segurança de um jeito que ajude quem desenvolve, por exemplo, evitando retrabalho.

• Faça com que corrigir seja o caminho mais fácil.

• Escolha ferramentas que as pessoas desenvolvedoras queiram usar.

Evite retrabalho

Uma sugestão bem recebida por quem estava à mesa foi apresentar a segurança de um jeito que faça sentido. Toda pessoa desenvolvedora detesta retrabalho. Quando a segurança ajuda a evitar retrabalho, deixamos de falar sobre segurança e passamos a falar sobre realizar certas atividades mais cedo para evitar muito retrabalho depois, ao corrigir problemas de segurança.

Faça da segurança o caminho mais fácil

É claro que prevenir problemas de segurança é muito importante. Além de serem caros de resolver, eles também são um ponto negativo no projeto que quem desenvolve não quer ver. Para evitar essa reação, é essencial oferecer políticas claras e visibilidade em um ciclo natural de feedback de segurança, facilitando para quem desenvolve evitar erros. Ofereça um caminho mais fácil que incentive a correção, em vez de evitá-la.

Ferramentas que colocam quem desenvolve em primeiro lugar

As ferramentas também influenciam a forma como quem desenvolve encontra e corrige problemas de segurança. Vlad Nikolov, da Intuit, destacou que incentiva as pessoas desenvolvedoras a escolherem suas próprias ferramentas de segurança. As pessoas querem sentir que contribuem e que têm autonomia. Vlad contou como a Snyk chegou à Intuit: a equipe de desenvolvimento apresentou a ferramenta à equipe de segurança porque queria usá-la.

Como podemos capacitar melhor quem desenvolve?

Estas são algumas ideias iniciais importantes que vale a pena reconhecer desde o começo:

• A segurança não faz parte do ensino de desenvolvimento de software nas escolas, o que já cria um obstáculo desde o início.

• Não tente transformar todas as pessoas desenvolvedoras em especialistas. Foque em quem quer aprender mais.

Educação em segurança

Para que a segurança faça parte do dia a dia de quem desenvolve, ela precisa ser uma extensão natural do processo e da compreensão sobre desenvolvimento de software. Observou-se que, durante a formação em faculdades e universidades, as pessoas desenvolvedoras muitas vezes nem chegam a conhecer o OWASP Top Ten ou os princípios de desenvolvimento e design seguros junto com o desenvolvimento de software. Para integrar de fato a segurança ao processo de desenvolvimento, ela precisa ser ensinada nas escolas junto com o desenvolvimento de software, para que profissionais de engenharia associem a programação segura ao desenvolvimento de software em geral.

As equipes precisam de conhecimento amplo em segurança, não de especialistas isolados

Mas não começamos esta mesa-redonda dizendo que quem desenvolve não se importa muito com segurança? Como garantir que as equipes de desenvolvimento tenham boa formação e conheçam as práticas de segurança, se o assunto nem sempre está entre suas prioridades e elas não têm vontade de aprender? O importante aqui é distinguir o nível de conhecimento em segurança que as equipes de desenvolvimento precisam ter. Quem desenvolve não precisa ser especialista em segurança, mas deve ter competências em algumas áreas, como modelagem de ameaças. Fazer perguntas do tipo “e se?” ajuda a pensar nos fluxos certos para reduzir os riscos de segurança.

Estimule a curiosidade com um programa de Security Champions

Para mim, os principais aprendizados sobre esse tema foram dois:

• Dedique tempo às pessoas desenvolvedoras naturalmente curiosas e que querem aprender mais sobre segurança.

• A participação em um programa de Security Champions deve ser voluntária. Recompensas, reconhecimento e benefícios são o que impulsiona o crescimento orgânico da comunidade.

Transforme curiosidade em conhecimento especializado

Precisamos reconhecer que há diferentes perfis de pessoas desenvolvedoras: aquelas que têm curiosidade sobre segurança, com quem queremos trabalhar de perto, e aquelas que cuidam da segurança por necessidade. Estas últimas farão apenas o mínimo necessário para concluir suas tarefas. Por isso, o que se espera delas deve ser simples, e o processo de segurança, descomplicado. Já quem tem curiosidade sobre segurança deve ser incentivado, aproveitando essa disposição para aprender, possivelmente por meio de um programa de Security Champions.

A participação de Security Champions deve ser voluntária

O grupo concordou que a participação em um programa de Security Champions deve ser voluntária. Para a equipe de segurança, esse tipo de programa é uma ótima maneira de reunir aliados da segurança em equipes de desenvolvimento distribuídas — pessoas que querem participar. Quando bem conduzido, o programa atrai participantes aos poucos, também de forma voluntária, à medida que percebem os benefícios, as recompensas e o reconhecimento oferecidos.

Celebre e recompense as conquistas

Celebrar o sucesso e recompensar quem contribuiu foi um tema importante, com o qual todos concordaram. Veja algumas ideias de como fazer isso:

• Meça as conquistas, não a ausência de violações.

• Compartilhe histórias de sucesso de equipes que fazem um bom trabalho para inspirar ainda mais conquistas.

• Vá além das métricas operacionais e celebre conquistas como a adoção de processos e práticas de segurança.

É justo dizer que a maioria das organizações mede a segurança de seus projetos pelo número de violações, e não pelas conquistas. Em grande parte, isso acontece porque é mais fácil acompanhar essa métrica de forma consistente entre diferentes equipes de desenvolvimento. No entanto, essa abordagem destaca o que há de errado nos projetos, em vez do que foi feito com sucesso. Há pouco a comemorar com as comunidades de desenvolvimento quando tudo funciona bem, além de haver menos problemas.

Em vez disso, o que realmente queremos destacar é quantas vezes uma pessoa desenvolvedora encontrou e corrigiu uma vulnerabilidade antes que ela se tornasse uma violação. Essa é uma medida concreta do sucesso de um programa de segurança, com um indicador-chave de desempenho (KPI) voltado a ações que melhoram a segurança. Além disso, essas iniciativas devem ser recompensadas e gamificadas para reconhecer o ótimo trabalho das pessoas e equipes que aprimoram sua postura de segurança e incentivar outras a fazer o mesmo.

É mais fácil falar do que fazer. Embora tenha sido reconfortante perceber que todos concordavam com essa ideia, foi mais difícil encontrar exemplos concretos de iniciativas assim em prática hoje. As pessoas à mesa apontaram alguns passos possíveis, incluindo mudar a linguagem para tornar a terminologia mais acessível a quem desenvolve. Também sugeriram oferecer mais incentivo e reconhecimento com histórias reais, além de dar visibilidade a quem está fazendo um ótimo trabalho ao corrigir vulnerabilidades — na expectativa de que outras pessoas sigam o exemplo e adotem uma postura mais voltada à segurança.

Uma conquista não precisa estar sempre ligada a uma métrica operacional. Por exemplo, pode estar relacionada à segurança no pipeline ou nos processos. Uma ideia mencionada foi criar um sistema de classificação que mostre a situação atual da postura de segurança sua e da sua equipe, além de um plano ou direcionamento para as mudanças e melhorias desejadas. Isso também registra o caminho percorrido pelas pessoas e equipes, incluindo todo o progresso alcançado.

Como medir a ausência de problemas de segurança?

É fácil complicar demais os KPIs e as métricas. Uma métrica importante é conseguir demonstrar a ausência de problemas de segurança. Para evitar retrabalho no desenvolvimento, precisamos entender o que foi feito para preveni-lo. Medir os hábitos de segurança é uma boa forma de saber como os problemas estão sendo detectados. Por exemplo, as próprias equipes identificam as ameaças à segurança, talvez com boas práticas de modelagem de ameaças?

Uma boa maneira de pensar no impacto de antecipar a segurança é começar pelo resultado. No fim das contas, queremos um ambiente de produção mais seguro, com menos riscos e vulnerabilidades. Se implementarmos processos e hábitos no início do ciclo, veremos as métricas e os números caírem no final. Isso mostrará o impacto e o sucesso das atividades adotadas no começo. Portanto, analise suas métricas de segurança, implemente práticas de segurança desde o início (com foco em quem desenvolve) e avalie as métricas novamente. Descubra onde estaremos em seguida em https://snyk.io/events/. Para receber convites para as próximas mesas-redondas interativas, entre em contato com seu representante da Snyk para saber mais!