Selo Carioca ESG Racial: equidade racial, sustentabilidade e governança nas organizações

Em abril de 2024, a Prefeitura do Rio de Janeiro lançou uma iniciativa que procurava aproximar três temas que precisam estar cada vez mais presentes na gestão das organizações:

sustentabilidade ambiental, governança e equidade racial.

O Selo Carioca ESG Racial foi apresentado pela Secretaria Municipal de Meio Ambiente e Clima — SMAC, em parceria com a Associação Pacto de Promoção da Equidade Racial.

O lançamento ocorreu em 4 de abril de 2024, no Museu Histórico Nacional, no Centro do Rio de Janeiro, depois de a programação inicial ter sido adiada em razão da previsão de fortes chuvas na cidade. A atividade integrou a I Semana das Nações de Matriz Africana Luzia de Pinta.

A proposta chamava atenção por um motivo importante:

equidade racial passava a ser tratada também como uma questão de gestão organizacional.

Não apenas como declaração de valores.

Mas como algo que pode ser:

planejado, acompanhado, medido e incorporado à governança.

O que é o Selo Carioca ESG Racial?

Na apresentação realizada pela Prefeitura em 2024, o Selo Carioca ESG Racial foi concebido para reconhecer organizações comprometidas com o enfrentamento ao racismo e às desigualdades étnico-raciais.

A proposta original mencionava:

• empresas privadas;

• organizações da sociedade civil;

• instituições públicas.

Foram previstas duas categorias de reconhecimento:

Compromisso

e

Responsabilidade.

O processo de desenvolvimento do selo foi estruturado em um ciclo de um ano.

Mais do que entregar uma certificação, a ideia era estimular as organizações a desenvolver e demonstrar práticas relacionadas à equidade racial.

O que significa ESG?

A sigla ESG vem das palavras em inglês:

Environmental — Ambiental

Social — Social

Governance — Governança

Ela passou a ser utilizada para analisar como organizações tratam aspectos que vão além dos resultados financeiros.

Na dimensão ambiental, podem aparecer questões como:

uso de recursos;

emissões;

resíduos;

mudanças climáticas;

preservação ambiental.

Na dimensão social:

relações de trabalho;

diversidade;

direitos humanos;

condições de trabalho;

relações com comunidades.

Na governança:

transparência;

integridade;

controles;

responsabilidades;

processos decisórios;

prestação de contas.

O Selo Carioca acrescentou ao debate uma ênfase específica na:

equidade racial.

Por que falar em ESG Racial?

A existência de uma política genérica de diversidade não significa necessariamente que uma organização esteja conseguindo enfrentar desigualdades raciais.

Para compreender o problema, é preciso observar resultados concretos.

Por exemplo:

Qual é a composição racial da força de trabalho?

Quem ocupa os cargos de liderança?

Existe diferença de remuneração?

Como funcionam os processos de recrutamento e promoção?

Existem mecanismos para prevenir e enfrentar discriminação racial?

Fornecedoras(es) e organizações parceiras também são avaliadas(os)?

Existem metas?

Os resultados são acompanhados?

É nesse ponto que a abordagem ESG Racial pode contribuir.

A questão deixa de ser apenas:

“a organização é favorável à diversidade?”

e passa a incluir:

“o que a organização efetivamente faz, como mede e quais resultados consegue demonstrar?”

Os três eixos do Selo

Na proposta divulgada pela Prefeitura, o Selo Carioca ESG Racial foi estruturado em três eixos:

E — Meio Ambiente

R — Equidade Racial

G — Governança

As variáveis desses eixos seriam organizadas principalmente em dois índices:

Índice ESG de Equidade Racial — IEER

e

Índice de Meio Ambiente e Governança — IEG.

Assim, a análise não ficaria limitada à existência de uma ação isolada.

A intenção era observar diferentes dimensões da atuação organizacional.

O Índice ESG de Equidade Racial

O IEER está relacionado ao Pacto de Promoção da Equidade Racial.

Na divulgação original do Selo, a adesão ao Protocolo ESG Racial da organização e a apresentação da certificação do Índice ESG de Equidade Racial — N1 apareciam como requisitos para candidatura ao reconhecimento.

A lógica de trabalhar com um índice é interessante para a Administração.

Aquilo que não é acompanhado tende a depender apenas de percepções.

Indicadores permitem observar:

