codafort × CMN 4.893 (pós-5.274) × Guia ANBIMA §7.1: mapa de evidências
Este mapa liga os requisitos citáveis da regulação financeira brasileira ao que a codafort entrega hoje. Usa o texto da Res. CMN 4.893/2021 consolidado após a Res. CMN 5.274/2025. Nada aqui é roadmap. Cada linha diz o que a evidência prova e o que ela não prova.
Este documento não é parecer jurídico.
A fronteira, antes de tudo
- SAST não cumpre o Art. 22-A. A exigência nova mais dura da CMN 5.274 é o teste de intrusão anual feito por terceiro independente, ou seja, pentest. Nenhuma evidência da codafort satisfaz essa exigência, e não a vendemos como se satisfizesse. A codafort entra como evidência complementar do programa de segurança (Art. 8º, gestão de vulnerabilidades, ANBIMA §7.1) e da gestão de risco de terceiros, o TPRM (Art. 3º §6º).
- O Guia ANBIMA recomenda SAST, DAST e SCA, e a codafort cobre os três: SAST e SCA no
codafort, DAST nocodaprobe, que testa a aplicação em funcionamento pelo lado de fora e só nos alvos que a instituição autorizou. Há também IAST, nocodatrace. O DAST não é pentest e não substitui o Art. 22-A. A evidência do IAST e do DAST entra na declaração contra-assinada. A do DAST vale por classe de vulnerabilidade (CWE): vai anexada, mas não altera o veredito, porque só evidência por arquivo e linha reprova um finding. - As resoluções são de dezembro de 2025, com prazo em março de 2026, e a prática de fiscalização do BCB ainda está se formando. Por isso este mapa se apoia só no texto da norma.
Requisito, entrega e valor probatório
| Requisito citável | O que a codafort entrega | O que prova e o que não prova |
|---|---|---|
| CMN 4.893, Art. 8º §1º V: testes e varreduras periódicas de vulnerabilidade | Varredura no pipeline de CI, feita localmente e de forma determinística (a mesma entrada dá o mesmo resultado). Relatório em SARIF 2.1.0, validado contra o schema oficial, com o caminho do dado da entrada até o ponto vulnerável em cada finding | Prova que a varredura ocorreu, quando, com qual motor e quais regras, e o que encontrou, com o caminho de cada finding. Não prova ausência de vulnerabilidade nem substitui o pentest (Art. 22-A) |
| CMN 4.893, Art. 23 X (pós-5.274): documentação dos resultados e dos planos de ação, retida por 5 anos à disposição do BCB | Evidências em arquivo único e determinísticas: o SARIF, o veredito do quality gate em JSON, um relatório HTML autocontido, que dispensa qualquer outro arquivo, e o resultado completo em JSON com a procedência da execução | Prova uma trilha íntegra no tempo, desde que arquivada a cada release (veja a prática de retenção abaixo). O plano de ação é processo da instituição: a codafort fornece o insumo rastreável (o finding e a correção sugerida), e o fluxo de tratamento fica com a instituição |
| CMN 4.893, Art. 3º §6º (novo, 5.274): verificação de controles em sistemas de terceiros na infraestrutura da instituição | Declaração contra-assinada: o fornecedor declara que a varredura X, com o conjunto de regras Y, no commit Z, teve o veredito W, e a codafort contra-assina a declaração com Ed25519. Qualquer parte a verifica offline | Prova a integridade e a autoria da declaração: o fornecedor (titular da licença) declarou o resultado e a codafort contra-assinou. Depois de emitida, qualquer alteração invalida a assinatura. Não prova que o resultado declarado é verdadeiro, porque a codafort não refaz a varredura. Também não prova ausência de vulnerabilidade e não cumpre o Art. 22-A. É evidência complementar de homologação e TPRM |
| Gestão de vulnerabilidades com governança (5.274): planos de ação reportados à administração | Quality gate com condições explícitas (a configuração padrão já inclui os riscos altos correlacionados) e veredito em JSON arquivável. A varredura também pode se limitar ao que uma mudança introduz | Prova que havia um critério objetivo para reprovar a mudança e qual era. Serve de insumo técnico ao relatório anual ao órgão de administração (Art. 8º), sem substituí-lo |
| Guia ANBIMA 2025 §7.1: "integrar SAST, DAST e SCA ao pipeline de CI/CD" | SAST em 16 linguagens. SCA com a base de vulnerabilidades OSV, consultada localmente, priorização por EPSS e pelo catálogo CISA KEV, e detecção de pacotes com nome imitado (typosquatting). No CI/CD, o veredito sai como código de saída do pipeline e o SARIF alimenta os painéis de code scanning. DAST no codaprobe, a partir do contrato da API (OpenAPI, Postman, HAR ou GraphQL), com laudo próprio e registro de auditoria verificável | Cobre nominalmente os três pilares do §7.1. O DAST não é pentest (Art. 22-A); a evidência dele entra na declaração contra-assinada sem alterar o veredito |
| Rastreabilidade e procedência de cada execução (evidência operacional, pós-5.274) | Quando a análise lê o repositório git, o resultado registra o commit analisado, a branch, se havia alteração não versionada e uma impressão digital da configuração efetiva. O SARIF também registra a execução e a origem no controle de versão. O catálogo de regras pode ser exportado em JSON ou CSV para auditoria | Prova qual código (commit), qual configuração e quais regras produziram cada resultado: o auditor reconstitui o contexto sem acesso à máquina. Não registra quem viu ou tratou o finding; essa trilha é da instituição |
| Restrição de saída de dados e sigilo (política de segurança cibernética; LGPD por extensão) | A análise roda inteira na máquina ou no pipeline da instituição e não usa a rede: o código não é enviado e a base de vulnerabilidades é uma cópia local. Para ambiente isolado, sem rede, existe uma versão entregue sob pedido no contrato Platform, da qual foi removido até o código de telemetria e de rede | Na versão para ambiente isolado, código e resultados não saem da máquina, porque o binário não tem como enviá-los. Na versão pública, saem a telemetria pseudônima, que se desliga numa linha, e o que a instituição conectar à Platform; a lista completa do que sai está em Telemetria e em Privacidade |
| SBOM e cadeia de suprimentos (subsídio a TPRM e inventário) | SBOM em CycloneDX 1.5 e SPDX 2.3, gerado localmente | Prova o inventário de dependências no momento da varredura. Ressalva documentada: os campos de fornecedor e licença do mínimo NTIA têm lacunas conhecidas, e as relações completas entre dependências só saem para projetos npm (lockfile v2 ou v3) e Rust |
Prática recomendada de retenção (Art. 23, 5 anos)
A cada release, ou a cada janela regulatória, arquive estes quatro arquivos juntos. Todos são determinísticos e podem ser verificados depois:
release-X.Y.Z/
├── report.sarif # varredura completa (Art. 8º §1º V)
├── gate.json # veredito do quality gate (critério objetivo)
├── attestation.txt # declaração contra-assinada (integridade assinada)
└── sbom.cdx.json # inventário de dependências (CycloneDX)A declaração contra-assinada pode ser verificada offline em qualquer data futura. A chave pública vem embarcada no binário, então a verificação não depende de a codafort estar no ar no dia da auditoria.
Como citar em questionário ou homologação
Sugestão de texto:
"Executamos análise estática (SAST) e de composição (SCA) com a codafort no pipeline de CI, com quality gate de critério objetivo e evidências retidas por release: SARIF, veredito do gate e declaração contra-assinada criptograficamente pelo fornecedor da ferramenta, verificável offline. A declaração comprova a integridade e a autoria do resultado declarado de cada varredura. Os testes de intrusão independentes (Art. 22-A) são conduzidos separadamente por [terceiro]."
Mantenha a última frase. Sem ela, o texto sobrevende: a declaração convive com o pentest e não o substitui.