Você não migra o que não enumera: o CBOM que falta aos bancos

TL;DR. O prazo de descoberta do NCSC, em 2028, antecede qualquer prazo de migração. Os bancos não podem cumpri-lo: o registro de ativos do DORA ignora a criptografia.

Principais conclusões

O prazo que ninguém orçou. Leia com atenção os cronogramas de migração publicados e o sequenciamento é inequívoco.
Seu registro do DORA anota tudo, menos a criptografia. Aqui está a parte que surpreende.
O que um CBOM realmente contém. Um Cryptography Bill of Materials é um inventário formal dos ativos criptográficos de um sistema — os algoritmos, as chaves, os certificados e os protocolos, e suas relações com os componentes de software que os usam.
Descoberta são quatro problemas, não um. Tratar a descoberta como uma frente única é a forma mais comum de esses programas falharem.

Todo roteiro pós-quântico no setor bancário pressupõe um inventário que não existe. Os planos estão escritos, os comitês diretivos se reúnem, os painéis de acompanhamento estão em amarelo. Por baixo de tudo isso está a suposição de que alguém, em algum lugar, consegue produzir a lista de cada ponto em que o banco executa uma operação criptográfica — qual algoritmo, qual tamanho da chave, qual biblioteca, qual certificado, expirando quando. Quase nenhuma instituição consegue. O primeiro marco do NCSC não é um marco de migração: é um marco de descoberta, com prazo em 2028, e é o único que ninguém orçou.

Resumo executivo

A sequência é descoberta, depois agilidade, depois migração. A orientação do NCSC fixa um marco definido de descoberta em 2028, a migração de maior prioridade em 2031 e a conclusão até 2035. A instituição que começa a migrar antes de enumerar vai migrar os sistemas que por acaso conhece.

O registro que você tem não responde à pergunta que você agora enfrenta. O Article 8 do DORA exige que as entidades financeiras identifiquem, classifiquem e documentem os ativos de TIC e mapeiem suas interdependências. Não exige uma única propriedade criptográfica, de modo que um registro conforme ao Article 8 pode estar completo e ainda assim ser inútil para o planejamento de agilidade criptográfica.

O padrão já existe. Ativos criptográficos — algoritmos com tamanho da chave, modo e curva; chaves; certificados; protocolos — são representáveis no CycloneDX, publicado como ECMA-424. Isto é uma questão de schema, não de compras.

O quartil mais difícil não é seu para escanear. Módulos de segurança de hardware, appliances de pagamento, bibliotecas embarcadas por fornecedores e provedores SaaS não são enumeráveis apontando um scanner para eles. Essa parte do inventário se constrói por atestação contratual, e a cláusula precisa existir antes do roteiro.

O prazo que ninguém orçou

Leia com atenção os cronogramas de migração publicados e o sequenciamento é inequívoco. O roteiro do National Cyber Security Centre coloca a descoberta — um retrato completo de quais sistemas e serviços dependem de criptografia — em 2028, o trabalho de migração de maior prioridade em 2031 e a conclusão em todos os sistemas, serviços e produtos em 2035. O relatório de transição do NIST, o IR 8547, corre em trilha compatível: algoritmos de chave pública vulneráveis a computadores quânticos, incluindo RSA e ECC, ficam depreciados após 2030 e proibidos após 2035.

A maioria dos programas bancários internalizou 2035 como a data. É a ponta errada do cronograma para planejar.

Duas datas importam muito mais. A primeira é 2028, porque a descoberta é o insumo de tudo o que vem depois — não se dimensiona, orça ou sequencia uma migração contra um denominador desconhecido. A segunda é 2030, porque "depreciado" não é palavra branda em uma instituição regulada: é o ponto em que continuar dependendo de um algoritmo vira uma decisão que alguém precisa assinar.

Entre agora e 2028 há menos de trinta meses. Isso são um, talvez dois, ciclos orçamentários para construir uma capacidade que a maioria das instituições sequer começou.

Seu registro do DORA anota tudo, menos a criptografia

Aqui está a parte que surpreende. A maioria dos grandes bancos europeus já mantém um inventário detalhado e revisado com regularidade dos ativos de TIC, porque o DORA os obriga a isso.

O Article 8 do Regulation (EU) 2022/2554 exige que as entidades financeiras identifiquem, classifiquem e documentem adequadamente todas as funções de negócio suportadas por TIC, as informações e os ativos de TIC que as sustentam e seus papéis e dependências em relação ao risco de TIC — e que mapeiem a configuração desses ativos e os vínculos entre eles, mantendo o mapa sob revisão.

