Colin Percival, el experto que destapó un fallo de Intel

El fallo que Colin Percival encontró en los chips de Intel

El 16 de noviembre de 2004, el mismo día en que entregaba su tesis doctoral en Oxford, Colin Percival tenía la cabeza en otro sitio: había detectado que la función Hyper-Threading que Intel introdujo en 2002 podía filtrar información entre hilos de ejecución a través del estado de la caché.

A mediados de diciembre ya tenía una prueba de concepto capaz de robar suficientes bits de una clave privada RSA como para reconstruirla por completo. Y ahí empezó la parte difícil, la que casi nadie ve: avisar en silencio a los equipos de seguridad y coordinar el arreglo antes de contarlo en público.

Eso le ocupó los seis meses siguientes. Mientras sus contemporáneos corregían tesis y buscaban trabajo, Percival dejó ambas cosas de lado —para irritación de sus supervisores— porque, en sus palabras, tenía una responsabilidad que pesaba más que una consideración de carrera. El 13 de mayo de 2005 presentó el paper en BSDCan y publicó el aviso; ese mismo día o poco después lo hicieron FreeBSD, NetBSD, Red Hat, SCO y Ubuntu.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El detalle que más dice de la cultura de la época: cuando Intel, molesta por la publicación inminente, pidió a Yahoo que le ordenara retirar el paper, la respuesta fue que Percival no trabajaba para Yahoo —a diferencia de muchos desarrolladores de FreeBSD— y que por tanto no había empleo que amenazar. Estar desempleado, ironías aparte, fue lo que le permitió sostener la posición.

¿Qué es la divulgación coordinada y por qué importa tanto?

Cualquiera que trabaje en seguridad de software abierto reconoce el proceso: si encuentras una vulnerabilidad, no la ignoras ni —mucho menos— la vendes a actores maliciosos. Tampoco la publicas y esperas que los buenos parchen antes que los malos exploten. La obligación es identificar quién necesita saberlo y contactarlo en privado, para que los parches estén listos en el momento en que el problema se haga público.

El sector aprendió a llamarlo divulgación coordinada, después de que algunos tuvieran problemas con la palabra "responsable". El caso de Percival es un ejemplo extremo por su duración, pero el principio es el mismo que hoy sostienen los equipos de seguridad de cualquier empresa que venda software.

Y el contexto regulatorio cambió el cálculo. Según Help Net Security, la agencia europea ENISA encendió el 11 de septiembre de 2026 la Single Reporting Platform de la Cyber Resilience Act, el mismo día en que las obligaciones de reporte empezaron a ser vinculantes para los fabricantes. El reloj arranca cuando el fabricante se entera del evento: aviso temprano en 24 horas, notificación con evaluación inicial en 72 horas y reporte final en 14 días desde que hay una medida correctiva disponible.

Tech Times detalla que las multas por incumplir el artículo 14 llegan hasta 15 millones de euros o el 2,5% de la facturación mundial anual, lo que sea mayor, y que la obligación alcanza también a productos ya en el mercado europeo, no solo a los lanzamientos nuevos. El mismo medio cita el caso del botnet Aisuru, que hacia 2025 lanzaba ataques de denegación de servicio superiores a 29,7 terabits por segundo desde entre 300.000 y 700.000 dispositivos comprometidos. Ese es el costo real de que un fallo se quede sin reportar.

La tesis de Fichte: el conocimiento no se acumula, se transmite

El ensayo toma su título de las conferencias de 1794 de Johann Gottlieb Fichte, Über die Bestimmung des Gelehrten. Fichte sostiene que el scholar "posee su conocimiento no para sí mismo, sino para la sociedad", y que no le corresponde acumularlo sino transmitirlo.

Percival no compra el paquete completo. Rechaza la idea de Fichte de que los scholars sean la clase más elevada y que se vean a sí mismos como "sacerdotes de la verdad", y también rechaza que el deber nazca de una deuda con la sociedad. Para él, el deber no viene de lo que la sociedad te dio: viene del conocimiento mismo, sin importar quién lo tenga.

De ahí sale una distinción operativa que vale para cualquier equipo técnico. Para Percival, un investigador crea conocimiento nuevo; un scholar lo lleva a las personas que lo necesitan. Muchos son ambas cosas, pero hay mucha investigación publicada en una revista que nadie lee, o que solo leen académicos y no quien podría actuar sobre los hallazgos. Su alma mater, Simon Fraser University, se describe como "la universidad comprometida de Canadá" y valora explícitamente conectar el aprendizaje académico con el mundo real. Percival es senador de esa universidad desde hace más de dos décadas.

El caso de Amazon EC2 y el límite del deber

El deber, dice el ensayo, no es ilimitado. Fichte ya lo marcaba: no hay obligación de forzar a nadie a actuar sobre lo que sabe, y hay una obligación moral de aceptar la libertad ajena. Tampoco hay deber de convertirse en Casandra: si todos los que podrían actuar ya fueron informados, el deber quedó agotado.

Percival aplica su propia escalera. En 2009 descubrió que el firewall de Amazon EC2 rompía por defecto el Path MTU Discovery y lo reportó a Amazon. En noviembre de 2012, al concluir que la empresa no lo iba a arreglar, publicó en su blog cómo los clientes podían resolverlo por su cuenta. Amazon corrigió el bug poco después. No era un problema de seguridad, pero él sentía que, sabiendo lo que sabía, tenía el deber ético de compartirlo.

La lógica de escalada es la misma que recomiendan los códigos de ética de ingeniería: primero reportar al empleador o al responsable, y solo si eso no da resultados, dar pasos más directos. Reportar a alguien que no actúa no descarga el deber; reportar todo a todo el mundo ahoga lo que de verdad necesita atención amplia.

¿Qué significa esto para tu startup?

La lección no es filosófica, es operativa. Cualquier equipo que construya software va a encontrarse del lado del que descubre o del que recibe un aviso, y la diferencia entre manejarlo bien o mal se mide en horas.

Define un canal interno y un plazo. Si vendes en la Unión Europea, la CRA ya te obliga a reportar vulnerabilidades explotadas activamente en 24 horas. Designa a una persona con credenciales, define quién la reemplaza si no está disponible y practica el flujo antes de que ocurra un incidente real.
Mapea tus componentes antes de necesitarlo. La correlación entre un inventario de componentes (SBOM) y las bases de vulnerabilidades es lo que hace posible saber en horas qué producto tuyo está afectado. Sin eso, el equipo revisa CVE a mano y no llega.
Cuando encuentres un fallo ajeno, escala en orden. Reporta primero al proveedor por un canal privado y guarda registro de la fecha. Si no hay respuesta en un plazo razonable, publica lo necesario para que los afectados puedan protegerse. Ese fue exactamente el camino de Percival con Amazon.
No confundas publicar con comunicar. Un paper, un informe o un post interno que nadie lee no cumple la función. Pregúntate quién puede actuar sobre lo que sabes y asegúrate de que esa persona se enteró.

Conclusión

Percival cierra su ensayo con una elección personal: él elige la vida y el deber de un scholar. No todos sienten los deberes igual, y no todos pueden actuar sobre ellos —él mismo reconoce que, viviendo en Estados Unidos en lugar de Canadá, habría tenido que priorizar un empleo con seguro médico y probablemente no habría podido sostener esos seis meses de trabajo silencioso.

Para un founder, la parte incómoda es esta: el conocimiento que tu equipo genera tiene valor solo cuando llega a quien puede usarlo. Y con la CRA ya vigente en Europa, esa idea dejó de ser una postura ética para convertirse, además, en una obligación legal con multas concretas.