JetBrains, firmaet bag IntelliJ IDEA, PyCharm, GoLand og byggeserveren TeamCity, har haft en broget sommer. Den 27. juli 2026 dukkede en kritisk sårbarhed op i TeamCity On-Premises med det maksimale alvorsniveau, CVSS 9,8. Mindre end en måned senere opdagede JetBrains selv, at nogen havde brugt netop den fejl til at bryde ind i firmaets egen cloud-tjeneste Cadence. Og som om det ikke var nok, offentliggjorde JetBrains den 7. september fem nye CVE’er på én dag i IntelliJ IDEA og GoLand. Det er sjældent, at en enkelt udviklervirksomhed rammes af så tæt en række af sikkerhedshændelser inden for få uger, og sagen rejser et ubehageligt spørgsmål for softwarehuse i Danmark og resten af Norden: Hvor sikker er den kæde af værktøjer, som koden faktisk bliver bygget og distribueret igennem?

Denne artikel gennemgår, hvad der konkret gik galt, hvordan angrebet mod JetBrains’ egen infrastruktur forløb, og hvad de nye CVE’er fra september betyder for udviklere, der arbejder i IntelliJ IDEA eller GoLand hver dag. Vi ser også på den historiske kontekst, sammenligner JetBrains med andre store udviklerværktøjer, og runder af med, hvad hændelserne sandsynligvis betyder for resten af 2026.

Hvad er CVE-2026-63077, og hvorfor er den kritisk

CVE-2026-63077 rammer TeamCity On-Premises, JetBrains’ selvhostede byggeserver til continuous integration og continuous delivery (CI/CD). Fejlen er klassificeret som CWE-502, altså deserialisering af data, som serveren ikke burde stole på, og den ligger specifikt i den protokol, som TeamCity-agenter bruger til at melde sig hos serveren (agent polling-protokollen). En uautentificeret angriber med almindelig netværksadgang til en sårbar TeamCity-server kan udnytte fejlen til at omgå loginkontroller og køre vilkårlige kommandoer på serveren, med de samme rettigheder som selve TeamCity-processen har.

Det lyder teknisk, men konsekvensen er ligetil: den, der styrer byggeserveren, styrer i praksis hele udviklingspipelinen. Ifølge JetBrains egen rådgivning kan et vellykket angreb “expose TeamCity data, configurations, and stored credentials, modify server state, and potentially compromise the integrity of build artifacts and downstream CI/CD pipelines”, som firmaet skrev i sin opdaterede sikkerhedsvejledning fra august 2026. Med andre ord: adgangskoder, byggehemmeligheder og selve den software, der ender hos slutbrugere, kan alle blive kompromitteret via en enkelt ubeskyttet server.

Sårbarheden rammer TeamCity On-Premises-versioner før 2026.1.3 samt den langtidsunderstøttede gren før 2025.11.7. JetBrains understreger samtidig, at TeamCity Cloud ikke er berørt, fordi cloud-versionen kører i en anden arkitektur uden den sårbare agent-protokol eksponeret direkte mod internettet. Det er en vigtig skelnen for danske virksomheder, der overvejer, om de skal flytte fra selvhostet til cloud-baseret CI/CD, netop for at reducere den slags eksponering.

Sådan blev JetBrains selv hacket via egen server

Den mest opsigtsvækkende del af historien er ikke selve sårbarheden, men at JetBrains blev offer for sin egen fejl. Ifølge en rapport fra The Hacker News opdagede JetBrains den 23. august 2026, at ukendte angribere havde udnyttet CVE-2026-63077 til at bryde ind i firmaets Cadence-miljø via en TeamCity-server, der stod eksponeret på api.cadence.jetbrains.com uden den patch, JetBrains selv havde udsendt knap en måned tidligere.

Bruddet gav angriberne adgang til dele af Cadence-infrastrukturen, herunder AWS IAM-nøgler, S3-buckets og potentielt kildekode, repository-tokens, adgangsnøgler til pakkeregistre samt SSH- og signeringsnøgler. Det er præcis den type hemmeligheder, som en angriber kan bruge til at plante ondsindet kode længere nede i en forsyningskæde, hvis de ikke bliver opdaget og skiftet ud i tide. JetBrains reagerede med det samme og bad alle Cadence-brugere om øjeblikkeligt at tilbagekalde og rotere samtlige adgangsnøgler og hemmeligheder brugt i deres Cadence-kørsler, og firmaet anbefalede desuden, at kunder fremover behandler alle input og output fra Cadence-kørsler som potentielt kompromitteret.