É um inventário sério. E é do formato errado para este problema.

Tabela 1: o registro que você tem e o registro que o marco de 2028 exige

Pergunta	Registro de ativos de TIC (DORA, Article 8)	Inventário criptográfico (CBOM)
O que é este ativo e de quem é?	Sim — é o núcleo do registro	Não é sua finalidade
Quão crítico ele é e do que depende?	Sim — classificação e mapeamento de interdependências	Herdado do registro de ativos
Quais algoritmos ele usa, e onde?	Não	Sim — por componente, com tamanho da chave, modo e curva
Qual biblioteca os implementa, em qual versão?	Parcialmente, via SBOM, se houver	Sim, como relação explícita
Quais certificados ele apresenta, expirando quando?	Raramente, e em geral em uma ferramenta de PKI separada	Sim
Onde ficam as chaves e como são protegidas?	Não	Sim — inclusive se há um HSM no caminho
Este ativo é vulnerável a computadores quânticos?	Não é derivável	Diretamente respondível

A última linha é o argumento inteiro. Uma instituição pode estar plenamente conforme ao Article 8, passar no exame do supervisor e ainda assim não conseguir responder "quantos dos nossos sistemas quebram em 2030" sem encomendar um projeto de descoberta do zero.

Isto não é uma crítica ao DORA. O Article 8 foi escrito para responder a perguntas de resiliência e concentração, e as responde bem. Só não foi escrito para responder a uma pergunta de agilidade criptográfica, e os dois registros precisam ser unidos, em vez de operados como planilhas separadas sob times separados.

O que um CBOM realmente contém

Um Cryptography Bill of Materials é um inventário formal dos ativos criptográficos de um sistema — os algoritmos, as chaves, os certificados e os protocolos, e suas relações com os componentes de software que os usam.

O ponto estrutural que importa é que não se trata de um formato de arquivo novo. O suporte a ativos criptográficos foi contribuído ao CycloneDX, a especificação de bill of materials apoiada pela OWASP, publicada como padrão da Ecma International, o ECMA-424. Um CBOM é, portanto, um documento CycloneDX com os campos de criptografia preenchidos. Valida contra o mesmo schema, percorre os mesmos pipelines e chega ao mesmo registro de artefatos que os SBOMs que a instituição já produz para fins de cadeia de suprimentos.

Isso importa mais do que parece. A diferença entre um padrão que entra em produção e um que emperra costuma ser se ele exige encanamento novo. Este não exige.

Tabela 2: classes de ativo do CBOM e a pergunta de migração que cada uma responde

Classe de ativo	O que é registrado	A pergunta que responde
Algoritmo	Primitiva, tamanho da chave, modo, curva, preenchimento e a função que executa	Quais das nossas operações são vulneráveis a computadores quânticos, e com que força de parâmetro?
Chave	Tipo, tamanho, formato, estado e onde o material reside	Quais chaves são protegidas por um HSM e quais ficam na memória da aplicação?
Certificado	Titular, emissor, algoritmo de assinatura, janela de validade	O que expira antes da janela de migração e o que está assinado com algoritmo depreciado?
Protocolo	Protocolo e versão, com os conjuntos de cifras oferecidos	O que é de fato negociado na rede, em oposição ao que o arquivo de configuração declara?
Componente relacionado	A biblioteca, a versão e o local do código que implementam o acima	Se esta biblioteca for substituída, o que mais se move junto?

A última linha é a que transforma um inventário em plano. Uma lista de algoritmos informa o tamanho do problema. Uma lista de algoritmos unida aos componentes que os implementam informa o formato do trabalho — que é do que uma sequência de migração é de fato feita.

Descoberta são quatro problemas, não um

Tratar a descoberta como uma frente única é a forma mais comum de esses programas falharem. São quatro problemas distintos, com quatro ferramentas, quatro donos e níveis de confiança bem diferentes.

1. Código-fonte — o que o código pede. A análise estática sobre os seus próprios repositórios encontra chamadas criptográficas, parâmetros fixados no código e as bibliotecas invocadas. Há ferramental aberto: o projeto CBOMkit e seu plugin para SonarQube detectam ativos criptográficos no código-fonte e emitem CycloneDX. Confiança mais alta, cobertura mais estreita — só enxerga o código que você escreveu e ainda compila.

