os desenvolvedores definiram “codificação segura” e suas respostas apontam para um problema crítico

Temos um longo caminho a percorrer, mas os obstáculos que impedem a sinergia necessária para abrir as portas para a responsabilidade compartilhada pela segurança de software estão se tornando bastante claros. Empresas inteligentes querem evoluir sua estratégia para evitar essas armadilhas, encontrar um caminho produtivo a seguir e usar o DevSecOps em todo o seu potencial movido a pessoas.

O que eu não estava antecipando é que a percepção do que constitui o ato de codificação segura está em debate. De acordo com uma nova pesquisa em colaboração com Evans Data, esse sentimento foi revelado em preto e branco. A pesquisa State of Developer-Driven Security 2022 investiga os principais insights e experiências de 1.200 desenvolvedores ativos, esclarecendo suas atitudes e desafios no domínio da segurança.

Uma das principais descobertas foi que apenas 14% dos desenvolvedores consideram a segurança uma prioridade ao codificar. Embora isso mostre que há um enorme espaço para melhorias, confirma o que já sabíamos: a construção de recursos é rei no mundo do desenvolvedor, e eles continuam mal equipados para fazer da segurança parte de seu DNA. No entanto, quando combinado com dados sobre as definições do desenvolvedor do que a codificação segura significa para eles, é motivo de preocupação.

Essas percepções são impulsionadas pela experiência do desenvolvedor em seu dia de trabalho e falam com o ambiente de muitas organizações, que é que os desenvolvedores simplesmente não são um ponto focal na luta contra vulnerabilidades comuns. A habilitação deles é crítica, mas, enquanto isso, devemos entrar rapidamente na mesma página com o escopo da “codificação segura” e o que devemos esperar de um desenvolvedor qualificado em segurança.

Precisamos desmistificar a segurança no mundo do desenvolvedor.

A segurança cibernética é uma fera multifacetada e difícil de manejar na melhor das hipóteses e, embora a codificação segura represente apenas uma parte do cenário geral, é uma engrenagem complexa no sistema que requer atenção especializada.

A pesquisa revelou que o conceito de trabalhar com código seguro era bastante isolado para o desenvolvedor médio, com seu escopo geralmente limitado a uma única categoria, em oposição a uma visão holística dos fundamentos e além. Os desenvolvedores indicaram uma confiança no uso de código existente (ou pré-aprovado), em vez da prática de escrever um novo código livre de vulnerabilidades. Embora a conscientização de segurança em relação a componentes de terceiros (especialmente patching, e o desastre do Log4Shell seja um ótimo exemplo: 30% das instâncias permanecem sem patch desde dezembro) é muito importante, assim como testar o código existente, eles sozinhos não atendem a um nível funcional de segurança capacidade de codificação.

Vulnerabilidades em nível de código são introduzidas por desenvolvedores que aprenderam padrões de codificação ruins, e a falta de ênfase em escrever código seguro em seus KPIs (juntamente com uma cultura de segurança sem brilho) apenas reforça isso como um padrão aceitável.

Os líderes de segurança podem percorrer um longo caminho para melhorar a conscientização inicial e identificar áreas das lacunas de conhecimento mais prementes, garantindo primeiro que a coorte de desenvolvimento tenha uma visão completa do que a codificação segura implica. Testar e escanear código pré-aprovado é uma função, mas a redução de vulnerabilidades requer treinamento prático em padrões de codificação bons e seguros, nas linguagens e estruturas que estão ativamente em uso.

O contexto é vital na qualificação do desenvolvedor, e eles precisam ser trazidos na jornada quando se trata das metas de segurança do negócio.

Muitas organizações precisam atualizar seus programas de segurança.

Com uma explosão de tecnologia orientada por software abrindo caminho para o rápido crescimento de incidentes de segurança cibernética na última década, estamos todos lutando para acompanhar os agentes de ameaças trabalhando ininterruptamente para descobrir explorações em sistemas valiosos.

A metodologia DevSecOps baseia-se na ideia de que todos compartilham a responsabilidade pela segurança – desenvolvedores incluídos – e é uma consideração principal desde o início do SDLC. O problema é que, especialmente em grandes empresas, elas podem estar muito longe de implementar o DevSecOps como padrão. Em 2017, um estudo do Project Management Institute mostrou que 51% das organizações ainda usavam o Waterfall para o desenvolvimento de software. Esse estudo já tem cinco anos, mas sabendo como as mudanças graduais podem ser em grandes empresas, é improvável que tenha havido uma transição acentuada para as mais recentes metodologias orientadas à segurança. Esses processos legados podem criar uma batalha difícil para os profissionais de segurança que tentam cobrir todas as bases com uma estratégia abrangente de proteção contra ameaças cibernéticas, e adaptar os desenvolvedores e suas necessidades a esse cenário é um desafio.

No entanto, não podemos usar isso como desculpa. Os profissionais de segurança nos negócios podem utilizar os desenvolvedores em uma estratégia aprimorada; eles só precisam se familiarizar com suas necessidades e considerá-las como parte de seu jogo defensivo. Eles precisam de treinamento abrangente e qualquer responsabilidade pela segurança precisa ser implementada em relação à sua pilha de tecnologia e fluxo de trabalho.

Codificação segura = a cesta “muito difícil”?

A pesquisa da Evans Data trouxe à luz que impressionantes 86% dos desenvolvedores acham desafiador praticar codificação segura, com 92% dos gerentes de desenvolvedores também admitindo que suas equipes precisavam de mais treinamento em estruturas de segurança. Preocupantemente, 48% dos entrevistados admitiram que conscientemente deixam vulnerabilidades em seu código.

Isso pinta um quadro muito preocupante. Parece que, geralmente, os desenvolvedores não estão recebendo treinamento frequente e adequado, nem estão recebendo exposição suficiente às boas práticas de segurança e higiene. Lendo nas entrelinhas, isso reforça o cerne da questão: simplesmente não é uma prioridade para os desenvolvedores considerar a segurança em seu trabalho. Isso e o treinamento que eles recebem não aumenta sua confiança ou habilidades práticas, nem os ajuda a entender o impacto de sua decisão de enviar código vulnerável.

O ataque de ransomware Colonial Pipeline foi um dos incidentes de segurança da cadeia de suprimentos mais perturbadores no ano passado, provocando medo de que metade do fornecimento de gás na costa leste dos Estados Unidos fosse cortado por um período indeterminado. Felizmente, eles voltaram a funcionar rapidamente, mas não sem uma apreensão significativa na comunidade. Foi um daqueles momentos difíceis em que o público em geral enfrentou a perspectiva de um incidente cibernético afetando seriamente um elemento do mundo físico que não é necessariamente pensado como orientado por software ou um risco de um ataque cibernético. E todo esse caos foi possibilitado por duas vulnerabilidades antigas e não corrigidas, uma das quais era a insidiosa, mas amplamente conhecida, injeção de SQL. Se os desenvolvedores soubessem o que realmente estava em jogo quando optaram por enviar código vulnerável, veriam rapidamente que não há cenário em que isso seja um risco comercial aceitável.

O “PPT” funcional não depende do desenvolvedor.

O famoso “triângulo dourado” de Pessoas, Processos e Ferramentas não é alcançável sem uma estratégia cuidadosamente considerada, e os desenvolvedores não estão em condições de assimilar um processo de segurança de trabalho sem considerar suas necessidades e desafios.

Será necessária uma mudança de cultura considerável para aprimorar a segurança orientada ao desenvolvedor e começa com caminhos educacionais que levam os engenheiros e a equipe de segurança a uma maior clareza.