Et skifte til en europæisk leverandør kan mindske risikoen for, at fremmed lovgivning rækker ind i jeres data. Det ændrer ikke på, at leverandøren skal vurderes på de samme sikkerhedskrav som den leverandør, I forlader.
Artiklen bruger to hændelser fra 2026 til at vise, hvorfor de to vurderinger skal holdes adskilt. Den slutter med de krav, der bør stilles til alle leverandører, uanset land. Oplysningerne er kontrolleret mod de berørte parters egne meddelelser 30. oktober 2026.
Hvorfor sikkerhed er et særskilt spørgsmål
Vurderingen af et alternativ handler ofte om ejerskab, hosting og jurisdiktion. De tre spørgsmål afgør, hvem der kan pålægges at udlevere data, og hvem der kan lukke en tjeneste. De siger ikke noget om, hvor godt leverandøren beskytter sine egne systemer.
En leverandør kan derfor score højt på suverænitet og lavt på sikkerhed, eller omvendt. Begge dele skal stå i vurderingen, hver for sig. Metoden for de fire krav til alternativer er beskrevet i → trin 7.
Hvad de tre lag dækker
Modellen i → De tre lag skelner mellem dataresidens, drift og jura. Driftslaget handler om, hvem der har den operationelle kontrol, og det er her, sikkerheden hører hjemme.
Et angreb på en leverandørs forsyningskæde rammer netop driftslaget. Det rammer de værktøjer, pakker og konti, som leverandøren bruger til at bygge og opdatere sine produkter. Hvor data ligger, og hvilket land leverandøren hører til, har ingen betydning for, om angrebet lykkes.
EU-Kommissionen: indgangen var et sikkerhedsværktøj
CERT-EU, EU-institutionernes cybersikkerhedstjeneste, beskrev hændelsen i et indlæg af 2. april 2026. Den 19. marts 2026 fik en angriber fat i en API-nøgle til en af Kommissionens AWS-konti, der er en del af platformen bag europa.eu.
Adgangen kom ifølge CERT-EU gennem en kompromitteret udgave af sikkerhedsværktøjet Trivy. Kommissionens overvågningscenter modtog alarmer 24. marts, og Kommissionen offentliggjorde hændelsen 27. marts. Dagen efter lagde afpresningsgruppen ShinyHunters de stjålne data ud.
Datasættet fylder ifølge CERT-EU omkring 340 GB ukomprimeret og omfatter blandt andet navne, brugernavne og mailadresser. Op til 71 kunder af Europa-webhostingtjenesten er berørt, heraf mindst 29 andre EU-organer. Ifølge Kommissionens pressemeddelelse, som CERT-EU henviser til, var de interne systemer ikke berørt.
CERT-EU beskriver én kompromitteret konto hos Kommissionen og ikke et brud på selve cloudplatformen. Nøglen gav ifølge indlægget rettigheder over andre af Kommissionens AWS-konti, men der var ikke fundet tegn på, at angriberen havde bevæget sig videre. Hændelsen viser derfor kundens del af ansvaret, nemlig de værktøjer og nøgler, kunden selv har i sine miljøer.
Trivy: en opdatering med en skjult funktion
Trivy er et open source-værktøj, der scanner software og cloudmiljøer for sårbarheder. Ifølge udviklerens sikkerhedsmeddelelse af 21. marts 2026 brugte en angriber 19. marts kompromitterede adgangsoplysninger til at udgive en ondsindet version 0.69.4.
Angriberen ændrede også 76 af 77 versionsmærker i værktøjets GitHub Action, så de pegede på ondsindet kode. Koden stjal hemmeligheder som SSH-nøgler, cloudnøgler og adgangstokens fra de miljøer, hvor værktøjet kørte.
Meddelelsen forklarer, at angrebet fortsatte et tidligere angreb fra februar 2026. Udskiftningen af adgangsoplysninger efter det første angreb skete ikke på én gang, og det kan have givet angriberen fortsat adgang. Meddelelsen anbefaler blandt andet, at GitHub Actions låses til en fast commit i stedet for et versionsmærke.
Mistral AI: pakker kompromitteret hos en europæisk leverandør
Mistral AI er et fransk selskab og nævnes ofte som et europæisk alternativ til amerikanske AI-modeller. I maj 2026 blev selskabets programbiblioteker til udviklere ramt af et angreb på forsyningskæden.
Ifølge Mistral AI’s sikkerhedsmeddelelse for Python-biblioteket, offentliggjort 12. maj 2026, indeholdt version 2.4.6 på PyPI kode, der hentede og kørte et ekstra program på Linux. Udgivelsen var ifølge meddelelsen sket uden om projektets normale udgivelsesproces.
Meddelelsen for JavaScript-bibliotekerne på npm oplyser, at de kompromitterede versioner var tilgængelige fra 11. maj kl. 22.45 til 12. maj kl. 01.53 UTC. Ifølge meddelelsen var en udviklers enhed involveret, og selskabet havde ingen indikationer af, at dets infrastruktur var kompromitteret.
Hvad leverandørens håndtering fortæller
De to hændelser viser to sider af samme sag. Kommissionens data lå hos en amerikansk cloududbyder, og indgangen var et open source-værktøj. Mistral AI er europæisk, og indgangen var et udviklermiljø. I ingen af tilfældene havde hosting eller jurisdiktion betydning for selve angrebet.
Begge udviklere offentliggjorde meddelelser med berørte versioner, tidsrum og anbefalede handlinger. Mistral AI’s meddelelser kom samme dag, som de kompromitterede versioner blev fjernet. Den slags åbenhed kan indgå i en vurdering. Den viser, at leverandøren har en praksis for at håndtere og oplyse om hændelser.
Det modsatte, en leverandør uden offentlig praksis for sikkerhedsmeddelelser, er sværere at vurdere. Spørg derfor, hvordan leverandøren oplyser kunderne om hændelser, og hvor hurtigt.
Samme krav uanset land
For virksomheder og myndigheder under NIS2 er kravene til leverandører de samme, uanset hvor leverandøren hører hjemme. NIS2-direktivets artikel 21, stk. 2, litra d, nævner forsyningskædesikkerhed, og litra e nævner sikkerhed ved erhvervelse, udvikling og vedligeholdelse af systemer.
Efter artikel 21, stk. 3, skal enhederne tage højde for sårbarheder hos hver direkte leverandør. De skal også vurdere kvaliteten af leverandørernes produkter og cybersikkerhedspraksis, herunder deres procedurer for sikker udvikling. Direktivet skelner ikke mellem europæiske og ikke-europæiske leverandører på det punkt.
Sammenhængen mellem NIS2 og jurisdiktion er beskrevet i → NIS2 og leverandørstyring.
Sikkerhedskrav, der gælder alle leverandører
- Udviklingsprocessen · Bed leverandøren beskrive, hvordan den sikrer sine byggemiljøer, udgivelser og de komponenter, den bygger på.
- Uafhængig gennemgang · Spørg, om sikkerheden er gennemgået af en uafhængig part, og hvad gennemgangen omfattede.
- Sikkerhedsmeddelelser · Find leverandørens offentlige praksis for at oplyse om sårbarheder og hændelser.
- Adgangsstyring · Spørg, hvordan adgangsoplysninger til udgivelser og cloudkonti beskyttes og udskiftes.
- Varsling af kunder · Afklar, hvordan og hvor hurtigt I får besked ved en hændelse, der berører jer.
- Jeres egen brug · Lås versioner af værktøjer og pakker i jeres egne miljøer, og begræns deres adgang til nøgler.
Kravene stilles på samme måde til den nuværende og den nye leverandør. Spørgsmål til leverandøren er også samlet i → seks spørgsmål, og dokumentationen, kunderne kan bede om, i → leverandørens dokumentation.
Typiske fejl
Den første fejl er at lade et skifte til en europæisk leverandør erstatte sikkerhedsvurderingen. Et land eller en hostingplacering er ikke et sikkerhedscertifikat.
Den anden fejl er at vurdere leverandøren og glemme de værktøjer, der indgår i jeres egen udvikling og drift. Kommissionens hændelse begyndte i et værktøj, der skulle finde sårbarheder. Mange af de samme værktøjer bruges også i danske organisationer, ofte uden at stå i nogen kortlægning.
Den tredje fejl er at tolke en offentlig sikkerhedsmeddelelse som et dårligt tegn. En meddelelse viser, at en hændelse er opdaget og håndteret. Fraværet af meddelelser viser ikke, at der ingen hændelser har været.
Hvad sagerne kan og ikke kan vise
Sagerne kan vise, at et forsyningskædeangreb kan ramme både en europæisk leverandør og en europæisk institution. De kan vise, at hosting og jurisdiktion ikke har betydning for selve angrebet. De kan vise, hvordan en leverandør kan oplyse om en hændelse.
De kan ikke vise, at europæiske leverandører generelt er mere eller mindre sikre end andre. To hændelser er ikke grundlag for en sammenligning. Sagerne ændrer heller ikke på den juridiske risiko, der er beskrevet i → Cloud Act.
Betydningen for exit-planen
Skriv sikkerhedskravene ind i vurderingen af hvert alternativ, på linje med ejerskab, hosting, aktualitet og prismodel. Stil de samme krav til den leverandør, I forlader, så sammenligningen er retfærdig.
Notér også de udviklings- og sikkerhedsværktøjer, der har adgang til jeres cloudkonti, i kortlægningen fra → trin 3. Når jurisdiktion og afhængighed skal vurderes uvildigt for hvert system, beskriver Nielco IT’s jurisdiktions- og afhængighedsvurdering fremgangsmåden.
Kilder
- CERT-EU: European Commission cloud breach: a supply-chain compromise, 2. april 2026. https://cert.europa.eu/blog/european-commission-cloud-breach-trivy-supply-chain
- Aqua Security (Trivy): Trivy ecosystem supply chain temporarily compromised, GHSA-69fq-xp46-6×23, 21. marts 2026. https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6×23
- Mistral AI: Malicious dropper in mistralai 2.4.6 PyPI package, GHSA-wx9m-wx4f-4cmg, 12. maj 2026. https://github.com/mistralai/client-python/security/advisories/GHSA-wx9m-wx4f-4cmg
- Mistral AI: Broken dropper in @mistralai/mistralai, @mistralai/mistralai-azure, @mistralai/mistralai-gcp, GHSA-jgg6-4rpr-wfh7, maj 2026. https://github.com/mistralai/client-ts/security/advisories/GHSA-jgg6-4rpr-wfh7
- Den Europæiske Unions Tidende (EUR-Lex): Direktiv (EU) 2022/2555 af 14. december 2022 (NIS2), artikel 21. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/dan
