Para quem é este artigo: qualquer pessoa que instale pacotes com pip, uv, conda ou pixi, quem executa programas que fazem chamadas HTTPS com bibliotecas como requests, e quem mantém imagens Docker ou CI com Python.
Este artigo se baseia em comunicados oficiais dos projetos Python (desenvolvedores do CPython e do pip), dos projetos certifi, uv e conda, da Mozilla, do Google, da eMudhra e das distribuições Linux. Ele não explica como atacar nada nem como as chaves foram recuperadas. Nas redes sociais, isto tem sido chamado de "emergência de segurança do Python", mas nenhuma falha de execução de código foi encontrada no próprio Python.
続報待ち：この記事は公式発表に合わせて更新します
24 de outubro de 2026 (JST)まだ分かっていないこと
- Se o módulo ssl do CPython vai rejeitar as chaves intermediárias comprometidas (a mudança está em revisão e ainda não foi integrada)
- Como o Python 3.11 e 3.12, e suas imagens oficiais do Docker, tratarão o pip antigo (os responsáveis pelas versões planejam fazer o backport da mudança no módulo ssl que bloqueia os intermediários comprometidos, em vez de atualizar o pip; não integrada até 24 de outubro)
- Relatório final de causa raiz da eMudhra
- Remoção da raiz no Chrome, prevista para 27 de outubro (horário do Pacífico)
Os projetos Python publicaram seu aviso em 20 de outubro e lançaram Python 3.15.1, 3.14.9 e 3.13.17 em 21 de outubro. Chrome e Firefox bloquearam os intermediários afetados em 17 de outubro. Nenhuma exploração foi anunciada. Acrescentaremos as decisões sobre 3.11 e 3.12 e quaisquer outras mudanças no CPython assim que forem confirmadas.
Eu sou afetado? Uma tabela rápida por ambiente
Ser afetado depende de qual parte da sua configuração Python carrega uma lista de CAs. Uma mesma máquina pode ter listas separadas para cada versão do Python, cada forma de instalação e cada ambiente virtual.
| Ambiente | O que carrega a lista antiga | O que fazer |
|---|---|---|
| Qualquer ambiente que use pip | O certifi incorporado ao pip (sobrevive a uma correção do sistema operacional) | Atualize o pip para 26.2.2+ |
| Programas configurados para usar o certifi independente, como requests | O pacote certifi independente | Atualize o certifi para 2026.10.19+ |
| Ambientes que usam uv | A lista de CAs embutida no uv | Atualize o uv para 0.13.4+ |
| conda, Mamba, pixi | Cada ferramenta mais os pacotes certifi e ca-certificates | Atualize para conda 26.9.4+ e pixi 0.82.1+, e atualize certifi e ca-certificates no ambiente |
| Python do instalador macOS do python.org | O certifi distribuído com o instalador | Siga o post oficial para atualizar pip e certifi; no 3.13+ mude para o Python corrigido |
| Imagens Docker e CI | Qualquer pip, certifi e pacote de CAs do sistema existente no momento da build | Reconstrua sem o cache |
| pip ou certifi instalados por pacotes Linux (apt, dnf) | O ca-certificates do sistema operacional (o Debian corrige o pip para usá-lo) | Atualize o ca-certificates para a versão corrigida |
Ao usar o urllib3 diretamente, o padrão é o repositório de CAs do sistema. Atualize esse repositório; se sua configuração usar explicitamente o certifi ou outro pacote, atualize também esse pacote (guia de verificação de certificados do urllib3).
O que aconteceu (segundo comunicados oficiais)
- Relatório
- Em 17 de outubro de 2026, um pesquisador de segurança informou aos programas de raiz da Apple, Google, Microsoft e Mozilla, e à eMudhra, que as chaves privadas de oito certificados intermediários da eMudhra podiam ser recuperadas
- Escopo
- Oito intermediários. Seis são para TLS (HTTPS) e eram confiáveis pelo Chrome, Mozilla, Microsoft e Apple; dois são para assinatura de código. Todos foram criados em uma cerimônia de geração de chaves em 30 de abril de 2025. Os seis intermediários TLS se encadeiam à raiz emSign ECC Root CA - G3 (os dois de assinatura de código ficam sob outra raiz)
- Causa
- O Google diz que as chaves privadas foram geradas com aleatoriedade insuficiente. A Mozilla diz que recuperou as chaves de forma independente e confirmou que a geração das chaves era falha. A eMudhra diz que uma etapa da cerimônia produziu um segundo conjunto de chaves fracas junto às fortes, e que as chaves fracas foram as usadas. A causa raiz completa ainda está em investigação
- O que as chaves permitem
- A Mozilla diz que as chaves poderiam ser usadas para emitir certificados HTTPS fraudulentos para sites que o detentor não controla. Um invasor que intercepte a conexão de um usuário poderia usá-las para se passar por sites e potencialmente ler ou modificar o tráfego
- Resposta da eMudhra
- Revogou todos os oito em 18 de outubro. Diz que sete nunca foram usados em produção e que o que foi usado não havia emitido nenhum certificado. Interrompeu a emissão sob esta raiz em 20 de outubro e, em 22 de outubro, anunciou que vai deixar o negócio global de certificados SSL/TLS
- Navegadores
- O Chrome bloqueou as chaves pelo CRLSet em 17 de outubro. O Firefox as bloqueou no mesmo dia pelo OneCRL e lançou o Firefox 158.0.1 e atualizações ESR em 20 de outubro. Em 20 de outubro a Mozilla decidiu uma remoção emergencial da raiz e a removeu do NSS 3.131.1. O Chrome a removerá em 27 de outubro (horário do Pacífico)
- Projetos Python
- Publicaram um aviso em 20 de outubro (atualizado até 22 de outubro) pedindo que os usuários atualizem para pelo menos certifi 2026.10.19, pip 26.2.2, uv 0.13.4, sigstore 4.5.1, conda 26.9.4 e pixi 0.82.1, e que reconstruam imagens de contêiner com o cache de camadas desativado. Em 21 de outubro lançaram Python 3.15.1, 3.14.9 e 3.13.17, que incluem pip 26.2.2
O certifi é o pacote Python amplamente usado que mantém uma lista de autoridades certificadoras confiáveis. Ele deriva da lista da Mozilla, e o requests e o pip o usam para decidir se o certificado de um servidor é legítimo. O certifi 2026.10.18 (publicado em 18 de outubro, UTC) removeu todas as raízes emSign, e o 2026.10.19 (publicado em 20 de outubro, UTC) restaurou as raízes emSign não afetadas. O aviso de segurança do próprio certifi lista a 2026.10.18 como corrigida, mas o registro no GitHub Advisory Database e os projetos Python recomendam a 2026.10.19 ou posterior, por compatibilidade com as raízes emSign não afetadas. O certifi 2026.10.23 então removeu outras duas raízes emSign para acompanhar a Mozilla (a eMudhra diz que essa remoção estava prevista antes e não está relacionada a este incidente).
Quão grave é?
Chrome, Firefox
Bloqueados em 17 de outubro. Também rejeitam certificados ausentes dos logs públicos de CT
pip anterior à 26.2.2
Sempre lê seu certifi incorporado, mesmo após uma correção do sistema operacional
requests e outros clientes baseados em certifi
Usam certifi independente anterior à 2026.10.19
uv anterior à 0.13.4, imagens Docker
Mantêm a lista do momento da build
Os navegadores estão protegidos por duas coisas: recebem bloqueios de certificados automaticamente e rejeitam certificados que não constam nos logs públicos de Certificate Transparency (CT). O Google diz que nenhum certificado TLS encadeado aos intermediários afetados foi registrado nos logs de CT antes do bloqueio, de modo que nenhum certificado forjado poderia ter sido usado contra clientes que exigem CT.
pip e requests não usam nenhum desses mecanismos. Eles decidem apenas pela lista de CAs que carregam, então, se essa lista estiver antiga, aceitam um certificado forjado como legítimo.
O que poderia acontecer
- Um invasor na rota da rede redireciona conexões ao PyPI, python.org e outros sites para um servidor falso
- O pip install instala um pacote adulterado
- Chaves de API ou senhas enviadas com requests são lidas
O que um invasor precisa, e o que sabemos
- O invasor precisa conseguir ficar na rota da sua rede (o mesmo Wi-Fi, um roteador comprometido, um proxy corporativo etc.)
- Não há falha de execução de código no próprio Python
- Nenhuma exploração havia sido anunciada até 24 de outubro
Não fique complacente. A Mozilla disse em 20 de outubro que várias pessoas recuperaram as chaves de forma independente e algumas divulgaram isso publicamente, então forjar um certificado não é difícil. Evite executar um pip antigo em qualquer lugar por onde alguém possa se colocar no caminho, como Wi-Fi público, redes compartilhadas ou a rede ao redor de um runner de CI. Nosso guia sobre riscos do Wi-Fi público cobre esse aspecto.
Primeiro, verifique suas versões
Verifique a versão do pip
Execute isto com o Python que você quer verificar (dentro do ambiente virtual, se usar um). A versão 26.2.2 ou posterior está corrigida.
python -m pip --versionExecutar pip sozinho pode apontar para o pip de outro Python. Use python -m pip para saber qual Python está verificando.
Verifique a versão do certifi
Isto mostra o certifi independente que o requests e bibliotecas semelhantes usam. A versão 2026.10.19 ou posterior está corrigida. Se não estiver instalado, o pip exibe um aviso de "not found".
python -m pip show certifiO certifi incorporado ao pip é uma cópia separada. Execute python -m pip debug e procure a linha certifi== em "vendored library versions". Depois de atualizar para o pip 26.2.2, ela deve mostrar 2026.10.19.
Verifique uv e conda
Execute uv --version (0.13.4+ está corrigido), conda --version (26.9.4+) e pixi --version (0.82.1+).
Liste todos os lugares onde o Python está instalado
Uma mesma máquina costuma ter o Python do sistema operacional, um Python do python.org, Pythons do Homebrew ou do pyenv, e ambientes virtuais por projeto (como .venv). Um ambiente virtual é qualquer diretório com um arquivo pyvenv.cfg. Anotar a lista completa antes torna muito mais difícil deixar algum de fora.
Atualize em uma ordem segura
A ordem importa. Um pip antigo confia nos certificados afetados, então, se ele simplesmente baixar um novo pip e esse download for interceptado, um pip falso poderia ser instalado. Os projetos Python recomendam instalar o pip com um hash de arquivo fixado (uma impressão digital do conteúdo do arquivo) e depois usar esse pip para todo o resto.
Atualize o pip para 26.2.2 com hash fixado
O post oficial e o blog do Python trazem um comando com a URL do arquivo do pip 26.2.2 e seu hash SHA-256. Ele tem esta forma. Copie a URL e o hash exatamente do post oficial (deliberadamente não os reproduzimos aqui).
python -m pip install "pip @ <URL do post oficial>#sha256=<hash do post oficial>"Com um hash fixado, o pip recusa instalar um arquivo cujo conteúdo seja diferente, então um download interceptado não consegue instalar um pip falso. O post oficial diz que os navegadores já devem ter atualizado seus repositórios e podem ser usados para conferência. Por exemplo, abra a página de arquivos do pip 26.2.2 no PyPI e confirme que o hash mostrado ali corresponde.
Use o novo pip para atualizar certifi e uv
Quando o pip estiver na 26.2.2, use-o para atualizar o certifi. Se você instalou o uv com pip, atualize-o aqui também.
python -m pip install --upgrade certifi
python -m pip install --upgrade uvSe você instalou o uv com o instalador independente, siga o aviso do uv e passe para 0.13.4 ou posterior. O aviso diz que, se você mudar o uv para usar os certificados do sistema, deve confirmar antes que o sistema operacional já removeu a raiz ou os intermediários afetados.
Repita em todo ambiente virtual
O pip e o certifi ficam dentro de cada ambiente virtual. Os projetos Python pedem que os usuários atualizem o pip e o uv em todos os ambientes virtuais existentes na máquina. Para ambientes antigos que você não usa mais, recriá-los ou excluí-los pode ser mais rápido.
Leve as versões 3.13 a 3.15 para as versões corrigidas; no 3.11 e 3.12, atualize o pip em cada novo venv
Python 3.15.1, 3.14.9 e 3.13.17 incluem pip 26.2.2, então novos ambientes criados com python -m venv também recebem o pip corrigido.
Os projetos Python dizem que não haverá versão 3.11 ou 3.12 que inclua um pip mais novo, por causa do risco de compatibilidade. Atualize o pip logo no início, sempre que criar um ambiente virtual. O pip 26.2.2 é compatível com Python 3.10 e posteriores. No 3.9 e anteriores o pip corrigido não está disponível, então atualize o próprio Python (o 3.10 também atingiu o fim de vida útil).
Para o Python do macOS do python.org, atualize com esse interpretador
O Python do instalador macOS do python.org inclui o certifi. O blog traz comandos para 3.13, 3.14 e 3.15 (o post oficial mostra o 3.15 como exemplo) que chamam esse interpretador diretamente, por exemplo /Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15, para atualizar pip e certifi. Atualize a build free-threaded (como python3.15t) separadamente. Se pip install --upgrade certifi falhar com o certifi distribuído pelo instalador, o post oficial sugere reinstalá-lo com --ignore-installed --no-deps certifi.
Docker, CI e lockfiles
É aqui que as correções mais costumam ser esquecidas. Corrigir o seu notebook não faz nada pelas imagens e pelos runners de CI, que mantêm a lista antiga do momento da build.
Reconstrua as imagens Docker sem o cache
Os projetos Python pedem que você reconstrua as imagens de contêiner com o cache de camadas desativado, para que os certificados mais recentes do sistema operacional sejam obtidos. Baixe também a imagem base novamente, por exemplo com docker build --pull --no-cache. Depois de reconstruir, execute python -m pip --version dentro do contêiner para confirmar.
Em 21 de outubro, as imagens oficiais do Docker atualizaram suas definições 3.13 e posteriores para as versões corrigidas do Python (3.15.1, 3.14.9 e 3.13.17). Os mantenedores das imagens dizem que não atualizarão o pip nas tags 3.11 e 3.12 a não ser que o Python publique novas versões. Se você usa imagens 3.11 ou 3.12, atualize o pip para 26.2.2 no seu Dockerfile com um hash fixado.
Eleve as fixações de certifi em requirements e lockfiles
Uma fixação como certifi==2025.x.x em requirements.txt ou constraints.txt devolve imediatamente o certifi antigo. O mesmo vale para uv.lock, poetry.lock, pylock.toml e Pipfile.lock. Eleve o certifi para 2026.10.19 ou posterior, gere o lockfile novamente e leve para suas imagens e para o CI.
Isente certifi e pip das janelas de espera de dependências
Se você usa uma configuração que aguarda um período fixo antes de aceitar versões recém-publicadas (uma janela de espera de dependências), a correção não chegará até o fim desse período. Um mantenedor de empacotamento Python alertou que usuários com essa espera continuam expostos até atualizarem. Isente certifi, pip e uv dessa configuração.
Atualize as ações e ferramentas que seu CI usa
A ação do GitHub pypa/gh-action-pypi-publish, usada para publicar no PyPI, tem uma versão corrigida, v1.14.3. Para o cibuildwheel, atualize para v4.3.4 ou posterior (a v4.3.3 trouxe a correção; a v4.3.4 também cobre o pip no Python 3.9 e outros alvos). Verifique se a configuração do seu CI não fixa versões antigas.
Atenção às cópias com assinatura cruzada de outra CA
Alguns dos intermediários afetados também tiveram cópias assinadas de forma cruzada por outra autoridade certificadora. A assinatura cruzada permite que a mesma chave intermediária seja confiável sob uma raiz diferente. Um desenvolvedor principal do CPython diz que a raiz usada para essa assinatura cruzada está presente nas versões do certifi anteriores a abril de 2025 e nas versões antigas do pip que as incluem (por exemplo, pip 25.0.1 com certifi 2024.8.30). Segundo a CA que fez a assinatura cruzada, essa raiz já havia sido removida dos repositórios do Chrome e da Mozilla, mas ainda era confiável para Microsoft e Apple em 18 de outubro (registro da Mozilla). O Debian e o Ubuntu 14.04 a 20.04 (USN-8944-2) também removeram essa raiz de assinatura cruzada junto com a raiz emSign. A CA que fez a assinatura cruzada diz que revogou as cópias assinadas em 19 de outubro, mas a maioria dos clientes fora do navegador não verifica revogação. Remover apenas a raiz emSign de um pacote antigo não basta, pois a raiz de assinatura cruzada permaneceria. Passe para certifi 2026.10.19 ou posterior (as versões do certifi lançadas desde abril de 2025 não contêm a raiz de assinatura cruzada).
Atualize os certificados do sistema operacional (ca-certificates)
No Linux, o pacote ca-certificates mantém a lista de CAs do sistema. O curl e os Pythons instalados a partir de pacotes do sistema operacional a utilizam.
| Distribuição | Aviso oficial | Versão corrigida |
|---|---|---|
| Debian 13 (trixie) | DSA-6572-1 (20 de outubro) | ca-certificates 20250419+deb13u1 |
| Debian 12 (bookworm) | DLA-4845-1 | ca-certificates 20250419~deb12u2 |
| Ubuntu 26.10, 26.04, 24.04, 22.04 | USN-8944-1 (20 de outubro) | ca-certificates 20260816ubuntu0.(release) |
| Ubuntu 20.04, 18.04, 16.04, 14.04 | USN-8944-2 (20 de outubro) | Disponível pelo Ubuntu Pro (ESM) |
A correção do Debian remove a emSign ECC Root CA - G3 e a raiz de assinatura cruzada. O USN-8944-1 do Ubuntu remove a emSign ECC Root CA - G3 e, no 22.04 a 26.04, atualiza a lista para a versão 2.90 do pacote da Mozilla; o USN-8944-2 remove as duas raízes no 14.04 a 20.04. O pip instalado pelo pacote próprio do Debian (python3-pip) foi corrigido para ler a lista do sistema em vez do certifi incorporado, então atualizar o ca-certificates resolve o problema. No Windows e no macOS, instale as atualizações do sistema operacional.
Como confirmar que terminou
Verifique três versões em todos os lugares
Na sua máquina, em cada ambiente virtual, dentro de cada imagem Docker e no CI, confirme pip 26.2.2+, certifi 2026.10.19+ e uv 0.13.4+. Se restar até uma cópia antiga, você ainda não terminou.
Confirme que a raiz afetada saiu da lista do certifi
python -m certifi mostra o caminho do arquivo de pacote do certifi. Se o nome "emSign ECC Root CA - G3" não aparecer mais nele, a lista está corrigida.
grep -c "emSign ECC Root CA - G3" "$(python -m certifi)"Uma saída 0 significa que ela foi removida. Com o certifi empacotado pelo Debian ou Ubuntu, o arquivo não tem nomes de certificados, então 0 não prova nada; verifique a versão do ca-certificates. A lista incorporada ao pip está corrigida assim que o pip for 26.2.2 ou posterior.
Verifique fixações e o sistema operacional
Procure certifi nos seus arquivos de requisitos e lockfiles e garanta que nada anterior a 2026.10.19 esteja fixado. No Linux, confirme que o ca-certificates está na versão corrigida da tabela acima ou posterior, por exemplo com apt policy ca-certificates.
Visão deste site: proteger os navegadores não protege todo o resto
Os usuários de navegador foram protegidos em poucas horas sem fazer nada, porque os navegadores recebem bloqueios automaticamente e rejeitam certificados ausentes dos logs de CT. pip, requests e imagens de CI não têm nenhum desses mecanismos. Cada um mantém sua própria cópia da lista de CAs, e o responsável precisa atualizar cada cópia individualmente. Há tantas cópias quanto ambientes virtuais e imagens.
Um hábito também ajuda contra o próximo incidente desse tipo: mantenha hashes de pacotes nos seus requisitos (--require-hashes). Se os hashes estiverem nos seus próprios arquivos, um download interceptado não consegue trocar um pacote com conteúdo diferente. Veja auditoria de dependências com o OSV-Scanner para fixar e verificar dependências, e o incidente de malware no LiteLLM 1.107.0 para um caso em que o próprio canal de distribuição foi atacado.
Para operadores de sites
O Chrome deixará de confiar na emSign ECC Root CA - G3 em 27 de outubro (horário do Pacífico). O Google pede que operadores cujos certificados se encadeiam a essa raiz obtenham imediatamente um novo certificado TLS de outra hierarquia (sob outra raiz) no Chrome Root Store. Se você usa um certificado da eMudhra, verifique as orientações do emissor.
Cronologia
30 de abril de 2025
A eMudhra cria intermediários, incluindo os oito afetados, em uma cerimônia de geração de chaves.17 de outubro de 2026
Um pesquisador de segurança relata que as oito chaves podem ser recuperadas. Chrome (CRLSet) e Firefox (OneCRL) as bloqueiam no mesmo dia.18 de outubro
A eMudhra revoga os oito intermediários. O certifi 2026.10.18 remove todas as raízes emSign.19 de outubro
A CA de assinatura cruzada revoga as cópias assinadas de forma cruzada.20 de outubro
A Mozilla decide a remoção emergencial da raiz. Certifi 2026.10.19, pip 26.2.2 e uv 0.13.4 são lançados e os projetos Python publicam seu aviso. Debian e Ubuntu atualizam o ca-certificates. O Google anuncia que o Chrome removerá a raiz em 27 de outubro.21 de outubro
Python 3.15.1, 3.14.9 e 3.13.17 e conda 26.9.4 são lançados. As imagens oficiais do Docker atualizam suas definições 3.13+ para as versões corrigidas do Python.22 de outubro
A eMudhra anuncia que vai deixar o negócio global de certificados SSL/TLS.23 de outubro
O certifi 2026.10.23 remove mais duas raízes emSign para acompanhar a Mozilla.
Fontes (registro público)
Os fatos deste artigo vêm das fontes públicas abaixo. Não reproduzimos como as chaves foram recuperadas nem nada que possa ser usado em um ataque.
- Projetos Python, "Information for Python users regarding eMudhra / emSign CA certificate security incident" (20 de outubro de 2026; posts posteriores verificados até 24 de outubro) — discuss.python.org
- Python, "Python 3.15.1, 3.14.9 and 3.13.17 are out" (21 de outubro de 2026) — blog.python.org
- Aviso de segurança do certifi (GHSA-6q48-6c7w-9gw2) — github.com / GitHub Advisory Database github.com
- certifi, "Remove emsign" (#437, 18 de outubro de 2026) — github.com / histórico de versões do certifi pypi.org
- Changelog do pip (26.2.2: atualização do certifi para 2026.10.19) — pip.pypa.io
- Aviso de segurança do uv (GHSA-hq85-5cpj-mr62) e 0.13.4 — github.com
- conda, "Security updates for conda, Mamba, and Pixi" (21 de outubro de 2026) — conda.org
- Google, "Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates" (20 de outubro de 2026) — blog.google
- Mozilla, "Protecting Firefox users following the compromise of eMudhra intermediate certificates" (20 de outubro de 2026) — blog.mozilla.org
- Registro de incidente da Mozilla (Bug 2083449: os oito intermediários, horários de revogação, remoção de raiz, cópias com assinatura cruzada) — bugzilla.mozilla.org
- eMudhra, "eMudhra Statement on Recent Certificate Security Incident" (publicado pela primeira vez em 20 de outubro, atualizado em 22 de outubro) — emudhra.com
- eMudhra, "eMudhra to exit global SSL/TLS certificate business" (22 de outubro de 2026) — emudhra.com
- Reportagem sobre a saída da eMudhra (The Record, 22 de outubro de 2026) — therecord.media
- Debian, "DSA-6572-1 ca-certificates" (20 de outubro de 2026) — lists.debian.org / "DLA-4845-1 ca-certificates" lists.debian.org
- Ubuntu, "USN-8944-1" e "USN-8944-2" ca-certificates (20 de outubro de 2026) — ubuntu.com / ubuntu.com
- Issue da imagem oficial do Docker (python), "These images ship vulnerable pip" (correção para 3.13+, tratamento de 3.11 e 3.12) — github.com
- CPython, "Distrust compromised eMudhra intermediate CA keys" (defesa adicional no módulo ssl, não integrada até 24 de outubro) — github.com
- Status das versões do Python — devguide.python.org
Histórico de atualizações
2026-10-24: Primeira versão, com base no aviso dos projetos Python de 20 de outubro e nas publicações até 23 de outubro, nas versões Python 3.15.1, 3.14.9 e 3.13.17, nos avisos do certifi, pip e uv, nos comunicados do Google, da Mozilla e da eMudhra, e nas atualizações do ca-certificates do Debian e do Ubuntu. Atualizaremos esta página quando o tratamento de 3.11 e 3.12 e quaisquer outras mudanças no CPython forem decididos.
Leia a seguir
- Auditoria de dependências: Auditoria de dependências com o OSV-Scanner
- Ataques a canais de distribuição: Incidente de malware no LiteLLM 1.107.0 / Comprometimento da cadeia de suprimentos do Trivy
- Quando uma vulnerabilidade é anunciada: Guia de remediação de CVE
- Personificação na rota da rede: Riscos do Wi-Fi público
- Termos: O que é criptografia de chave pública? / O que é o Let's Encrypt?