SCI Semiconductor logra 5 millones de libras para llevar sus chips con seguridad de memoria a mayor escala

SCI Semiconductor ha conseguido una ronda de crecimiento de 5 millones de libras esterlinas para acelerar la producción de sus chips ICENI y desarrollar una nueva generación de producto. La apuesta es relevante porque traslada parte de la protección frente a errores de memoria al propio hardware, en vez de depender exclusivamente de detectar y corregir fallos en el software una vez desplegado. 36

Quién invirtió y para qué servirá el dinero

La financiación, sobresuscrita, fue liderada por PXN Ventures y Mercia Ventures, gestoras de fondos vinculados al Northern Powerhouse Investment Fund II, un vehículo de inversión para impulsar empresas del norte de Inglaterra. También participaron Osney Capital, inversor especializado en ciberseguridad; Black Opal Ventures, con sede en Estados Unidos; e inversores privados. 36

La prioridad inmediata de SCI es aumentar la producción para atender la demanda de ICENI y continuar el desarrollo de chips. La compañía afirma que ya ha fabricado sus primeros dispositivos y que ha asegurado pedidos por más de 2 millones de libras. También comunica contratos públicos por 7,7 millones de libras y alianzas con Google Research y Microsoft. 612

Estas cifras apuntan a una primera tracción comercial, aunque el verdadero reto será convertirla en adopción sostenida. Para ello, el chip, las herramientas de desarrollo y el software de los clientes deben funcionar de forma integrada en productos reales.

Qué aporta CHERI a los chips ICENI

ICENI se basa en CHERI, una arquitectura informática basada en capacidades y desarrollada a partir de investigación respaldada en Reino Unido. CHERI emplea punteros con seguridad de memoria y compartimentación segura para controlar cómo el software accede a la memoria. El Gobierno británico la describe como un enfoque de seguridad desde el diseño que busca reforzar la protección de los sistemas y eliminar muchas vulnerabilidades habituales vinculadas a la memoria.

En la práctica, el objetivo es hacer mucho más difícil explotar clases de fallos como los accesos inválidos a memoria o los accesos fuera de los límites previstos. Es un planteamiento distinto al de aplicar únicamente comprobaciones de software después de escribir y desplegar el código.

La oportunidad es considerable: el material del Gobierno británico cita investigaciones de Google y Microsoft según las cuales los fallos de seguridad de memoria representan el 70 % de las vulnerabilidades cibernéticas persistentes.

Un problema de seguridad, pero también de continuidad operativa

Los errores de memoria no son una cuestión puramente teórica: también pueden provocar incidentes de disponibilidad. La interrupción global de CrowdStrike de julio de 2024 no fue un ciberataque, pero su análisis técnico de causa raíz identificó una lectura fuera de límites latente en su intérprete de contenido como uno de los elementos que contribuyeron a las caídas de sistemas tras una actualización defectuosa.

Eso no implica que un diseño basado en CHERI hubiera evitado todos los factores de aquel incidente. Sí ilustra por qué las organizaciones buscan reducir categorías enteras de errores, en lugar de confiar solo en detectarlos y remediarlos cuando el producto ya está en uso.

El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) sostiene una idea similar: las vulnerabilidades de seguridad de memoria son frecuentes y el desarrollo seguro desde el diseño podría reducir la carga constante de parches y respuesta a incidentes. Aun así, recalca que aplicar actualizaciones sigue siendo esencial, especialmente en sistemas expuestos o críticos.

Qué puede resolver —y qué no— la seguridad de memoria

Los límites de memoria aplicados por hardware pueden disminuir la probabilidad o el impacto de determinados fallos de corrupción de memoria. Esto puede ser especialmente valioso en productos con ciclos de soporte largos o en entornos donde una caída tiene consecuencias operativas graves.

Pero la seguridad de memoria es una capa, no una solución total. El hardware basado en CHERI no elimina fallos de identidad y control de acceso, procesos inseguros de actualización, configuraciones erróneas, ingeniería social, riesgos de cadena de suministro ni errores en la lógica de una aplicación. Siguen siendo necesarios el desarrollo seguro, las pruebas, la monitorización, la gestión de vulnerabilidades y las actualizaciones a tiempo.

Para SCI, por tanto, la cuestión comercial va más allá del rendimiento del chip: sus clientes necesitarán una vía creíble para integrar hardware y software compatibles con CHERI sin costes, problemas de compatibilidad o compromisos de desarrollo inasumibles.

La conexión con la Ley de Ciberresiliencia europea

Las obligaciones de notificación de la Ley de Ciberresiliencia de la Unión Europea (Cyber Resilience Act o CRA) se aplican a fabricantes de productos con elementos digitales. Desde el 11 de septiembre de 2026, deben comunicar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad de sus productos. La alerta inicial debe enviarse en un máximo de 24 horas desde que se tiene conocimiento y la notificación completa, en 72 horas. 1718

Una arquitectura con seguridad de memoria podría reducir la exposición a algunas vulnerabilidades reportables por corrupción de memoria y ayudar a acreditar una postura de seguridad desde el diseño. Sin embargo, no supone cumplimiento automático de la CRA: siguen siendo necesarios mecanismos de detección, gestión de vulnerabilidades, respuesta a incidentes, notificación y el resto de requisitos aplicables.

La próxima prueba: adopción a escala

SCI, fundada en 2022, figura como proveedor principal del programa británico Accelerated CHERI Adoption Programme y planea incorporar 15 puestos a su equipo de 35 personas repartido entre Sheffield y Cambridge. 1114

Los 5 millones de libras le dan margen para pasar del silicio inicial y los primeros pedidos a una producción de mayor escala. Su propuesta central es clara: si las reglas de acceso a memoria se aplican desde el hardware, algunos fallos pueden evitarse antes de convertirse en un parche urgente, una caída de servicio o una obligación de notificación. Que esa propuesta se consolide como una categoría de producto ampliamente utilizada dependerá de la integración de los clientes, la madurez de las herramientas para desarrolladores y el rendimiento demostrado en sistemas de producción.