situação atual;

metas;

evolução;

diferenças entre áreas;

resultados das ações realizadas.

Mas é importante lembrar:

o indicador não substitui a política.

Uma organização pode possuir excelentes números em determinado aspecto e ainda apresentar problemas que precisam ser enfrentados.

A função dos indicadores é ajudar a enxergar a realidade, não escondê-la.

Compromisso não é a mesma coisa que resultado

A existência das categorias Compromisso e Responsabilidade também permite uma reflexão interessante.

Uma organização pode estar começando sua jornada.

Pode ter:

um plano;

metas;

grupos de trabalho;

formações;

políticas internas.

Isso demonstra compromisso.

Mas, com o passar do tempo, é preciso observar:

o que mudou?

Por exemplo, depois de uma política afirmativa:

a participação de pessoas negras aumentou?

houve mudança na liderança?

as diferenças salariais diminuíram?

as denúncias passaram a receber tratamento adequado?

as pessoas permaneceram na organização?

As respostas ajudam a diferenciar:

intenção

de

resultado.

O Selo e a Administração

À primeira vista, uma iniciativa de equidade racial poderia parecer assunto restrito às áreas de responsabilidade social ou gestão de pessoas.

Não é.

Ela envolve diversas funções administrativas.

Planejamento

A organização precisa identificar problemas, definir objetivos e estabelecer metas.

Gestão de pessoas

Recrutamento, seleção, desenvolvimento, promoção, remuneração e permanência precisam ser observados.

Governança

É necessário definir responsabilidades:

quem acompanha?

quem decide?

quem recebe os dados?

quem responde pelos resultados?

Indicadores

As políticas precisam ser acompanhadas por informações que permitam avaliar sua execução.

Comunicação

As ações precisam ser conhecidas internamente e apresentadas com transparência.

Controle

É necessário verificar se aquilo que foi planejado realmente está acontecendo.

Portanto, equidade racial também é:

gestão.

Cuidado com o chamado diversity washing

Existe um risco quando diversidade começa a ser valorizada institucionalmente:

a organização pode descobrir que falar sobre diversidade é muito mais fácil do que modificar suas práticas.

Campanhas podem apresentar pessoas negras.

Redes sociais podem celebrar datas relacionadas à igualdade racial.

Documentos podem utilizar palavras como:

inclusão;

diversidade;

equidade.

Mas a pergunta administrativa continua sendo:

o que mudou dentro da organização?

Quando existe uma distância muito grande entre comunicação e prática, podemos encontrar fenômenos chamados de:

diversity washing

ou

social washing.

Ou seja, a organização utiliza determinada pauta para construir reputação sem produzir mudanças correspondentes em suas práticas.

Certificações e indicadores podem ajudar a reduzir esse problema quando exigem:

dados;

critérios;

evidências;

acompanhamento.

Equidade não significa tratar todo mundo exatamente da mesma maneira

Outro conceito importante é diferenciar:

igualdade

e

equidade.

A igualdade procura assegurar direitos e tratamento sem discriminação.

A equidade reconhece que diferentes grupos podem partir de situações historicamente muito distintas.

Imagine uma organização em que:

90% das posições de liderança sejam ocupadas por pessoas brancas.

Dizer:

“a partir de agora todas as pessoas concorrem da mesma forma”

pode impedir novas discriminações explícitas.

Mas talvez não seja suficiente para enfrentar as consequências de processos históricos que produziram aquela desigualdade.

Por isso, políticas de equidade podem envolver medidas destinadas a remover barreiras e ampliar oportunidades para grupos que enfrentam desigualdades persistentes.

A importância da governança

Um dos pontos mais interessantes do Selo é colocar:

equidade racial

junto de:

governança.

Uma política que depende exclusivamente da disposição de determinada liderança possui grande chance de desaparecer quando essa pessoa deixa a organização.

Para permanecer, ela precisa ser institucionalizada.

Isso pode envolver:

normas;

processos;

responsáveis;

indicadores;

orçamento;

capacitação;

mecanismos de denúncia;

monitoramento;

prestação de contas.

Quando isso acontece, a equidade racial deixa de depender apenas de:

“quem está no comando agora?”

e passa a fazer parte da maneira como a organização funciona.

E o que aconteceu depois do lançamento?

A iniciativa lançada em 2024 avançou para uma etapa normativa posterior.

