Machine translation — pending human review. The Portuguese version is authoritative.
codafort × CMN 4.893 (post-5.274) × ANBIMA Guide §7.1: evidence map
This map links the citable requirements of Brazilian financial regulation to what codafort delivers today. It uses the text of CMN Resolution 4.893/2021 as consolidated after CMN Resolution 5.274/2025. Nothing here is roadmap. Each row states what the evidence proves and what it does not prove.
This document is not legal advice.
The boundary, first
- SAST does not satisfy Art. 22-A. The toughest new requirement of CMN 5.274 is annual penetration testing by an independent third party, that is, a pentest. No codafort evidence satisfies that requirement, and we do not sell it as if it did. codafort serves as complementary evidence for the security program (Art. 8, vulnerability management, ANBIMA §7.1) and for third-party risk management, TPRM (Art. 3 §6).
- The ANBIMA guide recommends SAST, DAST and SCA, and codafort covers all three: SAST and SCA in
codafort, DAST incodaprobe, which tests the running application from the outside and only against targets the institution has authorized. There is also IAST, incodatrace. The DAST is not a pentest and does not replace Art. 22-A. Evidence from the IAST and the DAST goes into the counter-signed declaration. The DAST evidence counts per vulnerability class (CWE): it is attached but does not change the verdict, because only per-file, per-line evidence fails a finding. - The resolutions date from December 2025, with a March 2026 deadline, and the BCB's supervisory practice is still forming. That is why this map relies only on the text of the rule.
Requirement, deliverable and evidentiary value
| Citable requirement | What codafort delivers | What it proves and what it does not prove |
|---|---|---|
| CMN 4.893, Art. 8 §1 V: periodic vulnerability tests and scans | A scan in the CI pipeline, run locally and deterministically (the same input gives the same result). Report in SARIF 2.1.0, validated against the official schema, with the path of the data from the input to the vulnerable point in each finding | Proves that the scan took place, when, with which engine and which rules, and what it found, with the path of each finding. Does not prove absence of vulnerabilities and does not replace the pentest (Art. 22-A) |
| CMN 4.893, Art. 23 X (post-5.274): documentation of results and action plans, retained for 5 years at the BCB's disposal | Single-file, deterministic evidence: the SARIF, the quality gate verdict in JSON, a self-contained HTML report that needs no other file, and the full result in JSON with the provenance of the run | Proves an intact trail over time, provided it is archived per release (see the retention practice below). The action plan is the institution's process: codafort supplies the traceable input (the finding and the suggested fix), and the remediation workflow stays with the institution |
| CMN 4.893, Art. 3 §6 (new, 5.274): verification of controls in third-party systems within the institution's infrastructure | Counter-signed declaration: the vendor declares that scan X, with ruleset Y, at commit Z, had verdict W, and codafort counter-signs the declaration with Ed25519. Any party can verify it offline | Proves the integrity and authorship of the declaration: the vendor (the license holder) declared the result and codafort counter-signed it. Once issued, any change invalidates the signature. It does not prove that the declared result is true, because codafort does not rerun the scan. Nor does it prove absence of vulnerabilities, and it does not satisfy Art. 22-A. It is complementary evidence for onboarding and TPRM |
| Vulnerability management with governance (5.274): action plans reported to management | Quality gate with explicit conditions (the default configuration already includes high correlated risks) and a verdict in archivable JSON. The scan can also be limited to what a change introduces | Proves that there was an objective criterion for failing the change and what it was. Serves as technical input to the annual report to the governing body (Art. 8), without replacing it |
| ANBIMA Guide 2025 §7.1: "integrate SAST, DAST and SCA into the CI/CD pipeline" | SAST in 16 languages. SCA against the OSV vulnerability database, queried locally, with prioritization by EPSS and the CISA KEV catalog, and detection of packages with imitated names (typosquatting). In CI/CD, the verdict comes out as the pipeline exit code and the SARIF feeds code scanning dashboards. DAST in codaprobe, from the API contract (OpenAPI, Postman, HAR or GraphQL), with its own report and a verifiable audit log | Covers the three pillars of §7.1 by name. The DAST is not a pentest (Art. 22-A); its evidence goes into the counter-signed declaration without changing the verdict |
| Traceability and provenance of each run (operational evidence, post-5.274) | When the analysis reads the git repository, the result records the analyzed commit, the branch, whether there were uncommitted changes, and a fingerprint of the effective configuration. The SARIF also records the run and its origin in version control. The rule catalog can be exported as JSON or CSV for audit | Proves which code (commit), which configuration and which rules produced each result: the auditor reconstructs the context without access to the machine. Does not record who saw or handled the finding; that trail belongs to the institution |
| Egress restriction and confidentiality (cybersecurity policy; LGPD by extension) | The analysis runs entirely on the institution's machine or pipeline and does not use the network: the code is not uploaded and the vulnerability database is a local copy. For isolated environments without network access, there is a version delivered on request under the Platform contract, with even the telemetry and network code removed | In the isolated-environment version, code and results do not leave the machine, because the binary has no way to send them. In the public version, the pseudonymous telemetry, which can be turned off with one line, and whatever the institution connects to the Platform do leave; the full list of what leaves is on Telemetry and Privacy |
| SBOM and supply chain (input to TPRM and inventory) | SBOM in CycloneDX 1.5 and SPDX 2.3, generated locally | Proves the dependency inventory at scan time. Documented caveat: the supplier and license fields of the NTIA minimum have known gaps, and complete relationships between dependencies are produced only for npm (lockfile v2 or v3) and Rust projects |
Recommended retention practice (Art. 23, 5 years)
Per release, or per regulatory window, archive these four files together. All of them are deterministic and can be verified later:
release-X.Y.Z/
├── report.sarif # full scan (Art. 8 §1 V)
├── gate.json # quality gate verdict (objective criterion)
├── attestation.txt # counter-signed declaration (signed integrity)
└── sbom.cdx.json # dependency inventory (CycloneDX)The counter-signed declaration can be verified offline on any future date. The public key is embedded in the binary, so verification does not depend on codafort being online on the day of the audit.
How to cite it in a questionnaire or onboarding
Suggested text:
"We run static (SAST) and composition (SCA) analysis with codafort in our CI pipeline, with a quality gate based on an objective criterion and evidence retained per release: SARIF, the gate verdict and a declaration cryptographically counter-signed by the tool vendor, verifiable offline. The declaration proves the integrity and authorship of each scan's declared result. Independent penetration testing (Art. 22-A) is conducted separately by [third party]."
Keep the last sentence. Without it, the text oversells: the declaration coexists with the pentest and does not replace it.