Det ironiske twist er, at CVE-2026-63077 allerede var blevet tilføjet til den amerikanske CISA’s katalog over aktivt udnyttede sårbarheder (Known Exploited Vulnerabilities) den 5. august 2026, altså næsten tre uger før JetBrains selv opdagede angrebet mod sin egen infrastruktur. Med andre ord var det offentligt kendt, at fejlen blev misbrugt i den virkelige verden, mens en af firmaets egne servere stadig stod åben. Hele forløbet er beskrevet i The Hacker News’ dækning af Cadence-bruddet, og sagen er også optaget i Tenables løbende oversigt over opdaterede CVE’er.

Tidslinje: Fra sårbarhed til brud på seks uger

Forløbet strækker sig over godt seks uger og illustrerer, hvor hurtigt en enkelt upatchet server kan gå fra teoretisk risiko til reelt databrud. Nedenfor er de vigtigste datoer samlet.

DatoBegivenhed
27. juli 2026CVE-2026-63077 offentliggøres og registreres i NVD, CVSS 9,8
Ultimo juli 2026JetBrains udsender patch til TeamCity 2025.11.7 og 2026.1.3
5. august 2026CISA tilføjer CVE-2026-63077 til KEV-kataloget over aktivt udnyttede sårbarheder
23. august 2026JetBrains opdager udnyttelse mod egen Cadence-tjeneste via upatchet TeamCity-server
Ultimo august 2026JetBrains beder Cadence-brugere om at rotere alle adgangsnøgler og hemmeligheder
5. september 2026The Hacker News og andre medier omtaler Cadence-bruddet offentligt
7. september 2026Fem nye CVE’er offentliggøres i IntelliJ IDEA og GoLand

Fem nye CVE’er rammer IntelliJ IDEA og GoLand på én dag

Bare to uger efter Cadence-bruddet blev offentligt kendt, offentliggjorde JetBrains endnu en runde sårbarheder, denne gang i selve IDE’en. Den 7. september 2026 dukkede fire nye CVE’er op i IntelliJ IDEA, samt en enkelt i GoLand, JetBrains’ IDE til Go-udvikling. Til forskel fra TeamCity-fejlen kræver flere af disse, at offeret selv åbner et ondsindet projekt eller opretter forbindelse til en kompromitteret remote-server, men konsekvenserne kan stadig være alvorlige.

Den mest alvorlige af de fire, CVE-2026-86502, har en CVSS-score på 8,4 og skyldes, at IJent gRPC-serveren, som bruges i IntelliJ IDEA’s Remote Development-funktion, manglede både TLS-kryptering og autentificering. Det gjorde det muligt at køre kode lokalt på de servere, udviklere bruger til fjernudvikling, uden at logge ind først. CVE-2026-86504, med en score på 7,8, opstod fordi IDE’en ikke krævede bekræftelse af projekt-tillid, før den byggede en Dev Container, hvilket kunne føre til kodeudførelse direkte på værtsmaskinen. De to sidste, CVE-2026-86501 (score 2,8) og CVE-2026-86505 (score 3,3), er mindre alvorlige, men stadig relevante: den ene skrev terminalkommandoer i klartekst til loggen idea.log, hvilket kan lække adgangskoder, hvis loggen bliver eksponeret, mens den anden lækkede projektmetadata til JetBrains Marketplace på grund af manglende tillidstjek.

I GoLand blev CVE-2026-86506 registreret med middel alvorsgrad. Fejlen skyldtes, at GoLand-profilerens indbyggede pprof-server manglede autentificering, så profileringsdata om den kørende applikation kunne blive eksponeret for uvedkommende. Samtlige fem fejl er rettet i IntelliJ IDEA 2026.2.2 og GoLand 2026.2.2.1, og JetBrains anbefaler kraftigt, at alle brugere opdaterer med det samme. Den fulde tekniske beskrivelse af Dev Container-fejlen kan læses i NVD’s officielle registrering af CVE-2026-86504.

Overblik: Alle JetBrains-sårbarheder fra 2026 samlet

For at give et samlet billede har vi listet årets vigtigste JetBrains-CVE’er i én tabel. Læg mærke til, hvor forskellige alvorsgraderne er, fra kritiske fjernudførelsesfejl til mindre informationslæk.

