Capacitando seus desenvolvedores

Capacitar desenvolvedores significa dar a eles espaço para tomar decisões com base em diferentes informações, resolver seus próprios problemas de segurança e, por fim, assumir a responsabilidade pela segurança de suas aplicações. A capacitação exige apoio. Ela é oferecida, desenvolvida e sustentada por outras equipes. Vamos começar pelo apoio que precisa vir de cima para baixo, para que os desenvolvedores tenham tempo de entregar código seguro.

"Se você ler o memorando sobre cultura da Netflix no site da empresa, uma das coisas que mais chamam a atenção é a discussão sobre liberdade e responsabilidade. Esse conceito orienta o funcionamento da organização de engenharia deles. É interessante porque, como seres humanos, tendemos a nos concentrar na liberdade. Pensamos: “Que ótimo. Posso fazer o que quiser. E, com certeza, vou ter que assumir alguma responsabilidade. Mas a gente resolve isso depois.” Na realidade, existe uma enorme responsabilidade ao desenvolver software para uma empresa como a Netflix. Você não quer que o serviço saia do ar, então a confiabilidade é fundamental. Você não quer que ele seja invadido, então a segurança é fundamental. Por isso, como engenheiro, você também precisa agir com muita responsabilidade. E, como organização de segurança, muitas vezes nos víamos como uma equipe que estava ali para apoiar e viabilizar os negócios. Queríamos permitir que os engenheiros de software da empresa se concentrassem nas áreas para as quais foram contratados. Mas, se chegassem a um ponto em que a segurança fosse realmente essencial para o trabalho, poderiam contar com nossa ajuda. E definir exatamente onde fica esse limite é uma questão de julgamento. Com uma boa relação entre a equipe de segurança e os engenheiros, é possível chegar a essa definição."

Bryan Payne, CISO da BetterUp e ex-diretor de Engenharia de Segurança de Produtos e Aplicações na Netflix

O que motiva os desenvolvedores a dedicar tempo à segurança?

Independentemente de quererem ou não dedicar tempo à segurança, os desenvolvedores precisam ter tempo para isso — e de uma forma que permita priorizá-la junto com outras entregas funcionais ou não funcionais. Eles devem poder decidir quanto tempo investir em práticas de desenvolvimento seguro, em vez de confiabilidade ou escalabilidade, de acordo com as necessidades dos negócios. Ao tomar essas decisões, devem poder apresentar o que fizeram e alcançaram na avaliação de desempenho de fim de ano e contar com o apoio do gerente. Cabe aos gerentes reconhecer essas decisões para que os desenvolvedores saibam que estão usando bem o tempo. Se isso não acontece, a empresa não está capacitando os desenvolvedores a dedicar tempo ao desenvolvimento seguro.

Quem deve priorizar a segurança para a equipe e para os negócios?

Em última instância, isso vem do topo: do CEO. Se a segurança é uma preocupação para os negócios, deve ser uma preocupação do CEO. Essa prioridade precisa se espalhar pela organização, passando pelo CIO e pelo CTO, pelos vice-presidentes de Engenharia, diretores, gerentes e líderes de equipe, até chegar ao desenvolvedor que executa os testes e corrige os problemas. Com o apoio da liderança executiva, as equipes podem reservar uma parte de cada sprint para a saúde da engenharia, incluindo a segurança, em vez de serem obrigadas a se concentrar sempre em novos recursos.

Quando esse apoio e essa priorização não vêm da liderança, é extremamente difícil argumentar que os testes de segurança são tão importantes — ou talvez mais importantes — do que o próximo recurso ou uma necessidade do cliente. Se esse tipo de ação ou atividade é visto como algo extra que precisa ser justificado, a resposta padrão passa a ser “não fazer nada”, e as conversas começam com “por quê?” em vez de “como?”.

