El mundo de antivirus

viernes, 29 de mayo de 2026

Si le interesan las tecnologías de la información y, en particular, la seguridad informática, seguro que ha oído hablar de conceptos como «código abierto», «Open Source» y «software abierto». Mucha gente percibe los programas de código abierto como un referente en materia de seguridad y, en entornos expertos de especialistas en TI, su promoción y uso se consideran poco menos que una norma no escrita. Y no se debe solo a que sean gratuitos y de libre distribución, porque no siempre es así. A menudo se da por hecho que el código abierto y la seguridad del sistema son una misma cosa. Sin embargo, detrás de los grandes eslóganes sobre el «software libre» se desdibuja el fondo técnico de la cuestión. ¿Por qué se considera tan importante el acceso abierto al código fuente para proteger los sistemas? ¿Es el «código abierto» una garantía automática de seguridad o no deja de ser una herramienta más en manos del desarrollador? En la edición de hoy de «El Mundo de Antivirus» vamos a ir al fondo del funcionamiento del software para entender qué ocurre a nivel de instrucciones de máquina y dónde nace realmente la seguridad.

¿Qué es el código abierto y el código cerrado?

Para profundizar en esta cuestión y entender cómo influye en última instancia el código abierto en nuestra seguridad, conviene empezar por ver en qué forma existe el software en nuestros dispositivos. Y es que ningún procesador es capaz de «leer» el texto de un programa como lo hace una persona. Para un chip de silicio no existen conceptos como «algoritmo», «lógica», «interfaz gráfica» o incluso «lenguaje de programación». Todos los programas de su dispositivo, así como los archivos que esos programas utilizan, no son en realidad más que secuencias de bits, es decir, ceros y unos. Esto puede comprobarse fácilmente al abrir cualquier archivo en un editor de código binario. Toda esa sintaxis compleja con la que trabajan los desarrolladores desaparece durante el proceso de compilación y se convierte en un simple conjunto de instrucciones elementales en el caso de los archivos ejecutables, o en matrices estructuradas de datos en el caso de los archivos auxiliares. Así pues, un programa compilado es una «caja negra»: vemos lo que hace por fuera, pero sin el código fuente no podemos saber con certeza cómo lo hace exactamente a nivel de instrucciones de máquina.

Por ejemplo, los archivos ejecutables EXE y las bibliotecas DLL son formatos binarios que empaquetan el código máquina compilado de forma que el sistema operativo sepa cómo cargarlo en memoria y entregárselo al procesador para su ejecución. Ahora bien, reconstruir la lógica original del funcionamiento del programa y las verdaderas intenciones de su desarrollador a partir de un archivo EXE ya terminado es una tarea muy complicada. Precisamente en esa «caja negra» es donde se ven obligados a mirar los analistas de virus en su trabajo diario. Al no disponer del código fuente, recurren a métodos de ingeniería inversa, tratando de reconstruir el algoritmo del programa a partir de indicios indirectos y fragmentos de instrucciones máquina. Es un proceso minucioso y costoso en recursos: donde el autor del código tarda unos segundos en leer una línea clara y comprensible, el analista puede pasarse horas descifrando la lógica de una sola acción sospechosa.

Para entenderlo mejor, podemos recurrir a una analogía muy conocida: si un programa compilado o un archivo binario es un plato ya preparado, el código fuente es su receta detallada. Se trata, en realidad, del texto del programa escrito en uno de los lenguajes de programación, y tiene una característica fundamental: es comprensible para una persona. A diferencia de los impersonales ceros y unos, el código fuente contiene —o puede contener— una estructura lógica, nombres de variables con sentido y, algo muy importante, comentarios del autor. Al estudiar ese texto, a un experto en seguridad le resulta mucho más fácil entender por qué un programa accede al registro del sistema o a una pasarela de red: todas las decisiones del autor quedan reflejadas en el algoritmo. No obstante, aquí conviene hacer una precisión: el código fuente no siempre es cristalino. Existe un concepto llamado ofuscación, que consiste en enredar el código de forma deliberada. Entre las técnicas habituales de ofuscación están sustituir los nombres de las variables por combinaciones de símbolos sin sentido y complicar artificialmente la lógica del programa. Todo ello dificulta el análisis del funcionamiento del programa, incluso cuando se dispone del código fuente. Además, también existe, sencillamente, un mal estilo de programación, en el que un algoritmo útil puede quedar sepultado bajo una acumulación de funciones caóticas y «parches» poco transparentes.

Hemos llegado al punto clave: la diferencia entre el código abierto y el código cerrado. Siguiendo con nuestra analogía, el código abierto es una receta publicada y al alcance de cualquiera. En teoría, cualquier persona puede examinar sus ingredientes y comprobar que al plato no se le ha añadido nada de más. Este principio es la base del atractivo del software abierto en materia de seguridad: permite una auditoría abierta y la revisión del código por parte de todo el que quiera hacerlo.

