<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Notas on Conteúdo</title><link>https://blog.alfredoneto.com.br/</link><description>Recent content in Notas on Conteúdo</description><generator>Hugo</generator><language>pt-br</language><lastBuildDate>Sun, 06 Sep 2026 13:07:58 -0300</lastBuildDate><atom:link href="https://blog.alfredoneto.com.br/index.xml" rel="self" type="application/rss+xml"/><item><title>CodeQL 2.26.4 improves GitHub actions security detections</title><link>https://blog.alfredoneto.com.br/posts/2026-09-06-codeql-2-26-4-improves-github-actions-security-detections/</link><pubDate>Sun, 06 Sep 2026 13:07:58 -0300</pubDate><guid>https://blog.alfredoneto.com.br/posts/2026-09-06-codeql-2-26-4-improves-github-actions-security-detections/</guid><description>&lt;p>O CodeQL 2.26.4 aperfeiçoa consultas de segurança e passa a detectar referências mutáveis a reusable workflows em GitHub Actions. O ponto parece pequeno, mas ataca uma superfície importante de cadeia de suprimentos: um workflow pode chamar outro por uma tag ou branch que muda de conteúdo ao longo do tempo. A execução fica dependente de código que o repositório consumidor não fixou nem revisou na alteração que disparou o pipeline.&lt;/p></description></item><item><title>CISA Adds One Known Exploited Vulnerability to Catalog</title><link>https://blog.alfredoneto.com.br/posts/2026-09-06-cisa-adds-one-known-exploited-vulnerability-to-catalog/</link><pubDate>Sun, 06 Sep 2026 12:46:12 -0300</pubDate><guid>https://blog.alfredoneto.com.br/posts/2026-09-06-cisa-adds-one-known-exploited-vulnerability-to-catalog/</guid><description>&lt;p>A CISA adicionou a CVE-2026-85046 ao catálogo Known Exploited Vulnerabilities (KEV). O problema está no V8, o motor JavaScript usado pelo Google Chromium, e foi classificado como uma confusão de tipos com evidência de exploração ativa. Essa combinação muda a prioridade operacional. Não se trata de corrigir uma falha porque ela recebeu um identificador novo; há indício de que alguém já encontrou uma forma de usá-la fora do laboratório.&lt;/p>
&lt;p>Para equipes de infraestrutura, navegador ainda é parte da superfície administrativa. Consoles de nuvem, painéis Kubernetes, interfaces de observabilidade, bastions com desktop, portais de fornecedores e consoles de CI/CD passam pelo browser. Uma estação de um operador comprometida pode entregar sessão autenticada, cookies, credenciais temporárias ou acesso a uma rede que deveria exigir várias barreiras. O caminho inicial pode parecer distante do cluster, mas o resultado pode chegar rapidamente aos controles que administram esse cluster.&lt;/p></description></item><item><title>Kubernetes v1.37: KubeletInUserNamespace (aka Rootless mode) Graduates to Beta</title><link>https://blog.alfredoneto.com.br/posts/2026-09-06-kubernetes-v137-kubeletinusernamespace-aka-rootless-mode-graduates-to-beta/</link><pubDate>Sun, 06 Sep 2026 12:46:12 -0300</pubDate><guid>https://blog.alfredoneto.com.br/posts/2026-09-06-kubernetes-v137-kubeletinusernamespace-aka-rootless-mode-graduates-to-beta/</guid><description>&lt;p>O Kubernetes 1.37 leva o feature gate KubeletInUserNamespace, também chamado de modo rootless, a beta e o deixa habilitado por padrão. A mudança não transforma contêineres em processos sem privilégio; ela muda o contexto em que componentes críticos do nó operam. Kubelet, runtime CRI/OCI, CNI e kube-proxy podem executar dentro de um user namespace Linux. Nesse modelo, o root percebido por esses processos não é automaticamente root no host.&lt;/p>
&lt;p>A diferença é relevante porque o nó continua sendo uma fronteira de segurança decisiva. Em um cluster multitenant, uma falha que permita escapar de um contêiner ou explorar um componente local costuma ser avaliada pelo acesso que pode alcançar no host. Reduzir os componentes do nó a uma identidade não privilegiada limita esse impacto. O invasor ainda pode comprometer a carga ou o processo vulnerável, mas passa a encontrar uma barreira adicional antes de obter controle administrativo real do servidor.&lt;/p></description></item><item><title>Plataforma fictícia testa alertas contextuais em equipes remotas</title><link>https://blog.alfredoneto.com.br/posts/2026-09-06-plataforma-ficticia-testa-alertas-contextuais-em-equipes-remotas/</link><pubDate>Sun, 06 Sep 2026 12:46:12 -0300</pubDate><guid>https://blog.alfredoneto.com.br/posts/2026-09-06-plataforma-ficticia-testa-alertas-contextuais-em-equipes-remotas/</guid><description>&lt;p>O sinal descreve uma plataforma fictícia que agrupa atualizações pelo contexto de trabalho, em vez de notificar cada pessoa a cada evento. A ideia parece simples, mas ataca um problema operacional recorrente: alerta demais transforma tudo em prioridade e, no fim, ninguém consegue distinguir uma falha de produção de uma mudança rotineira.&lt;/p>
&lt;p>Equipes remotas sofrem mais com esse efeito porque boa parte da coordenação passa por ferramentas assíncronas. Um deploy, uma alteração de rota, uma rotação de certificado e a recuperação de um serviço podem gerar mensagens em canais diferentes. Cada ferramenta conhece apenas uma parte do incidente. Quem está de plantão recebe o fluxo completo, muitas vezes sem uma relação explícita entre os eventos. O resultado é ruído, troca de contexto e decisões tomadas com informação incompleta.&lt;/p></description></item></channel></rss>