Sucesso de um programa DevSecOps

Aprimorar o desenvolvimento seguro é uma jornada que leva tempo e começa com a visibilidade dos processos e práticas de segurança que cada equipe adota atualmente. Se isso não for feito com empatia, o processo pode ser visto como uma reação às falhas de desenvolvimento. Quando as pessoas sentem que estão sendo culpadas ou julgadas, é fácil que reajam na defensiva. Uma ótima maneira de evitar isso é pedir à pessoa responsável pela iniciativa que preencha uma avaliação dos processos e práticas da equipe. Assim, ela tem tempo para refletir sem criar uma dinâmica de “nós contra eles”. A avaliação reúne perguntas que identificam diferentes comportamentos de segurança, tipos de teste, processos etc. A equipe de desenvolvimento pode indicar o que já é feito em cada área. É comum que as equipes se concentrem mais em algumas áreas do que em outras, e isso é perfeitamente normal.

A próxima etapa é promover melhorias — e é aí que a equipe de segurança pode ajudar e dar suporte às equipes de desenvolvimento. Um ótimo exemplo de melhoria liderada por desenvolvedores foi pedir à equipe de desenvolvimento que escolhesse quais itens da avaliação gostaria de aprimorar. Bastava selecionar alguns pontos e definir quando o processo de melhoria seria implementado. Por exemplo, a equipe pode querer incluir perguntas de segurança nas revisões de código ou eliminar do backlog todas as vulnerabilidades de alta severidade com pontuação CVSS igual ou superior a 9,5. Seja qual for o objetivo, é importante que ele seja liderado e assumido pelos desenvolvedores. O orientador de segurança está ali para ajudar a pessoa responsável pela iniciativa a colocá-lo em prática. Seja com capacitação, orientação, mudanças no pipeline ou outras necessidades, essa pessoa pode ajudar a liderança de segurança a implementar a mudança desejada.

Um princípio fundamental, porém, é que o sucesso do orientador de segurança — e possivelmente um KPI formal — depende do sucesso da pessoa responsável pela iniciativa de segurança. O orientador só tem sucesso se essa pessoa alcançar seu objetivo ou avançar no plano. Essa medida compartilhada de sucesso sustenta o objetivo comum de desenvolver software com segurança, algo que as duas equipes buscam juntas.

Outra atividade comum dos programas de champions de segurança é o gerenciamento de vulnerabilidades. Ter visibilidade de onde elas estão é ótimo, pois destaca os pontos críticos das aplicações e implantações. Porém, em projetos e implantações maiores, o grande número de vulnerabilidades nos backlogs pode rapidamente sobrecarregar os desenvolvedores. Tanto as equipes de desenvolvimento quanto as de segurança podem fazer a triagem, decidir quais vulnerabilidades ignorar e priorizar os backlogs, incluindo as vulnerabilidades recém-identificadas. As equipes de desenvolvimento conhecem muito melhor do que a equipe de segurança os fluxos, a arquitetura e o design das aplicações. Da mesma forma, a equipe de segurança entende melhor as ameaças e os riscos. A colaboração com canais de comunicação abertos — inclusive, mas não exclusivamente, por meio da relação entre champion e orientador — facilita e agiliza essas conversas e avaliações.

Como iniciar e expandir um programa de champions de segurança

Antes de tudo, lembre-se de que clareza e simplicidade são muito importantes. Ao iniciar o programa, disponibilize informações suficientes para que as pessoas entendam o que é o programa de champions de segurança, quais são seus objetivos e qual é o patrocínio e a importância dele para a empresa. Escreva pensando nos desenvolvedores e peça a opinião deles durante a elaboração.

A lição mais importante ao definir o tamanho inicial do programa é não tentar expandi-lo demais e rápido demais. Identifique e aprenda as melhores práticas específicas da sua organização e das suas equipes, que poderão ser aplicadas em uma expansão futura. Ao escolher as equipes para a primeira fase, considere quais delas na sua organização têm:

• Os serviços, as aplicações e as equipes mais importantes para a empresa e de maior risco

• As equipes com maior maturidade em segurança e desenvolvimento, capazes de se adaptar às mudanças

• Pessoas com relacionamentos já estabelecidos com a equipe de segurança

• Pessoas interessadas em segurança e abertas a melhorar a postura e as práticas de segurança da equipe.

Começar com apenas algumas equipes reduz o risco de uma expansão malsucedida, pois você pode dedicar o tempo necessário a cada uma. Ao identificar as necessidades das equipes, também vale considerar os problemas em comum, caso já seja possível identificá-los. Por exemplo, se você implementar o programa em três equipes e todas quiserem começar a adotar a modelagem de ameaças, poderá compartilhar o aprendizado entre elas e concentrar os esforços em menos frentes.

