0
0
Os desenvolvedores se preocupam com a qualidade e a segurança de seu código e, quando autorizados a ajudar, os desenvolvedores são ótimos defensores da segurança que podem ajudar a fortalecer a segurança da cadeia de suprimentos , reduzindo a carga sobre o DevOps e as equipes de segurança. A introdução de ferramentas de segurança que permitem aos desenvolvedores possuir a segurança do código em seu processo de desenvolvimento existente pode aumentar a identificação precoce de riscos e simplificar o processo de mitigação de riscos, retardando o crescimento (ou até mesmo reduzindo) as pendências de vulnerabilidade.
Os desenvolvedores querem produzir código seguro
Os desenvolvedores se orgulham muito da qualidade de seu código, o que inclui o quão seguro ele é. Se você percorrer os argumentos sobre espaços versus tabulações e qual linguagem é a superior, os fóruns de desenvolvimento fornecem exemplos intermináveis de discussões sobre segurança e eficiência de código, abrangendo desde como armazenar senhas até a busca de práticas recomendadas para código seguro.
Esses exemplos incluem compartilhamento de conhecimento sobre armazenamento de senhas existente , métodos de criptografia para novas senhas, práticas gerais de codificação segura e muito mais. O take-away? Os desenvolvedores consideram a segurança do código um componente-chave da qualidade geral do código, eles apenas querem que ela faça parte do processo de desenvolvimento e não seja apresentada como uma nota de aprovação/reprovação após seus esforços.
Historicamente, a relação desenvolvedor-segurança foi definida pela percepção de que as ferramentas de segurança adicionam atrito e frustração ao fluxo de trabalho do desenvolvedor. Grande parte dessa percepção pode ser explicada pelo timing dos alertas, e pela sensação de “te peguei” ao ser apresentado por um colega ao final de um ciclo de desenvolvimento. A realidade é que os desenvolvedores estão abertos a comentários orientados à segurança e até mesmo os procuram durante o processo de desenvolvimento.
O que os desenvolvedores desejam é um processo oportuno e livre de julgamento para avaliar a segurança do código que se encaixe em seu processo existente e forneça um contexto útil sobre como resolver o risco.
Os desenvolvedores são sua primeira linha de defesa
A segurança não começa com verificações no processo de compilação em seu pipeline de CI/CD. Muito antes de o novo código ser introduzido no ambiente de produção, ele passa por testes locais na máquina de um desenvolvedor e passa por revisões por pares quando o código é adicionado a solicitações pull. Estes representam os primeiros e mais avançados esforços da “esquerda” para identificar vulnerabilidades, bem como a primeira oportunidade de mitigação de riscos.
O feedback fornecido neste estágio, diretamente para o desenvolvedor em tempo real, pode ser executado de forma rápida e eficiente, sem exigir que o desenvolvedor se reaclimate com o código que escreveu semanas atrás ou qualquer DevOps ou intervenção de segurança.
Os desenvolvedores têm o contexto para agir rapidamente
Resolver vulnerabilidades requer conhecimento inato do código existente, bem como a maneira correta de corrigir a vulnerabilidade. Quanto mais tempo leva para identificar um risco de código, mais complicado é mitigar o risco. Nos casos em que as vulnerabilidades são adicionadas a um backlog, os desenvolvedores originais podem ter alterado os projetos ou deixado a organização e os novos recursos podem depender do código vulnerável no momento em que uma correção é priorizada.
Nesses cenários, as equipes de DevOps e segurança ficam tentando encontrar um ou mais novos desenvolvedores para identificar e implementar a correção, que podem ter pouco conhecimento do código original. Esse processo sobrecarrega cada departamento, diminui os tempos de resolução e produz correções de código menos eficientes – sem mencionar que prejudica seriamente a velocidade de desenvolvimento de novos recursos, pois os desenvolvedores gastam ciclos revisando códigos antigos em vez de escrever novos códigos.
Localizar vulnerabilidades no código o mais cedo possível e capacitar o desenvolvedor para corrigir essas vulnerabilidades garante que a pessoa certa seja sempre responsável por mitigar o risco e que o código ainda esteja fresco na mente do desenvolvedor. Isso significa que menos riscos são identificados nos estágios posteriores do pipeline de CI/CD, reduzindo acúmulos de vulnerabilidades e devolvendo um tempo precioso aos desenvolvedores, DevOps e equipes de segurança.
A tendência crescente dos campeões de segurança
As organizações estão cada vez mais cientes dos benefícios da descentralização dos esforços de segurança e da incorporação de desenvolvedores em seus processos de proteção. Alguns estudos até encontraram evidências de que as práticas de segurança integradas ao desenvolvedor são um sinal de maturidade visto em organizações de segurança bem-sucedidas. Em um estudo anual, a equipe Building Security in Maturity Model (BSIMM) descobriu que todas as 10 empresas com pontuações BSIMM mais altas implementaram equipes satélites que aumentam os esforços de segurança e que essas mesmas equipes satélites estavam ausentes das 10 empresas com pontuação mais baixa empresas.
Uma abordagem completa para a segurança da cadeia de suprimentos deve incluir defensores da segurança do desenvolvedor. Os desenvolvedores não devem apenas ser incluídos no processo de segurança, mas também devem ter o poder de agir sobre riscos conhecidos com ferramentas de segurança voltadas para desenvolvedor
FONTE: HELPNET SECURITY