Tudo que vem antes da contêinerização de uma aplicação está nas mãos do desenvolvedor e do engenheiro DevOps, que tem a tarefa de construir e manter as integrações necessárias em todo o ciclo de desenvolvimento de software.

Pensando do ponto de vista do desenvolvedor, a responsabilidade deste profissional gira em torno de:

• Atender as demandas de negócio, criando serviços e funcionalidades que permitam a “tradução” da regra de negócio.

• (periodicamente) auxiliar no design da solução, fornecendo insights e trabalhando com staff engineers, arquitetos de solução e outros engenheiros na construção da arquitetura.

• Construir código “bem escrito”, seguindo as boas práticas de engenharia, guardrails de qualidade e segurança da empresa em que trabalha.

• Realizar manutenção nas bases de código existentes no ambiente, sejam elas de sua autoria ou da autoria de outros engenheiros.

Nós, profissionais de segurança, sabemos que até o melhor dos engenheiros está sucetível ao erro. Nós também estamos. Por isso existem os controles, para “pegar” o que os olhos humanos não pegaram.

Dito isso, os controles implementados nas pipelines de DevSecOps são para evitar que erros não vistos e escondidos dentro da aplicação, passem despercebidos. Não é por desconfiança no trabalho dos desenvolvedores e dos times de engenharia de software que esses controles existem, eles servem como aliados dos desenvolvedores, que uma vez que recebem o rápido “feedback” das ferramentas de qualidade, podem ajustar seus entregáveis.

Controles

Sabemos que esses controles existem, mas afinal de contas, o que são eles? Para que servem? O que analisam?

SCA - Software Composition Analysis

Como todo código hoje em dia faz uso de bibliotecas externas e de SDKs para integrações com os mais diversos service providers do mundo, é crucial que essas relações de dependência com fornecedores externos seja mapeada e esteja visível.

As ferramentas de Software Composition Analysis auxiliam nesta atividade, fazendo um scanning nas bibliotecas e avaliando a conformidade com o licenciamento das mesmas.

Ferramentas de mercado: Snyk e WhiteSource

XAST - X Application Security Testing

Agora vamos comentar de uma série de ferramentas que fazem análise do código escrito de maneiras diferentes. Os acrônimos mencionados abaixo são frequentemente mencionados nas conversas entre os times de DevOps, pois representam um pilar muito importante na cultura de segurança de uma empresa, o de Segurança de Código.

Essas ferramentas são utilizadas em momentos diferentes do ciclo de desenvolvimento de software, oferecendo insights diferentes em cada um desses momentos, insights esses que fazem com que o desenvolvedor compreenda melhor o comportamento da aplicação dele mediante determinados cenários.

Essas análises diferenciadas habilitam a redução da superfície de ataque das aplicações, dado que os cenários avaliados são mais extensos e permitem a captura mais precisa de falhas de segurança.

SAST - Static Application Security Testing

Aqui temos a primeira validação do código escrito pelo engenheiro. A análise será feita de forma estática, com o código sem compilação, do jeito que está no repositório.

Essa primeira análise busca por erros “comuns” presentes no código fonte, erros como SQL Injection e Cross-Site Scripting são capturados antes que possam expor a aplicação à falhas graves de segurança.

Ferramentas de mercado: SonarQube e Fortify

DAST - Dynamic Application Security Testing

Após a análise do SAST, temos o DAST, que faz seu scanning após a compilação da aplicação.

As falhas aqui identificadas são mais sofisticadas e de difícil captura. Aqui, todo o contexto é levado em conta, não apenas o código escrito pelo usuário.

Os problemas aqui identificados costumam ser mais complexos e caros de se corrigir, visto que há a necessidade de se fazer toda uma análise nos componentes da aplicação para alterar seu funcionamento, mitigando a vulnerabilidade. Esse trabalho costuma ser feito em conjunto com os times de arquitetura, que precisam compreender as ligações entre os componentes para evitar que essa vulnerabilidade se espalhe para outras aplicações.

Ferramentas de mercado: Burp Suite

IAST - Interactive Application Security Testing

Tudo que falamos das ferramentas anteriores é integrado em uma só, com o IAST!

Essas soluções visam capturar com mais precisão e efetividade os problemas de segurança identificados nos passos anteriores. Essa precisão nos ajuda a validar as identificações, que muitas vezes podem ser o que chamamos de “falsos positivos".

