O conceito de “deslocamento para a esquerda” é fundamentalmente sólido. Integrar a segurança antecipadamente ao ciclo de vida de desenvolvimento de software program (SDLC) parece ser a medida óbvia. Em vez de deixar a segurança em segundo plano, por que não abordá-la antes que se torne um problema? Parece best: correção mais rápida, menos vulnerabilidades escapando e os desenvolvedores se tornando heróis da segurança. Viva!
No entanto, apesar do apelo, a mudança para a esquerda não cumpriu totalmente a sua promessa. A intenção é clara, mas a execução deixa muito a desejar. Embora nossa indústria tenha tentado migrar a segurança no início do processo, a forma como isso foi feito não está funcionando para os desenvolvedores.
Experimentei isso em primeira mão e acredito que há uma maneira melhor de cumprir a promessa authentic de mudança para a esquerda.
Onde a mudança para a esquerda fica aquém
Toda a premissa do shift left é colocar a segurança nas mãos dos desenvolvedores, capacitando-nos a gerenciar os riscos associados ao código que escrevemos. Em teoria, isto descentraliza a segurança, dando àqueles que estão mais próximos do código mais responsabilidade na sua proteção.
Mas para que isso funcione para nós, nós, desenvolvedores, precisamos ser capazes de tomar decisões de segurança sólidas. Para mim, “capaz” se traduz em três coisas:
- Precisamos realmente querer fazer isso. No momento, não temos. Os desenvolvedores não são incentivados a se concentrar na segurança. Nossos objetivos estão centrados nos recursos de envio e no cumprimento de prazos e tendemos a ver a segurança como algo que nos atrasa. As ferramentas que recebemos geralmente servem mais para ajudar as equipes de segurança a detectar nossos erros após o fato, em vez de nos ajudar a evitá-los. Essa postura de “policial de segurança” significa que experimentamos segurança principalmente por meio de notificações frustrantes do tipo “Ei, peguei você em flagrante”, que criam uma desconexão e levam à resistência em vez do engajamento.
- Precisamos de ferramentas que não prejudiquem nossa velocidade. Muitas das ferramentas comercializadas como “amigáveis ao desenvolvedor” integram-se ao nosso conjunto de ferramentas de desenvolvimento – principalmente Jira e Pull Requests – mas não tentam se encaixar em nossa maneira de trabalhar. Eles não são “amigáveis para desenvolvedores”, são apenas “compatíveis com desenvolvedores”. Eles normalmente aparecem mais tarde no SDLC, após o código ter sido confirmado. Eles nos alertam tarde demais, adicionando trocas de contexto desnecessárias e nos forçando a revisitar e corrigir o código do qual já migramos. Nem mesmo mencionando revisões redundantes por pares. É um processo ineficiente e contribui para uma frustração geral com a segurança.
- Precisamos adquirir julgamento cibernético (de preferência sem ficar entediado até a morte). Os desenvolvedores adoram aprender – sim, até mesmo assuntos de segurança – mas não sobre coisas que talvez nunca encontremos. A abordagem do setor ao treinamento em segurança exige que gastemos um tempo significativo aprendendo por meio de programas de treinamento extensos e generalizados que não se alinham com nossas necessidades específicas. O resultado é que muitos de nós vemos o treinamento em segurança como uma interrupção e não como uma oportunidade de crescimento. É difícil manter-se motivado quando o treinamento parece desconectado do nosso conhecimento prévio e do nosso trabalho diário.
Como podemos fazer o turno à esquerda funcionar
A boa notícia é que a mudança para a esquerda não está além da salvação. O conceito ainda tem um valor imenso – se pudermos executá-lo melhor. A chave é abordar estes três pontos acima de tal forma que a segurança pareça uma extensão pure do trabalho que já estamos a fazer, em vez de uma série de exigências externas.
Aqui estão algumas maneiras específicas de tornar isso uma realidade.
- Segurança como treinador, não como policial. Um dos primeiros passos é mudar a forma como a segurança é integrada no desenvolvimento. Em vez de nos concentrarmos em uma abordagem “pegadinha” e posterior ao fato, precisamos de segurança para nos ajudar o mais cedo possível no processo: à medida que escrevemos o código. Ao nos orientar enquanto ainda estamos no modo “trabalho em andamento” com nosso código, a segurança pode adotar uma postura positiva de treinamento e ajuda, estimulando-nos a corrigir problemas antes que eles se tornem problemas e atrapalhem nosso backlog. Essa abordagem reduziria o estigma em torno da segurança e tornaria algo que os desenvolvedores consideram benéfico, em vez de uma penalidade.
- Ferramentas que não nos fazem trabalhar duas vezes. As ferramentas de segurança que usamos precisam detectar vulnerabilidades com antecedência suficiente para que ninguém volte para corrigir problemas de bumerangue mais tarde. Muito alinhado com meu ponto anterior, detectar e corrigir vulnerabilidades à medida que codificamos economiza tempo e preserva o foco. Isso também reduz as idas e vindas nas revisões por pares, tornando todo o processo mais tranquilo e eficiente. Ao incorporar a segurança mais profundamente no fluxo de trabalho de desenvolvimento, podemos resolver problemas de segurança sem interromper a produtividade.
- Treinamento direcionado. Quando se trata de treinamento em segurança, precisamos de uma abordagem mais focada. Os desenvolvedores não precisam se tornar especialistas em todos os aspectos da segurança de código, mas precisamos estar equipados com o conhecimento que é diretamente relevante para o trabalho que estamos fazendo, quando o fazemos — enquanto codificamos. Em vez de programas de treinamento amplos e de tamanho único, vamos nos concentrar em abordar lacunas de conhecimento específicas que pessoalmente ter. O treinamento em tempo actual, ministrado em porções pequenas e digeríveis à medida que encontramos desafios específicos em nosso código, seria muito mais eficaz. Esta abordagem just-in-time permite-nos aprender no contexto, no trabalho, tornando a formação mais memorável e diretamente aplicável.
Ironicamente, no ultimate, consertar a segurança do deslocamento para a esquerda exige que redobremos a ideia authentic, empurrando a segurança ainda mais para a esquerda – no código enquanto ele está sendo escrito e na base de conhecimento dos desenvolvedores que escrevem esse código. Ao adoptarmos uma abordagem mais integrada e de apoio à segurança, podemos transformar a segurança de um obstáculo numa vitória pessoal.
O potencial de mudança para a esquerda continua vasto, mas para o desbloquear, precisamos de repensar a forma como cumprimos a promessa. Com as ferramentas, a mentalidade e o treinamento certos, os desenvolvedores podem ser capacitados para tornar a segurança uma parte pure do processo de desenvolvimento. É assim que finalmente cumpriremos a promessa da Shift Left Safety.