0
0
Estamos vendo um aumento significativo nos ataques contra aplicativos, como scripts entre sites, ataques de força bruta e injeções de SQL, o que está gerando preocupações significativas. Tanto que a segurança de aplicativos foi rotulada como “inegociável” e se tornou uma prioridade para muitos, enquanto Jen Easterly, diretora da Agência de Segurança Cibernética e Infraestrutura (CISA), está fazendo campanhapara que a indústria de tecnologia assuma a responsabilidade por produtos seguros.
Soluções de tecnologia como teste de penetração e varredura de código são inegavelmente valiosas para mitigar software inseguro, mas por si só não são suficientes. Até 70% das organizações estão perdendo etapas críticas de segurança em seu ciclo de vida de desenvolvimento de software (SDLC) e as vulnerabilidades estão aumentando exponencialmente. Para resolver esse dilema, as empresas precisam mudar seu foco de encontrar, corrigir e corrigir vulnerabilidades para garantir proativamente que não forneçam códigos inseguros em primeiro lugar. Isso requer visão humana e, como resultado, maior investimento em educação para todos os responsáveis pelo desenvolvimento de software para garantir que eles possam não apenas reconhecer os principais princípios e vulnerabilidades de segurança, mas também aplicar seus conhecimentos a novas situações para proteger melhor os aplicativos.
Indo além da digitalização de código
Uma dependência excessiva de ferramentas de varredura de código ou ferramentas de análise de código-fonte é um exemplo de segurança que foi deixada muito para trás no SDLC. A varredura de código para identificar vulnerabilidades antes que um aplicativo seja lançado é uma peça chave na máquina segura de desenvolvimento de software, mas a prevenção é sempre melhor do que remediar (como sabemos pela lei de Boehm que as falhas se tornam mais caras de corrigir com o tempo).
O principal problema é que as ferramentas de varredura de código correm o risco de um grande número de falsos positivos, levando eventualmente à “fadiga de alerta”, onde os desenvolvedores ignoram quaisquer falhas sinalizadas, eventualmente criando uma falsa sensação de segurança. Além do mais, quando problemas críticos são destacados, provavelmente se torna responsabilidade do desenvolvedor identificar e corrigir esse código inseguro, e eles precisam do conhecimento para realmente aplicar essas correções.
É aqui que entra um maior investimento em treinamento de codificação segura e educação contínua para o desenvolvedor e todos que os apoiam no SDLC. A varredura de código ainda tem um papel significativo a desempenhar, mas seria muito mais valiosa se apoiada por treinamento programático em segurança princípios e boas práticas. Isso não é apenas para aumentar a “conscientização” das principais vulnerabilidades, mas para capacitar as equipes com o conhecimento para codificar com segurança e evitar problemas críticos antes que cheguem às ferramentas de verificação ou mesmo à produção. Também pode reduzir a carga sobre os desenvolvedores, evitando pressão adicional para corrigir no último estágio. Em vez disso, a abordagem deve ser “começar pela esquerda” e garantir que a segurança seja incorporada desde o início (conforme defendido por Easterly).
A pesquisa apóia isso; uma pesquisa da EMA com profissionais de desenvolvimento de software constatou que apenas 10% das organizações que utilizam ferramentas de verificação de código evitam mais vulnerabilidades do que aquelas que não o fazem. No entanto, o treinamento contínuo melhorou muito a segurança do código para mais de 60% das organizações que o adotaram. Mas não é necessariamente o caso de um ou outro: a EMA argumenta que uma combinação de varredura de código, revisões de código e treinamento contínuo de terceiros é a melhor abordagem para um desenvolvimento de software mais seguro.
Adotando Hábitos Mais Seguros
Coding securely essentially needs to become a more lasting and ingrained habit. Yet behavioral change is challenging without the knowledge and education to support it. Truly enacting change to ensure application security becomes nonnegotiable means investing in developer and SDLC team training that encourages and enables more secure habits. And it’s important to recognize that these secure habits will change depending on the role of each professional.
Por exemplo, os líderes de desenvolvimento não serão pessoalmente responsáveis pelo desenvolvimento do código, portanto, em vez disso, precisarão ver como eles se tornam responsáveis pelo desenvolvimento de aplicativos com menos vulnerabilidades. Garantir que os recursos de segurança sejam considerados recursos de “bote salva-vidas” – um elemento essencial antes de liberar o código – pode exigir uma mudança de hábitos, mas será inestimável para aumentar a segurança do aplicativo. Para os próprios desenvolvedores de software, seus hábitos de segurança podem abranger todas as verificações ou revisões de código importantes no início do processo de desenvolvimento, mas isso só será relevante se eles puderem reconhecer o valor da codificação segura e tiverem o conhecimento para reduzir tantas vulnerabilidades como eles podem em primeiro lugar.
Se ainda não o fez, é hora de dar o primeiro passo para resolver esse dilema de segurança de aplicativos. No entanto, o SDLC precisa ir muito além do patch reativo e da varredura de código e, em vez disso, procurar como capacitar as equipes, reduzir os fardos do estágio final e investir em educação contínua se quisermos realmente mudar o rumo das crescentes vulnerabilidades dos aplicativos.
FONTE: DARK READING