Rodrigo Brito

Será que estamos jogando para ganhar?

Em nosso dia a dia como profissionais de segurança da informação, especialmente atuando na trincheira do Red Teaming e buscando integrar segurança desde o berço com DevSecOps, frequentemente nos deparamos com uma crença comum, mas perigosa: a de que "segurança no pipeline" se resume a rodar um SAST aqui e um scanner de dependências ali. É como acreditar que colocar um cadeado na porta garante a segurança de uma casa inteira.

Com a experiência de quem veste o chapéu do atacante e desenvolvedor, posso afirmar com convicção: testar como um atacante é fundamentalmente diferente de testar como um desenvolvedor. Enquanto o desenvolvedor busca garantir a funcionalidade e a qualidade do código, o atacante procura, com olhar clínico e malicioso, as brechas, as configurações descuidadas, os caminhos não óbvios para comprometer o sistema.

Se o seu pipeline CI/CD, por mais moderno e automatizado que seja, ainda patina em pontos cruciais como:

• Ignorar a segurança das configurações de containers, deixando de lado a preocupação com possíveis fugas ($container\; escape$) que dariam ao atacante acesso ao host subjacente ou com a facilidade com que ele poderia se movimentar lateralmente ($pivoting$) entre os containers (como bem detalhado em frameworks como o MITRE ATT&CK® para Containers [1]);
• Não simular ataques reais contra suas APIs e aplicações em pré-produção, confiando apenas em testes funcionais ou de carga, sem explorar vulnerabilidades comuns como injeção de SQL, cross-site scripting (XSS) ou quebras de autenticação (amplamente documentadas no OWASP Top Ten [2] para APIs e aplicações web);
• Deixar de lado testes de segurança "adversariais" em branches críticas, permitindo que vulnerabilidades se acumulem no código antes mesmo de chegar à fase de integração principal;
• Não ter um olhar atento e em tempo real para alterações sensíveis e não rastrear ações que fogem do comportamento normal, perdendo a chance de detectar um ataque em seus estágios iniciais (uma prática fundamental em qualquer estratégia de detecção e resposta [3]).

Então a verdade é que a superfície de ataque do seu ambiente continua escancarada. É como ter um sistema de alarme sofisticado, mas deixar as janelas abertas.

Qual a luz no fim do túnel? Integrar a inteligência do Red Team diretamente no seu pipeline. Imagine utilizar o conhecimento prático de como invasores realmente agem dentro de um sistema para criar testes automatizados que "pensam" como eles. Em vez de apenas procurar por vulnerabilidades conhecidas, esses testes simulam cenários de ataque complexos, explorando a interação entre diferentes componentes e configurações.

Além disso, podemos criar "gatilhos" para revisões manuais quando padrões de comportamento incomuns forem detectados. Se uma alteração de configuração em um container crítico acontecer fora do fluxo normal, ou se um padrão de acesso à API levantar suspeitas, um especialista em segurança ofensiva pode ser acionado para uma análise mais aprofundada.

Porque, no fim das contas, DevSecOps não é apenas sobre as ferramentas que você implementa. É sobre cultura, sobre incorporar a mentalidade de segurança em cada etapa do desenvolvimento. É sobre inteligência, utilizando o conhecimento de ameaças reais para guiar suas defesas. E, acima de tudo, é sobre antecipação, buscando ativamente as brechas antes que um atacante as encontre.

Estamos realmente fazendo o suficiente para proteger nossos ambientes de desenvolvimento? A resposta, para muitos, ainda é um sonoro "não". Mas a boa notícia é que temos o conhecimento e as técnicas para mudar esse jogo. Precisamos apenas da coragem de ir além do básico e integrar a visão do atacante em nosso dia a dia.

Referências:

• [1] MITRE ATT&CK® for Containers: https://attack.mitre.org/matrices/enterprise/containers/
• [2] OWASP Top Ten: https://owasp.org/www-project-top-ten/
• [3] NIST Cybersecurity Framework - Identify, Protect, Detect, Respond, Recover: https://www.nist.gov/cyberframework (especialmente a função "Detect")