Traducción automática — pendiente de revisión humana. La versión en portugués es la vigente.
codafort × CMN 4.893 (post-5.274) × Guía ANBIMA §7.1: mapa de evidencias
Este mapa vincula los requisitos citables de la regulación financiera brasileña con lo que codafort entrega hoy. Usa el texto de la Resolución CMN 4.893/2021 consolidado tras la Resolución CMN 5.274/2025. Nada aquí es roadmap. Cada fila dice qué prueba la evidencia y qué no prueba.
Este documento no es asesoría jurídica.
La frontera, antes de todo
- SAST no satisface el Art. 22-A. El requisito nuevo más exigente de la CMN 5.274 es la prueba de penetración anual realizada por un tercero independiente, es decir, un pentest. Ninguna evidencia de codafort satisface ese requisito, y no la vendemos como si lo hiciera. codafort aporta evidencia complementaria del programa de seguridad (Art. 8, gestión de vulnerabilidades, ANBIMA §7.1) y de la gestión de riesgo de terceros, el TPRM (Art. 3 §6).
- La guía ANBIMA recomienda SAST, DAST y SCA, y codafort cubre los tres: SAST y SCA en
codafort, DAST encodaprobe, que prueba la aplicación en funcionamiento desde fuera y solo en los objetivos que la institución autorizó. También hay IAST, encodatrace. El DAST no es un pentest y no sustituye el Art. 22-A. La evidencia del IAST y del DAST entra en la declaración contrafirmada. La del DAST vale por clase de vulnerabilidad (CWE): va adjunta, pero no cambia el veredicto, porque solo la evidencia por archivo y línea reprueba un finding. - Las resoluciones son de diciembre de 2025, con plazo en marzo de 2026, y la práctica de fiscalización del BCB todavía se está formando. Por eso este mapa se apoya solo en el texto de la norma.
Requisito, entrega y valor probatorio
| Requisito citable | Qué entrega codafort | Qué prueba y qué no prueba |
|---|---|---|
| CMN 4.893, Art. 8 §1 V: pruebas y escaneos periódicos de vulnerabilidades | Escaneo en el pipeline de CI, ejecutado localmente y de forma determinista (la misma entrada da el mismo resultado). Informe en SARIF 2.1.0, validado contra el schema oficial, con el camino del dato desde la entrada hasta el punto vulnerable en cada finding | Prueba que el escaneo ocurrió, cuándo, con qué motor y qué reglas, y qué encontró, con el camino de cada finding. No prueba ausencia de vulnerabilidades ni sustituye el pentest (Art. 22-A) |
| CMN 4.893, Art. 23 X (post-5.274): documentación de resultados y planes de acción, retenida 5 años a disposición del BCB | Evidencias de un solo archivo y deterministas: el SARIF, el veredicto del quality gate en JSON, un informe HTML autocontenido que no necesita ningún otro archivo y el resultado completo en JSON con la procedencia de la ejecución | Prueba una traza íntegra en el tiempo, siempre que se archive por release (ver la práctica de retención abajo). El plan de acción es proceso de la institución: codafort aporta el insumo trazable (el finding y la corrección sugerida), y el flujo de remediación queda con la institución |
| CMN 4.893, Art. 3 §6 (nuevo, 5.274): verificación de controles en sistemas de terceros dentro de la infraestructura de la institución | Declaración contrafirmada: el proveedor declara que el escaneo X, con el conjunto de reglas Y, en el commit Z, tuvo el veredicto W, y codafort contrafirma la declaración con Ed25519. Cualquier parte la verifica offline | Prueba la integridad y la autoría de la declaración: el proveedor (titular de la licencia) declaró el resultado y codafort lo contrafirmó. Una vez emitida, cualquier alteración invalida la firma. No prueba que el resultado declarado sea verdadero, porque codafort no vuelve a ejecutar el escaneo. Tampoco prueba ausencia de vulnerabilidades ni satisface el Art. 22-A. Es evidencia complementaria de homologación y TPRM |
| Gestión de vulnerabilidades con gobernanza (5.274): planes de acción reportados a la dirección | Quality gate con condiciones explícitas (la configuración por defecto ya incluye los riesgos altos correlacionados) y veredicto en JSON archivable. El escaneo también puede limitarse a lo que introduce un cambio | Prueba que había un criterio objetivo para reprobar el cambio y cuál era. Sirve de insumo técnico para el informe anual al órgano de administración (Art. 8), sin sustituirlo |
| Guía ANBIMA 2025 §7.1: "integrar SAST, DAST y SCA en el pipeline de CI/CD" | SAST en 16 lenguajes. SCA con la base de vulnerabilidades OSV, consultada localmente, priorización por EPSS y por el catálogo CISA KEV, y detección de paquetes con nombre imitado (typosquatting). En CI/CD, el veredicto sale como código de salida del pipeline y el SARIF alimenta los paneles de code scanning. DAST en codaprobe, a partir del contrato de la API (OpenAPI, Postman, HAR o GraphQL), con informe propio y registro de auditoría verificable | Cubre por nombre los tres pilares del §7.1. El DAST no es un pentest (Art. 22-A); su evidencia entra en la declaración contrafirmada sin cambiar el veredicto |
| Trazabilidad y procedencia de cada ejecución (evidencia operativa, post-5.274) | Cuando el análisis lee el repositorio git, el resultado registra el commit analizado, la rama, si había cambios sin versionar y una huella de la configuración efectiva. El SARIF también registra la ejecución y su origen en el control de versiones. El catálogo de reglas se puede exportar en JSON o CSV para auditoría | Prueba qué código (commit), qué configuración y qué reglas produjeron cada resultado: el auditor reconstruye el contexto sin acceso a la máquina. No registra quién vio o atendió el finding; esa traza es de la institución |
| Restricción de egreso y confidencialidad (política de ciberseguridad; LGPD por extensión) | El análisis se ejecuta por completo en la máquina o en el pipeline de la institución y no usa la red: el código no se sube y la base de vulnerabilidades es una copia local. Para entornos aislados, sin red, existe una versión entregada a pedido en el contrato Platform, de la que se quitó incluso el código de telemetría y de red | En la versión para entorno aislado, el código y los resultados no salen de la máquina, porque el binario no tiene cómo enviarlos. En la versión pública salen la telemetría seudónima, que se desactiva con una línea, y lo que la institución conecte a la Platform; la lista completa de lo que sale está en Telemetría y en Privacidad |
| SBOM y cadena de suministro (insumo para TPRM e inventario) | SBOM en CycloneDX 1.5 y SPDX 2.3, generado localmente | Prueba el inventario de dependencias en el momento del escaneo. Salvedad documentada: los campos de proveedor y licencia del mínimo NTIA tienen huecos conocidos, y las relaciones completas entre dependencias solo se generan para proyectos npm (lockfile v2 o v3) y Rust |
Práctica de retención recomendada (Art. 23, 5 años)
Por cada release, o por cada ventana regulatoria, archiva juntos estos cuatro archivos. Todos son deterministas y se pueden verificar después:
release-X.Y.Z/
├── report.sarif # escaneo completo (Art. 8 §1 V)
├── gate.json # veredicto del quality gate (criterio objetivo)
├── attestation.txt # declaración contrafirmada (integridad firmada)
└── sbom.cdx.json # inventario de dependencias (CycloneDX)La declaración contrafirmada se puede verificar offline en cualquier fecha futura. La clave pública viene embebida en el binario, así que la verificación no depende de que codafort esté en línea el día de la auditoría.
Cómo citarlo en un cuestionario o una homologación
Texto sugerido:
"Ejecutamos análisis estático (SAST) y de composición (SCA) con codafort en nuestro pipeline de CI, con un quality gate basado en un criterio objetivo y evidencias retenidas por release: SARIF, el veredicto del gate y una declaración contrafirmada criptográficamente por el fabricante de la herramienta, verificable offline. La declaración prueba la integridad y la autoría del resultado declarado de cada escaneo. Las pruebas de penetración independientes (Art. 22-A) las realiza por separado [tercero]."
Mantén la última frase. Sin ella, el texto sobrevende: la declaración convive con el pentest y no lo sustituye.