Isso não significa que o CEO e os desenvolvedores façam isso pelos mesmos motivos imediatos. O desenvolvedor tem orgulho do próprio código. Quer que ele seja preciso, rápido, confiável e seguro. Já o CEO se preocupa com a marca e os resultados financeiros, além de pensar nos danos que um incidente de segurança ou vazamento de dados poderia causar aos negócios. Embora ambos sejam bons motivos para investir em segurança, o fato é que uma abordagem de adoção da segurança de cima para baixo terá mais impacto do que simplesmente esperar que os desenvolvedores acrescentem mais tarefas à sua carga de trabalho.

"Quanto ao apoio da liderança, o nosso veio do CISO, que tinha acesso direto ao CTO. Por isso, o apoio veio de cima para baixo na área de tecnologia. Desde o início, havia entendimento e reconhecimento da necessidade de segurança. Para implementar as medidas, dependíamos da organização de engenharia de software e de seus líderes."

Nicholas Vinson, líder de DevSecOps na Pearson

Sua equipe de segurança apoia seus desenvolvedores?

Embora a equipe de desenvolvimento seja responsável por proteger suas aplicações e seu código, ela precisa do apoio da equipe de segurança para fazer isso bem. Quando trabalham em colaboração, a equipe de segurança deixa de atuar como auditora, executando testes e apresentando resultados — e sendo vista como um obstáculo — e passa a funcionar mais como uma equipe de engenharia de segurança. Assim, ajuda os desenvolvedores a automatizar a segurança em seus processos e oferece consultoria especializada sobre as áreas de maior risco e sua priorização.

A equipe de segurança não pode obrigar os desenvolvedores a priorizar o trabalho de segurança em detrimento de outras tarefas. Como mencionado, essa decisão faz parte das prioridades gerais da equipe de engenharia e dos negócios. Historicamente, os desenvolvedores veem as equipes de segurança como obstáculos, pois elas fazem auditorias de segurança no fim do ciclo de desenvolvimento. Ao capacitar os desenvolvedores para auditar o próprio código e testá-lo por conta própria, a equipe de segurança pode recuar um pouco. Então, pode ajudar as equipes de desenvolvimento a analisar os resultados que exigem conhecimento especializado em segurança, deixando de ser um obstáculo e passando a ser uma facilitadora. Além disso, essa abordagem dá à equipe de segurança espaço para identificar defensores da segurança nas equipes de desenvolvimento, criando ainda mais oportunidades de colaboração.

A equipe de segurança também pode ensinar as equipes de desenvolvimento sobre tipos de vulnerabilidade e riscos de exploração. Isso pode ser feito por meio de programas formais de defensores da segurança, nos quais outras atividades, como a implementação de processos, também podem ser bem coordenadas. Mesmo que as equipes de desenvolvimento trabalhem com mais autonomia, ainda é necessária uma estrutura geral de governança e visibilidade para que a empresa entenda seus riscos e sua exposição. A equipe de segurança pode oferecer diretrizes sustentadas por políticas para os testes de segurança, que podem ser aplicadas aos pipelines e às práticas das equipes. Isso ajuda a identificar problemas antecipadamente e a cumprir os SLAs.

"Quando penso em defensores da segurança e em modelos bem-sucedidos, vocês identificam algumas pessoas das equipes de engenharia que ficam responsáveis por segurança. Criam um painel de métricas pelo qual elas respondem, que mostra o que estamos fazendo para proteger corretamente nosso produto ou recurso. Os engenheiros podem conversar com a equipe central de segurança quando necessário, e também oferecemos a eles os treinamentos mais atuais e completos. Se a equipe de segurança é responsável por desenvolver ferramentas e outros recursos, esses defensores ajudam a impulsionar sua adoção. Por isso, os defensores da segurança precisam fazer parte das organizações de engenharia. Não podem ficar de fora. Eles realmente impulsionam a segurança."

Rinki Sethi, vice-presidente e CISO da Bill.com

