O que os desenvolvedores precisam para combater a batalha contra vulnerabilidades comuns.

O cenário de ameaças de hoje está em constante evolução e agora, mais do que nunca, organizações e empresas em todos os setores têm uma necessidade crítica de produzir e manter software seguro de forma consistente. Embora algumas verticais - como o setor financeiro, por exemplo - estejam sujeitas a requisitos regulatórios e de conformidade há algum tempo, estamos vendo um aumento constante na atenção às melhores práticas de segurança cibernética nos níveis mais altos do governo, com os EUA, Reino Unido e A Austrália está lançando uma luz muito recente sobre a necessidade de um desenvolvimento seguro em todas as fases do SDLC.
O cenário de ameaças de hoje está em constante evolução e agora, mais do que nunca, organizações e empresas em todos os setores têm uma necessidade crítica de produzir e manter software seguro de forma consistente. Embora algumas verticais - como o setor financeiro, por exemplo - estejam sujeitas a requisitos regulatórios e de conformidade há algum tempo, estamos vendo um aumento constante na atenção às melhores práticas de segurança cibernética nos níveis mais altos do governo, com os EUA, Reino Unido e A Austrália está lançando uma luz muito recente sobre a necessidade de um desenvolvimento seguro em todas as fases do SDLC.
Compartilhe

O cenário de ameaças de hoje está em constante evolução e agora, mais do que nunca, organizações e empresas em todos os setores têm uma necessidade crítica de produzir e manter software seguro de forma consistente. Embora algumas verticais – como o setor financeiro, por exemplo – estejam sujeitas a requisitos regulatórios e de conformidade há algum tempo, estamos vendo um aumento constante na atenção às melhores práticas de segurança cibernética nos níveis mais altos do governo, com os EUA, Reino Unido e A Austrália está lançando uma luz muito recente sobre a necessidade de um desenvolvimento seguro em todas as fases do SDLC.

Apesar disso, os invasores estão constantemente encontrando novas maneiras de contornar até mesmo as proteções e defesas mais avançadas. Por exemplo, muitos mudaram seu foco de fornecer malware para comprometer APIs ou lançar ataques direcionados contra uma cadeia de suprimentos . E enquanto esses incidentes de alto nível estão acontecendo com uma frequência muito maior, o mesmo acontece com as explorações mais simplistas, como cross-site scripting e injeção de SQL, que têm sido um flagelo nas defesas de segurança cibernética por décadas. No mês passado , uma vulnerabilidade crítica de injeção de SQL foi relatada em um plug-in WordPress WooCommerce, com uma classificação de gravidade de 9,8/10.

Está ficando claro que, embora as plataformas e defesas de segurança cibernética sejam componentes críticos na defesa contra ataques modernos, o que é realmente necessário é um código seguro que possa ser implantado sem vulnerabilidades. E isso requer um aumento deliberado e comprometido em padrões de codificação seguros, acionados por desenvolvedores conscientes da segurança.

Muitos desenvolvedores dizem que estão dispostos a defender a segurança e se comprometer com padrões mais altos de qualidade de código e saída segura, mas não podem fazer isso sozinhos. Não podemos ignorar as necessidades dos desenvolvedores na luta contra vulnerabilidades comuns, e eles precisam do suporte de ferramentas e treinamento adequados, bem como de uma reformulação das métricas tradicionais pelas quais são frequentemente julgados por seus empregadores e organizações.

Por que a maioria dos desenvolvedores ainda não prioriza a segurança#

As melhores práticas de codificação continuaram a evoluir ao longo dos anos, em resposta às necessidades de negócios e às tendências do mercado. No passado, a maioria dos aplicativos era criada usando o chamado modelo de desenvolvimento em cascata , no qual os engenheiros de software trabalhavam para deixar seu código pronto para atender a uma série contínua de marcos ou metas antes de passar para a próxima fase de desenvolvimento. O Waterfall tendia a apoiar o desenvolvimento de programas que, tendo cumprido todos os marcos anteriores ao longo do caminho, estavam livres de bugs ou falhas operacionais quando estavam prontos para o ambiente de produção. Mas, pelos padrões de hoje, era dolorosamente lento, às vezes com 18 meses ou mais entre o início de um projeto e a chegada à linha de chegada. E isso não vai funcionar na maioria das empresas hoje em dia.

