Medan alla bråkar om vilken modell som skriver bäst kod, växer ett mycket äldre och betydligt mindre glamoröst problem tyst i takt med varje nytt AI-datacenter: baseboard management controller, eller BMC. Säkerhetsforskare presenterade den här veckan resultat som visar att tusentals internetanslutna servrar från stora tillverkare kan förses med bakdörrar på distans genom sårbarheter i dessa styrenheter – vissa av bristerna är över ett decennium gamla. Det här handlar inte alls om AI. Det handlar om hårdvaran som AI körs på, och det är värt att förstå om du funderar på var nästa våg av AI-nära säkerhetsjobb kommer att uppstå.

Vad en BMC faktiskt är och varför den är skrämmande

En BMC är en liten, separat dator som är fastlödd på i stort sett alla moderkort för företagsservrar. Den kör sitt eget operativsystem, sin egen nätverksstack och har sin egen IP-adress – helt oberoende av vilket operativsystem och vilka applikationer som körs på huvudservern. Administratörer använder BMC:er för så kallad ”lights-out”- eller ”out-of-band”-hantering: att starta om en maskin, skriva om firmware, installera om ett operativsystem, allt på distans och, vilket är avgörande, även när huvudservern är avstängd eller helt svarslös.

Det är också precis det som gör en komprometterad BMC så farlig. En angripare som tar sig in i en behöver inte att värdoperativsystemet körs, behöver inte kringgå den slutpunktssäkerhet som finns installerad där och kan finnas kvar efter ominstallationer av operativsystemet, eftersom BMC:n ligger under och utanför det lager som normala IT-säkerhetsverktyg övervakar. Enligt forskningen som uppmärksammades den här veckan är det protokoll som oftast berörs IPMI, och säkerhetsforskare har varnat för den här typen av risk åtminstone sedan 2013. Med andra ord: det här är inte en ny bugg, utan en gammal, känd och strukturellt svåråtgärdad kategori av buggar som branschen har tolererat i långt över ett decennium.

Varför det här spelar större roll nu, inte mindre

AI-utbyggnaden är fysiskt sett en av de största vågorna av serverinköp i historien – rad efter rad av GPU-servrar installeras i nya och utbyggda datacenter så snabbt som leverantörerna kan leverera dem. Alla dessa servrar levereras med en BMC, eftersom BMC:er är det datacenteroperatörer använder för att hantera stora serverflottor; man kan inte gå in i en lagerstor byggnad och manuellt starta om tiotusen maskiner. AI-boomen köper alltså inte bara beräkningskapacitet – den köper av nödvändighet också en lika stor flotta av små, otillräckligt övervakade datorer utanför bandet, med en dokumenterad historik på över ett decennium av kritiska sårbarheter.

Det är den tekniska skulden: utbyggnadstakten är optimerad för att få GPU:er på plats och träningskörningar igång, inte för att granska den hanteringsfirmware som finns inbyggd i varje moderkort under dem. Forskarna bakom veckans avslöjande beskrev enligt uppgift BMC:er som en ”utbredd, otillräckligt övervakad och otillräckligt patchad parallell attackyta” – en beskrivning som är äldre än AI-datacenterboomen, men det är boomen som just nu mångdubblar antalet BMC:er i produktion.

Nischen som detta öppnar

Om du kartlägger vart säkerhetskarriärer är på väg i takt med AI-infrastrukturen är de flesta uppenbara områden – red teaming av modeller, försvar mot promptinjektion och styrning av agenter – redan trångbodda och väl täckta på andra håll. Det gäller inte hårdvaru- och out-of-band-säkerhetsgranskning. Det är ett oglamoröst och osexigt hörn av infrastruktursäkerheten som inte dyker upp i AI-keynotes, och det är precis där luckan finns: efterfrågan växer med varje nytt datacenter, medan tillgången på personer som förstår attackytor på firmware-nivå och out-of-band är liten, eftersom det verkligen är en annan kompetensuppsättning än applikations- eller molnsäkerhet.

Så här ser arbetet faktiskt ut, i konkreta termer:

  • Kunskap om firmware och protokoll. Förstå IPMI (och dess kända svaga punkter – till exempel den sedan länge föråldrade cipher suite 0 som vissa enheter fortfarande levereras med aktiverad) tillräckligt väl för att bedöma om en viss serverflotta är exponerad, inte bara teoretiskt sårbar.
  • Granskning av nätverkssegmentering. Kontrollera om BMC-/hanteringsgränssnitt faktiskt är isolerade på ett dedikerat hanteringsnätverk, eller om de kan nås från produktionsnätet eller det allmänna internet – en grundläggande kontroll som gång på gång visar sig saknas i verkligheten.
  • Granskning av autentiseringsuppgifter och patchrutiner. BMC:er levereras ofta med standarduppgifter eller leverantörsinställda autentiseringsuppgifter och firmware som inte ingår i ett datacenters normala patchcykel för operativsystem, eftersom det inte är operativsystemet – det är lätt för den att hamna utanför ansvaret hos den som äger ”patchning”.
  • Leverantörs- och försörjningskedjemedvetenhet. BMC-firmware skrivs vanligtvis av ett litet antal specialiserade leverantörer och licensieras till servertillverkare, så en brist i en leverantörs kod kan spridas till många hårdvarumärken samtidigt – det är precis det mönster som framkom i veckans avslöjande. Att veta vilken firmwarestack som finns under vilket servervarumärke är en del av jobbet.

Så positionerar du dig faktiskt för detta

Det här är verkligen ett nischat område, och det är rimligt att vara skeptisk till hur många särskilda tjänster som kommer att öppnas för det, jämfört med att det förblir en specialisering inom befintliga infrastruktur- eller säkerhetsteam – var ärlig mot dig själv och inse att ”BMC-säkerhetsgranskare” kan sluta som en kompetens du lägger till i en bredare roll inom hårdvaru-/datacentersäkerhet, snarare än en separat jobbtitel. Men några konkreta och verifierbara steg är meningsfulla oavsett: skaffa praktisk erfarenhet av IPMI och out-of-band-hanteringsverktyg om du har tillgång till företagsservrar eller till och med begagnad hårdvara att labba med; läs säkerhetsbulletiner om BMC-firmware från de stora server- och BMC-firmwaretillverkarna, eftersom de publicerar verkliga sårbarhetsrapporter som du kan studera; och om du redan arbetar med moln- eller infrastruktursäkerhet, börja ställa en enkel, verifierbar fråga till den egna organisationens datacenter- eller hårdvaruinköpsteam – ligger vårt BMC-/IPMI-hanteringsplan på ett isolerat nätverk, och vem ansvarar för att patcha det? Om ingen har ett självsäkert svar är det inte bara ett resultat, utan en demonstration av exakt den expertis som den här nischen behöver.