Seguridad en C++, en contexto

Comité, proceso y características de seguridad

• Muchos comentaristas están frustrados porque existen buenas ideas de seguridad, pero la estandarización es lenta e inconsistente (p. ej., std::span se publicó sin .at() hasta C++26, y operator[] sigue sin comprobación).
• Aclaración de que el comité de C++ principalmente ratifica propuestas respaldadas por implementaciones en funcionamiento; no puede “imponer” unilateralmente un nuevo C++.
• La compatibilidad hacia atrás y la estabilidad del ABI se ven como restricciones dominantes que bloquean cambios más profundos de seguridad (p. ej., punteros gordos, sintaxis que rompe compatibilidad, épocas).

Cultura e inseguridad por defecto

• Varias historias de equipos desactivando sanitizers, ignorando informes de ASAN, rechazando depuradores y tratando el acceso fuera de límites como aceptable si “no se cuelga”.
• Algunos sostienen que esto es fundamentalmente un problema de actitud: las herramientas ya existen, pero muchos desarrolladores y organizaciones no las usarán a menos que haya fuertes incentivos o castigos.
• Otros contraargumentan que no todo el software necesita el mismo nivel de endurecimiento, pero los críticos responden que cualquier aplicación conectada a la red puede convertirse en parte de una cadena de explotación.

Comprobación de límites y trade-offs de rendimiento

• Hay un debate recurrente sobre las comprobaciones de límites por defecto: si operator[] debería abortar, lanzar una excepción o seguir sin comprobación; si la seguridad debería estar activada por defecto con una vía de escape explícita unsafe_*.
• Algunos argumentan que la sobrecarga es pequeña en la práctica (citando mediciones a nivel de sistema) y merece la pena; otros enfatizan cargas de trabajo HPC/embebidas donde incluso una regresión de unos pocos puntos porcentuales importa.
• Las excusas históricas (“demasiado lento en 1990”) se ven como menos válidas hoy, pero algunos siguen priorizando el rendimiento sobre la seguridad.

CVEs, métricas y ejemplo de carrera del sistema de archivos

• Fuerte desacuerdo sobre usar recuentos brutos de CVE para comparar C/C++ con Rust: la gravedad difiere, y las comunidades de lenguajes fijan umbrales distintos para que algo reciba un CVE.
• Ejemplo: un problema TOCTOU del sistema de archivos recibió un CVE en Rust y una corrección publicada en un blog; las bibliotecas estándar de C++ corrigieron en silencio errores similares pero no emitieron CVEs, mientras que la especificación de C++ etiqueta las carreras del sistema de archivos como comportamiento indefinido.
• Algunos temen que actores del ecosistema C++ puedan “gestionar” los recuentos de CVE en vez de arreglar las causas raíz; otros dicen que el problema se manejó con responsabilidad incluso sin un CVE.

Comparaciones con Rust y otros lenguajes

• Muchos ven Rust como un salto cualitativo: seguridad de memoria por defecto, unsafe encapsulado, mejores garantías de seguridad en hilos y una cultura que trata la seguridad como prioritaria.
• Contraargumentos: Rust todavía tiene CVEs; muchos crates de Rust usan unsafe (a menudo para FFI); el Rust seguro tiene dificultades con algunas estructuras de datos sin indireccionamiento (arenas, Rc/Arc, índices).
• Algunos subrayan que la seguridad de memoria es solo una clase de vulnerabilidad; los lenguajes seguros en memoria siguen sufriendo errores lógicos, inyección, manejo de secretos, etc., pero otros sostienen que eliminar una gran clase de fallos sigue siendo un “buen problema para tener”.

Gobierno, presión industrial y futuro de C++

• Los informes recientes de gobiernos y grandes proveedores que instan a alejarse de lenguajes inseguros en memoria se ven como un telón de fondo clave; algunos leen el artículo como una respuesta defensiva.
• Debate sobre si C++ puede alcanzar de forma realista una “paridad” con los lenguajes seguros en memoria mediante cambios no rompientes y herramientas, o si requiere cambios radicales y rompientes (épocas, subconjuntos seguros o enfoques tipo “Typescript-for-C++”).
• Muchos creen que el C++ heredado persistirá durante décadas, así que mejores herramientas y modos más seguros siguen importando aunque los proyectos nuevos migren a Rust, Go, etc.

Carga cognitiva y elecciones de proyecto

• Varios mensajes describen el C++ moderno como cognitivamente agotador: sintaxis compleja, errores de templates pesados, muchas características superpuestas y UB sutil.
• Algunos dicen que todavía usan C++ solo por código heredado, ecosistema o normas del dominio (HPC, motores de juegos), y que de otro modo preferirían Rust u otros lenguajes.
• Estado de ánimo general: C++ puede hacerse más seguro en los márgenes, pero para trabajo nuevo desde cero, muchos comentaristas lo evitarían si pueden.