CVEProduktAlvorsgradCVSSKort beskrivelse
CVE-2026-63077TeamCity On-PremisesKritisk9,8Uautentificeret fjernkodeudførelse via agent polling-protokol
CVE-2026-44413TeamCity On-PremisesHøjIkke oplystSårbarhed efter login, der muliggør uautoriseret adgang
CVE-2026-86502IntelliJ IDEAHøj8,4Manglende TLS/autentificering i IJent gRPC-server ved Remote Development
CVE-2026-86504IntelliJ IDEAHøj7,8Manglende projekt-tillidstjek før opbygning af Dev Container
CVE-2026-86506GoLandMiddelIkke oplystManglende autentificering på profilerens pprof-server
CVE-2026-86505IntelliJ IDEALav3,3Projektmetadata lækket til JetBrains Marketplace
CVE-2026-86501IntelliJ IDEALav2,8Terminalkommandoer skrevet i klartekst til idea.log

Ifølge en gennemgang fra Cybersecurity News har JetBrains i løbet af 2026 løbende rettet flere alvorlige fejl på tværs af sit produktkatalog. Mediet skrev direkte, at “JetBrains has addressed six security vulnerabilities in its software development and project management products” i én af de tidligere patch-runder, som ramte både IntelliJ IDEA, TeamCity og YouTrack. Den mest alvorlige af de tidligere fejl, CVE-2026-59792, blev beskrevet som en kritisk sårbarhed med en score på 9,6, hvor “the most serious is CVE-2026-59792, a critical 9.6-severity flaw in IntelliJ IDEA versions before 2026.1.4 and 2026.2, which enables code execution through path traversal in how the IDE handles project workspace IDs”. Det tegner et billede af et 2026, hvor JetBrains har måttet lukke huller i næsten hvert eneste kvartal.

Historisk kontekst: TeamCity har været mål før

Det er ikke første gang, TeamCity har været i søgelyset. I 2023 blev en anden kritisk sårbarhed, CVE-2023-42793, i TeamCity-versioner før 2023.05.4 udnyttet af en gruppe, som vestlige efterretningstjenester og sikkerhedsforskere kædede sammen med den russiske udenrigsefterretningstjeneste, ofte omtalt under dæknavnet APT29 eller Cozy Bear. Den sag blev et lærestykke i, hvorfor byggeservere er så attraktive mål: de sidder centralt i softwareforsyningskæden og har typisk adgang til kildekode, hemmeligheder og udgivelsesprocesser for mange forskellige projekter på samme tid. Flere sikkerhedsrådgivninger fra vestlige regeringer beskrev dengang, at et betydeligt antal sårbare TeamCity-servere globalt blev kompromitteret, før patchen nåede ud til alle.

Det gør 2026-sagen ekstra påfaldende. Tre år efter en statssponsoreret aktør udnyttede en kritisk TeamCity-fejl til at ramme kunder over hele verden, blev JetBrains’ egen infrastruktur ramt af den samme grundtype af fejl, en uautentificeret fjernkodeudførelse i den samme byggeserverplatform. Mønsteret peger på, at CI/CD-værktøjer generelt, og TeamCity i særdeleshed, forbliver et attraktivt mål for både kriminelle og statslige aktører, netop fordi de er den fælles flaskehals, al kode passerer igennem.

Markedsindflydelse: Hvad betyder det for CI/CD-branchen

JetBrains-produkter er dybt indlejret i mange virksomheders udviklingsproces, fra Java- og Kotlin-shoppen til teams, der bruger PyCharm, WebStorm eller GoLand som daglig IDE. Firmaet markedsfører selv sit produktkatalog som brugt af millioner af udviklere globalt, og TeamCity er en af de mest udbredte selvhostede CI/CD-platforme ved siden af Jenkins og GitLab CI. Når en så central del af værktøjskæden bliver ramt af en kritisk sårbarhed, og efterfølgende bruges til at bryde ind hos leverandøren selv, rejser det spørgsmål, som rækker langt ud over JetBrains’ egne kunder.

