“Shift-left”: Armadilhas e como evitá-las

Os desenvolvedores de aplicativos desempenham um papel fundamental para garantir que as empresas tenham sucesso e mantenham-se competitivas. Mas a filosofia “shift-left” que passou a dominar o pensamento sobre DevOps (ou melhor, DevSecOps) teve o efeito de deixá-los sobrecarregados, estressados e cansados de serem culpados por todos os problemas ou vulnerabilidades que surgem na implementação dos aplicativos dos quais as organizações dependem.

Especialmente agora, quando o talento dos programadores está a tornar-se mais difícil de encontrar, a rotatividade de funcionários e a perda de produtividade resultante de programadores esgotados é tremendamente dispendiosa. Felizmente, este é um problema que pode ser resolvido.

O que é shift-left?

Antigamente, os programadores desenvolviam aplicações, e depois os engenheiros de QA avaliavam as aplicações quanto à funcionalidade e facilidade de uso, e as equipas de segurança verificavam-nas em busca de vulnerabilidades. E só depois de tudo estar verificado é que as aplicações eram implantadas para uso operacional.

Ninguém tem mais tempo para isso. Precisamos dessas aplicações operacionais já já já! A solução foi, e é, shift-left, que se refere a mover QA e segurança para a esquerda no ciclo de vida de desenvolvimento de software (SDLC), anteriormente linear. QA e segurança seriam doravante tratados durante o desenvolvimento inicial da aplicação, ou mesmo na fase de design. 

Teoria vs. prática

Uma excelente ideia em princípio. Em princípio, significava que engenheiros de QA, especialistas em segurança e programadores trabalhariam juntos ao longo do SDLC, colaborando em tempo real para acelerar dramaticamente o processo e lançar apps mais cedo.

Na prática, no entanto, esta abordagem muitas vezes significa que as equipas de desenvolvimento são responsabilizadas por coisas que estão fora da sua área de especialização. Questões culturais tornam mais desafiante do que o esperado alcançar esse nível de colaboração, e os desenvolvedores têm, em muitos casos, recebido as tarefas de QA e segurança além da sua descrição básica de funções. 

É claro que não há nada de errado em pedir aos programadores que pensem seriamente na segurança desde o início. Se conseguirem identificar uma potencial vulnerabilidade na fase de design, esta pode ser corrigida facilmente. Enquanto que, se só vier à tona depois de a aplicação ter sido codificada e compilada, pode ser um processo muito mais demorado corrigi-la, especialmente se o código vulnerável tiver dependências codificadas também.

Conforme explica Shannon McFarland em este artigo de blogue da Cisco, os benefícios projetados do shift-left são significativos: 

1. Colaboração melhorada, à medida que as equipas de QA, segurança e desenvolvimento trabalham em conjunto e todas melhoram a sua compreensão de todo o processo SDLC
2. Custos reduzidos graças à identificação e correção de problemas mais cedo no processo, o que significa mais rápido e fácil
3. Maior segurança à medida que os programadores aprendem a integrar a segurança no processo de design
4. Melhoria da qualidade do software à medida que menos problemas de qualidade provavelmente sobreviverão à implantação operacional

Mas em vez destes benefícios, demasiadas vezes os resultados são:

1. Aumento da carga de trabalho à medida que os programadores assumem novas tarefas para as quais não estão treinados, sem redução da sua carga de trabalho existente
2. Aprendizagem contínua como desenvolvedores é necessária para dominar constantemente novas ferramentas, processos e tecnologias, à medida que mais coisas são movidas para mais cedo no ciclo de vida de desenvolvimento
3. Esgotamento, à medida que os programadores se veem sob pressão crescente para criar aplicações seguras e de alta qualidade ainda mais rapidamente do que antes
4. Dinâmica de equipa perturbada à medida que as fronteiras organizacionais tradicionais se tornam difusas.

De linear a contínuo

Como Melinda Marks argumenta no este artigo da TechTarget, parte do problema com o shift-left é que se baseia numa compreensão tradicional e linear do SDLC. Mas os processos de desenvolvimento baseados na nuvem de hoje são dominados por pipelines de integração contínua/entrega contínua (CI/CD).

Para simplificar excessivamente, isto significa que novas funções e funcionalidades—novos ramos de uma base de código em constante crescimento—estão continuamente a ser desenvolvidos, implementados e integrados em aplicações existentes. Não há um momento em que a aplicação esteja concluída, carimbada como "APROVADA" tanto pelas equipas de QA como de segurança, e implementada para ir e fazer o bem no mundo. As aplicações críticas para o negócio estão sempre num estado contínuo de desenvolvimento.

Isso torna muito mais difícil apontar para um ponto ao longo de um processo linear e dizer "Agora vamos fazer QA aqui, em vez de mais tarde." E significa que os desenvolvedores, engenheiros de QA e especialistas em segurança estão todos a aplicar as suas habilidades ao mesmo tempo, num ciclo contínuo de inovação e melhoria.

Fazer com que funcione

Liderança, responsabilidades claramente definidas, uma cultura sem culpa e o apoio de todas as partes interessadas são as chaves para uma estratégia de shift-left bem-sucedida que obtém os benefícios sem as desvantagens do esgotamento dos desenvolvedores e todos os custos que isso implica.

Isso requer fortes competências organizacionais, como ser capaz de desenhar um processo que delineia especificamente as responsabilidades de cada equipa, em vez de simplesmente dizer que os desenvolvedores têm de fazer mais testes de QA e auditorias de segurança. E requer muitas competências de liderança interpessoal, como encorajar todas as partes interessadas a participarem em análises pós-mortem sem culpabilização, ensinar todos a receber e dar críticas construtivas de forma graciosa, e gerir a integração e colaboração de equipas que tradicionalmente operaram em silos separados.