Alura > Cursos de DevOps > Cursos de Builds > Conteúdos de Builds > Primeiras aulas do curso DevSecOps e Inteligência Artificial: automatizando a segurança no pipeline

DevSecOps e Inteligência Artificial: automatizando a segurança no pipeline

Segurança Integrada ao Fluxo de Entrega - Introdução

Apresentando o curso e o instrutor

Olá! Eu agradeço por estarem aqui neste curso na Alura. Espero que seja uma jornada de aprendizado para todas as pessoas. Este é um curso sobre DevSecOps (Desenvolvimento, Segurança e Operações) e Inteligência Artificial, e desejo que todas as pessoas possam aproveitar ao máximo o conteúdo.

Eu vou fazer minha autodescrição e minha apresentação. Eu gosto muito de participar de eventos. Meu nome é Amaury, falo do estúdio da Alura. Estou em São Paulo realizando a gravação. É um prazer estar aqui com vocês.

Audiodescrição: Amaury é um homem branco, de cabelo preto e barba escura. Ele veste uma camiseta preta do evento B-Sides. Está no estúdio da Alura, em São Paulo.

Compartilhando trajetória e estrutura do curso

Hoje estou como engenheiro de segurança com foco em nuvem. Já tenho uma boa trajetória na área. Sou professor na FIAP e estou participando da criação deste curso. Gosto muito de participar de eventos da área; sempre que posso, estou em algum meetup (encontro) em São Paulo e, às vezes, vou a Campinas para participar de eventos e conferências. Quando nos encontrarmos, podemos aproveitar para tomar um café e conversar. Acreditamos que a área evolui muito bem quando há proximidade entre as pessoas, pois aprendemos com certeza nesse intercâmbio.

Vamos dar sequência para apresentar a ideia do curso e o que vamos aprender. Teremos um conteúdo distribuído em cinco aulas. Em cada aula, trabalharemos conceitos e teoria para construir uma base sólida e, ao longo de todo o percurso, aplicaremos práticas — tanto em momentos intermediários quanto ao final. Faremos pausas para aproveitar e reforçar o que estamos aprendendo, consolidando a base e os conceitos.

Detalhando a Aula 1 e seus objetivos

Na Aula 1, veremos segurança integrada ao fluxo de entrega. Faremos um paralelo substancial entre segurança, DevSecOps (Desenvolvimento, Segurança e Operações) e Inteligência Artificial. Preparamos um material consistente para aprofundar as principais práticas e inserir a Inteligência Artificial no SDLC (Ciclo de Vida de Desenvolvimento de Software), considerando a perspectiva de segurança e o fluxo de entrega.

Nesta Aula 1, abordaremos pontos principais: desafios, ferramentas, como o DevOps (Desenvolvimento e Operações) evoluiu para o DevSecOps (Desenvolvimento, Segurança e Operações) e como a segurança se tornou mais importante ao longo do ciclo de desenvolvimento.

Antecipando conteúdos das próximas aulas

Nas próximas aulas, aprofundaremos esse conhecimento, criando pipelines (esteiras) mais inteligentes, com maior capacidade de agregação de IA e de outras culturas e aprendizados.

Na Aula 3, veremos dependências, como inserir segurança nessa etapa e como realizar a proteção de supply chain (cadeia de suprimentos). Na Aula 4, abordaremos segurança operacional e em runtime (tempo de execução). Na Aula 5, trabalharemos segurança automatizada e governança operacional, fechando o ciclo e consolidando o aprendizado.

Definindo público-alvo e ferramentas do curso

Este curso é destinado a quem já trabalha com cloud (nuvem), possui familiaridade com DevOps (integração entre desenvolvimento e operações), se interessa por segurança e deseja aplicar IA no dia a dia de projetos e do trabalho, agregando valor. A proposta é incentivar a automação: se hoje há um processo mais manual, queremos automatizá-lo em prol da segurança, sempre buscando experiência prática com ferramentas modernas.

Veremos o uso de Trivy, GitHub Actions e como utilizar a inteligência artificial em uma pipeline (esteira). Também exploraremos ferramentas cloud-native (nativo em nuvem), como o Falco, entre outras que impulsionam o trabalho com dependências e com o ciclo de runtime (tempo de execução). São temas relevantes e atuais no mercado, amplamente utilizados por empresas, com foco em aprender a partir de conceitos e ferramentas reais.

Estabelecendo objetivos e integrando IA ao DevSecOps

Para esta parte inicial da aula, apresentamos alguns objetivos principais: compreender os conceitos centrais de DevSecOps (integração entre desenvolvimento, segurança e operações), a importância de adotar essa metodologia e como a segurança é agregada gradualmente ao fluxo de DevSecOps, aplicado ao desenvolvimento de software.

O curso enfatiza a integração entre DevSecOps (integração entre desenvolvimento, segurança e operações) e inteligência artificial. Nós fazemos questão de fortalecer essa carreira na Alura, pensando em como utilizaremos cada vez mais a IA no desenvolvimento de software. Sabemos que a adoção é irreversível e crescente. Observamos empresas como a Anthropic e várias outras criando novos modelos de agentes mais robustos, ampliando o potencial dessas soluções. Faz sentido adotar essa metodologia e incorporar agentes em nosso fluxo de entrega, colocando a segurança como componente central.

Daremos sequência na Aula 1.1: Segurança integrada ao fluxo de entrega e como os desafios de segurança em ambientes de DevOps (integração entre desenvolvimento e operações) modernos têm mudado.

Segurança Integrada ao Fluxo de Entrega - Desafios de segurança

Introduzindo a segurança no fluxo de entrega

Voltando, esperamos que tenham aproveitado a parte inicial da primeira aula. Agora, na Aula 1.1, vamos focar na segurança integrada ao fluxo de entrega. Como podemos observar os desafios da segurança em ambientes de DevOps (Desenvolvimento e Operações) modernos?

A proposta é retomar o conceito de DevOps, observando que, ao longo do tempo, a segurança foi criando uma barreira dentro desse modelo. Precisamos, gradualmente, incorporar uma visão orientada a DevSecOps (Desenvolvimento, Segurança e Operações), que enfatiza de forma mais robusta a segurança sem perder de vista a velocidade e o fluxo de entrega. Esse é o ponto central.

No cenário moderno, velocidade, automação e novos desafios de segurança tornaram-se marcos do novo contexto de DevOps. Com o avanço da inteligência artificial, identificamos outras possibilidades e novas formas de trabalho, o que torna a segurança ainda mais importante nesse fluxo.

Explorando os desafios de segurança no devops moderno

Hoje, por exemplo, quando falamos de agentes de IA, falamos também de cybercrime (cibercrime). Se não tratarmos a segurança desde o início, com um SDLC (Ciclo de Vida de Desenvolvimento de Software) bem definido, o fluxo da pessoa desenvolvedora tende a ficar mais vulnerável a ataques. Nos últimos meses, vimos claramente nos noticiários incidentes na cadeia de suprimento de software. Em diversos casos, a falta de configuração adequada do princípio do menor privilégio dentro do CI/CD (Integração Contínua/Entrega Contínua), isto é, na esteira de pipeline (esteira), deixou brechas exploráveis. Nosso papel é fortalecer essa postura.

Em ambientes modernos, é comum o uso de tecnologias e práticas como cloud native (nativo em nuvem), contêineres, Kubernetes, CI/CD (Integração Contínua/Entrega Contínua) mais robusto, API (Interface de Programação de Aplicações), microserviços e infraestrutura como código. Esse é o conjunto que compõe o ambiente de DevOps moderno, amplamente utilizado por empresas e projetos em larga escala. Esse é o panorama atual.

Como nos inserimos nesse cenário? Quais são os desafios de segurança no DevOps moderno? A segurança precisa acompanhar a velocidade do DevOps. O DevOps surgiu para acelerar a entrega de software, do desenvolvimento à operação. Como colocamos a segurança nessa mesma velocidade, com equilíbrio e maturidade desde o início do processo? Precisamos considerar essa possibilidade de forma sistemática.

Apontando desafios e referências da owasp

Elencamos, a seguir, alguns dos principais desafios presentes hoje no DevOps moderno e o que eles trazem na prática:

Diante disso, precisamos manter atenção contínua aos riscos críticos do CI/CD. A OWASP destaca esses riscos e fornece diretrizes para monitoramento constante. Trata-se de um dos principais portais com foco em segurança para desenvolvimento e é uma referência para trazer essas práticas para nossos ambientes e projetos, adotando as boas práticas recomendadas pela própria OWASP.

A OWASP disponibiliza um guia muito bom para DevSecOps (Desenvolvimento, Segurança e Operações). Vale a pena observarmos esse material e incorporarmos suas recomendações em nossos fluxos de trabalho.

Isso ajuda bastante. O guia da OWASP Top 10 (dez principais riscos) destaca, por exemplo, segredos expostos, permissões excessivas, execução de código malicioso e dependências comprometidas. Esses são alguns dos principais riscos mapeados, e a OWASP consolida essas referências. É um material útil para estudarmos, consultarmos e aplicarmos com o objetivo de enfatizar e suportar ambientes de DevSecOps (integração de desenvolvimento, segurança e operações) e o uso de inteligência artificial.

Ao longo do curso, vamos passar por outros guias e apresentar outras diretrizes da OWASP. É muito interessante utilizar esses materiais e manter a familiaridade com eles, adotando-os no dia a dia como prática geral, apoiando toda a jornada de desenvolvimento dentro do SDLC (Software Development Life Cycle, ciclo de vida de desenvolvimento de software).

Detalhando a integração do devsecops ao sdlc

Hoje, avançando da parte de desafios para o foco em DevSecOps, observamos o papel do DevSecOps moderno na era da inteligência artificial. Temos a segurança integrada ao SDLC, contemplando etapas como: SCA (Software Composition Analysis, análise de composição de software), SAST (Static Application Security Testing, teste estático de segurança de aplicações), DAST (Dynamic Application Security Testing, teste dinâmico de segurança de aplicações), IaC Scan (Infrastructure as Code, varredura de infraestrutura como código) e Secrets Scan (varredura de segredos).

Também integramos segurança, automação, pipelines (fluxos de integração/entrega), observabilidade e governança contínua. O DevSecOps tem o papel de orquestrar esses pontos em cada etapa do fluxo, tornando mais evidente a aplicação do Shift Left (antecipação da segurança) desde o início do desenvolvimento do código.

Fortalecendo a cultura devsecops e o shift left

Quanto à cultura DevSecOps, é essencial entendermos que não se trata apenas de ferramentas. Precisamos de uma base cultural clara: por que essa metodologia foi criada e como devemos atuar nesse contexto. Devemos promover velocidade, segurança e operação, pensando em fluxo contínuo. A segurança é responsabilidade compartilhada: desde a pessoa desenvolvedora, a pessoa engenheira de DevOps, as pessoas de QA (Garantia de Qualidade) até quem realiza o deploy (implantação). Essa visão faz parte da cultura: cultura + automação + segurança contínua. Quanto mais cedo levarmos a segurança para o início do ciclo, maior será o foco e o sucesso quando precisarmos fazer o deploy e colocar a aplicação em produção.

As etapas de segurança no DevSecOps incluem, como comentamos, SAST, Secrets Scan, segurança de IaC e a implementação de Security Gates (barreiras de segurança) ao longo do ciclo.

A importância de implementar o Shift Left desde o começo é amplamente discutida. Na própria Alura, promovemos diversos eventos e vídeos destacando a antecipação da segurança, isto é, trazer o Shift Left para o início do processo.

Aplicando o shift left em um exemplo prático

Suponhamos que vamos implementar um carrinho de compras como nova funcionalidade no nosso processo de desenvolvimento. O que devemos considerar? Que porta vamos expor para testes? Precisaremos abrir alguma porta? Teremos de criar um Security Group (grupo de segurança) que fique temporariamente exposto para validar o cenário? Haverá algum tipo de firewall caso subamos um banco de dados ou uma instância? Esse firewall bloqueará ou permitirá portas específicas? Se permitirmos uma porta que ficará temporariamente exposta, teremos outras proteções em nível de VPC (Virtual Private Cloud, nuvem privada virtual) e de rede? Esses são pontos que precisamos incorporar na arquitetura, pensando no Shift Left desde o início.

Fico agradecido por terem assistido à aula anterior. Nós nos vemos no próximo vídeo. Obrigado!

Segurança Integrada ao Fluxo de Entrega - Identificando sinais de risco

Introduzindo a aula 1.2

Estamos de volta. Espero que tenham gostado da aula anterior. Vamos dar sequência para começar a falar de segurança integrada ao fluxo de entrega na Aula 1.2.

Nesta aula, vamos identificar sinais de riscos em códigos e em fluxos de entrega. Na aula anterior, vimos os principais riscos e algumas vulnerabilidades, apresentamos a OWASP (Open Web Application Security Project) e explicamos como funcionam os testes nas etapas de DevSecOps (desenvolvimento, segurança e operações). Agora, vamos mostrar alguns sinais de risco voltando ao fluxo de entrega, partindo do conceito inicial de DevOps (desenvolvimento e operações) e avançando para DevSecOps, para que se tenha uma visão mais completa.