For det første bliver sagen endnu et argument i debatten om, hvorvidt selvhostede CI/CD-løsninger reelt er sikrere end cloud-varianter. JetBrains understreger selv, at TeamCity Cloud ikke var berørt af CVE-2026-63077, mens det netop var en selvhostet server, der endte med at blive misbrugt til at ramme Cadence. For det andet lægger sagen pres på virksomheder, der er omfattet af EU’s NIS2-direktiv, hvor kravene til hurtig patching og hændelsesrapportering er skærpet markant siden 2024. Softwarehuse i Danmark, der er omfattet af NIS2, kan ikke længere nøjes med at opdatere “når der er tid til det”, når leverandøren selv demonstrerer, hvor hurtigt en kendt sårbarhed kan blive udnyttet mod produktionsmiljøer.

For det tredje ser vi en bredere tendens i branchen: udviklerværktøjer er blevet et lige så attraktivt angrebsmål som selve de applikationer, de er med til at bygge. Det gælder ikke kun JetBrains. GitLab måtte i 2026 rette en sårbarhed i sin AI-assistent Duo med en CVSS-score på 8,7, der truede CI/CD-pipelines på lignende vis, og flere AI-kodeassistenter har fået kritik for at introducere ny, usikker kode i stor skala. Fælles for hændelserne er, at de rammer selve fundamentet for softwareudvikling, ikke kun slutprodukterne.

Konkurrencesammenligning: JetBrains mod andre udviklerværktøjer

JetBrains er langt fra det eneste udviklerværktøj, der har haft en hård sikkerhedssæson i 2026. Nedenfor sammenligner vi de seneste større sikkerhedshændelser hos fire centrale aktører i udviklerværktøjs-økosystemet.

VærktøjSeneste større hændelse i 2026AlvorsgradBerørt komponent
JetBrains TeamCity / IntelliJ IDEACVE-2026-63077 udnyttet mod egen Cadence-tjeneste, plus 5 nye CVE’er i IDE’enKritisk (9,8)Byggeserver og IDE
GitLab DuoSårbarhed i AI-assistenten, der kunne true CI/CD-pipelinesHøj (8,7)AI-kodeassistent i CI/CD-flow
GitHub Copilot / Claude CodeFlere nye CVE’er, samtidig med rapporter om øget andel usikker AI-genereret kodeVarierendeAI-kodegenerering
MCP-baserede AI-assistenter (GhostSplice-angreb)Angrebsteknik, der lækkede nøgler i store dele af testede opsætningerHøjModel Context Protocol-integrationer

Billedet, der tegner sig, er ikke, at JetBrains er værre stillet end konkurrenterne. Det er snarere, at hele kategorien af udviklerværktøjer, fra traditionelle IDE’er og byggeservere til nye AI-assistenter, er blevet et modent mål for angribere i 2026. Forskellen ligger i, hvor tæt værktøjet sidder på selve byggeprocessen: jo tættere på CI/CD-pipelinen, desto større er den potentielle skade, hvis noget går galt, hvilket forklarer, hvorfor netop TeamCity-sagen vejer så tungt. Se også vores gennemgang af GhostSplice-angrebet mod MCP-baserede AI-kodeassistenter for et beslægtet eksempel på, hvordan integrationslag omkring udviklerværktøjer bliver et selvstændigt angrebsflade.

Sådan tjekker du, om din TeamCity- eller IntelliJ-installation er sårbar

Hvis din organisation kører en selvhostet TeamCity-server eller bruger IntelliJ IDEA/GoLand til daglig, er det første skridt at bekræfte, hvilken version I faktisk kører. JetBrains anbefaler at opdatere med det samme, hvis versionen ligger under de patchede numre.

# Tjek TeamCity-serverens version via REST API
curl -s -u brugernavn:adgangskode https://din-teamcity-server:8111/app/rest/server | grep -i version

# Sammenlign med de patchede versioner:
# TeamCity On-Premises: 2025.11.7 (LTS) eller 2026.1.3 eller nyere

# Tjek IntelliJ IDEA-version fra kommandolinjen (macOS/Linux)
/Applications/IntelliJ\ IDEA.app/Contents/MacOS/idea --version

# Målet er mindst 2026.2.2 for IntelliJ IDEA
# og mindst 2026.2.2.1 for GoLand

Ud over selve opdateringen anbefaler sikkerhedsforskere også, at TeamCity-servere aldrig eksponeres direkte mod det åbne internet uden yderligere lag som VPN eller adgangsbegrænsning på netværksniveau, at adgangsnøgler og hemmeligheder roteres jævnligt uanset om der er sket et kendt brud, og at logfiler som idea.log gennemgås for følsomt indhold, hvis en ældre, sårbar version har været i brug.