2. Binários e contêineres — o que de fato é entregue. A análise de fonte perde tudo o que entra como dependência compilada ou vem embutido em uma imagem base. A varredura de contêineres e de sistema de arquivos fecha parte dessa lacuna. Espere que as duas visões discordem; a discordância já é um achado.

3. A rede — o que é genuinamente negociado. Configuração é intenção, não observação. A observação passiva da negociação TLS ao vivo em todo o parque é o único jeito de descobrir que um serviço que documenta TLS 1.3 ainda aceita algo mais antigo com uma contraparte interna que nunca atualizou. Em um parque de pagamentos, essa contraparte costuma ser a que importa.

4. O parque de fornecedores e hardware — o que não dá para escanear de jeito nenhum. Módulos de segurança de hardware, terminais de pagamento, appliances de rede, subsistemas de mainframe e todo provedor SaaS na cadeia. Nenhum scanner alcança isso. Este quartil se enumera perguntando, sob contrato, e é onde a exposição genuína do banco de atacado se concentra, porque os sistemas que compensam e liquidam são desproporcionalmente fornecidos por terceiros.

O quarto é o que se começa agora, porque tem o maior prazo de maturação e não é tarefa de engenharia. É tarefa de compras: colocar uma cláusula de divulgação criptográfica e de agilidade criptográfica no contrato e no modelo de renovação, para que em 2028 a resposta chegue como obrigação do fornecedor, e não como favor. Cada trimestre em que a cláusula não está no modelo é um trimestre de renovações que terão de ser reabertas depois.

Transformar isso em controle, não em projeto

O modo de falha em que eu apostaria não é os bancos pularem o inventário. É encomendarem-no como esforço único, entregarem um retrato defensável em 2028 e deixarem-no envelhecer — porque foi financiado como entregável de projeto pós-quântico, e não construído como controle mantido.

Um inventário criptográfico envelhece mais rápido que um registro de ativos. Certificados rotacionam. Bibliotecas são atualizadas pela automação de dependências. Uma imagem base muda e um serviço inteiro adquire silenciosamente outra pilha TLS. Um retrato tirado em 2028 estará materialmente errado em 2029, que é exatamente quando o trabalho de priorização de 2031 depende dele.

Três compromissos evitam isso.

Gere no pipeline, não em pesquisa. Um CBOM deve ser emitido pelo build, ao lado do SBOM, e armazenado como artefato versionado contra a release. Um inventário montado enviando questionário por e-mail aos donos das aplicações já chega desatualizado e não permite diff.

Faça o diff e alerte sobre o diff. O sinal valioso não é o inventário; é a mudança no inventário. Um serviço que adquiriu nova dependência criptográfica, um certificado que encurtou, um algoritmo que apareceu onde antes não estava — esses são os eventos que merecem um controle. É o mesmo raciocínio que torna o diff de SBOM mais útil do que o arquivamento de SBOM.

Una ao registro que você já mantém. O CBOM responde "qual criptografia"; o registro do Article 8 responde "quão crítico, de quem e o que depende disso". Nenhum dos dois é uma priorização sozinho. Unidos, produzem o único ranking que importa: operações vulneráveis a computadores quânticos ordenadas pela criticidade da função de negócio que se apoia nelas. Essa união é a entrega real de um programa de descoberta, e vale nomeá-la assim no plano.

O manual de operação

Reformule o marco de 2028 como capacidade, não como relatório. A entrega é um inventário mantido e legível por máquina que se regenera sozinho, não um documento produzido uma vez para o supervisor.
Emita CBOMs a partir do build agora, começando pelos serviços novos. Não tente o parque inteiro de uma vez. Ligue isso ao pipeline de tudo o que for construído ou alterado de forma relevante neste ano, para que a cobertura se acumule em vez de exigir uma campanha.
Coloque a cláusula contratual no modelo de renovação neste trimestre. Divulgação criptográfica e compromisso de agilidade criptográfica. É o item de maior prazo de maturação da lista e não depende de nenhuma decisão de ferramenta.
Rode a observação de rede primeiro nos caminhos de pagamento e liquidação. É onde a distância entre configuração e realidade causa mais estrago e onde as contrapartes legadas se concentram.
Una o CBOM ao registro do Article 8 e ordene pela união. Publique a lista ordenada. É o artefato que converte um inventário de engenharia em conversa de conselho sobre sequenciamento e dinheiro.
Faça diff de cada regeneração e alerte sobre novas dependências vulneráveis a computadores quânticos. Inventário sem diff é arquivo morto.