Em 2025, publicações especializadas registraram a formalização do Selo Carioca ESG Racial pela Resolução “N” SMAC nº 22/2025, com regras para certificação e manutenção dos eixos relacionados a equidade racial, meio ambiente e governança.

Há uma diferença que merece atenção.

A divulgação inicial de 2024 apresentava como público potencial:

empresas privadas, organizações da sociedade civil e instituições públicas.

Já informações publicadas sobre a regulamentação de 2025 descrevem a certificação especificamente voltada a empresas privadas.

Por isso, organizações interessadas em participar atualmente devem consultar as regras vigentes da Secretaria Municipal de Meio Ambiente e Clima antes de iniciar qualquer processo de candidatura.

O que uma organização pode fazer mesmo sem buscar o Selo?

A existência de uma certificação pode estimular mudanças, mas nenhuma organização precisa esperar um selo para começar.

Algumas perguntas já ajudam a iniciar um diagnóstico:

Quem trabalha aqui?

Quem ocupa a liderança?

Existem diferenças de remuneração por raça?

Como são divulgadas as vagas?

Quem participa dos processos seletivos?

Quem é promovida(o)?

Quem deixa a organização?

Existem denúncias de racismo ou discriminação?

Como elas são tratadas?

As pessoas conhecem os canais de acolhimento e denúncia?

Existem metas e responsáveis?

Responder essas perguntas pode revelar problemas que permaneciam invisíveis.

Reconhecimento precisa estar acompanhado de transformação

Selos e certificações podem cumprir funções importantes.

Eles podem:

reconhecer boas práticas;

estimular organizações;

criar parâmetros;

dar visibilidade a experiências;

incentivar acompanhamento de resultados.

Mas um selo não deve ser visto como um ponto de chegada.

Equidade racial é um processo contínuo.

A composição de uma organização muda.

Lideranças mudam.

Políticas podem funcionar ou falhar.

Novas desigualdades podem aparecer.

Por isso, o reconhecimento só possui sentido quando está acompanhado de:

continuidade;

acompanhamento;

transparência;

capacidade de corrigir rumos.

Uma iniciativa relevante para quem estuda Administração

O Selo Carioca ESG Racial é também um bom estudo de caso para estudantes de Administração.

Ele reúne temas de:

Gestão de Pessoas

Planejamento

Governança

Indicadores

Responsabilidade Social

Gestão Ambiental

Diversidade e Inclusão

Políticas Públicas

Gestão Estratégica

Em outras palavras, mostra que questões sociais não estão separadas da Administração.

Toda organização escolhe:

quem contrata;

quem promove;

como distribui recursos;

quais indicadores acompanha;

quais comportamentos aceita;

quais problemas decide enfrentar.

Essas escolhas também produzem consequências sociais.

Para guardar

O Selo Carioca ESG Racial nasceu no Rio de Janeiro como uma proposta para aproximar:

meio ambiente;

equidade racial;

governança.

Seu lançamento em 2024 mostrou uma tentativa de transformar a promoção da equidade racial em algo que possa fazer parte dos mecanismos de planejamento, acompanhamento e reconhecimento das organizações.

Mais do que perguntar se uma organização declara apoio à diversidade, iniciativas como essa permitem formular uma pergunta mais exigente:

quais práticas, dados e resultados demonstram que a equidade racial realmente faz parte da gestão?

Essa é uma pergunta que não interessa apenas às organizações que desejam conquistar um selo.

Interessa a qualquer organização que pretenda compreender como suas decisões afetam as pessoas que trabalham nela e a sociedade da qual faz parte.

---

Matéria original

Prefeitura do Rio anuncia o inédito Selo Carioca ESG Racial

Publicada em 28 de março de 2024 pela Prefeitura da Cidade do Rio de Janeiro.

Backdoor no XZ Utils: o caso CVE-2024-3094 e as lições para segurança e gestão de riscos

Em março de 2024, administradoras(es) de sistemas Linux de todo o mundo receberam um alerta que rapidamente se tornou um dos episódios mais comentados da história recente do software livre.

Um código malicioso havia sido introduzido no XZ Utils, um conjunto de ferramentas de compressão utilizado em inúmeras distribuições Linux.

A vulnerabilidade recebeu a identificação:

CVE-2024-3094