Hvad branchen siger om sagen

JetBrains har selv været usædvanligt åbne om detaljerne i deres rådgivninger, hvilket adskiller sagen fra flere tidligere leverandørhændelser, hvor detaljer først kom frem måneder senere. I den oprindelige advarsel fra juli skrev firmaet direkte om alvoren af TeamCity-fejlen: “A critical security vulnerability has been identified in TeamCity On-Premises and assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2026-63077”, ifølge JetBrains’ officielle sikkerhedsvejledning fra juli 2026.

Firmaet har også historik for at navngive og forklare sine sårbarheder relativt detaljeret. I en tidligere vejledning om en anden TeamCity-fejl fra maj 2026 skrev JetBrains: “A high-severity post-authentication security vulnerability has been identified in TeamCity On-Premises and assigned the CVE identifier CVE-2026-44413”, som fremgår af firmaets vejledning fra maj 2026. Det viser et mønster, hvor TeamCity har krævet gentagne sikkerhedsopdateringer gennem hele året, ikke kun i forbindelse med den kritiske sag fra juli og august.

Sikkerhedsmedier har fulgt tæt med i, hvor bredt problemet rækker på tværs af JetBrains’ produktportefølje. Som nævnt tidligere konstaterede Cybersecurity News, at flere produkter blev ramt samtidig, og at den mest alvorlige af de tidligere fejl gjorde det muligt at udføre kode gennem path traversal i den måde, IDE’en håndterer projekt-arbejdsplads-ID’er på. Det underbygger et billede af, at 2026 har været et år, hvor JetBrains’ sikkerhedsteam har været under konstant pres for at følge med. Se også vores omtale af, hvordan JetBrains AI Assistant sættes op og prissættes for kontekst om, hvor bredt JetBrains-økosystemet rækker ind i en almindelig udviklerhverdag.

Betydning for danske og nordiske udviklerteams

Der findes ingen offentligt verificerede tal for, præcis hvor mange danske eller nordiske virksomheder der kører TeamCity eller bruger JetBrains’ IDE’er, men værktøjerne er udbredte i Java-, Kotlin- og .NET-tunge miljøer, som fylder meget i både den danske fintech-sektor og i større industrivirksomheder med egne udviklingsafdelinger. Det relevante spørgsmål for danske it-afdelinger er derfor mindre “bruger vi det her” og mere “hvor hurtigt reagerer vi, når leverandøren udsender en kritisk patch”.

Med NIS2 nu fuldt indfaset i dansk lovgivning, er kravene til hændelseshåndtering og rettidig patching skærpet for en bred kreds af virksomheder, ikke kun kritisk infrastruktur i traditionel forstand. En sag som denne, hvor selve leverandøren demonstrerer, at en kendt og patchet sårbarhed stadig kan udnyttes mod egen infrastruktur en måned senere, er et konkret argument for, at danske virksomheder bør have automatiserede processer til at opdage og lukke sårbare versioner af CI/CD-værktøjer, fremfor at stole på manuelle rutiner.

Det gælder især for teams, der eksponerer byggeservere som TeamCity mod internettet af hensyn til fjernarbejde eller distribuerede teams på tværs af de nordiske hovedstæder. Jo mere tilgængelig en byggeserver er udefra, desto vigtigere bliver det, at patch-vinduet fra sårbarhed til opdatering måles i timer og dage, ikke uger. Vores tidligere dækning af VS Code’s nye Agent Host-protokol peger på samme underliggende problem: jo flere agenter og eksterne processer, der får adgang til udviklingsmiljøet, desto større bliver angrebsfladen.

Fem forudsigelser for resten af 2026

