SCI Semiconductor zdobywa 5 mln funtów na produkcję układów ICENI z ochroną pamięci

SCI Semiconductor pozyskała 5 mln funtów w rundzie wzrostowej, która była nadsubskrybowana. Dla spółki z Sheffield to przede wszystkim test biznesowy idei od dawna obecnej w cyberbezpieczeństwie: zamiast wykrywać i łatać każdy błąd w oprogramowaniu, ograniczać część z nich już w architekturze procesora. Kapitał ma sfinansować zwiększenie produkcji układów ICENI oraz prace nad ich następną generacją. 36

Kto zainwestował i na co pójdą środki

Rundę poprowadziły PXN Ventures i Mercia Ventures — zarządzający odpowiednimi funduszami udziałowymi Northern Powerhouse Investment Fund II (NPIF II), brytyjskiego programu wspierającego inwestycje w przedsiębiorstwa z północy Anglii. Udział wzięli również wyspecjalizowany inwestor cyberbezpieczeństwa Osney Capital, amerykański Black Opal Ventures oraz inwestorzy prywatni. 36

Bezpośrednim celem jest zwiększenie produkcji ICENI w odpowiedzi na popyt oraz dalszy rozwój chipów. SCI podaje, że wyprodukowała pierwsze urządzenia i pozyskała zamówienia o wartości przekraczającej 2 mln funtów. Spółka informuje też o kontraktach rządowych na 7,7 mln funtów oraz partnerstwach z Google Research i Microsoft. 612

Te liczby wskazują na wczesne zainteresowanie rynkowe, lecz kluczowym sprawdzianem będzie przejście do trwałego wdrożenia. Klienci potrzebują bowiem sprzętu, narzędzi programistycznych i aplikacji, które będą współpracowały w faktycznie używanych systemach.

Na czym polega różnica w ICENI

ICENI wykorzystuje CHERI — architekturę komputerową opartą na tzw. zdolnościach (capabilities), rozwijaną w ramach badań wspieranych w Wielkiej Brytanii. CHERI stosuje wskaźniki bezpieczne pamięciowo i bezpieczną segmentację pamięci, aby kontrolować sposób, w jaki program uzyskuje do niej dostęp. Brytyjski rząd opisuje tę technologię jako podejście „security by design”, mające wzmacniać bezpieczeństwo systemów i eliminować wiele typowych podatności związanych z pamięcią.

W praktyce chodzi o to, by błędy takie jak nieprawidłowy dostęp do pamięci lub odwołanie poza dozwolonym zakresem były trudniejsze do wykorzystania. To inne podejście niż poleganie wyłącznie na kontrolach programowych dodawanych po napisaniu i wdrożeniu kodu.

Stawka jest duża, ponieważ błędy bezpieczeństwa pamięci pozostają stałym źródłem podatności. Materiały brytyjskiego rządu, powołujące się na badania Google i Microsoft, wskazują, że błędy tego rodzaju odpowiadają za 70% utrzymujących się podatności cybernetycznych.

Dlaczego bezpieczeństwo pamięci stało się problemem biznesowym

Błędy pamięci to nie tylko teoretyczny problem bezpieczeństwa — mogą też prowadzić do awarii operacyjnych. Awaria CrowdStrike z lipca 2024 r. nie była cyberatakiem, ale analiza przyczyn technicznych opublikowana przez firmę wykazała, że do awarii systemów przyczynił się ukryty błąd odczytu poza zakresem w module Content Interpreter, ujawniony po problematycznej aktualizacji.

Nie oznacza to, że projekt oparty na CHERI zapobiegłby wszystkim elementom tego incydentu. Przykład pokazuje jednak, dlaczego organizacje chcą ograniczać całe kategorie błędów, zamiast polegać wyłącznie na ich wykrywaniu i naprawianiu po wydaniu produktu.

Podobny argument przedstawia brytyjskie National Cyber Security Centre (NCSC): podatności związane z bezpieczeństwem pamięci są powszechne, a rozwój zgodny z zasadą „secure by design” może zmniejszyć ciągłe obciążenie związane z zarządzaniem poprawkami i reagowaniem na incydenty. NCSC podkreśla zarazem, że aktualizacje pozostają konieczne, zwłaszcza w systemach wystawionych na internet i krytycznych.

Gdzie CHERI pomaga — i gdzie nie zastępuje innych zabezpieczeń

Granice dostępu do pamięci egzekwowane sprzętowo mogą ograniczać prawdopodobieństwo albo skutki części błędów uszkodzenia pamięci. Jest to szczególnie cenne w produktach z długim cyklem wsparcia oraz w środowiskach, w których awaria pociąga za sobą wysokie koszty operacyjne.

Bezpieczeństwo pamięci jest jednak tylko jedną z warstw ochrony. Sprzęt oparty na CHERI nie eliminuje problemów z tożsamością i kontrolą dostępu, niebezpiecznym procesem aktualizacji, błędną konfiguracją, socjotechniką, ryzykiem w łańcuchu dostaw ani błędami logiki aplikacji. Nadal potrzebne są bezpieczne praktyki tworzenia oprogramowania, testy, monitoring, zarządzanie podatnościami i szybkie aktualizacje.

Dla SCI pytanie handlowe wykracza więc poza wydajność układu. Klienci będą potrzebowali wiarygodnej drogi do integracji sprzętu i oprogramowania świadomego CHERI, bez nieakceptowalnych kosztów, problemów ze zgodnością lub utrudnień dla zespołów programistycznych.

Co zmienia unijny Cyber Resilience Act

Obowiązki raportowe wynikające z unijnego Cyber Resilience Act (CRA) dotyczą producentów produktów z elementami cyfrowymi. Od 11 września 2026 r. muszą oni zgłaszać aktywnie wykorzystywane podatności oraz poważne incydenty wpływające na bezpieczeństwo produktu. Wstępne ostrzeżenie należy przesłać w ciągu 24 godzin od uzyskania informacji, a pełniejsze zgłoszenie — w ciągu 72 godzin. 1718

Architektura bezpieczna pamięciowo może pomóc producentom zmniejszać ekspozycję na część podatności związanych z uszkodzeniem pamięci, które mogłyby podlegać raportowaniu, a także wzmacniać podejście „security by design”. Nie oznacza jednak automatycznej zgodności z CRA. Nadal konieczne są procesy zarządzania bezpieczeństwem produktu, wykrywania incydentów, obsługi podatności i raportowania, a także spełnienie pozostałych wymogów regulacji.

Następny sprawdzian: wdrożenie na większą skalę

SCI, założona w 2022 r., jest również wskazywana jako kluczowy dostawca w brytyjskim programie Accelerated CHERI Adoption Programme. Firma planuje zatrudnić 15 osób, zwiększając zespół liczący obecnie 35 pracowników w Sheffield i Cambridge. 1114

Runda o wartości 5 mln funtów daje spółce środki, by przejść od pierwszych wyprodukowanych układów i początkowych zamówień do produkcji na większą skalę. Jej podstawowa teza jest prosta: jeśli zasady dostępu do pamięci można egzekwować sprzętowo, część podatności da się zatrzymać, zanim staną się problemem wymagającym poprawki, wywołają awarię lub obowiązek zgłoszenia. O tym, czy rozwiązanie stanie się szeroko stosowaną kategorią produktów, zdecydują integracja po stronie klientów, narzędzia dla programistów i potwierdzona wydajność w systemach produkcyjnych.