As instituições que chegarão a 2031 com folga não são as que têm a visão mais avançada de ML-KEM. São as que conseguem responder, em qualquer manhã e sem encomendar um projeto, onde a criptografia delas está de fato.

Perguntas frequentes

Um CBOM é coisa diferente de um SBOM?
É o mesmo tipo de documento com campos diferentes preenchidos. O suporte a ativos criptográficos foi incorporado ao CycloneDX, publicado como ECMA-424, de modo que um CBOM valida contra o mesmo schema e percorre o mesmo ferramental de um SBOM. As instituições que já geram SBOMs estão mais perto disso do que costumam supor.

O DORA exige um inventário criptográfico?
Não nesses termos. O Article 8 do Regulation (EU) 2022/2554 exige identificação, classificação e documentação dos ativos de TIC e o mapeamento de sua configuração e interdependências. Propriedades criptográficas não estão entre os atributos que ele obriga a registrar, e é por isso que um registro conforme ao Article 8 não responde a uma pergunta de vulnerabilidade a computadores quânticos sem ser estendido.

Por que a descoberta precisa terminar tão à frente da migração?
Porque é o insumo da priorização. A orientação do NCSC fixa a descoberta em 2028 e a migração de maior prioridade em 2031 justamente para haver um intervalo definido em que se ordena o parque e se sequencia o trabalho. Comprimir os dois significa migrar o que é mais bem compreendido, e não o que mais importa.

Como inventariar a criptografia dentro de hardware de fornecedor e de SaaS?
Não se escaneia; exige-se divulgação. Módulos de segurança de hardware, appliances de pagamento e prestadores de serviço precisam estar cobertos por uma obrigação contratual de divulgação criptográfica e de agilidade criptográfica. Como isso depende de ciclos de renovação, e não de esforço de engenharia, tem o maior prazo de maturação de todo o programa e deve começar primeiro.

Devemos esperar o ferramental amadurecer antes de começar?
Não, e o argumento do ferramental costuma ser procuração para o argumento do orçamento. Implementações abertas já emitem inventários criptográficos em CycloneDX a partir do código-fonte e de imagens de contêiner, e a especificação é um padrão ratificado. A restrição sobre o marco de 2028 é cobertura e alcance contratual, não disponibilidade de ferramenta.

Referências

Parlamento Europeu e Conselho da União Europeia, 2022. Regulation (EU) 2022/2554 relativo à resiliência operacional digital do setor financeiro (DORA). Bruxelas: Jornal Oficial da União Europeia. Disponível em: Parlamento Europeu e Conselho da União Europeia, 2022..
National Cyber Security Centre, 2025. Cronogramas para a migração à criptografia pós-quântica. Londres: NCSC. Disponível em: National Cyber Security Centre, 2025..
National Institute of Standards and Technology, 2024. NIST IR 8547 (Initial Public Draft), Transição para os padrões de criptografia pós-quântica. Gaithersburg: Departamento de Comércio dos EUA. Disponível em: National Institute of Standards and Technology, 2024..
National Institute of Standards and Technology, 2024. FIPS 203, padrão de mecanismo de encapsulamento de chaves baseado em reticulados modulares. Gaithersburg: Departamento de Comércio dos EUA. Disponível em: National Institute of Standards and Technology, 2024..
OWASP Foundation, 2026. Especificação CycloneDX Bill of Materials (ECMA-424). Wakefield: OWASP Foundation. Disponível em: OWASP Foundation, 2026..
OWASP CycloneDX, 2026. Cryptography Bill of Materials (CBOM). Wakefield: OWASP Foundation. Disponível em: OWASP CycloneDX, 2026..
IBM Research, 2026. CBOM: Cryptography Bill of Materials. Armonk: IBM. Disponível em: IBM Research, 2026..

Última revisão 2026-08-05.

Republicar este artigo

Você não migra o que não enumera: o CBOM que falta aos bancos — Sebastien Rousseau

O prazo de descoberta do NCSC, em 2028, antecede qualquer prazo de migração. Os bancos não podem cumpri-lo: o registro de ativos do DORA ignora a criptografia.

Este artigo está licenciado sob Creative Commons Attribution 4.0 International. A republicação exige atribuição à URL canônica.

Você não migra o que não enumera: o CBOM que falta aos bancos — Sebastien Rousseau

O prazo de descoberta do NCSC, em 2028, antecede qualquer prazo de migração. Os bancos não podem cumpri-lo: o registro de ativos do DORA ignora a criptografia.

Originally published at https://sebastienrousseau.com/pt-br/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER