 mundo vendo aí os slides, ok? Beleza. Bom, primeiramente, bom dia pessoal, né? Prazer estar aqui com vocês aí. Vai ser difícil seguir aí o keynote da Via, da Ellen, né? Então, já peço desculpas aí, se a minha palestra não atender aí as, os requisitos aí de vocês. Mas a ideia é trazer uma conversa um pouco que a Vi mencionou aí na palestra dela sobre segurança, sobre a importância aí de, né? Bernet, não é seguro por padrão e falar um pouquinho pra vocês, né? Da importância e da segurança dentro desses projetos aí. Bom, antes de eu começar com a palestra que estamos a apresentar aqui, né? Meu nome é Magno Logan, estou envolvido aí com a comunidade, né? De Kubernetes há mais ou menos dois anos, quando eu comecei a trabalhar na Trend Micro, eu moro aqui no Canadá e basicamente ajudando um produto de scan de imagens, de vulnerabilidade de imagens em contêndios e tudo mais. O produto praticamente funcionava em Kubernetes, né? Então, eu tive que trabalhar com Kubernetes aí e aí começou o meu interesse com a tecnologia, depois eu mudei um pouco pra área de pesquisa e disse, não, agora eu quero aprender, né? Como é que a segurança desse negócio, como é que funciona especificamente a segurança do Kubernetes e tudo mais, né? Então, atualmente eu trabalho nesse time de pesquisa de segurança em Nuven, né? Segurança e containers e em Nuven, né? Também faço parte aí da CNCF, né? Participei de algumas reuniões do grupo de segurança da CNCF que a gente chama o Security Tag Team, né? Ajudei na elaboração dos White Papers de Cloud Native na revisão desses White Papers do Cloud Native Security e do Supply Chain Security, são dois White Papers bem legais aí que a gente tem. Um deles eu acho que a gente tá trabalhando na resolução em português que deve tá saindo em breve, né? Então, minha área é basicamente essa, meu background é em desenvolvimento e depois eu mudei pra área de segurança de aplicações, né? E tamo aí. Eu tenho um blog pessoal chamado katanasack.com onde tem todas as minhas palestras, minhas informações pessoais aí, contatos e redes sociais, quem quiser dar uma olhada, quando eu posto uns artigos lá também, né? Só pra vocês terem uma noção aqui no Canadá, são duas horas a menos e ontem caiu mais de 40 centímetros de neve, né? Então só pra vocês verem aqui, eu acho que na minha janela, não sei se dá pra ver, ó, tem neve entrando na janela aqui do meu basement. Mas beleza, vamos lá. Bom, a agenda dessa palestra aqui é uma ideia do projeto que eu tive, né? Discutindo aí com várias pessoas na comunidade, durante as reuniões da CNCF lá do grupo de segurança, né? Não sei se vocês sabem, mas tem algumas auditorias de segurança esses projetos aí open source, né? Por serem mantidos pela CNCF, eles passam para um certo critério, né? Tem que aceitar um nível de risco aceitável de segurança. Então, tem algumas auditorias que são feitas aí nele, né? E aí eu vou falar sobre essas auditorias, né? A gente vai entender como é que eu fiz pra juntar todos esses resultados de auditorias independentes de cada projeto e tentar trazer uma visão mais holística, uma visão mais geral ali do qual a situação atual da segurança desses projetos e como é que a gente pode melhorar o ambiente, né? Beleza. Então a ideia do projeto é essa, né? A gente tem uma, né? A CNCF ela faz, ela realiza e patrocina mesmo, né? Investe contratando empresas de renome, né? Empresas gabaritadas de consultoria de segurança aí pra fazer a auditoria dos projetos de, da que fazem e passam a CNCF. Normalmente quando eles estão graduando, né? Passando de uma fase de consultoria ali de sandbox ou pra graduated, né? Então eles são obrigados a passar pra uma auditoria de segurança pra uma empresa independente, né? Uma empresa de consultoria focada em testes de aplicações e open source, revisão de código e tudo mais, né? Só que daí, né? É cada projeto eles passam por uma RFP, tem uma seleção, né? E aí vence a empresa da empresa, né? A melhor oferta lá da empresa e tudo mais, né? Não sei exatamente os detalhes do processo. Só que o resultado final, né? Desse pentest, né? Desse digamos assim desse acessamente de segurança é um relatório em PDF, né? É um PDF lá com um formato específico, né? Um layout, um template específico da empresa detalhando as vulnerabilidades, né? Então se você quer saber quais foram as vulnerabilidades encontradas em cada um desses projetos aí de estado, né? Você vai ter que ir lá, procurar o link do PDF, baixar o PDF, ler, ver os resultados, ver se essa vulnerabilidade foi corrigida ou não, se é crítico ou não e tudo mais, né? Então é um pouco trabalhoso, né? Daí que que eu fiz, né? Eu basicamente a minha ideia era essa, é só ir aí se eu juntar, né? Se eu conseguir pegar os resultados de todos esses relatórios aí em PDF de várias empresas, em vários formatos, né? E tentar unificar, formar uma base de funções única de vulnerabilidades em aplicações cloud native, né? Então basicamente foi isso que eu fiz. Eu baixei os PDFs, estudinho, né? Criei um repositório no Git, lá tem um repositório no meu GitHub específico e fiz um parsing desses relatórios, pregando as informações mais importantes no nome da vulnerabilidade, severidade, impacto, né? Qual o arquivo, o ponto afetado da vulnerabilidade e tudo mais, para dar uma estudada mais geral, ou seja, o que que a gente está, qual são os maiores problemas de segurança, ou seja, quais são os, o que que a gente tem que focar na parte de segurança em relação a esses projetos como um todo, né? Não tô focando só no Kubernetes, não tô focando, né, numa ferramenta específica, mas todos esses aplicações aí cloud native, né? Beleza, né? Então eu falei aqui das, né, das auditorias que são independentes, falei um pouquinho, elas começaram mais ou menos em 2018, mais ou menos as datas que a gente tem aqui, o registro das primeiras auditorias de segurança, então é algo relativamente recente, né? E o resultado é um PDF que é difícil de você, de você trabalhar, manusear, né? Se você quer utilizar ele para alguma coisa, para pesquisar, você vai ter que passear ele, não tem para onde correr, e cada um vai ter um template diferente. Então beleza, né? Aí, o que que eu fiz? A metodologia foi essa, foi juntar essas informações, criar uma base de dados específica de vulnerabilidades de cada projeto e aí analisar esses resultados, né? Então não é algo muito complexo, mas eu achei que era um trabalho interessante. Daí desse, daí eu fiz o que? Do resultado de todas as bases a fiz análise, né? Qual projeto tem mais vulnerabilidade? Qual é o tipo de vulnerabilidade mais crítica, né? Onde é que tá o maior tipo de problema? Onde é que a gente tem que melhorar não só para trazer recomendações de segurança para a CNCF, mas para quem tá começando, né? Para quem tá começando também com esses projetos, quer escolher, quer avaliar melhor, né? Tem alguns projetos que têm funcionalidades semelhantes e você pode, né, escolher um do que o outro, então por aí vai, né? Então é para ajudar a CNCF mais a comunidade também. E aí depois, né? Apresentar alguns resultados aí sobre os gráficos, né? A quantidade de cada vulnerabilidade e tudo mais. E também a parte no final eu faço uma análise da parte das dependências, né? Das bibliotecas, das vulnerabilidades em dependências que têm crescido cada vez mais. É mais importante aí hoje em dia, principalmente do ano, né? Quem não perdeu aí um final de semana com a vulnerabilidade do log4j, né? Então a gente vai falar um pouquinho sobre isso também. Bom, aí no resultado da pesquisa, né? A questão das vulnerabilidades aí, a análise dos projetos, né? O que tem maior vulnerabilidade, né? Não é um assustador para a gente, não é uma surpresa, é o Kubernetes, né? O Kubernetes tem mais de projetos maiores, tem mais linhas de código ali, então tem mais chances de ter mais vulnerabilidade, é uma proporção ali, né? É meio que equivalente, mais linhas de código que tem mais chance, não quer dizer que mais vulnerável, mas tem mais chance de ter mais problemas. É complexo, né? E pode ter mais problemas. Então o Kubernetes sai disparado aí, também já fez mais auditoria, se não me engano, tinha uma auditoria no ano passado, deve estar começando nesse ano aí para fazer mais uma auditoria também no Kubernetes, por ser o projeto mais representativo de mais utilidade aí também para a comunidade também. Beleza. E aí os tipos de vulnerabilidade, né? O que você vai fazer com esses tipos? O que a gente tem que focar? Não sei se vocês viram, no ano passado saiu a nova versão do Asp Top 10, né? Que é uma lista de vulnerabilidades mais comuns ou mais impactantes e vulnerabilidades e riscos, né? Para aplicações web, né? Então ano passado ao Asp, que também é uma fundação sem fins lucrativos, publicou a nova versão do Asp Top 10 2021, recomendo dar uma olhada, né? E aí eles classificam aqui as empresas que fizeram as vulnerabilidades, deles têm uma categoria, né? Essa tabelinha foi da própria e do relatório da própria empresa dizendo como é que eles classificam as vulnerabilidades que eles foram encontrando, né? Então beleza, eu peguei essa classificação deles e algumas vulnerabilidades tinham essa classificação, outras que eram feitas por outras empresas não tinham e eu tentei justamente entender o conceito, o que que ela é a vulnerabilidade, o que ela está fazendo? Realmente, ah, é um problema de controle de acesso, é um problema de validação de entrada, negação de acesso e aí também eu coloquei em algumas vulnerabilidades que não tinham essa classificação e eu classifiquei elas também para poder medir, né? Tudo de uma forma mais igualitária aí. Então qual é a classificação, a categoria da vulnerabilidade que mais ocorre nesses projetos que mais foi identificada, né? A primeira é a de validação de entrada, de validação de dados, né? Ou seja, o grande problema do código dessas aplicações é validação de entrada, input validation, que é algo que a gente já vem falando há muito tempo atrás, né? Validação de entrada, recebe um parâmetro, não sabe de onde vem, não confia, faz a validação, né? E a gente tem vários tipos de validação de entrada, né? A gente tem a validação, a Lauliste ou Denylist, né? Que era um antigo Blacklist ou Whitelist. A gente tem validação sintática, validação semântica, certo? A gente tem validação no lado cliente, validação no lado servidor. Então tem vários tipos de validação que podem ser complexos, muitas vezes para o desenvolvedor, né? Principalmente se alguém está começando, certo? Então lembrar de validar dados, né? Assim que receber eles é uma das coisas e é um dos problemas que ainda causa maior número de vulnerabilidades, né? Até em aplicações cloud-net, certo? Daí depois dela vem a parte de configuração, né? Que a gente sabe que configuração é um problema, misconfiguration é um grande problema para ambientes em nuvem, né? Então você não configurar corretamente a ferramenta, não setar as configurações de segurança também é um problema grave, né? E o terceiro lugar ali fica para o negação de serviço, o denial service, né? Então alguma vulnerabilidade que causa um consumo muito grande da memória ou trava o programa que pode impactar, né? Para toda aplicação e isso são considerados negação de serviço, entendeu? Então é bem importante a gente dar uma olhada nessas vulnerabilidades, nesses tipos de vulnerabilidades, mas como entender como é que elas ocorrem, né? Tipo Buffer Overflow também, tem alguns casos ali, alguns testes que foram feitos nas aplicações que foram testes de fuzzing, né? Que a gente chama ali, que é onde a gente vai tentar causar um erro, causar uma exceção de propósito na aplicação também. Então foram identificados alguns problemas de validação de entrada. Beleza, só seguindo aqui para a gente concluir um pouco essa parte do relatório, né? Para deixar um pouco mais calmo, apesar de ter falado já de vulnerabilidade e segurança, para deixar o pessoal um pouco mais calmo, é o seguinte, né? A severidade dessas vulnerabilidades, né? O tipo, a criticidade do problema, como é isso, né? Pela análise, pelo resultado da classificação, essa classificação foi dada pelas próprias empresas que encontraram as vulnerabilidades, né? Dos que eu analisei, a maioria das vulnerabilidades são vulnerabilidade de nível baixo, né? Considerado nível low, né? E em segundo lugar, de nível médio. Então isso quer dizer que as vulnerabilidades existem, mas elas não são tão críticas, são alguns erros ali que podem ser facilmente corrigidos e consertadas e a maioria deles já foram corrigidos também ali dentro desses projetos, né? Principalmente porque eles precisam, né? Corrigir esses problemas para ser em frente, para serem graduados aí e ser promovidos aí dentro do formato da CNCE, né? Então não é algo tão crítico assim, mas a gente precisa pensar na segurança desses projetos também. Aí a segunda parte da pesquisa, né? Foi analisar a questão das vulnerabilidades, das dependências, né? Quais são as dependências desses projetos? Quanto essas bibliotecas estão atualizadas, né? Estão utilizando a biblioteca dependência na última versão, então essa biblioteca tem alguma vulnerabilidade publicamente conhecida. Então eu tentei fazer essa análise aí desses projetos, de todos os projetos que... Não todos os projetos da CNCEF, mas todos os projetos que tinham um relatório, né? Uma auditoria de pen teste aí publicada anteriormente, né? Então o que que eu fiz? Eu juntei todos os projetos que eu coloquei numa ferramenta de análise de dependências, chamada open source security, né? É baseada em um outro produto, né? A gente tem uma parceria com a ferramenta da SNCC, que é uma ótima ferramenta para análise de bibliotecas. Então ela é gratuita para open source, então você quer que eu utilizar, analisar qualquer código que seja gratuito, que seja open source, tem um repositório público, você pode fazer isso gratuitamente. Então beleza, aí eu subi esses projetos lá, fiz análise e comecei a analisar, né? E a gente pode ver pela imagem ali, né? A quantidade de bibliotecas com vulnerabilidade, né? Então ali tem o C de crítico, H de high, né? Alto, médio e low de baixo, né? E tirando o projeto do Notary, né? Que tá ali em primeiro lugar porque tem uma vulnerabilidade da biblioteca, né? Na época da inspeção, o Kubernetes tá em primeiro lugar, né? Provavelmente em número de bibliotecas e consequentemente número de vulnerabilidades. E aí quando eu falo número de vulnerabilidades, né? Eu não tô analisando apenas as dependências diretas da aplicação, né? Eu tô utilizando também as dependências indiretas, ou seja, se eu tenho uma biblioteca que chama uma outra biblioteca e essa biblioteca tá vulnerável, né? Ela também tá, né? Tá, é um problema, pode afetar a minha aplicação no caso aqui do afetar o Kubernetes. Foi exatamente o que aconteceu, né? Na situação do do log4j, né? No final do ano passado. Muitas aplicações tinham a biblioteca do log4j, mas não chamavam elas diretamente, né? Se eu não fizeram uma pesquisa lá, é de 70 a 70% das aplicações que utilizavam o log4j, utilizavam uma dependência indireta, uma dependência transiente. Daí, ou seja, eu tinha uma biblioteca que chamava o log4j. Então, se eu não tivesse uma ferramenta pra analisar isso, pra fazer essa análise de composição de software, né? Que a gente chama SCA, e aí eu não teria como saber se eu estava na biblioteca se eu estava vulnerável ou não. Então, a ideia é essa, é manter essas bibliotecas atualizadas, apoiar o projeto pra atualizar se tiver algum problema, né? A gente precisa ver se realmente isso pode ser explorado por alguém externamente, é um projeto, né? E por aí vai. Então, aqui a gente fez uma análise, ou seja, do aumento das dependências, das vulnerabilidades, das dependências com o tempo, né? Então, quando foi passando o tempo, mais dependências foram colocadas nos projetos, ou novas vulnerabilidades foram encontradas por aqui, as dependências, né? Então, é algo que é, você tem que estar em constante monitoramento e sempre atualizando ali, e obviamente pra atualizar essas dependências, precisa ter uma série de testes, né? Regressivos ali pra garantir que sua aplicação vai continuar funcionando depois de atualizar, né? Porque a gente tem medo, o maior medo do desenvolvedor é esse, é quebrar a aplicação, né? Então, não mexe em algo que tá rodando pra não quebrar, né? Então, a gente tem que ter esse, é, perder esse medo e tentar atualizar sempre pra corrigir esses problemas, ok? Pra finalizar aqui, eu fico só deixar algumas recomendações, não só pra CNCF, mas pra comunidade, né? A ideia é o seguinte, eu acho legal essas auditorias, eu acho que são importantes e são essenciais pra segurar essa desses projetos, mas a gente precisa melhorar. A primeira coisa que eu vejo, né? Na minha análise aí, que eu fiz no final do ano passado, é o seguinte, esses projetos, né? Essas análises não são periódicas, não seguem um determinado fluxo a cada seis meses, a cada um tem alguma coisa assim, né? São esporádicas e fez uma e acabou, né? Então, elas analisam o projeto naquele momento específico, né? E aí depois que passou um tempo, o projeto melhorou ou piorou na questão de segurança, eles não vão, não vão mais analisar, né? Então, acho que fazer esses testes, fazer essas análises mais periódicas é, é bem importante. O segundo ponto aqui é a análise de criação de programas de bug bounty, né? Programas de recompensa. Apenas um projeto de toda CNCF tem um programa de recompensa, né? Um bug bounty program, que é o Kubernetes, né? Então, se você for lá na plataforma da Hacker One, você encontrou uma vulnerabilidade no Kubernetes, você pode lá reportar essa vulnerabilidade e eles te pagam uma quantia lá em dólar, né? Dependendo da criticidade, tem todos os critérios lá, pra vulnerabilidade. Mas apenas o Kubernetes, os outros não tem, né? E daí isso dificulta, né? Em meio que desmotiva pesquisadores de segurança analisarem esses projetos pra achar vulnerabilidade e reportar essas falhas pra os mantenedores dos projetos, né? O terceiro problema que eu vi é que o processo de seleção das empresas, né? Não sei se vocês notaram nos slides ali, mas é praticamente duas ou três empresas são as que a maioria que fizeram os testes de segurança ali de todos os projetos, né? Então, esse processo de seleção das empresas muitas vezes é um pouco, pra mim, né? Pareceu meio obscuro, faltou divulgar mais, faltou promover mais ou talvez pegar empresas de vários países ou se importacionar um pouco mais pra ter visões diversificadas, visões diferentes ali dessas empresas, né? Então, nesse último RFP da auditoria de segurança do Kubernetes, eu tentei divulgar mais, chamar algumas empresas brasileiras pra participarem e tal. Então, acho que promover mais esses RFPs é interessante não só pra CNCF, mas pra comunidade como um todo. E por último, né? Acho que uma, né? Seria uma reclamação, eu acho que meio que no mundo de segurança e no mundo que a gente tá vivendo com DevOps, DevSecOps, né? Fica difícil a gente tratar vulnerabilidades, né? Se a gente tá recebendo tudo aquilo ali num PDF, né? Hoje em dia, desde a empresa anterior que eu trabalhava e disse, olha, a gente não vai entregar PDF pro desenvolvedor, né? Um PDF com várias páginas ali pro cara ter que olhar cada uma e corrigir os problemas, senão vai funcionar, né? A gente tem que tirar essas barreiras aí também e facilitar pro pessoal corrigir esses problemas. Então, ter uma forma mais fácil de interpretar, de receber esses resultados, algo que possa ser consumível pela comunidade, pela comunidade open source, pela CNCF pra ajudar na análise, na interpretação, na retoração desses resultados de alguma forma, né? Nem que seja um Excel ou um CSV ali da vida pra gente trabalhar, acho que seria interessante, né? E obviamente, focar nesses problemas aí, a gente viu que tinha vários problemas de vulnerabilidades em bibliotecas, né? Independências ali nesses projetos. Nem todos eles vão gerar vulnerabilidades no fim das contas, mas é importante dar uma analisada e ver se é atualizar essas bibliotecas, tá? Bom, acho que é isso que eu tinha pra compartilhar com vocês. Estou à disposição aí pra perguntas, né? Primeiramente, antes de mais nada, agradecer mais uma vez a organização do evento, né? A gente foi difícil aí sair esse evento aí, mas finalmente saiu. E é isso, tô agradecendo a todos a participação, todos tô abertos pra perguntas. Deixa eu ver aqui se tem perguntas que eu nem... Pregunta não, só agradecer mesmo. É isso aí, valeu, show. É, eu não sei, é que formato a CNCF tem que botar latex, né? Eu pode sempre até um ponto md ali e jogar no GitHub ficaria mais fácil. Acho que é isso. Mais alguém? Mais uma pergunta aqui. Aqui é a pergunta. Na sua visão, em quanto tempo as vulnerabilidades podem ser corrigidas ou diminuídas? Ou ainda enquanto conhecimento esposo social do Kubernetes? Ah, enquanto tempo, cara, pra corrigir a vulnerabilidade vai debender pra quem tem que corrigir, né? Se a pessoa, quanto mais detalhes na vulnerabilidade tiver pra reproduzir o problema e eu vi que alguns relatórios, eles davam até o arquivo, a linha do arquivo pra corrigir, às vezes é um código simples, é uma alteração simples, né? Por mais que é complexa ou crítica que a vulnerabilidade possa parecer, às vezes é coisa simples. Então, para os manter enduros dos clientes, eles que tem que analisar, não sou eu, né? Nem quem achou a vulnerabilidade, nem eu, que estou só analisando como um terceiro de fora, que vou dizer, não, essa aqui é estimativa, essa aqui é 8 horas, essa aqui é 4 horas, isso não existe, né? Quem vai dizer, quem tem que dizer o que que tem que ser alterado, né? Pode ser só uma linha na minha visão, mas essa alteração dessa linha pode afetar outros componentes, né? Então fica difícil de dizer que o tipo vai levar, né? É cada correção. Eu só acho que tem que ser tratado de alguma forma, a gente pode ser algo mais periódico e colocar mais ênfase nessa parte da segura, da segurança, principalmente nas dependências que a gente viu no final do ano, que com o Log4j, vamos supor que tem uma dependência, uma vulnerabilidade no estilo do Log4j, né? O Log4j, ali do final que acontece no Kubernetes, né? Quantos clusters, quantas empresas vão ter que parar, vão ter que correr atrás para gerar uma nova versão, para saber se estão vulneráveis, né? A ideia é tentar prevenir um incidente como esse, que aconteceu no final do ano, na comunidade aqui nos projetos da CNCF. Deixa eu ver, aqui tem mais perguntas, agora está parecendo bastante. Qual é o scanner de vulnerabilidade que eu usei? É, o scanner de vulnerabilidade que eu usei para a parte das dependências, né? Que o outro foi só analisar os relatórios que já existiam. Então para as dependências eu usei o open source security da trem de micro, mas ele é baseado no SNEAK. Então SNEAK.io ele tem uma versão gratuita ou para o projeto OpenSoce. Ah, deixa eu ver aqui, tá sumindo aqui as perguntas. Pode expulser uma API, você acha que isso traz mais vulnerabilidade? Se você está dizendo na questão do Kubernetes ter uma API, a vulnerabilidade da API vai estar mais a questão de se sua API está exposta, né? Então, por exemplo, o que o BAPI serve no caso do Kubernetes exposto para a internet, isso já é um problema. Se você não tem um tipo de autenticação ou autorização para fazer requisições para aquela API também é um problema, fazer um trabalho de hate limit também, né? Então uma das recomendações mais básicas de segurança para o Kubernetes, desculpa, é não expor o seu API server, né? Seu servidor de API ali do Kubernetes não tem internet, se não tem necessidade. Mais uma aqui. Os produtos dos players de cloud, por exemplo, o Microsoft Defender Powered by Qualys, fazem uma série de verificações de vulnerabilidade. Sabe se essa solução apresenta, tá? Tem algumas semelhanças com ferramentas embarcadas nos players. Eu não cheguei a testar esse Microsoft Defender da Qualys, né? Eu acho assim, para quem, ah, eu tenho, vamos supor que fugindo um pouco do conteúdo da palestra, mas focando mais na segurança do Kubernetes, ou ambientes cloud native em geral, eu tenho três, eu vejo três produtos que são três ferramentas, né? Que são importantes, são importantes para você testar a segurança dos seus clusters, né? Do seu ambiente cloud native containers, né? O primeiro é um scan de imagens, né? De containers, né? Então, pode ser um clare da vida, um trivia, né? Uma outra ferramenta aí que faça a scan da imagem do seu container antes de ela entrar na produção. Você também pode ter um analisador, né? Um linter de Dockerfiles, para mesmo antes de você gerar a imagem, você vê se o Dockerfile está criando um container vulnerável, está rodando o container como root, você pode ter isso, né? Isso é um pré-estágio, digamos assim. A segunda ferramenta que eu acho importante ter é um tipo de um Admission Controller, né? Que a gente tinha o Pod Security Policy, agora virou uma nova versão Pod Security, para o quê? É o segurança da boate, né? O de Admission Controller, ele vai controlar a admissão das imagens no cluster, né? Então, é aquele segurança da boate que vai dizer, ó, esse seu container foi escaneado, né? Esse seu container está vulnerável, tem alguma vulnerabilidade crítica? Não, não tem. Ah, beleza, ele pode entrar no cluster, senão ele é barrado, não pode entrar, né? Aí tem outras soluções, além do Pod Security Nativo, do Kubernetes, você tem o Kaiverno, você tem o OPA, né? Que é o OPA Gatekeeper. Então, você pode implementar as suas próprias políticas ali para a entrada no cluster. E o terceiro e a terceira ferramenta que eu acho que é importante é a de runtime security, né? Analisar o runtime. Depois que seus containers estão rodando ali no cluster, você tem visibilidade do que está acontecendo com eles? Se alguém conseguiu alguma execução de código remota, está baixando o ferramenta, está instalando um CryptoMiner, né? Que é o que mais acontece nesses ambientes aí, é instalação de CryptoMiner, de bitcoins. Então, você conseguiu detectar isso. Então, um ferramenta como um falco da vida ajudaria aí na, né, na detecção desses problemas de runtime, tá? Deixa eu postar aqui uma, que é o General, postar o link dessa pesquisa, sneak.io, beleza, deixa eu ver se tem mais aqui perguntas. Backstaging. Se eu tenho um cluster na minha infra interna e meu time de segurança, eu acho uma vulnerabilidade para um serviço tipo com a melhor maneira de reportar. Beleza, o show de bola. A melhor maneira de reportar hoje em dia, né? Uma das coisas que eu acho que eu não falei na palestra que havia mencionado é o seguinte, apesar dos programas das ferramentas da CNCF ali não terem um programa de bug bounty, a maioria deles tem uma forma de comunicação, eles têm um arquivo lá dentro do repositório chamado security.md, né? Que é o que? É o contato de segurança para você entrar com um contato com os mantenedores, né? Então, eles vão te dizer, olha, se você achou uma vulnerabilidade de segurança, né? Se ela é crítica, você não vai criar um inch no GitHub e deixar isso público, né? Porque tem atacantes que monitoram esses GitHub também, pegam esse conceito da vulnerabilidade e podem começar a atacar como aconteceu com o log4j, né? Então, a ideia é você entrar em contato novamente com os mantenedores ali do projeto, cada GitHub deles deve ter um contato, principalmente se eles forem da CNCF. Você acha que voltará a ter credibilidade logo for jay? Existe outra alternativa? É, eu acho que essa é uma discussão aí mais um pouco fora da da palestra, mas eu não sei se vai se vai voltar ainda. Eu acho que é uma biblioteca importante para o ambiente de Java, né? Não sei se vai. O pessoal vai procurar outras alternativas. Ah, ok, vamos iniciar. Já estou finalizando aqui, deixa eu ver ter mais muitas perguntas aqui. Como faz quando as ferramentas que fazem checks de vulnerabilidades divergem? Por exemplo, a RedHat usa uma pra imagens dela e no ArtFactsRub usa a outra. Sempre vai ter. A diferença de resultado em as ferramentas sempre vai ter, né? As ferramentas não são iguais, elas utilizam não só técnicas diferentes para analisar a vulnerabilidade, mas às vezes a base de dados, a base de vulnerabilidades delas são diferentes, né? Por exemplo, essas ferramentas open source normalmente usam base de dados públicas, né? Como o NVD, né? Baseado em CVS. E tem outras ferramentas mais comerciais que têm a sua própria base de dados. Então, além de utilizar uma base de vulnerabilidades pública, eles criam, né? Eles alimentam aquela base com mais informações. Então fica mais rica, por isso que vai dar divergência de resultado. Isso é normal em ferramentas de segurança, né? Em qualquer local. O prowler é uma boa ferramenta para vulnerabilidades no case. Que eu saiba o prowler mais voltado para a WS, para a nuvem, né? Eu não sei se ele tem regras ou algumas verificações aí para o Kubernetes, né? Eu nunca usei ele para o Kubernetes, não. Allison Oliveira, você é muito monstro, Magnum, valeu, obrigada, hein? O David Corbeta na Trive, melhor que o Clare. Eu nunca cheguei a comparar os dois, né? Quando eu comecei a testar, a gente utilizava o Clare. Só última pergunta aqui para eu finalizar aí, pessoal. Deixa eu passar a próxima pergunta. Para diminuir o risco, melhor forma é criar o de camadas possíveis e fazer o uso do multi-stage build. Boa, Jornel, até isso aí. É não só o mínimo de camadas, mas utilizar uma imagem mínima possível, não? Uma imagem pequena que eles chamam lá. Você pode criar uma distroless ou uma from scratch, né? Então tem algumas técnicas de criar um container bem pequeno para reduzir a superfície de ataque, né? Quanto as pacotes instaladas no seu container, menos chances de ter uma vulnerabilidade e ela ser explorada. E também a multi-stage build ali que você falou também é importante, né? Você utilizar um processo de criar, a partir da mesma imagem, você criar sua imagem para o ambiente de deve, homologação e produção. Isso é sensacional. Beleza? Acho que eu finalizei com as perguntas e também está acabando o meu tempo. Queria agradecer a atenção de todos aí e a oportunidade de palestra aqui para a comunidade do Brasil, apesar de estar fora do Brasil faz uns anos. E é isso daí. Obrigado pessoal e até mais.