El código cerrado es esa misma receta, pero guardada bajo llave en la caja fuerte de la empresa desarrolladora. Al usuario solo le llega el producto terminado, y sobre lo que ocurre en la cocina interna solo puede hacer conjeturas. El llamado software propietario tiene precisamente código cerrado, entre otras cosas como medida de protección frente a modificaciones y usos al margen de los acuerdos de licencia. El código cerrado garantiza que los usuarios no puedan ver, modificar ni estudiar los algoritmos del programa sin recurrir a la ingeniería inversa, que por lo general también está prohibida legalmente. Ese secretismo sienta las bases del modelo comercial: la empresa no vende solo un conjunto de instrucciones, sino un resultado garantizado del que responde con su nombre y su reputación. Las prohibiciones legales sobre la descompilación y el código cerrado son medidas del beneficiario para mantener el control sobre el producto y rentabilizar su actividad. Conviene señalar que precisamente por eso los ataques de los hackers contra las empresas desarrolladoras suelen tener como objetivo el robo del código fuente. Y, si lo consiguen, las consecuencias pueden ser incluso más graves que el robo de bases de datos o una parada técnica de la infraestructura.

Sin embargo, para los defensores del Open Source, esas mismas puertas cerradas son la principal fuente de desconfianza. De ahí nace el eterno debate: ¿qué resulta más fiable, los enfoques de una empresa comercial o las paredes de cristal de la comunidad?

Sobre la seguridad del software abierto

Como ya se ha dicho, el atractivo del software abierto en el contexto de la seguridad se basa en el principio de transparencia. Uno de los pilares de la fe en la seguridad del Open Source es la llamada «ley de Linus», formulada por Linus Torvalds, creador del núcleo abierto de Linux. Esta ley también se conoce como la «teoría de los mil ojos». Su planteamiento es sencillo: cuantas más personas tengan acceso al código fuente, más probabilidades hay de que cualquier error o puerta trasera introducida intencionadamente sea detectada y eliminada con rapidez. Según esta lógica, la comunidad de voluntarios que mantiene el código actúa como una especie de inmunidad colectiva que filtra de forma continua las posibles amenazas.

A primera vista, la elección parece evidente: el código abierto puede revisarse, mientras que con el código cerrado solo queda confiar en el desarrollador. Pero en la práctica esta lógica choca de frente con la realidad técnica del desarrollo de software. La principal trampa del software abierto está en la palabra «puede». Que el código pueda ser revisado por cualquiera no significa en absoluto que alguien lo haya revisado de verdad. En la práctica, miles de bibliotecas de las que dependen sistemas críticos pueden arrastrar vulnerabilidades durante años simplemente porque su código fuente resulta demasiado aburrido o demasiado complejo para una auditoría voluntaria. Al final se crea una situación en la que cada participante da por hecho que ese código ya lo ha revisado otra persona, seguramente más cualificada. Así pues, la teoría de los mil ojos solo funciona allí donde realmente existen esos ojos, por ejemplo, al desarrollar una nueva función de un navegador popular o durante la preparación de una nueva actualización del núcleo Linux. Al mismo tiempo, el software complejo actual se parece a un iceberg: el usuario ve la punta, pero bajo el agua se esconden cientos de bibliotecas muy especializadas, encargadas del cifrado, del procesamiento de fuentes tipográficas o de cálculos matemáticos. Esos componentes pueden permanecer durante años en repositorios abiertos sin pasar ninguna auditoría. Como resultado, un código de importancia crítica, del que depende la seguridad de millones de personas, no lo revisan durante años «mil ojos» voluntarios, sino apenas un par de desarrolladores en plantilla. La historia ofrece no pocos ejemplos de vulnerabilidades fundamentales en bibliotecas de este tipo, como OpenSSL o Log4j, que pasaron desapercibidas durante décadas pese a ser completamente abiertas.

El segundo aspecto crítico es el vacío jurídico. En el mundo del Open Source, a menudo nadie responde por un error concreto más allá de la «comunidad» en su conjunto. Si en una biblioteca abierta se descubre una brecha por la que se filtran los datos de millones de usuarios, los afectados no podrán reclamar judicialmente a un grupo de voluntarios. En el sector del software propietario, la situación es distinta: la empresa comercial asume una responsabilidad reputacional y jurídica directa frente a sus clientes, lo que la obliga a establecer sistemas de control de calidad y de soporte técnico. La eficacia de las auditorías internas suele superar con creces la «inmunidad colectiva» del software abierto, ya que las empresas destinan cantidades muy importantes a expertos en plantilla y a auditorías externas. No lo hacen por altruismo, sino como parte de un enfoque pragmático en un contexto de competencia de mercado: la seguridad del código cerrado está respaldada por contratos jurídicos (SLA) y por seguros.