método ágil tendeu a substituir Waterfall, colocando uma ênfase muito maior na velocidade. E isso foi seguido pelo DevOps, que é construído para ainda mais velocidade, combinando desenvolvimento e operações para garantir que os programas estejam prontos para produção quase assim que eles concluírem os ajustes finais de desenvolvimento.

Colocar a velocidade acima da segurança e quase tudo além da funcionalidade era uma necessidade à medida que o ambiente de negócios evoluía. Em um mundo baseado em nuvem, onde todos estão online o tempo todo e transações móveis aos milhões podem acontecer a cada poucos segundos, implantar o software e colocá-lo no pipeline de integração contínua e entrega contínua (CI/CD) o mais rápido possível é uma missão crítica para negócios.

Não é que as organizações não se preocupassem com a segurança. É que no ambiente de negócios competitivo que existe na maioria das indústrias, a velocidade era vista como mais importante. E os desenvolvedores que conseguiram igualar essa velocidade prosperaram a ponto de se tornar o principal meio pelo qual seu desempenho no trabalho era julgado.

Agora que os ataques avançados estão aumentando drasticamente, a implantação de código vulnerável está se tornando uma responsabilidade. A preferência está mudando mais uma vez, com a segurança se tornando cada vez mais o foco principal do desenvolvimento de software, com a velocidade em segundo lugar. Aumentar a segurança após o fato não é apenas perigoso, mas também retarda o processo de implantação do software. Isso levou ao surgimento da metodologia DevSecOps , que tenta mesclar velocidade e segurança para ajudar a gerar código seguro e considerar a segurança como uma responsabilidade compartilhada. Mas os desenvolvedores treinados para velocidade pura não podem se tornar funcionalmente conscientes da segurança sem muito suporte de suas organizações.

O que os desenvolvedores precisam para realmente causar impacto na redução de vulnerabilidades#

A boa notícia é que a maioria dos desenvolvedores deseja ver uma mudança na codificação segura e uma repriorização da segurança como parte do processo de desenvolvimento. Em uma pesquisa abrangente realizada pela Evans Data com mais de 1.200 desenvolvedores profissionais trabalhando ativamente em todo o mundo no início deste ano, a esmagadora maioria disse apoiar o conceito de criação de código seguro. A maioria também esperava que isso se tornasse uma prioridade em suas organizações. No entanto, apenas 8% dos entrevistados disseram que escrever um código seguro era fácil de realizar. Isso deixa muito espaço para melhorias dentro das equipes de desenvolvimento da maioria das organizações entre o que é necessário e o que é necessário para chegar lá.

Simplesmente exigir um código seguro não resolverá o problema e, sem esforço para desenvolver as habilidades e a conscientização corretas, será altamente prejudicial para o fluxo de trabalho. As equipes de desenvolvimento precisam existir em um ambiente que alimente sua mentalidade de segurança e promova uma cultura de responsabilidade compartilhada.

A maior necessidade é um melhor treinamento para eles, seguido de ferramentas que ajudem a tornar a codificação segura uma parte perfeita de seu fluxo de trabalho. E o programa deve ser customizado para que desenvolvedores menos experientes possam começar seu treinamento aprendendo a reconhecer os tipos de vulnerabilidades comuns que frequentemente se infiltram no código, com muito aprendizado prático e exemplos. Enquanto isso, desenvolvedores mais avançados que demonstram suas habilidades de segurança podem, em vez disso, ser encarregados de bugs mais complexos e talvez até de conceitos avançados de modelagem de ameaças.

Além de financiar e apoiar programas de treinamento, incluindo dar aos desenvolvedores tempo suficiente longe da codificação para participar adequadamente desses programas, as organizações também precisam mudar a maneira como sua coorte é avaliada. A principal métrica para recompensar os desenvolvedores precisa se afastar da velocidade bruta. Em vez disso, as avaliações poderiam recompensar aqueles que podem criar um código seguro livre de vulnerabilidades ou explorações. Sim, a velocidade também pode ser um fator avaliado, mas, acima de tudo, o código precisa ser seguro e o desenvolvimento moderno precisa forjar um caminho em que a segurança na velocidade não seja mais um mito.

O envio de código inseguro ou vulnerável não deve ser um risco comercial aceitável, e aumentar a segurança após o fato está se tornando cada vez mais ineficaz. Felizmente, a melhor arma para combater essa tendência perturbadora é fazer com que a comunidade de desenvolvedores produza um código seguro que os invasores não possam explorar. A maioria dos desenvolvedores está disposta a enfrentar esse desafio; dar-lhes o apoio para que isso aconteça.