Escolher o orientador de segurança certo também pode fazer toda a diferença, pois essa pessoa será o principal ponto de contato das equipes de desenvolvimento. Alguém que se comunique bem, de preferência com experiência anterior em engenharia e empatia pelos desenvolvedores, pode fazer uma grande diferença.

No início, ofereça recompensas e reconhecimento generosos para incentivar as pessoas e despertar o interesse em avançar ainda mais. Comece também a criar um guia de melhores práticas para usar depois com outras equipes. Além disso, atualize a documentação e os guias existentes conforme necessário, para que as próximas equipes tenham informações úteis e atualizadas.

À medida que o programa crescer na empresa, considere incluir outros grupos de diferentes áreas da organização para representar melhor todas as partes do negócio. Você pode fazer uma série de apresentações para entender que outros tipos de ajuda são necessários e ainda não estão sendo oferecidos, além de compartilhar os resultados das equipes que já participam do programa. Compartilhar esses resultados dentro do programa também permite que as equipes acompanhem o progresso umas das outras, o que pode gerar uma competição saudável e ajudar todas a evoluir.

Ao implementar o programa em uma equipe de desenvolvimento, reconheça as ações, os novos aprendizados e a responsabilidade que ela demonstra, dando-lhe ainda mais autonomia! Pode parecer estranho, mas, no fim das contas, queremos que as equipes de desenvolvimento sejam mais autônomas. À medida que mostrarem mais capacidade e disposição para assumir a segurança, dê a elas mais autoridade e responsabilidade.

Como conquistar a adesão dos desenvolvedores

Entender os desafios e as necessidades da área de desenvolvimento é essencial para conquistar a adesão dos desenvolvedores ao programa. Quer você decida expandi-lo apenas com voluntários, por indicação da gestão ou com uma combinação dos dois, é importante garantir que as pessoas participantes se envolvam e contribuam.

É importante explicar claramente por que o programa existe. Deixar claros os objetivos, os papéis e as responsabilidades das pessoas de desenvolvimento e de segurança ajuda todos a se sentirem à vontade e a se envolverem. Uma característica essencial do programa é que desenvolvimento e segurança trabalham como uma equipe em busca de um objetivo comum: desenvolver e entregar código e aplicações seguros. Especialmente para conquistar a adesão e o entusiasmo dos desenvolvedores, é importante que o trabalho de desenvolvimento seguro seja visto, em grande parte, como parte do próprio trabalho de desenvolvimento.

Ao escolher temas de capacitação, pedir que desenvolvedores realizem tarefas ou acompanhar chamados, tenha sempre em mente o público de desenvolvimento. Em geral, os desenvolvedores se interessam mais pelas melhores práticas do que por informações básicas que muitas vezes já conhecem. Para que o conteúdo seja eficaz, ele precisa ser prático, técnico e aplicável à resolução de problemas.

Detalhes como o local das comunicações e interações também são importantes. Por exemplo, se você quiser abrir um chamado para a equipe de desenvolvimento, use o sistema de chamados que ela prefere. Se a equipe já usa o Jira, por exemplo, abra chamados no Jira. Considere cada ferramenta ou serviço adicional que você espera que a equipe use como uma barreira a mais para a participação.

Como mencionamos, também é importante deixar claras as responsabilidades e atribuições de cada champion de segurança. Isso fica mais fácil quando existe uma função oficial que especifica quanto tempo a pessoa deve dedicar às atividades de segurança da equipe. De qualquer forma, definir dois ou três objetivos e atividades para os champions nos próximos 3 a 6 meses é suficiente para evitar sobrecarregá-los e ajudá-los a se concentrar nas tarefas mais importantes.

Já mencionamos a importância de recompensar e reconhecer as pessoas, além de algumas maneiras de demonstrar o valor dessas atividades para a empresa. Comemorar o sucesso não significa necessariamente levar alguém a uma conferência. Na maioria das vezes, basta destacar o esforço da pessoa para incentivá-la a fazer ainda mais, atuando como sua defensora ou seu champion. Ao mesmo tempo, esse comportamento inspira outras pessoas a se dedicarem além do esperado para receber o mesmo reconhecimento.

Como é o sucesso?

