Skip links

DevSecOps: o que você precisa saber sobre segurança no desenvolvimento de aplicações

Se você é desenvolvedor, profissional de DevOps ou arquiteto de software, saiba: provavelmente sua aplicação está sob ataque de cibercriminosos neste momento – mesmo que ainda não tenha sido lançada.

Uma pesquisa divulgada em julho deste ano analisou 1,6 trilhão de dados coletados durante a execução de aplicações em produção. A conclusão foi de que, em geral, essas aplicações são atacadas a cada 3 minutos. Além disso, os atacantes são capazes de explorar novas falhas em apenas 5 dias, enquanto a correção pode levar 84 dias, em média.

O caminho mais eficiente de evitar que ataques sejam bem-sucedidos é incluir DevSecOps nos ciclos de desenvolvimento da aplicação. Neste artigo, vamos explicar os conceitos fundamentais de DevSecOps e porque é tão importante que essa prática faça parte da produção do software.

O que é DevSecOps?

DevSecOps é a prática de integrar segurança (Security) em cada etapa do ciclo de vida de desenvolvimento de um software, principalmente desde o início com a metodologia do Shift-left Security, garantindo que cada etapa — do código à produção — seja pensada, construída e monitorada de forma segura. DevSecOps integra três times: cibersegurança, desenvolvimento e operacional.

Ferramentas de teste: a família AST

AST significa Application Security Testing. E um conjunto de práticas, metodologias e ferramentas utilizadas para identificar vulnerabilidades em diferentes camadas do processo de desenvolvimento de aplicações (SDLC).

Há 6 tipos principais de AST:

  1. SAST (Static Application Security Testing): faz análise estática do código fonte ou binários e busca vulnerabilidades no código proprietário. Funciona como “corretor ortográfico” para vulnerabilidades. Pode ser implementado na IDE, SCM ou pipeline.
  2. DAST (Dynamic Application Security Testing): realiza análise dinâmica da aplicação em execução, simula pentests automatizados, faz crawling e fuzzing da aplicação e identifica vulnerabilidades que só aparecem em runtime. É um teste complementar ao SAST.
  3. IAST (Interactive Application Security Testing): combina SAST e DAST (dependendo da tecnologia implantada, até SCA). É um agente implantado no container que observa a aplicação em tempo real, mapeia vulnerabilidades durante testes de QA e fornece informações detalhadas como linha de código, URL e tipo de vulnerabilidade.
  4. MAST (Mobile Application Security Testing): análise específica para aplicações mobile combinando técnicas de SAST, DAST e muitas vezes IAST com RASP, para identificar vulnerabilidades tanto no código quanto com o seu comportamento em execução.
  5. SCA (Software Composition Analysis): realiza a análise de bibliotecas e frameworks open source e mapeia vulnerabilidades em dependências diretas e transitivas. É um teste essencial, devido ao uso extensivo de código open source (algo presente em mais de 95% das aplicações).
  6. RASP (Runtime Application Self Protection): é um agente de proteção inserido para bloquear ataques em tempo real e gerar alertas detalhados. Usa machine learning para detecção de tentativas de violação, funciona como camada adicional ao WAF. O RASP existe tanto para aplicações mobile quanto para web.

Todas essas ferramentas estão ligadas diretamente as bases de CWEs e CVEs, que são:

  1. CVE (Common Vulnerabilities and Exposures): Uma classificação de tipos de fraquezas de software, hardware ou até mesmo firmwares, que podem levar a explorações de vulnerabilidades. (Ex. CVE-2021-44228 – Log4Shell)
  2. CWE (Common Weakness Enumeration): Identificador único para a natureza da vulnerabilidade (Ex. CWE-89 – SQL Injection).

Os custos de um ataque bem-sucedido

Os prejuízos financeiros e operacionais são algumas razões que tornam a implantação de DevSecOps fundamental no desenvolvimento de aplicações.

Há exemplos de como essa diferença de custo funciona na prática, como este envolvendo uma vulnerabilidade SQL injection. Esse tipo de vulnerabilidade, que seria corrigida em 30 minutos durante o desenvolvimento da aplicação, pode levar até 15 horas para ser corrigida quando descoberta em produção. A diferença no cálculo de custos, assumindo o valor de US$100/hora, ficaria assim:

  • Correção pós-produção: US$1,500
  • Correção pré-produção: US$50
  • Total: 30 vezes mais caro.

RedTalks: DevSecOps na prática

No primeiro webinar da nossa trilha de DevSecOps, abordamos com mais detalhes esses fundamentos e trazemos casos reais de incidentes que causaram grande impacto a aplicações de todo o mundo, como o Log4j, Apache Struts 2 e o Heartbleed. Assista:

A Redbelt Security pode apoiar a sua empresa adicionando segurança ao desenvolvimento de aplicações sem perder a velocidade de suas entregas. Solicite agora o contato com um de nossos especialistas.

Julio Raveli – consultor DevSecOps III

This website uses cookies to improve your web experience.