e classificação crítica, com pontuação CVSS 10.0 atribuída pela Red Hat. (nvd.nist.gov)

Na época, a Diretoria Geral de Tecnologia da Informação — DGTI/Uerj publicou um alerta direcionado às(aos) administradoras(es) de sistemas Linux da Universidade.

A preocupação era justificável.

O código malicioso tinha sido desenvolvido de forma extremamente sofisticada e poderia, em determinadas configurações, interferir justamente em um dos principais mecanismos utilizados para administração remota de servidores Linux:

o SSH.

O que é o XZ Utils?

O XZ Utils é um conjunto de ferramentas utilizado para compressão e descompressão de dados.

Entre seus componentes está a biblioteca:

liblzma

utilizada por diversos programas no ecossistema Linux.

Isso significa que o problema não precisava ficar restrito ao aplicativo xz.

Uma biblioteca pode ser utilizada indiretamente por outros programas.

É justamente essa característica que tornou o caso tão preocupante.

A vulnerabilidade atingia especificamente os tarballs distribuídos das versões:

XZ Utils 5.6.0

e

XZ Utils 5.6.1. (tukaani.org)

Uma descoberta quase acidental

A história de como o problema foi descoberto é uma das partes mais interessantes.

Andres Freund, desenvolvedor do PostgreSQL e engenheiro da Microsoft, estava investigando um comportamento estranho em instalações Debian.

Algumas conexões SSH estavam consumindo mais CPU do que deveriam e determinadas ferramentas de análise apresentavam erros relacionados à liblzma.

Em vez de simplesmente aceitar aquilo como um pequeno problema de desempenho, Freund continuou investigando.

Em 29 de março de 2024, publicou suas conclusões na lista de segurança oss-security.

Ele havia encontrado algo muito mais grave:

o XZ Utils havia sido deliberadamente adulterado.

Sua mensagem original alertava que partes do código malicioso estavam presentes nos pacotes distribuídos das versões 5.6.0 e 5.6.1 e poderiam comprometer o servidor SSH em determinadas configurações. (openwall.com)

Uma investigação de desempenho havia encontrado uma:

backdoor.

O que é uma backdoor?

Uma backdoor — literalmente, uma “porta dos fundos” — é um mecanismo que permite contornar formas normais de autenticação, controle ou proteção de determinado sistema.

Ela pode ser criada legitimamente para alguma função específica, embora isso gere riscos.

Mas também pode ser introduzida de maneira maliciosa.

No caso do XZ Utils, tratava-se de:

código malicioso inserido deliberadamente no processo de distribuição do software.

O objetivo era interferir em sistemas que atendessem a determinadas condições e potencialmente permitir execução remota de código antes mesmo da autenticação normal do SSH.

O CERT da União Europeia classificou o cenário como possibilidade de execução remota de código pré-autenticação, desde que determinadas condições fossem atendidas e o atacante possuísse a chave correspondente. (cert.europa.eu)

Mas o XZ não é um programa de compressão? O que ele tem a ver com SSH?

Essa foi uma das perguntas mais frequentes na época.

O OpenSSH não precisava utilizar diretamente a biblioteca XZ para que o ataque funcionasse.

Em determinadas distribuições Linux, o serviço sshd utilizava componentes relacionados ao systemd.

Essas dependências acabavam carregando:

libsystemd → liblzma

e, consequentemente, a versão comprometida da biblioteca podia acabar dentro do processo do servidor SSH.

Foi essa cadeia de dependências que criou o caminho utilizado pelo código malicioso. (cert.europa.eu)

Esse detalhe traz uma importante lição:

uma vulnerabilidade em uma biblioteca aparentemente distante pode atingir aplicações muito mais sensíveis por meio das dependências de software.

O ataque não atingia qualquer computador Linux

Nos primeiros momentos do incidente, havia muita incerteza.

Hoje sabemos que o cenário era mais específico.

O código malicioso precisava encontrar determinadas condições de:

• sistema operacional;

• arquitetura;

• processo de compilação;

• distribuição;

• biblioteca;

• configuração do sshd.

Além disso, as versões comprometidas eram muito recentes.

Por isso, o código havia chegado principalmente a versões de desenvolvimento, teste ou atualização contínua de algumas distribuições.

A Red Hat, por exemplo, informou que:

Red Hat Enterprise Linux — RHEL não foi afetado.