Com casos de uso definidos, a ferramenta configurada fará a análise de uso da aplicação, validando se as vulnerabilidades são verdadeiramente exploráveis.

O uso computacional de uma ferramenta de IAST é muito mais alto do que o das ferramentas anteriores, muito por sua complexidade, robustez e cobertura, portanto é crucial que sua solução de IAST esteja bem parametrizada e com seus workflows bem definidos.

Ferramentas de mercado: Seeker

Secret Scanning

Agora já não estamos mais falando de como o código está escrito, mas sim o que está contido nele.

Na era da segurança, toda chamada deve ser autenticada e autorizada, garantindo que apenas o “dono” de um recurso tenha acesso a ele.

Essas camadas de segurança apresentam certa complexidade na escrita do código, visto que muitas vezes o engenheiro precisa trabalhar com múltiplas credenciais com o propósito de validar as chamadas ao ambiente.

Para evitar que credenciais sejam enviadas aos repositórios de código, as pipelines devem implementar controles para identificar possíveis credenciais “mockadas”, que possam ser vazadas ao público uma vez que o repositório não esteja bem protegido.

Essa análise pode ocorrer em diversas etapas do processo, tanto nas automações, quanto diretamente no repositório de código, através do uso das capacidades avançadas da sua plataforma. Utilizar um ecossistema como o presente no GitHub, permite que o administrador da ferramenta tenha uma visão completa dos repositórios que contém algum tipo de credencial salva. Essa visão permite a criação de workflows de notificação aos owners dessas aplicações como também o estabelecimento de guardrails, que podem evitar que códigos com credenciais embutidas sejam enviados aos repositórios das mesmas.

Ferramentas de mercado: GitHub Advanced Security e GitGuardian

Indo além das ferramentas

Ferramentas são ótimas e nos permitem passar ao ambiente uma visão esperada pelos times de segurança da empresa, porém nem sempre temos facilidade para modificá-las.

Como qualquer plataforma, ao ser selecionada, o time responsável por ela se encontra em uma gangorra, que equilibra a capacidade de personalização daquela ferramenta e o custo de operacionalização da mesma.

Quanto mais personalização, mais complicada de se manter, porém com mais possibilidades.

Menos personalização significa menos possibilidades, contudo, mais facilidade na manutenção.

No final das contas as ferramentas não são nada além de softwares. Softwares esses que podem conter vulnerabilidades e falhas, como as aplicações que nós escrevemos.

Para aumentarmos ainda mais a superfície coberta do nosso ambiente, é crucial que os times de engenharia de plataforma e segurança façam um trabalho de “evangelização” dos desenvolvedores da sua empresa. É necessário que eles não só entendam a necessidade e os controles implementados, mas também que saibam receber o feedback dessas plataformas.

Além disso não podemos virar nossas costas aos treinamentos. Melhor que um cenário onde você encontre desenvolvedores despreparados e ferramentas bem configuradas, é quando achamos ferramentas bem configuradas e desenvolvedores BEM CAPACITADOS. Desenvolvedores esses que melhoram seu código escrito a cada semana que passa, utilizando da análise das ferramentas e dos treinamentos fornecidos como seus aliados na construção de uma melhor plataforma.

Cursos externos, playlists no YouTube, treinamentos internos ministrados por especialistas no assunto, plataformas de codificação, artigos na internet, tudo que possa servir como fonte de conhecimento para o desenvolvedor deve ser considerado. Essas capacidades devem ser passadas aos novos engenheiros (ingressantes na empresa e estagiários efetivados) e aos experientes, oferecendo a eles a possibilidade de fornecimento de feedback para melhoria dos materiais. Os insumos também devem ser atualizados de maneira frequente, para que sempre correspondam aos controles recomendados pela empresa.

Não é só uma ferramenta de SCA ou SAST que fará com que o seu ambiente esteja seguro e protegido de vulnerabilidades. O verdadeiro shift-left começa com o seu desenvolvedor sabendo o que está fazendo!

Mesmo no momento em que nos encontramos hoje, com o crescimento cada vez maior de ferramentas de inteligência artificial e popularização do vibe coding, quem coloca o código em produção é o desenvolvedor, não o “robô". Não há melhor controle do que um engenheiro que sabe o que faz. Te poupará dores de cabeça no curto, médio e longo prazo.

Invista nos seus engenheiros!

Nos vemos em breve com mais conteúdo sobre security!

Até logo! :)