{"id":2097,"date":"2026-07-22T12:55:03","date_gmt":"2026-07-22T18:55:03","guid":{"rendered":"https:\/\/hacking.onesec.mx\/?p=2097"},"modified":"2026-07-24T12:45:23","modified_gmt":"2026-07-24T18:45:23","slug":"rust-vs-c-como-eliminar-el-70-de-las-vulnerabilidades-antes-de-compilar","status":"publish","type":"post","link":"https:\/\/hacking.onesec.mx\/index.php\/2026\/07\/rust-vs-c-como-eliminar-el-70-de-las-vulnerabilidades-antes-de-compilar\/","title":{"rendered":"Rust vs. C: c\u00f3mo eliminar el 70% de las vulnerabilidades antes de compilar"},"content":{"rendered":"\n

Cerca del 70% de las vulnerabilidades de seguridad documentadas en software de sistemas durante la \u00faltima d\u00e9cada corresponden a errores de seguridad de memoria<\/strong>. Este art\u00edculo examina por qu\u00e9 el lenguaje C facilita la aparici\u00f3n de esa categor\u00eda de fallos y de qu\u00e9 manera Rust los previene mediante garant\u00edas que el compilador verifica antes de producir el binario. Se revisan las cifras publicadas por Microsoft y Google, el caso de adopci\u00f3n de Rust en el sistema operativo Android y las limitaciones que conviene reconocer para sostener una valoraci\u00f3n rigurosa.<\/p>\n\n\n\n

Una categor\u00eda de error que no cede<\/h3>\n\n\n\n

Conviene precisar desde el inicio el alcance de la cifra que da t\u00edtulo a este texto. Cuando se afirma que se puede eliminar el 70% de las vulnerabilidades, la referencia no abarca la totalidad de las brechas de seguridad que existen en el mundo. La cifra describe una proporci\u00f3n concreta, la fracci\u00f3n de vulnerabilidades a las que se asigna un identificador CVE (Common Vulnerabilities and Exposures)<\/strong> cuyo origen est\u00e1 en errores de seguridad de memoria.<\/p>\n\n\n\n

El Microsoft Security Response Center report\u00f3 en 2019, a partir de la revisi\u00f3n hist\u00f3rica de cada vulnerabilidad reportada en sus productos desde 2004, que alrededor del 70% de los CVE que la empresa asigna cada a\u00f1o corresponden a problemas de seguridad de memoria<\/strong>. La proporci\u00f3n se ha mantenido pr\u00e1cticamente constante, y Microsoft la reiter\u00f3 en su informe de seguridad de noviembre de 2025. El proyecto Chromium de Google reporta una cifra equivalente para sus errores de seguridad graves, y el equipo Project Zero, al analizar vulnerabilidades de d\u00eda cero explotadas activamente, encontr\u00f3 que el 67% correspond\u00eda a corrupci\u00f3n de memoria. La Agencia de Seguridad Nacional de Estados Unidos y la agencia CISA (Cybersecurity and Infrastructure Security Agency) <\/strong>retoman esta estad\u00edstica en sus recomendaciones oficiales sobre lenguajes de memoria segura, lo que le da respaldo institucional adem\u00e1s del sector corporativo.<\/p>\n\n\n\n

La convergencia de fuentes independientes alrededor del mismo orden de magnitud es lo que sostiene el peso del argumento. Distintos actores, con metodolog\u00edas propias y sin coordinarse entre s\u00ed, llegaron por separado a un n\u00famero muy similar.<\/p>\n\n\n\n

\"Proporci\u00f3n<\/figure>\n\n\n\n

\u00bfQu\u00e9 errores comprende la seguridad de memoria?<\/h3>\n\n\n\n

La seguridad de memoria designa la propiedad de un programa seg\u00fan la cual todo acceso a memoria est\u00e1 bien definido. Su ausencia produce una familia de fallos conocida y bien estudiada, entre ellos el desbordamiento de b\u00fafer o buffer overflow<\/strong> (escritura m\u00e1s all\u00e1 de los l\u00edmites reservados para una estructura), el uso despu\u00e9s de liberaci\u00f3n o use after free<\/strong> (acceso a memoria que ya fue devuelta al sistema), el puntero colgante o dangling pointer<\/strong>, la doble liberaci\u00f3n o double free<\/strong> y la condici\u00f3n de carrera o race condition<\/strong> sobre datos compartidos entre hilos. Todos comparten una consecuencia com\u00fan, ya que derivan en comportamiento indefinido, un estado en el que el programa puede hacer cualquier cosa, desde fallar sin darnos un aviso hasta ejecutar c\u00f3digo bajo control de un atacante<\/strong>.<\/p>\n\n\n\n

La gravedad de estos errores est\u00e1 en que suelen ser la puerta de entrada para ataques m\u00e1s complejos. Un desbordamiento de b\u00fafer puede convertirse en ejecuci\u00f3n remota de c\u00f3digo, y t\u00e9cnicas como la programaci\u00f3n orientada a retorno (es una t\u00e9cnica de hackeo que reutiliza pedacitos de c\u00f3digo que ya est\u00e1n en el programa, uni\u00e9ndolos como un rompecabezas para hacer que haga algo malicioso, sin tener que meter c\u00f3digo nuevo) permiten eludir buena parte de las defensas que los sistemas operativos modernos incorporan para contenerlos.<\/p>\n\n\n\n

\u00bfPor qu\u00e9 el lenguaje C facilita estos fallos?<\/h3>\n\n\n\n

El lenguaje C le da al programador control directo sobre la memoria.<\/strong> Esa caracter\u00edstica explica su permanencia durante medio siglo en sistemas operativos, controladores de dispositivos y software embebido, donde la ausencia de un recolector de basura o garbage collector y el acceso cercano al hardware resultan deseables. La contrapartida es que C deja en manos del programador la tarea de gestionar correctamente cada reserva y liberaci\u00f3n, sin verificar durante la compilaci\u00f3n que los accesos respeten los l\u00edmites de las estructuras ni que los punteros sigan apuntando a memoria v\u00e1lida.<\/p>\n\n\n\n

En consecuencia, un programa en C puede tener un uso despu\u00e9s de liberaci\u00f3n o un desbordamiento de b\u00fafer y compilar sin ninguna advertencia. El error aparece en tiempo de ejecuci\u00f3n, muchas veces bastante despu\u00e9s de que el c\u00f3digo se escribi\u00f3, y en los casos que importan para la seguridad, cuando un atacante lo provoca de manera deliberada. La experiencia acumulada durante d\u00e9cadas muestra que ning\u00fan volumen de herramientas de an\u00e1lisis est\u00e1tico o static analysis, pruebas de fuzzing, revisiones de c\u00f3digo o capacitaci\u00f3n ha logrado bajar de forma sustancial la proporci\u00f3n de estos fallos. La cifra estable del 70% refleja esa limitaci\u00f3n.<\/p>\n\n\n\n

El modelo de Rust y la verificaci\u00f3n durante la compilaci\u00f3n<\/h3>\n\n\n\n

Rust, cuyo desarrollo comenz\u00f3 en 2006 en Mozilla y cuya versi\u00f3n 1.0 se public\u00f3 en 2015, fue pensado para ofrecer un rendimiento comparable al de C y C++ junto con garant\u00edas de seguridad de memoria que se comprueban antes de que el programa exista como tal. La idea de fondo es sencilla aunque su implementaci\u00f3n no lo sea. Cada dato en memoria tiene un \u00fanico due\u00f1o en el c\u00f3digo, y el compilador lleva la cuenta de qui\u00e9n puede leerlo, qui\u00e9n puede modificarlo y hasta cu\u00e1ndo sigue siendo v\u00e1lido. Ese seguimiento lo hace un componente del propio compilador llamado verificador de pr\u00e9stamos, conocido en ingl\u00e9s como borrow checker<\/strong>, y lo hace durante la compilaci\u00f3n, no cuando el programa ya est\u00e1 corriendo.<\/p>\n\n\n\n

En la pr\u00e1ctica, Rust revisa el uso de la memoria antes de generar el programa<\/strong>. Si el c\u00f3digo intenta acceder a un dato que ya no es v\u00e1lido o realizar operaciones que podr\u00edan provocar conflictos de memoria, el compilador detiene la compilaci\u00f3n hasta que el problema se corrija. A diferencia de C o C++, donde estos errores pueden llegar a producci\u00f3n, Rust bloquea durante la compilaci\u00f3n categor\u00edas enteras de fallos como use-after-free<\/em>, referencias colgantes y data races<\/em>. La prevenci\u00f3n ocurre antes de la ejecuci\u00f3n, no despu\u00e9s.<\/p>\n\n\n\n

\"Diagrama<\/figure>\n\n\n\n

La evidencia emp\u00edrica<\/h3>\n\n\n\n

El caso mejor documentado es el de Android. Google empez\u00f3 a priorizar el desarrollo de c\u00f3digo nuevo en lenguajes de memoria segura alrededor de 2019 y anunci\u00f3 formalmente el soporte de Rust en 2021. En septiembre de 2024 report\u00f3 que la proporci\u00f3n de vulnerabilidades de Android atribuibles a errores de memoria baj\u00f3 del 76% en 2019 a un 24% estimado para finales de 2024<\/strong>, una cifra muy por debajo del promedio del 70% que se observa en la industria. En n\u00fameros absolutos, las vulnerabilidades de seguridad de memoria pasaron de 223 en 2019 a menos de 50 en 2024.<\/p>\n\n\n\n

Un dato adicional refuerza el argumento desde la perspectiva de la ingenier\u00eda. Seg\u00fan Jeff Vander Stoep, del equipo de seguridad de Android, el c\u00f3digo nuevo escrito en Rust tiene una densidad de vulnerabilidades de memoria menor que el c\u00f3digo heredado en C y C++. Google report\u00f3 adem\u00e1s que los cambios en Rust tienen una tasa de reversi\u00f3n cuatro veces menor y requieren cerca de 25% menos tiempo de revisi\u00f3n de c\u00f3digo, lo que sugiere que la adopci\u00f3n del lenguaje mejor\u00f3 la velocidad de entrega y la calidad del software adem\u00e1s de su seguridad. Vale la pena notar que esta reducci\u00f3n ocurri\u00f3 aun cuando el c\u00f3digo en C y C++ sigue presente en la base de Android, lo que apunta a que el efecto viene de c\u00f3mo se escribe el c\u00f3digo nuevo y no de una reescritura masiva del c\u00f3digo existente.<\/p>\n\n\n\n

Los l\u00edmites del argumento<\/h3>\n\n\n\n

Rust ofrece una v\u00eda de escape deliberada mediante el bloque unsafe<\/strong><\/code>, que habilita operaciones de bajo nivel comparables a las de C y suspende algunas de las verificaciones del compilador en la regi\u00f3n marcada. Dentro de esos bloques, los errores de seguridad de memoria pueden volver a aparecer. Un caso concreto lo ilustra bien, ya que en 2025 se document\u00f3 la vulnerabilidad CVE-2025-48530, de severidad alta, originada en un bloque unsafe<\/code> dentro de un analizador de im\u00e1genes AVIF en Android, que en combinaci\u00f3n con otra condici\u00f3n pod\u00eda habilitar la ejecuci\u00f3n remota de c\u00f3digo. El fallo se identific\u00f3 y corrigi\u00f3 antes de su publicaci\u00f3n, y mecanismos de protecci\u00f3n en tiempo de ejecuci\u00f3n limitaron su explotabilidad.<\/p>\n\n\n\n

El episodio confirma que unsafe<\/code> no desactiva por completo las garant\u00edas del lenguaje y que las defensas en capas siguen siendo necesarias. La lecci\u00f3n pr\u00e1ctica para quien adopte Rust es que el c\u00f3digo marcado como unsafe<\/code> debe mantenerse reducido, aislado y sujeto a una revisi\u00f3n especialmente cuidadosa, precisamente porque ah\u00ed se concentra el riesgo que el resto del lenguaje elimina.<\/p>\n\n\n\n

Vale la pena se\u00f1alar tambi\u00e9n que adoptar Rust implica una curva de aprendizaje real<\/strong>. El verificador de pr\u00e9stamos rechaza construcciones que un programador de C escribir\u00eda sin dificultad, y aprender bien el modelo de propiedad toma tiempo. C y C++, por su parte, conservan una base instalada enorme y un ecosistema maduro que no va a desaparecer en el corto plazo. En la pr\u00e1ctica, pocas organizaciones est\u00e1n reescribiendo su c\u00f3digo existente. Lo com\u00fan es mantener ese c\u00f3digo como est\u00e1, buscar que Rust conviva bien con \u00e9l, y empezar a escribir en Rust lo que se construye de aqu\u00ed en adelante.<\/p>\n\n\n\n

Conclusi\u00f3n<\/h3>\n\n\n\n

Los errores de seguridad de memoria representan cerca del 70% de las vulnerabilidades con CVE asignado en software de sistemas. Esa cifra viene de fuentes independientes que coinciden entre s\u00ed, no de una sola organizaci\u00f3n. Rust elimina esa categor\u00eda completa de errores en el c\u00f3digo que respeta su modelo de propiedad, porque las verificaciones ocurren durante la compilaci\u00f3n y no despu\u00e9s. El caso de Android muestra que ese efecto es real y medible, no solo te\u00f3rico, en un entorno de producci\u00f3n de gran escala.<\/p>\n\n\n\n

Nada de esto significa que Rust resuelva todos los problemas de seguridad. Los bloques unsafe<\/code> pueden reintroducir los mismos errores que el lenguaje previene en el resto del c\u00f3digo, y C seguir\u00e1 presente en la infraestructura existente durante mucho tiempo. Adem\u00e1s, el 70% deja un 30% de vulnerabilidades (inyecci\u00f3n SQL, XSS, fallas de configuraci\u00f3n, errores de l\u00f3gica de negocio, ingenier\u00eda social) que Rust no toca en absoluto, ya que esas no son problemas de memoria. Rust ataca una categor\u00eda espec\u00edfica y bien delimitada del problema, no la seguridad inform\u00e1tica en general. Dentro de esa categor\u00eda, sin embargo, la evidencia es clara. La seguridad de memoria ya no depende solo de qu\u00e9 tan disciplinado sea cada programador, porque el lenguaje mismo puede garantizarla desde antes de que el c\u00f3digo corra.<\/p>\n\n\n\n

Referencias<\/h3>\n\n\n\n

Microsoft Security Response Center \u2013 A proactive approach to more secure code<\/a>. Recuperado el 16 de julio de 2026.<\/p>\n\n\n\n

Microsoft Security Response Center \u2013 We need a safer systems programming language<\/a>. Recuperado el 16 de julio de 2026.<\/p>\n\n\n\n

Windows Experience Blog (Microsoft) \u2013 Advancing security with Windows and Surface: Microsoft SFI Report Nov 2025<\/a>. Recuperado el 16 de julio de 2026.<\/p>\n\n\n\n

CISA \u2013 The Urgent Need for Memory Safety in Software Products<\/a>. Recuperado el 15 de julio de 2026.<\/p>\n\n\n\n

Google Online Security Blog \u2013 Eliminating Memory Safety Vulnerabilities at the Source<\/a>. Recuperado el 15 de julio de 2026.<\/p>\n\n\n\n

Google Security Blog \u2013 Rust in Android: move fast and fix things<\/a>. Recuperado el 15 de julio de 2026.<\/p>\n\n\n\n

The Hacker News \u2013 Rust Adoption Drives Android Memory Safety Bugs Below 20% for First Time<\/a>. Recuperado el 15 de julio de 2026.<\/p>\n\n\n\n

NVD (NIST) \u2013 CVE-2025-48530 Detail<\/a>. Recuperado el 15 de julio de 2026.<\/p>\n\n\n\n

Android Open Source Project \u2013 Android Security Bulletin, agosto de 2025<\/a>. Recuperado el 8 de julio de 2026.
<\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

Cerca del 70% de las vulnerabilidades de seguridad documentadas en software de sistemas durante la \u00faltima d\u00e9cada corresponden a errores de seguridad de memoria. Este art\u00edculo examina por qu\u00e9 el lenguaje C facilita la aparici\u00f3n de esa categor\u00eda de fallos y de qu\u00e9 manera Rust los previene mediante garant\u00edas que el compilador verifica antes de […]<\/p>\n","protected":false},"author":2,"featured_media":2125,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-2097","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-seguridad-de-la-informacion"],"_links":{"self":[{"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/posts\/2097","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/comments?post=2097"}],"version-history":[{"count":6,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/posts\/2097\/revisions"}],"predecessor-version":[{"id":2128,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/posts\/2097\/revisions\/2128"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/media\/2125"}],"wp:attachment":[{"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/media?parent=2097"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/categories?post=2097"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/tags?post=2097"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}