O Fedora 40 Beta chegou a possuir versões do XZ 5.6.0, embora a empresa tenha informado que aquela versão não parecia vulnerável à exploração completa e recomendasse a reversão para a série 5.4. (redhat.com)

O Kali Linux informou que usuários que haviam atualizado seus sistemas entre 26 e 29 de março de 2024 poderiam ter recebido o pacote comprometido e deveriam atualizar imediatamente. (kali.org)

Esse alcance limitado foi extremamente importante.

O ataque foi descoberto antes de as versões comprometidas serem incorporadas de maneira ampla às principais distribuições estáveis utilizadas em servidores de produção.

Se tivesse permanecido oculto por mais tempo, o cenário poderia ter sido muito diferente.

O que realmente havia nos arquivos?

Aqui também vale atualizar a informação publicada nos primeiros dias.

Inicialmente, parecia especialmente intrigante que parte do código malicioso não aparecesse claramente no repositório Git.

A estratégia utilizada era bastante sofisticada.

O processo envolvia:

• arquivos aparentemente relacionados a testes;

• dados maliciosos escondidos nesses arquivos;

• scripts ofuscados;

• diferenças entre o repositório e os pacotes de distribuição;

• código executado durante a compilação;

• alteração da liblzma.

O NIST atualmente descreve a vulnerabilidade como um processo no qual o sistema de compilação da liblzma extraía um objeto pré-compilado escondido dentro de um arquivo de testes e o utilizava para modificar funções da biblioteca. (nvd.nist.gov)

Ou seja:

não se tratava simplesmente de alguém acrescentando uma linha chamada:

“backdoor = true”.

O código foi deliberadamente desenvolvido para dificultar sua descoberta.

E quem colocou a backdoor?

No alerta inicial da época, ainda existia dúvida.

Poderia ter ocorrido:

• comprometimento do computador de uma pessoa desenvolvedora;

• invasão de uma conta;

• participação deliberada de alguém ligado ao projeto.

Hoje temos uma compreensão muito mais clara.

A página oficial do XZ Utils afirma que Jia Tan, que atuou como co-mantenedor do projeto entre 2022 e 2024, e o grupo associado a ele introduziram deliberadamente a backdoor nas versões 5.6.0 e 5.6.1. (tukaani.org)

Isso transforma o episódio em algo ainda mais relevante:

um ataque à cadeia de suprimentos de software.

O que é um ataque à cadeia de suprimentos?

Uma organização pode proteger:

• seus servidores;

• suas senhas;

• suas redes;

• seus computadores.

Mas ela também utiliza programas criados por terceiros.

E esses programas dependem de:

bibliotecas;

frameworks;

pacotes;

plugins;

código aberto.

Imagine que o invasor perceba que atacar diretamente milhares de servidores é difícil.

Existe outra possibilidade:

comprometer um componente utilizado por milhares de servidores.

Depois, esperar que as próprias organizações:

baixem;

instalem;

atualizem

o código malicioso.

Esse é o problema da cadeia de suprimentos.

Em vez de atacar cada vítima individualmente, tenta-se comprometer aquilo em que todas elas confiam.

O aspecto humano do ataque talvez seja ainda mais interessante

O caso XZ não começou apenas com código.

A história do projeto mostra um processo de longo prazo de conquista de confiança.

O XZ Utils era mantido durante muitos anos principalmente por um número extremamente pequeno de pessoas.

Jia Tan começou contribuindo com o projeto e gradualmente recebeu maior participação e confiança.

Posteriormente tornou-se co-mantenedor.

Quando as versões comprometidas foram lançadas, a pessoa responsável pelo ataque já ocupava uma posição que lhe permitia interferir diretamente no processo de desenvolvimento e distribuição.

Isso mostra que segurança da informação não depende apenas de:

firewall;

antivírus;

criptografia.

Também depende de:

governança.

Uma pequena biblioteca sustentava uma enorme cadeia

Talvez essa seja uma das maiores lições do episódio.

XZ Utils não era uma empresa gigantesca com centenas de programadoras(es).

Era um projeto de código aberto mantido por pouquíssimas pessoas.

Mesmo assim, seu código estava presente ou poderia ser utilizado indiretamente em:

milhões de sistemas.

Isso cria uma assimetria impressionante.

Um componente pequeno pode se tornar infraestrutura para organizações enormes.

Uma universidade.

Um banco.