Antes de tudo, é fundamental não esperar resultados incríveis em poucas semanas ou mesmo em alguns meses. O objetivo de criar um programa como esse é aprimorar o processo e as práticas de desenvolvimento para permitir a entrega segura de software. Não existe solução da noite para o dia e, quando se trata de pessoas, as mudanças levam ainda mais tempo. É preciso definir prazos realistas para mudanças e resultados, para que as decisões sejam tomadas corretamente, em vez de apenas tentar atingir uma meta arbitrária.

Adoção

Um indicador essencial para qualquer programa de champions de segurança é o nível de adoção. Como dissemos, é importante que a participação de cada champion seja voluntária. Por isso, sinais de sucesso podem incluir o número total de champions, o crescimento do grupo ao longo do tempo e a permanência dos participantes.

Outra boa métrica é o número de equipes de desenvolvimento alcançadas pela área de segurança por meio do programa de champions e a proporção que elas representam em toda a área de desenvolvimento. Lembre-se de que crescer rápido demais pode levar ao fracasso. Por isso, as metas devem ser alcançáveis e crescer de forma orgânica, sem serem agressivas ou impostas.

Engajamento

O engajamento dos participantes é outro indicador a acompanhar, pois mostra se o programa e os relacionamentos estão funcionando. É difícil monitorar se os champions realmente dedicam de 10% a 20% do tempo a atividades de segurança — e provavelmente nem é isso que você quer fazer. O mais importante é dar apoio oficial aos engenheiros, incorporando esse trabalho de segurança às suas funções, em vez de deixá-lo como uma tarefa extra que talvez seja feita no tempo livre. Além disso, essa dedicação é apenas uma estimativa e pode variar de uma semana para outra, conforme a demanda.

Uma métrica muito melhor é acompanhar as atividades em que eles se envolvem, desde reuniões recorrentes até iniciativas conduzidas nas próprias equipes. É fácil monitorar as reuniões, registrando quantos champions participam regularmente das chamadas mensais ou dos encontros semanais com seus orientadores de segurança. Esses dados não devem ser usados contra os champions, mas para aprimorar o conteúdo e as atividades do programa, aumentando seu apelo e sua relevância para eles.

Impacto

Como mencionamos anteriormente, é importante dar autonomia à equipe de desenvolvimento para assumir a responsabilidade por mudanças e melhorias no próprio time. Até onde você quer levar isso depende de você, mas entender o que a equipe está assumindo, o que está melhorando e o que já concluiu é uma medida concreta do impacto do programa.

Uma boa forma de fazer isso usando a técnica do scorecard é pedir à equipe de desenvolvimento que avalie as próprias práticas e processos. Para começar, quantas pessoas estão preenchendo os scorecards de suas equipes? Depois de trabalhar com elas para que entendam os maiores riscos, as correções mais rápidas etc., elas elaboraram um plano de melhoria pelo qual são responsáveis e que lideram, com o apoio da equipe de segurança? E, claro, estão medindo o progresso das equipes em relação aos planos? Essa deve ser uma KPI pela qual tanto a pessoa defensora quanto a pessoa mentora sejam responsáveis e que meça essa evolução.

Progresso

Como já mencionamos, os tipos de capacitação que uma pessoa defensora e um desenvolvedor com menos interesse em segurança podem querer são diferentes. E tudo bem, mas ainda é importante medir e acompanhar o progresso de aprendizagem. Depois de decidir como você quer capacitar as equipes — por meio de certificações internas ou externas, ou até mesmo de horas de trabalho prático com segurança —, use um modelo de faixas, medalhas ou certificações para mostrar o nível de conhecimento das equipes como um todo, com metas de melhoria a cada trimestre.

Painéis

A última área a medir, que pode ser considerada uma métrica mais influenciável, são os painéis de segurança de produtos, que apresentam estatísticas sobre vulnerabilidades, número de testes, adoção pelas equipes etc. Sem contexto, esses números podem não refletir a qualidade ou o risco de um projeto. Por exemplo, o fato de uma equipe realizar mais testes do que outra provavelmente significa que ela identificará mais vulnerabilidades, pois tem mais visibilidade e conhecimento sobre os próprios problemas. Isso não significa que ela apresente um risco maior, apesar dos números mais altos.

É muito valioso mostrar os impactos por equipe, com contexto e justificativas. Ao medir essas métricas, não deixe de acompanhar também os processos e as práticas que as influenciam. Por exemplo, pedir à equipe que faça modelagem de ameaças para cada funcionalidade desenvolvida reduz muito o risco do projeto. Isso afeta o número de vulnerabilidades encontradas durante o desenvolvimento, e esse contexto enriquece bastante os resultados.