Identificando sinais de risco no fluxo de entrega

Ao detectar padrões inseguros no desenvolvimento, o cenário muda um pouco. Precisamos pensar em como identificar riscos quando estamos no desenvolvimento integrado a um fluxo de entrega, por exemplo.

O que pode indicar risco dentro de um fluxo de entrega?

Se houver uma ação que modifica o código e essa mudança não foi realizada por nós, isso é suspeito e possivelmente indica um problema. Precisamos manter atenção a novos pacotes chegando: de onde vêm essas dependências? Realizamos uma análise de SBOM (Software Bill of Materials)? Geramos um inventário de vulnerabilidades das dependências, incluindo bibliotecas de terceiros? Existe uma etapa de SCA (Software Composition Analysis) no nosso fluxo de DevSecOps? Esses são pontos importantes para identificar riscos.

Adotando política como código com Checkov

Um ponto essencial ao falar de riscos é adotar Policy as Code (política como código). Essa prática é muito útil porque permite automatizar e validar regras de segurança para apoiar o cenário de proteção do fluxo de entrega. Podemos definir políticas focadas em permissões excessivas, recursos inseguros, imagens não aprovadas, portas expostas publicamente e padrões obrigatórios de conformidade, como PCI DSS. Com Policy as Code, conseguimos fortalecer a proteção do fluxo de entrega e ampliar a cobertura dentro do nosso processo.

É especialmente relevante detectar padrões inseguros antes do deploy (implantação). Fazendo a conexão com o Checkov, ferramenta que apoia a adoção de Policy as Code, conseguimos identificar esses padrões de forma automatizada. O Checkov permite detectar configurações inseguras, apontar a linha problemática, o arquivo correspondente, o nome da política, o nome da regra e fornecer um link de referência para correção.

A política como código agrega bastante ao nosso fluxo e não se limita à infraestrutura como código (IaC). Também podemos aplicar políticas à aplicação e ao fluxo de entrega da aplicação, não apenas ao fluxo de IaC. Quando falamos em fluxo de entrega, precisamos diferenciar:

Podemos usar política como código no CI/CD (Integração Contínua e Entrega Contínua). Essa prática fortalece nossa postura de segurança e torna o processo mais consistente.

No exemplo apresentado com o Checkov analisando um Dockerfile, a ferramenta identifica problemas como ausência da diretiva HEALTHCHECK e uso inadequado ao adicionar arquivos durante a criação da imagem. O Checkov evidencia esses problemas, mostrando-os de forma clara, o que reforça a importância de incorporarmos esse tipo de verificação ao nosso fluxo de entrega.

Monitorando riscos em CI/CD e uso de IA

Quando falamos de riscos voltados para CI/CD no fluxo de entrega, precisamos monitorar alguns pontos principais para criar um processo mais seguro, com qualidade e velocidade:

Além disso, é preciso ter cuidado com o uso de IA para gerar código: muitas vezes a pessoa não verifica de onde a IA trouxe o pacote ou a dependência. É fundamental validar a procedência e a segurança desses componentes antes de integrá-los ao projeto.

Execução inesperada de scripts às vezes é interessante incluirmos na parte de Runtime (tempo de execução). Vamos falar sobre Runtime (tempo de execução) e segurança em Runtime (tempo de execução) na Aula 4. Em alguns cenários, enquanto criamos recursos, gerenciamos configurações ou ajustamos algo dentro de um pod, no momento de subir o pod ou ao executar um contêiner Docker, pode ser gerado algum script aleatório. É importante termos uma etapa que identifique esse tipo de ocorrência: por exemplo, se foi acessado o arquivo /etc/shadow ou o /etc/passwd, esse comportamento não era esperado. A segurança em Runtime (tempo de execução) ajuda a capturar exatamente esse ponto, e vale a pena abordarmos esse aspecto também.

Utilizando o Trivy para varreduras locais e em imagens

Vamos mostrar o uso do Trivy, que utilizamos com frequência justamente por destacar esses pontos do fluxo. Fizemos uma demonstração simples: pegamos um arquivo com uma linha de teste apenas para validação e verificamos como o fluxo fica consistente. O Trivy evidencia claramente os achados relevantes.

Para reproduzir essa validação local de diretórios/projetos, focando em vulnerabilidades, segredos e configurações incorretas, podemos rodar o Trivy em modo de sistema de arquivos assim:

