Shai-Hulud visar varför processcertifiering inte räcker
Supply chain-attacken Shai-Hulud, upptäckt 11 maj 2026, har drabbat över 170 mjukvarupaket inklusive komponenter i UiPath automation-plattformen, AI-tjänster och flygrelaterade system. Det är första gången skadlig kod publicerats med giltiga SLSA Build Level 3-attesteringar — den högsta nivån av processcertifiering för säkra mjukvarubyggen. Händelsen demonstrerar varför civil motståndskraft måste mätas på utfall, inte enbart på processer.
Vad som hänt
Attacken utnyttjar sårbarheter i mjukvaruleveranskedjor för att förgifta legitima releaser av kritiska komponenter. Bland de drabbade paketen finns @tanstack/react-router (cirka 12 miljoner nedladdningar per vecka), hela UiPath automation-plattformen, OpenSearchs JavaScript-klient, och flera paket i Mistral AI:s och Guardrails AI:s ekosystem.
Skadeprogrammet exfiltrerar inloggningstoken, moln-nycklar, SSH-nycklar, lösenordshanterare och kryptoplånböcker från system som installerat de förgiftade paketen. Det etablerar persistens via flera kanaler och innehåller en mekanism som triggar radering av användarens hemkatalog om någon stulen nyckel återkallas innan skadeprogrammet är helt borttaget.
Vilka som är exponerade i Sverige
Drabbade paket används brett i svensk näringslivs- och offentlig IT-infrastruktur. Direkt eller indirekt exponering finns hos kommuner som använder UiPath för automatiserade processer, näringslivsaktörer som bygger på @tanstack-ramverket, organisationer som använder OpenSearch för logghantering och säkerhetsövervakning, samt myndigheter och företag som integrerat AI-tjänster i sin verksamhet.
Eftersom attacken sker djupt i mjukvaruleveranskedjan kan en organisation vara exponerad utan att direkt ha installerat något av de namngivna paketen. Beroenden i flera led innebär att kartläggning av exponering kräver systematisk genomgång av lock-filer och bygghistorik.
Varför ISO-certifiering inte räcker
Det centrala är att SLSA Build Level 3 är den högsta erkända nivån inom processcertifiering för säkra mjukvarubyggen. En organisation som följt SLSA-processen vid installation av de förgiftade paketen hade ändå exponerats. Processen var korrekt utförd. Resultatet blev katastrofalt.
Detta är fenomen som återkommer regelbundet inom cybersäkerhet och som blir alltmer akut: en organisation kan vara fullt certifierad enligt ISO 27001, ISO 22301 eller SLSA, och samtidigt sakna faktisk förmåga att upptäcka, hindra eller hantera attacker av denna komplexitet.
Skillnaden mellan processkrav och utfallskrav är inte teoretisk. Den blir avgörande i en attack som Shai-Hulud.
Vad SIBAC tillför
SIBAC-standarden mäter utfall. I cybersäkerhetsvertikalen mäts inte om en organisation har en informationssäkerhetspolicy på plats, utan om organisationen kan upptäcka avvikelser i sin mjukvaruleveranskedja, hur snabbt en kompromisserad komponent identifieras, och hur effektivt incidentresponsen begränsar skadan. Detta är operativa kapaciteter som inte fångas av processcertifiering.
SIBAC är konstruerad som en levande standard. Hotbilden mot svensk civil infrastruktur utvecklas kontinuerligt, vilket innebär att standardens mätpunkter måste utvecklas i takt. Detta sker genom strukturerad metodutveckling i SIBAC:s metodikråd, baserad på vetenskaplig analys och fältförankrade observationer från certifierade konsulter inom respektive vertikal.
En supply chain-attack av Shai-Huluds typ ger direkt input till mätpunkterna i cybersäkerhetsvertikalen. Vilka kontroller hade fångat attacken? Vilka kompenserande mekanismer hade begränsat skadan? Hur snabbt upptäcker en mogen organisation att en build-pipeline är förgiftad? Dessa frågor blir konkreta mätpunkter som certifierade konsulter använder i analyser hos kommuner och företag.
Iterativ metodutveckling är central för att SIBAC ska vara relevant över tid. Det är en av de centrala skillnaderna mellan SIBAC och statiska processramverk. Standarden ska reflektera dagens hot, inte gårdagens.
Vad organisationer bör göra nu
För omedelbara åtgärder kring Shai-Hulud hänvisas till CERT-SE och respektive leverantörs säkerhetsadvisories. Centrala åtgärder inkluderar inaktivering av eventuella persistensmekanismer innan tokenrotation, blockering av kända exfiltreringsdomäner, samt systematisk genomgång av lock-filer i pågående projekt.
För strukturell beredskap är frågan vidare: kan organisationen demonstrera mätbar förmåga att hantera supply chain-incidenter, inte enbart att processer finns på plats?
Kontakt: Anders Hansson, kontaktperson under uppbyggnadsfasen. Permanent kontaktadress (info@sibac.se) etableras under hösten 2026.