A documentação é outro aspecto muito importante da adoção pelos desenvolvedores. Muitas vezes, ela é escrita por desenvolvedores e apresenta a perspectiva deles, com orientações de uso, explicações sobre decisões e particularidades. A equipe de segurança pode ajudar a coordenar e compartilhar essa documentação com outras equipes que também estejam adotando práticas, processos ou ferramentas semelhantes, além de participar da criação do material. Oferecer à equipe de desenvolvimento uma boa experiência de autoatendimento, familiar a quem já usa ferramentas para desenvolvedores, é essencial para uma adoção bem-sucedida.

Como são definidas as regras de segurança e as decisões sobre processos nos fluxos de trabalho de desenvolvimento?

Uma forma de medir a capacitação é observar quanta influência e autonomia um desenvolvedor ou uma equipe tem sobre seus próprios processos e testes de pipeline. É compreensível que as regras e políticas de segurança sejam definidas com a contribuição da equipe de segurança e, depois, apresentadas às equipes de desenvolvimento, que recebem orientações sobre como implementá-las nos processos existentes e oferecer treinamentos eficazes. O mais importante é como essas regras são apresentadas e implementadas. As equipes de desenvolvimento precisam poder assumir a responsabilidade e decidir como adaptar seus fluxos de trabalho. Isso não significa que cada equipe deva adotar uma abordagem própria, pois é essencial que aprendam umas com as outras e adotem as melhores práticas. As equipes de desenvolvimento precisam ter espaço para tomar decisões com base nas contribuições de outras equipes de desenvolvimento e da equipe de segurança, para que as soluções adotadas atendam às necessidades e aos padrões exigidos pela segurança.

Uma das vantagens dessa abordagem é a dinâmica que ela cria. Em primeiro lugar, ao não impor uma prática ou um processo à equipe de desenvolvimento, você, como profissional de segurança, pode trabalhar com ela para resolver um problema ou requisito de segurança, em vez de enfrentar a resistência natural quando algo é imposto por alguém de fora. Quando a equipe de segurança assume um papel consultivo, ela oferece um apoio que costuma ser mais bem recebido pelas equipes de desenvolvimento e as ajuda a tomar as decisões certas.

Em última instância, tudo se resume a uma questão de responsabilidade. Se você tentar fazer com que sua equipe de segurança assuma a responsabilidade pela segurança do código escrito pelas equipes de desenvolvimento, estará pedindo que ela amplie muito seus serviços em toda a organização — e provavelmente se torne um gargalo. Tradicionalmente, a equipe de segurança tende a assumir o papel de impor requisitos à organização de desenvolvimento, muitas vezes sem ter um mandato claro, na visão dos desenvolvedores.

Se você decidir que precisa restringir as tecnologias ou a stack que a equipe de desenvolvimento deve usar, é importante criar um caminho recomendado que ofereça opções bem sustentadas pela equipe de segurança e por outras equipes. Por exemplo, é comum disponibilizar um conjunto de imagens de contêiner padrão, totalmente testadas pelas equipes de segurança e por outras áreas, que os desenvolvedores podem escolher e usar como base. Ao oferecer opções que também funcionam como um caminho recomendado, você evita ser visto como um obstáculo e ajuda as equipes a se manterem seguras.

Visibilidade e transparência entre as equipes

Ter visibilidade da postura de segurança das suas aplicações, pipelines e processos é o primeiro passo para identificar os riscos e a exposição das suas equipes e dos negócios. No entanto, se as descobertas não forem usadas para agir, obter visibilidade não adianta. Neste estudo, descobrimos que usar essa visibilidade para apresentar regularmente um resumo da postura de segurança, na forma de um painel de responsabilização ou relatório, foi um dos fatores que mais contribuíram para o sucesso da adoção pelos desenvolvedores.

Os painéis de quem alcançou os melhores resultados de adoção incluíam segurança e vários outros aspectos, como desenvolvimento de recursos, confiabilidade, desempenho e muito mais. Gerados mensalmente, eles apresentavam métricas operacionais como número de vulnerabilidades, adoção de ferramentas de segurança, métricas de teste de projetos, nível de treinamento e muito mais. É importante destacar que as métricas incluídas nos painéis de cada empresa estavam alinhadas aos objetivos dos negócios. Vamos analisar em mais detalhes como esses painéis eram usados.