trivy fs --scanners vuln,secret,misconfig /root/alura-devsecops

Esse comando varre a pasta informada reunindo, em um único relatório, achados de vulnerabilidades, segredos expostos e más configurações, exatamente como discutimos nesta demonstração rápida no terminal.

O que executamos aqui foi o Trivy, uma ferramenta open source (código aberto) com diversas funcionalidades. Seu foco principal é a verificação de vulnerabilidades, riscos e configurações incorretas (misconfigurations — configurações inadequadas) em imagens de contêiner. No exemplo, verificamos a imagem do NGINX na versão 1.31. É um teste local no terminal, mas que faz sentido para pensarmos no processo completo. Existe Trivy para GitHub Actions, e pretendemos, ao final, na Aula 1.5, realizar um laboratório completo mostrando todo o fluxo de uma pipeline (esteira de entrega) de ponta a ponta.

Para escanear a imagem do NGINX usada no exemplo, o comando é:

trivy image nginx:1.31

Esse comando analisa a imagem nginx:1.31, consulta as bases de vulnerabilidades e retorna um relatório detalhado com os achados — o que se conecta diretamente aos pontos que vamos observar no output do Trivy.

O Trivy apresenta pontos principais do relatório, como:

Escolhemos o NGINX de teste justamente porque ele expõe muitas vulnerabilidades e riscos — foram 348 encontradas. A ferramenta mostra ainda:

Tudo isso o Trivy evidencia, gerando um report (relatório) bastante completo. Ao rolar a tela até a parte final, percebemos a riqueza de detalhes do relatório, o que facilita a evidência de riscos. Vamos retomar essa demonstração ao final, na última parte desta aula, para termos um fluxo completo do uso do Trivy e de como conseguimos identificar os riscos discutidos agora, além dos desafios de DevOps (integração entre desenvolvimento e operações) que já comentamos na Aula 1, reforçando a importância de utilizarmos ferramentas de segurança para agregar valor ao SDLC (ciclo de vida de desenvolvimento de software).

Integrando segurança ao CI/CD com Trivy e SonarQube

Retomando outras possibilidades, incluímos um exemplo do Trivy integrado ao GitHub Actions. É apenas um exemplo ilustrativo, ainda que pequeno, mas suficiente para darmos uma ideia: há uma série de passos e, ao final, obtemos um report (relatório) bastante útil. Vamos analisar isso em detalhes depois, no contexto de CI/CD (Integração Contínua/Entrega Contínua).

Também apresentamos um exemplo de gestão de vulnerabilidades com o SonarQube, uma ferramenta muito forte em qualidade de software que, recentemente, tem avançado bastante em segurança. Utilizamos bastante o SonarQube nos projetos da empresa e vale destacá-lo. Observamos alguns pontos principais ao usarmos o Trivy em conjunto:

Percebemos benefícios relevantes quando passamos a incorporar ferramentas de segurança no nosso SDLC (ciclo de vida de desenvolvimento de software). Outro ponto importante: nem todo risco aparece como CVE. Pequenas mudanças no código, como vimos, podem indicar riscos já dentro da pipeline (esteira de entrega), então precisamos considerar essa dimensão também.

Listando riscos comuns e ferramentas de apoio

Exemplos comuns de riscos que comentamos:

Ferramentas que podemos utilizar para ajudar na identificação desses riscos:

Aprimorando o desenvolvimento com Snyk e encerrando a aula

Por fim, mostramos um exemplo do uso do Snyk no VS Code (Visual Studio Code). O Snyk possui uma extensão muito eficiente para o VS Code (Visual Studio Code), oferecendo diversos recursos úteis quando tratamos de scan (varredura) automático no editor, detecção de vulnerabilidades enquanto estamos codificando e feedback (retorno) rápido. Com isso, aplicamos correções antes da entrega do software.

Eu agradeço por terem assistido à aula anterior e espero vocês na próxima, quando falaremos sobre a Aula 1.3. Obrigado por assistir, e nos vemos na próxima aula.

Sobre o curso DevSecOps e Inteligência Artificial: automatizando a segurança no pipeline

O curso DevSecOps e Inteligência Artificial: automatizando a segurança no pipeline possui 255 minutos de vídeos, em um total de 49 atividades. Gostou? Conheça nossos outros cursos de Builds em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda Builds acessando integralmente esse e outros cursos, comece hoje!

Conheça os Planos para Empresas