Uma empresa de tecnologia.

Um governo.

Todos podem depender de um pequeno projeto mantido por poucas pessoas em seu tempo disponível.

O que a Administração pode aprender com o caso XZ?

À primeira vista, esse parece ser um assunto apenas para profissionais de Tecnologia da Informação.

Não é.

É também um excelente caso de:

• gestão de riscos;

• governança;

• gestão de fornecedores;

• controles internos;

• continuidade;

• gestão do conhecimento;

• cadeia de suprimentos.

1. Conheça suas dependências

Uma organização sabe quais softwares utiliza?

E sabe:

de quais bibliotecas esses softwares dependem?

A quantidade de dependências pode ser enorme.

Por isso, surgiu uma prática chamada:

SBOM — Software Bill of Materials

ou:

Lista de Materiais de Software.

A lógica é semelhante à composição de um produto industrial.

Se ocorre um problema com determinado componente, precisamos conseguir responder:

Onde ele está sendo utilizado?

Sem inventário, a primeira pergunta durante uma vulnerabilidade vira:

“Será que temos isso em algum servidor?”

2. Atualização também é risco

Normalmente ensinamos:

mantenha tudo atualizado.

Continua sendo uma boa recomendação.

Mas o episódio XZ mostra uma nuance.

As versões antigas não estavam contaminadas.

As versões:

5.6.0

e

5.6.1

estavam.

Ou seja, naquele caso específico, quem havia atualizado primeiro poderia estar mais exposto.

Não significa que devemos deixar de atualizar sistemas.

Significa que uma política de atualizações precisa considerar:

• criticidade;

• testes;

• homologação;

• origem dos pacotes;

• canais de distribuição;

• estabilidade da versão.

Em ambientes sensíveis, “instalar imediatamente qualquer nova versão” também pode representar risco.

3. Não dependa apenas da reputação

XZ Utils era um projeto legítimo.

O problema estava dentro do próprio processo de desenvolvimento.

Isso ensina algo importante sobre controles:

confiança não substitui verificação.

Uma pessoa confiável pode ter uma conta comprometida.

Um fornecedor tradicional pode ser atacado.

Uma biblioteca conhecida pode receber código malicioso.

Uma boa estrutura de controle trabalha com a ideia de:

confiança + verificação.

4. Monitore comportamentos estranhos

A backdoor foi descoberta porque alguém observou:

algumas conexões SSH estavam consumindo CPU demais.

Era um detalhe.

Andres Freund poderia simplesmente ter pensado:

“deve ser algum bug”.

Mas investigou.

Segurança também depende da capacidade de perceber:

algo mudou.

Isso vale para TI e para Administração.

Despesas aumentando inesperadamente.

Prazo de atendimento se tornando maior.

Número de reclamações subindo.

Processamento ficando mais lento.

Indicadores anormais podem ser sintomas de problemas muito maiores.

5. Revisão independente importa

Código aberto possui uma vantagem importante:

em princípio, outras pessoas podem examinar o código.

Mas:

código disponível para revisão

não significa automaticamente:

código efetivamente revisado.

Milhares de projetos utilizavam XZ.

Pouquíssimas pessoas provavelmente acompanhavam cada mudança realizada em seu desenvolvimento.

A mesma lógica vale para organizações.

Um procedimento pode ter:

dupla conferência.

Um pagamento pode exigir:

segregação de funções.

Uma análise pode passar por:

revisão independente.

Não porque todas as pessoas sejam suspeitas.

Mas porque controles existem justamente para evitar que um único ponto de falha comprometa todo o sistema.

6. Pessoas sobrecarregadas também são risco organizacional

Projetos críticos mantidos por poucas pessoas criam riscos.

Se apenas uma pessoa conhece determinado sistema:

temos um risco.

Se apenas uma pessoa sabe executar determinado procedimento:

temos um risco.

Se apenas uma pessoa pode revisar determinado código:

temos um risco.

Isso se relaciona diretamente à:

gestão do conhecimento

e à:

continuidade organizacional.

A dependência excessiva de indivíduos cria fragilidade mesmo quando não existe qualquer intenção maliciosa.

7. Segurança também é governança

O episódio XZ mostra que segurança da informação precisa participar das decisões de gestão.

Não basta perguntar:

“Nosso antivírus está atualizado?”

Também é necessário perguntar:

