Seguridad de software y regulación en Latinoamérica: qué exigen de verdad

Las regulaciones de ciberseguridad están llegando al código. Ya no alcanza con un firewall y una política en PDF: cada vez más, una auditoría pregunta cómo desarrollas, cómo pruebas y cómo tratas tus vulnerabilidades.

Esta nota resume qué piden algunas normas relevantes para la región. Es una guía de ingeniería, no asesoría legal: cada norma tiene alcance, plazos y excepciones que debes validar con tus especialistas.

Primero, lo que no dicen

Ninguna de estas normas obliga a usar Rust ni un lenguaje seguro en memoria. Quien diga lo contrario te está vendiendo algo.

En Estados Unidos, la guía de NSA y CISA de 2025 sí recomienda estos lenguajes como la mitigación más completa contra esa clase de fallos, pero es una recomendación, no una obligación.

Lo que sí hacen las normas es exigir controles, pruebas y evidencia. Y ahí es donde tus decisiones técnicas pesan.

Comparación rápida

Perú: la SBS y el desarrollo seguro

El Reglamento SBS 504-2021 es, para el sector financiero, el documento clave. Su artículo 12 pide incluir prácticas de seguridad en la planificación, el desarrollo y la operación, e implementar procedimientos con prácticas de desarrollo seguro. Estos son los puntos más útiles para un equipo técnico:

• Control de cambios: limitar quién modifica el código fuente, con un estricto control (art. 12, num. 5, lit. c).
• Pruebas antes de producción: técnicas, funcionales y de seguridad de la información (lit. e).
• Ambientes separados: desarrollo, pruebas y producción (num. 3, lit. c).
• API: prácticas de desarrollo seguro, revisión de codificación segura, análisis de vulnerabilidades y pruebas de penetración (art. 21).
• Terceros: evaluar amenazas en lo que proveen, definir responsabilidades y, en la nube, verificar certificaciones (art. 22 a 24).

El reglamento no fija un estándar de código ni una herramienta específica. Te deja elegir, pero debes poder demostrar que lo haces. Además, tiene regímenes distintos según la entidad, y fue modificado por la Resolución 01515-2021, de modo que conviene revisar la versión vigente.

Fuera del sistema financiero, el nuevo reglamento de la Ley 29733, en vigor desde 2025, refuerza las obligaciones sobre datos personales.

Chile: la Ley Marco de Ciberseguridad

La Ley 21.663 creó la Agencia Nacional de Ciberseguridad. Distingue deberes generales, como reportar incidentes, de deberes específicos para los Operadores de Importancia Vital, como implementar un sistema de gestión de seguridad de la información.

La agencia ha publicado nóminas de esos operadores, y las multas pueden llegar a 20 000 UTM, con hasta el doble para esos operadores. Si das servicios a uno de ellos, es probable que sus exigencias te lleguen por contrato.

Brasil: el Banco Central tras el caso C&M

En 2025, un ataque a C&M Software, proveedora conectada al sistema financiero, desvió al menos R$ 800 millones, según reportes de prensa. La lección fue incómoda: el eslabón débil era un tercero. En diciembre de ese año, el Banco Central publicó la Resolución BCB 538, que endurece los requisitos para las entidades reguladas. Según resúmenes jurídicos, incluye grupos de controles mínimos, pruebas de intrusión anuales y el aislamiento de los ambientes de Pix.

Si desarrollas para banca o pagos, esto te incumbe aunque no estés en Brasil: es probable que marque tendencia en la región.

Europa: una razón para exportadores

Si vendes software a Europa, presta atención a la Ley de Ciberresiliencia. Según Jones Day, desde el 11 de septiembre de 2026 los fabricantes deben reportar vulnerabilidades explotadas e incidentes graves, con una alerta en 24 horas. La mayoría de las demás obligaciones aplican desde el 11 de diciembre de 2027.

Para una empresa latinoamericana que exporta software, esto dejó de ser un tema lejano.

La evidencia que sí puedes preparar

Todas estas normas convergen en lo mismo. Aquí tienes una lista práctica, útil en cualquier jurisdicción:

Cómo ayuda Rust

Rust no te da cumplimiento, pero reduce trabajo y riesgo en varios puntos:

• Elimina una clase de vulnerabilidades en el código seguro, antes de llegar a las pruebas. Vimos cuáles.
• Hace visible el riesgo: el código unsafe queda marcado y se puede auditar.
• Facilita el control de dependencias: con Cargo.lock, cargo audit y cargo deny puedes bloquear versiones y documentar lo que usas.

Sigue siendo necesario todo lo demás: autorización, cifrado, gestión de secretos, registro, respuesta a incidentes. Y como vimos en Evidencia, cambiar de lenguaje no siempre es lo más urgente.

Por dónde empezar

No empieces por reescribir nada. Empieza por saber dónde estás: qué sistemas son críticos, qué depende de terceros y qué evidencia te falta. Ese inventario suele ser más valioso que cualquier herramienta.