Priorização e justificativa

Com um scorecard que abrange métricas de negócio — inclusive de segurança — fica fácil entender se a segurança é a prioridade do momento ou se há problemas mais urgentes a resolver em outras áreas. Avaliar mais do que apenas a segurança é importante, pois só é possível tomar decisões bem fundamentadas quando todos os dados estão disponíveis.

Os scorecards devem ser gerados em diferentes níveis, com dados adaptados a quem vai consultá-los. Por exemplo, um executivo precisa de menos detalhes do que um líder de equipe, mas de uma conexão mais direta com as metas gerais do negócio. A equipe executiva pode ajustar as prioridades com base nos resultados do relatório, identificando onde a empresa precisa concentrar mais esforços. Já uma equipe precisa saber onde deve dedicar mais tempo e como suas pontuações se comparam às do restante da organização.

Todos esses dados ajudam desenvolvedores e equipes a priorizar melhor o que precisam fazer nos próximos sprints e a justificar essas escolhas. Se alguém perguntar por que a segurança está recebendo atenção especial, é importante apresentar um scorecard objetivo, em vez de uma explicação subjetiva.

Como parte desses scorecards, a equipe de segurança também deve fazer recomendações específicas para ajudar a equipe de desenvolvimento a definir prioridades. Por exemplo, pode destacar as principais vulnerabilidades (ou tipos de vulnerabilidade) que devem ser priorizadas para gerar o maior impacto.

Responsabilização

Para que a segurança seja uma prioridade, é preciso haver responsabilização em todos os níveis. O CTO responde ao CEO, os VPs de Engenharia respondem aos CTOs, os gerentes respondem aos VPs, e assim por diante, até chegar aos engenheiros. Quando todos têm um motivo para se importar com a segurança, ela passa a fazer parte das responsabilidades de cada função.

Felizmente, os scorecards são uma maneira simples e eficaz de responsabilizar as pessoas certas pelos padrões esperados. Ao publicar scorecards, todos na organização podem identificar rapidamente os pontos críticos e perceber se estão avançando na direção certa. Quando os limites definidos são atingidos, quem responde por métricas específicas pode identificar as causas, as justificativas e as possíveis soluções.

Assim como vimos ao falar sobre priorização da segurança, a responsabilização pela segurança precisa começar no topo. Caso contrário, a mensagem de que ela é importante para o negócio — e, portanto, também deve ser importante para a equipe de desenvolvimento — perde força, e o engajamento desaparece.

Aposte nos valores dos desenvolvedores e na gamificação

Em geral, desenvolvedores se preocupam em entregar aplicações que não só funcionem, mas que também sejam rápidas, confiáveis e seguras. Muitos fatores podem impedir que um desenvolvedor entregue código de acordo com os padrões que definiu, mas, no fim das contas, ele tem orgulho do que entrega. Os scorecards são uma ótima maneira de gamificar esse desejo de entregar o melhor código possível, substituindo a cobrança por incentivos.

Dar às equipes de desenvolvimento visibilidade sobre o andamento de seus projetos é uma boa forma de mostrar o que está indo bem ou melhorando, além dos desafios e atrasos. O orgulho de um desenvolvedor ou de uma equipe pode ser afetado ao ver que seu scorecard é o pior do departamento ou está bem abaixo da média da unidade de negócios ou da empresa como um todo. É natural que queiram melhorar, mas, para isso, precisam saber onde estão.

A gamificação funciona bem quando é bem-feita. A forma de aplicá-la depende bastante da cultura da empresa, mas compartilhar scorecards entre equipes e dar visibilidade aos resultados estimula uma reação de gamificação. Ninguém quer ser a pior equipe, e as pessoas gostam de acompanhar a evolução de seus scorecards e ficar acima da média da área — ou até entre as melhores do departamento. Também é importante compartilhar ideias e conquistas em comunicados e discussões. Isso dá origem a novas iniciativas, com equipes que querem reproduzir essas ideias ou levá-las ainda mais longe em suas áreas.