Os desenvolvedores profissionais desejam adotar o DevSecOps e escrever código seguro, mas suas organizações precisam oferecer suporte a essa mudança se quiserem que esse esforço cresça.
O cenário de ameaças cibernéticas está se tornando mais complexo a cada dia. Os invasores estão constantemente varrendo as redes em busca de aplicativos, programas e instâncias de nuvem vulneráveis, e a última novidade do mês são as APIs, amplamente consideradas uma vitória fácil graças aos seus controles de segurança muitas vezes frouxos.
Eles são tão persistentes que novos aplicativos às vezes podem ser comprometidos e explorados horas após a implantação. Um Relatório de investigações de violação de dados em 2021 deixa muito claro que as ameaças levantadas contra empresas e organizações são mais perigosas hoje do que em qualquer outro momento da história.
Está ficando muito claro que a única maneira de realmente fortalecer o software que está sendo criado é garantir que ele seja construído em um código seguro. Em outras palavras, a melhor maneira de impedir a invasão do agente de ameaça é negar a eles uma posição segura em seus aplicativos. Depois de começar a lutar nessa guerra, a maioria das vantagens é direcionada para os atacantes.
Essa situação deu origem ao desenvolvimento ágil e DevOps, e depois a todo o movimento DevSecOps, onde a segurança é uma responsabilidade compartilhada por todos os envolvidos no processo de criação de software, desde o desenvolvimento até a implantação. Mas a base dessa pirâmide, e sem dúvida a parte mais importante, são os desenvolvedores. Embora a maioria dos desenvolvedores queira fazer sua parte e escrever um código seguro, muitas das organizações para as quais trabalham dão menos apoio às mudanças que essa grande mudança nas prioridades exige.
Design
Por muitos anos, os desenvolvedores foram informados de que seu principal papel em suas organizações era construir e implantar rapidamente aplicativos em um ambiente acelerado, onde os negócios nunca param e os clientes nunca dormem. Quanto mais rápido que os desenvolvedores pudessem codificar e quanto mais recursos eles poderiam implantar, mais valiosos foram vistos em termos de suas revisões de desempenho.
A segurança era uma reflexão tardia, se fosse considerada. Em vez disso, tudo isso foi deixado para as equipes de segurança do aplicativo (AppSEC) para descobrir. As equipes do AppPSEC foram não gostadas pela maioria dos desenvolvedores porque freqüentemente enviariam os aplicativos concluídos devolvidos ao desenvolvimento para aplicar patches de segurança ou para reescrever código para remediar vulnerabilidades. E toda hora que um desenvolvedor passou trabalhando em um aplicativo que já estava “acabado” foi uma hora que eles não estavam criando novos aplicativos e recursos, diminuindo assim seu desempenho (e seu valor, aos olhos de uma empresa).
E então o ambiente de ameaça mudou a importância e a priorização da segurança para a maioria das empresas. De acordo com o recente custo de um relatório de violação de dados da IBM e do Instituto Ponemon, a violação média de segurança cibernética agora custa cerca de US $ 3,8 milhões por incidente, embora dificilmente seja o limite superior. Uma empresa sozinha incorreu em US $ 1,3 bilhão em perdas após uma violação em sua rede. As empresas de hoje querem a segurança oferecida por Devsecops, mas, infelizmente, têm sido lentas para recompensar os desenvolvedores que respondam esse chamado.
Basta dizer às equipes de desenvolvimento para considerar a segurança não funcionará, especialmente se ainda estiverem sendo incentivadas com base na velocidade sozinha. De fato, dentro de tal sistema, os desenvolvedores que assumem o tempo para aprender sobre segurança e proteger seu código podem estar perdendo em melhores avaliações de desempenho e bônus lucrativos que seus colegas com reconhecimento de segurança continuam a ganhar. São quase como as empresas estão involuntariamente enviando o sistema para suas próprias falhas de segurança, e volta à sua percepção da equipe de desenvolvimento. Se eles não estão vê-los como as fronteiras de segurança, então é muito improvável que um plano viável utilizar sua força de trabalho virá para a fruição.
E isso nem conta a falta de treinamento. Alguns desenvolvedores muito qualificados têm décadas de experiência de experiência, mas muito pouco quando se trata de segurança … Afinal, nunca foi exigido deles. A menos que uma empresa forneça um bom programa de treinamento para seus programadores qualificados, dificilmente espera que seus desenvolvedores obtenham novas habilidades e coloque-as em ação de uma maneira significativa que reduz ativamente as vulnerabilidades.
Recompensando desenvolvedores por boas práticas de segurança
A boa notícia é que a esmagadora maioria dos desenvolvedores faz o seu trabalho porque acham tanto desafiador quanto recompensador, e porque gostam do respeito que sua posição implica.
Ao longo da vida codificador profissional Michael Shpilt escreveu recentemente sobre todas as coisas que ele e seus colegas de codificação motivam em seu trabalho de desenvolvimento. Sim, ele lista compensação monetária entre esses incentivos, mas é surpreendentemente longe da lista. Em vez disso, ele prioriza a emoção de criar algo novo, aprendendo novas habilidades e a satisfação de saber que seu trabalho será diretamente usado para ajudar os outros. Ele também fala sobre querer se sentir valorizado em sua empresa e comunidade. Em suma, os desenvolvedores são como muitas pessoas boas que se orgulham de seu trabalho.
Desenvolvedores como SHPILT e outros não querem atores de ameaças comprometendo seu código e usá-lo para prejudicar sua empresa, ou os usuários que estão tentando ajudar. Mas, eles não podem de repente mudar suas prioridades para a segurança sem apoio. Caso contrário, é quase como o sistema estará trabalhando contra eles.
Para as equipes de desenvolvimento ajudar a melhorar suas proezas cibersegurança, eles devem primeiro ser ensinadas as habilidades necessárias. Utilizando aprendizagem andaimada e ferramentas como o treinamento just-in-time (JIT) pode tornar este processo muito menos doloroso e ajuda a construir o conhecimento existente no contexto certo.
O princípio do JIT é que os desenvolvedores são servidos o conhecimento certo no momento certo, por exemplo, se um detecta ferramenta JiT desenvolvedor de treinamento que um programador está criando um pedaço inseguro de código, ou é acidentalmente introduzir uma vulnerabilidade em sua aplicação, Pode ativar e mostrar o desenvolvedor como eles podem corrigir esse problema e como escrever um código mais seguro para executar a mesma função no futuro.
Com um compromisso com o upskilling no lugar, os antigos métodos de avaliar os desenvolvedores baseados unicamente na velocidade precisam ser eliminados. Em vez disso, os codificadores devem ser recompensados com base em sua capacidade de criar código seguro, com os melhores desenvolvedores que se tornam campeões de segurança que ajudam o resto da equipe a melhorar suas habilidades. E esses campeões precisam ser recompensados com a compensação de prestígio e monetária da empresa. Também é importante lembrar que os desenvolvedores não têm tipicamente uma experiência positiva com segurança e edificá-los com aprendizagem positiva, divertida e incentivos que falam com seus interesses irão um longo caminho para garantir tanto a retenção de conhecimento quanto o desejo de manter as habilidades de construção .
As empresas ainda podem incluir codificação de velocidade como uma parte da avaliação de um desenvolvedor, mas com a expectativa de que o desenvolvimento de aplicações seguras pode demorar um pouco mais, especialmente como codificadores estão aprendendo estas novas habilidades.
DevSecOps pode ser a última defesa contra as artes das trevas de um cenário de ameaças cada vez mais perigoso. Só não esqueça que os campeões deste novo mundo, os desenvolvedores que estão criando consistentemente novos códigos, precisam ser respeitados e compensados pelo seu trabalho.
REFERÊNCIAS:
https://thehackernews.com/2021/09/incentivizing-developers-is-key-to.html