Baseret på mønsteret i årets hændelser er der en række udviklinger, som med rimelig sandsynlighed vil udspille sig i de kommende måneder.

  • Flere virksomheder vil overveje at flytte fra selvhostet TeamCity til TeamCity Cloud eller alternative CI/CD-platforme, netop fordi cloud-varianten ikke var berørt af den kritiske fejl fra juli.
  • JetBrains vil sandsynligvis stramme sin interne patch-proces yderligere, efter at det kom frem, at firmaets egen infrastruktur stod eksponeret næsten en måned efter en offentligt kendt kritisk sårbarhed.
  • Flere nationale cybersikkerhedsmyndigheder, ud over de allerede kendte advarsler fra blandt andet australske og canadiske myndigheder, vil formentlig udsende deres egne vejledninger specifikt om JetBrains-produkter i løbet af efteråret 2026.
  • Konkurrenter til TeamCity, herunder GitLab CI og Jenkins-baserede løsninger, vil bruge sagen aktivt i deres markedsføring over for virksomheder, der overvejer at skifte CI/CD-leverandør.
  • Presset for at revidere, hvordan Dev Containers og Remote Development-funktioner håndterer tillid som standard, vil sandsynligvis brede sig til andre IDE-leverandører end JetBrains, efterhånden som flere forskere begynder at lede efter lignende designfejl.

Sådan beskytter du dit team fremadrettet

Ud over at opdatere til de patchede versioner er der en række strukturelle tiltag, som reducerer risikoen for, at den næste TeamCity- eller IntelliJ-sårbarhed rammer lige så hårdt. Segmenter byggeservere væk fra det almindelige interne netværk, så en kompromitteret CI/CD-server ikke automatisk giver adgang til resten af infrastrukturen. Indfør automatisk versionsovervågning, der advarer, så snart en kendt sårbar version af TeamCity, IntelliJ IDEA eller GoLand dukker op i miljøet. Begræns, hvilke hemmeligheder en byggeserver har adgang til ad gangen, i stedet for at give den vidtrækkende rettigheder til hele forsyningskæden på én gang. Endelig bør enhver organisation, der har kørt en sårbar version i den periode, hvor fejlen var kendt, som minimum rotere alle nøgler og adgangskoder, byggeserveren har haft adgang til, uanset om der er konkrete tegn på misbrug.

Ofte stillede spørgsmål

Hvad er CVE-2026-63077?

Det er en kritisk sårbarhed i JetBrains TeamCity On-Premises med en CVSS-score på 9,8. Den giver en uautentificeret angriber mulighed for at udføre vilkårlig kode på serveren via byggeagenternes polling-protokol.

Er TeamCity Cloud også berørt?

Nej. JetBrains har bekræftet, at der ikke er tegn på, at TeamCity Cloud er blevet udnyttet via denne sårbarhed. Kun selvhostede On-Premises-installationer før version 2025.11.7 eller 2026.1.3 er berørt.

Hvordan blev JetBrains selv hacket?

Angribere udnyttede en upatchet TeamCity-server i JetBrains’ egen Cadence-infrastruktur til at få adgang til blandt andet AWS-nøgler, S3-buckets og potentielt kildekode. Bruddet blev opdaget af JetBrains den 23. august 2026, næsten en måned efter at patchen var udsendt.

Hvilke IntelliJ IDEA-sårbarheder blev fundet i september 2026?

Fire CVE’er blev offentliggjort den 7. september 2026 i IntelliJ IDEA: CVE-2026-86501, CVE-2026-86502, CVE-2026-86504 og CVE-2026-86505. Den mest alvorlige, CVE-2026-86502, har en CVSS-score på 8,4 og skyldes manglende kryptering og autentificering i IDE’ens Remote Development-funktion.

Hvad skal jeg gøre, hvis mit team bruger en sårbar version?

Opdater TeamCity til mindst version 2025.11.7 eller 2026.1.3, og opdater IntelliJ IDEA til mindst 2026.2.2 samt GoLand til mindst 2026.2.2.1. Roter derefter alle adgangsnøgler og hemmeligheder, som byggeserveren har haft adgang til i den periode, hvor den var sårbar.

Er der en forbindelse til TeamCity-hacket fra 2023?

Der er ingen bekræftet teknisk forbindelse mellem CVE-2026-63077 og CVE-2023-42793 fra 2023, som blev udnyttet af en gruppe kædet sammen med russisk efterretning. Men begge sager viser det samme mønster: TeamCity er et attraktivt mål, fordi byggeservere sidder centralt i softwareforsyningskæden.

Påvirker sagen danske virksomheder omfattet af NIS2?

Der findes ingen offentlige tal for, hvor mange danske virksomheder der specifikt bruger TeamCity, men virksomheder omfattet af NIS2 skal generelt kunne dokumentere hurtig patching og hændelseshåndtering. En sag som denne understreger, hvorfor automatiseret overvågning af CI/CD-værktøjers versioner bør indgå i den compliance.