Quais softwares utilizamos?

Quem pode instalá-los?

De onde vêm?

Como atualizamos?

Como identificamos componentes vulneráveis?

Quem acompanha alertas de segurança?

Quem decide quando uma atualização urgente precisa ser aplicada?

Como respondemos se uma biblioteca utilizada em dezenas de servidores for comprometida?

Essas são questões administrativas.

O alerta da DGTI/Uerj estava correto?

Considerando as informações disponíveis na manhã de 30 de março de 2024, o alerta da DGTI cumpriu exatamente aquilo que uma área de Tecnologia da Informação deveria fazer:

avisar rapidamente as(os) administradoras(es) para verificar seus ambientes.

Naquele momento ainda existiam muitas dúvidas sobre:

• abrangência;

• mecanismo;

• autoria;

• distribuições afetadas;

• possíveis consequências.

Por isso, a recomendação de verificar a presença das versões 5.6.0 e 5.6.1 fazia sentido diante da incerteza existente.

Hoje, entretanto, sabemos que o alcance foi mais limitado do que se temia inicialmente e que muitas distribuições estáveis nunca chegaram a oferecer as versões comprometidas.

O caso deixou de ser uma emergência mundial em andamento.

Mas tornou-se um extraordinário:

estudo de caso.

E qual é a situação hoje?

Se um sistema Linux moderno está devidamente mantido e utiliza os repositórios oficiais atualmente disponíveis, não há motivo para instalar deliberadamente versões vulneráveis do XZ Utils 5.6.0 ou 5.6.1.

Essas são versões historicamente comprometidas.

O próprio projeto XZ identifica oficialmente os tarballs 5.6.0 e 5.6.1 como contendo a backdoor e não os distribui como versões seguras. (tukaani.org)

O registro CVE continua existindo porque vulnerabilidades não desaparecem do histórico quando são corrigidas.

Elas permanecem documentadas justamente para:

• auditoria;

• investigação;

• gestão de ativos antigos;

• análise forense;

• inteligência de ameaças.

Em 2026, o NVD continua registrando especificamente as versões 5.6.0 e 5.6.1 como afetadas. (nvd.nist.gov)

O detalhe que mudou uma história

Talvez o aspecto mais fascinante de todo esse episódio seja pensar no que poderia ter acontecido se Andres Freund simplesmente tivesse ignorado aquele pequeno aumento no consumo de CPU.

Uma diferença de desempenho levou a:

uma investigação;

que encontrou:

uma biblioteca modificada;

que revelou:

uma backdoor;

que expôs:

um ataque à cadeia de suprimentos construído durante anos.

E tudo foi identificado antes que as versões comprometidas chegassem amplamente às distribuições Linux estáveis.

Foi um caso no qual:

curiosidade técnica + investigação + compartilhamento rápido da informação

evitaram um problema potencialmente muito maior.

Para guardar

O CVE-2024-3094 não deve ser lembrado apenas como:

“aquele problema do XZ Utils”.

Ele demonstra que uma organização pode possuir excelente segurança interna e continuar vulnerável por meio de seus fornecedores e dependências.

Também demonstra que:

pequenos componentes podem sustentar grandes infraestruturas;

confiança precisa ser acompanhada de controles;

dependências precisam ser conhecidas;

atualizações precisam ser gerenciadas;

conhecimento não deveria ficar concentrado em poucas pessoas;

e comportamentos aparentemente pequenos podem revelar grandes problemas.

Para quem trabalha com Administração, fica uma lição especialmente importante:

gestão de riscos não consiste apenas em imaginar o que pode dar errado dentro da organização. É preciso compreender também de quem — e de quê — a organização depende para continuar funcionando.

---

Matéria original

Este texto foi inspirado no alerta publicado pela Diretoria Geral de Tecnologia da Informação — DGTI/Uerj em março de 2024:

Aos administradores de sistemas Linux

https://www.dgti.uerj.br/aos-administradores-de-sistemas-linux/

Para saber mais

National Vulnerability Database — CVE-2024-3094
Registro oficial da vulnerabilidade no NIST. (nvd.nist.gov)

Divulgação original de Andres Freund — oss-security
Mensagem que apresentou publicamente a descoberta em 29 de março de 2024. (openwall.com)

XZ Utils
Página oficial do projeto com o registro histórico da backdoor. (tukaani.org)