A utilização de DevSecOps em Engenharia de Dados
Hoje, resolvi trazer esse post para falar de um assunto que vim estudando durante esse ano e que eu usei como trabalho final na minha pós em Engenharia de Dados.
A motivação desse trabalho começou justamente como ocorre nessa imagem anterior: Analistas de segurança e desenvolvedores trabalhando juntos para priorizar as vulnerabilidades. Enquanto o time de operações tenta priorizar novas funcionalidades nas aplicações para que assim seja possível melhorar ferramentas, analistas de segurança tentam mostrar como é importante o business entender que correções de vulnerabilidades precisam fazer parte do dia a dia do desenvolvedor até criarem o mindset de desenvolvimento seguro.
Assim, quando pensamos em DevSecOps, pensamos em esteira que compõe todo o ciclo de desenvolvimento de um software e automações que possam ser utilizados durante esse ciclo para que ajude a trazer maturidade, segurança e qualidade para as aplicações.
Diante disso, sabemos que existem diversas ferramentas que podemos utilizar desde a fase de build até o deploy da aplicação. Por conta disso, precisamos criar um processo para que seja possível adicionar as correções de vulnerabilidades nas sprints e que possível acompanhar o entendimento dos desenvolvedores frente ao tema.
Nesse trabalho, eu utilizei algumas ferramentas que pudessem gerar outputs frente ao SAST, DAST e SCA. Assim, o trabalho seguinte, do analista de segurança, é retirar os falsos positivos referentes as ferramentas e levar a informação para o desenvolvedor sobre os pontos que ele precisa corrigir.
Além disso, podemos gerar um dashboard de acompanhamento sobre as correções, gerar insights de como melhorar a abordagem da cultura (Security Champions) ou mesmo, mostrar aos gestores como as correções estão ocorrendo ou que tipo de vulnerabilidade está acontecendo com maior frequência.
A partir desses pontos definidos, foram utilizadas as seguintes ferramentas por serem bastante populares na área de segurança, possuírem alta assertividade nos alertas de vulnerabilidades e pela grande parte ser OpenSource:
- Snyk — Ferramenta utilizada para analisar vulnerabilidade em código (SAST)
- WhiteSource — Ferramenta utilizada para checagem de dependências (SCA)
- OWASP ZAP API — Ferramenta utilizada para análise dinâmica na aplicação (DAST)
- Dependency Check — Ferramenta utilizada para checagem de dependências (SCA)
- Bandit — Ferramenta utilizada para analisar vulnerabilidade em código (SAST) exclusivo para linguagem Python
As ferramentas escolhidas fazem parte do seguinte grupo e escopo de tecnologias frente a segurança: SAST (Teste de código da aplicação), DAST (Teste dinâmico na aplicação) e SCA (Checagem de bibliotecas da aplicação).
Após a análise, foram desenvolvidos diversos scripts que obtivessem as informações de vulnerabilidades, desenvolvidas na linguagem Python, por meio de repositórios obtidos no Github e Gitlab.
Para a extração dessas informações das APIs referentes ao Gitlab, foi necessário adicionar na pipeline de CI/CD do mesmo, uma opção de artefato, pois apenas dessa maneira, era possível extrair o objeto JSON que seria utilizado para desenvolvimento de arquivo CSV e a concatenação das diversas extrações em um único arquivo CSV final.
É possível analisar o csv final gerado com todas as vulnerabilidades presentes nos repositórios escolhidos no Github e Gitlab, além das ferramentas que foram integradas.
O código para o desenvolvimento da sprint encontra-se nesse repositório:
Após a etapa das escolhas de ferramentas de segurança, escolhi um banco de dados SQL para armazenar as vulnerabilidades, principalmente os status, para que pudesse criar as métricas necessárias para o entendimento da cultura de desenvolvimento seguro.
Dessa maneira, foi escolhido o MySQL, por ser um banco SQL, conforme explicado anteriormente e que possui uma integração muito boa com as bibliotecas em Python (linguagem utilizada no projeto majoritariamente). A linguagem Python foi utilizada por ser muito comum em projetos de Engenharia de dados e análise de dados.
Enquanto o Airflow foi escolhido por ter grande integração com a linguagem Python. Como também, ele é comumente utilizado na área de dados para a realização de uma pipeline de ETL (Extração, transformação e carregamento desses dados ). Um outro ponto a ser ressaltado também, como premissa do projeto, era utilizar ferramentas opensource, como ocorre com o Airflow.
Após os dados populados e os scripts das APIs estarem funcionando, foi necessário criar uma dag que pudesse criar cada uma das etapas e de maneira automatizada.
Assim, podemos analisar o script na imagem abaixo, onde foi adicionado para o script rodar mensalmente para coletar as vulnerabilidades. Esse tempo foi escolhido porque é um tempo comum para o desenvolvedor fazer o deploy (levar a aplicação para produção, após esse tempo).
Como também, podemos analisar que os scripts em Python são chamados por cada dag.
Por fim, podemos observar a pipeline executando de maneira funcional, no Airflow.
Na figura abaixo, podemos observar os dados coletados, através do visualizador de dados, DBeaver.
Por último, foi escolhida a ferramenta Trello para realizar o gerenciamento das tarefas dos desenvolvedores.
Essa escolha do Trello deve-se pela facilidade da utilização da API para adicionar cards ou atualizá-los por meio de uma ótima documentação.
Outro ponto que o Trello foi crucial para esse projeto é ter como premissa um quadro simples e muito intuitivo para a utilização da metodologia do Kanban que tem como premissa ser simples, incremental e que utiliza cards para tornar o gerenciamento visual.
Assim, foi criado um quadro que será utilizado nesse trabalho, como PoC (Prova de Conceito).
Após os testes, podemos observar o Airflow rodando com a etapa de integração da API do Trello. Isso pode ser visto na imagem abaixo, na etapa de “generate-card-trello”. Além disso, podemos observar que essa fase foi concluída com sucesso, portanto, sem erro na atualização ou inserção de um novo item no Trello.
Assim, conforme figuras abaixo, podemos ver a sequência de três etapas:
- A primeira imagem abaixo, é possível observar a inserção de um novo item na coluna “To Do”, após o processo do Airflow ter iniciado.
- Na segunda imagem abaixo, podemos ver esse mesmo item que agora está sendo tratado pelo time de desenvolvimento, na coluna “Testing”.
- Na terceira imagem, após o status desse item ter sido alterado, ou seja, concluído, a pipeline envia de forma automatizada para a coluna “Done”.
Nessa imagem abaixo, disponibilizada pelo Airflow, podemos observar todas as etapas funcionando do início ao final do processo.
Por fim, podemos observar o Dashboard criado no Data Studio na imagem abaixo. Nesse Dashboard podemos filtrar pelo tipo de vulnerabilidade, ferramentas de SAST, DAST e SCA, como time responsável pela tratativa de vulnerabilidade (Squad) e quantidade de vulnerabilidades de acordo com a severidade e data limite para essa resolução.
Assim, é possível fazer um acompanhamento personalizado com os desenvolvedores e gerar insights para garantir a segurança das aplicações.
Aqui eu trouxe um resumo de como foi o trabalho e como é possível juntarmos áreas que podem parecer distantes inicialmente.
No entanto, podemos ver que é possível juntar diferentes ideias e gerar um grande valor tanto para a empresa, o negócio e principalmente para a área de segurança ❤
Espero que tenham gostado 💜
Qualquer dúvida, podem me chamar e o código do projeto está aqui:
Obrigada 👩💻