Hay otro factor técnico importante que conviene tener en cuenta al hablar de la seguridad del software abierto. Aunque supongamos que el código fuente es impecable y ha sido revisado por miles de expertos, el usuario corriente nunca ejecuta ese código directamente. Lo que descarga de internet y utiliza es un programa ya terminado: precisamente esa instrucción compilada para el procesador central. Nada garantiza que el archivo final se haya generado exactamente a partir de ese código fuente transparente. Durante el proceso de compilación pueden introducirse en el programa funciones maliciosas o simplemente no declaradas mediante un compilador «envenenado» o una infraestructura del desarrollador comprometida. Este problema es tan serio que en el mundo del software abierto existe incluso un movimiento específico en favor de las «compilaciones reproducibles» (Reproducible Builds). Su objetivo es permitir que cualquiera pueda comprobar la correspondencia entre el archivo binario y el código fuente. Sin embargo, para la mayoría de los proyectos esa comprobación sigue siendo un lujo inalcanzable, lo que convierte la apertura del código fuente en una protección solo parcial.

Por último, todos los argumentos anteriores sobre la auditoría y la transparencia, igual que los riesgos señalados, chocan con una realidad muy simple: la inmensa mayoría de los usuarios no tiene los conocimientos de un programador de sistemas o de un analista de virus. Para el usuario común, el debate sobre la apertura del código tiene un carácter puramente teórico. Al final, la «apertura» no es un hecho técnico comprobado personalmente, sino una forma más de confiar en la honestidad de la comunidad, del mismo modo que en el caso del software cerrado se confía en la reputación de la empresa. Así pues, para el usuario corriente la diferencia entre un código transparente y una «caja negra» prácticamente se difumina: tanto en un caso como en el otro, se ve obligado a delegar por completo la cuestión de su seguridad en terceros, sin posibilidad material de verificar por sí mismo su trabajo.

Seguridad por oscuridad

No conviene olvidar que la apertura del código tiene dos caras. Que la «receta» esté disponible para la comunidad significa también que lo está por completo para los atacantes. Los creadores de malware no necesitan dedicar meses a la ingeniería inversa, a comparar instrucciones en ensamblador ni a interpretar bytes a ciegas: el algoritmo, las particularidades de la arquitectura y los fallos lógicos que pueden convertirse en vulnerabilidades están ante ellos a la vista. En el caso del software cerrado, el hacker primero tiene que «abrir la caja fuerte» para entender simplemente cómo está organizada la protección, mientras que en el software abierto puede pasarse años estudiando el código fuente en busca de una sola grieta.

De hecho, precisamente por eso la inmensa mayoría de los programas antivirus tiene el código fuente cerrado. Un antivirus moderno y completo es un producto multimódulo, con una funcionalidad amplísima, que opera en el sistema con privilegios elevados. Y eso marca también el precio del error. Si imaginamos que el código fuente de todos los módulos de un programa así fuera abierto, a los creadores de malware les resultaría mucho más fácil adaptar sus desarrollos para esquivar los mecanismos de protección o incluso aprovechar el trabajo del fabricante para crear nuevas variantes de malware. En este contexto, el carácter cerrado del código no solo protege la propiedad intelectual, sino que constituye también una necesidad estratégica en la lucha constante entre el escudo y la espada.

Eso sí, hay que señalar que realmente existen soluciones antivirus abiertas, como el conocido ClamAV. Sin embargo, su popularidad y su carácter abierto no contradicen las ideas expuestas, sino que más bien las confirman. ClamAV no es un escudo absoluto, sino más bien un filtro eficaz de primera criba. No está pensado para combatir métodos sofisticados de evasión de la protección en el sistema operativo de un usuario corriente. Su función principal es comparar rápidamente archivos con una base de firmas conocidas en servidores y pasarelas de correo. Y, aun siendo eficaz dentro de su ámbito, con frecuencia se convierte también en un campo de pruebas para los creadores de malware.

Conclusión

En resumen, puede decirse que el debate entre la «apertura» y el «cierre» del código en materia de seguridad es, en el fondo, una elección entre dos modelos distintos de confianza.

El código abierto es una poderosa herramienta de transparencia para quienes están dispuestos a invertir tiempo en la auditoría o confían en la competencia de la comunidad. Al fin y al cabo, la ideología Open Source es uno de los pilares de toda la industria IT y uno de los motores del desarrollo digital. Pero conviene recordar que no se trata de un amuleto mágico que convierta automáticamente un programa en algo seguro.

El código cerrado, por su parte, supone apostar por las garantías comerciales, la reputación de la marca y la reserva estratégica de los algoritmos, algo crítico para muchos productos del mercado, entre ellos los antivirus.

La seguridad, en términos generales, no es una propiedad estática del código ni del archivo compilado. Es un proceso continuo, sostenido tanto por el entusiasmo de la comunidad y la transparencia como por la responsabilidad comercial y los enfoques rigurosos de desarrollo dentro de las empresas privadas. Para el usuario final, la elección entre uno y otro seguirá siendo siempre una cuestión de confianza: o bien en la «inteligencia colectiva» de los mantenedores, o bien en la reputación profesional y el capital de un desarrollador concreto.