KO IZVORNA KODA NI VEČ CILJ, AMPAK ZEMLJEVID DO PRODUKCIJE

Pri napadu na razvojno okolje najprej pomislimo na izvorno kodo. Napadalec jo lahko ukrade, v njej išče ranljivosti ali poskuša vanjo neopazno vnesti spremembo. V sodobnem DevOps okolju pa je koda le del tega, kar razvojna platforma razkriva. Okoli repozitorija so cevovodi za gradnjo in nameščanje programske opreme, service connections, tehnične identitete, konfiguracije infrastrukture, spremenljivke in povezave do drugih sistemov. Posamezna komponenta ima povsem legitimen namen. Skupaj pa lahko precej natančno pokažejo, kako razvojno okolje komunicira z infrastrukturo in po kateri poti pride sprememba od repozitorija do produkcije.

Microsoft je 29. septembra 2026 objavil primer incidenta, pri katerem je prav ta povezava postala pomembnejša od same izvorne kode.

Od enega računa do razvojnega okolja

Microsoftova ekipa za odzivanje na incidente je preiskovala dejavnost akterja, ki ga podjetje spremlja pod oznako Storm-3068. Po njihovem poročilu se je napad začel s prevzemom uporabniškega računa prek postopka samopostrežne ponastavitve gesla. Napadalec je nato na račun registriral lastne metode preverjanja pristnosti in si s tem zagotovil nadaljnji dostop.

Pozornost je zatem preusmeril na Azure DevOps. Z legitimnimi administrativnimi orodji in avtomatiziranimi skriptami je pregledoval repozitorije, projekte, cevovode in okolja za nameščanje.

Preiskovalci so ugotovili, da je spreminjal razvojne cevovode in ustvaril zlonamerni pipeline za zbiranje Kubernetes poverilnic. Ta je izvajal opravila za pridobivanje datotek kubeconfig, v katerih so podatki za povezovanje s Kubernetes gručami in podatki za preverjanje pristnosti. Po Microsoftovih navedbah je bil uporabljeni pipeline pooblaščen za dostop do več kot 50 virov in storitev.

V nadaljevanju napada je bilo v repozitorij dodanih tudi sedem ukradenih datotek kubeconfig, ki so omogočale dostop do ciljnih Kubernetes gruč. Preiskovalci so ta del aktivnosti rekonstruirali z Azure DevOps revizijskimi dnevniki in zgodovino sprememb v Gitu. Razvojno okolje se je tako pokazalo v dveh vlogah. Napadalcu je ponudilo informacije in mehanizme za širjenje dostopa, preiskovalcem pa je ob ustrezno ohranjeni revizijski sledi omogočilo rekonstrukcijo dela njegove poti.

Ko dovoljenja postanejo pot

Posamezni sistemi v takem okolju so lahko dobro zaščiteni. Microsoft Entra ID upravlja identitete, Azure DevOps razvojne projekte in cevovode, Kubernetes aplikacije, namenski trezorji pa skrivnosti. Varnostna slika se spremeni, ko namesto posameznega sistema pogledamo povezave med njimi.

Uporabnik ima lahko na primer pravico spreminjati določen pipeline. Ta za dostop do Azure uporablja service connection, za katero je določena identiteta in njen obseg dostopa do ciljnih virov. Azure DevOps pri takšnih povezavah podpira med drugim aplikacijske registracije oziroma service principale ter managed identities.

Če ima uporabljena identiteta široka dovoljenja, postane pomembno tudi vprašanje, kdo lahko spreminja proces, ki to identiteto uporablja.

Pot je lahko videti približno tako:

uporabnik → pipeline → service connection → identiteta → Azure vir → produkcijsko okolje

Pregled pravic lahko povsem pravilno pokaže, da uporabnik nima neposrednega dostopa do produkcijskega vira. To pa še ne pove, ali sme spreminjati avtomatizacijo, ki do istega vira dostopa z drugo identiteto.

Zato je poleg klasičnega pregleda vlog, članstev in ACL-jev smiselno analizirati tudi poti: kaj je mogoče doseči prek povezav, ki med sistemi že obstajajo.

CI/CD kot privilegirano izvajalno okolje

Cevovodi niso samo priročna avtomatizacija gradnje programske opreme. Lahko objavljajo artefakte, uporabljajo registre, kličejo API-je, ustvarjajo infrastrukturo in nameščajo aplikacije v produkcijska okolja. Za takšna opravila potrebujejo ustrezne pravice.

OWASP zato pri varovanju CI/CD okolij posebej izpostavlja upravljanje identitet, skrivnosti in privilegijev. Priporoča najmanjše potrebne pravice, omejevanje deljenja poverilnic med različnimi cevovodi, pregled sprememb konfiguracije ter ročno odobritev pred produkcijskim nameščanjem, kjer je to smiselno.

Enako načelo velja pri Azure DevOps. Microsoft priporoča, da so service connections omejene na vire, ki jih cevovod dejansko potrebuje, in odsvetuje široke pravice Contributor čez celotno Azure naročnino, kadar za opravilo niso potrebne. Pri povezovanju z Azure priporoča workload identity federation z aplikacijsko registracijo ali managed identity namesto aplikacijske registracije z dolgoročno skrivnostjo.

Načelo najmanjših privilegijev se torej ne konča pri uporabniških računih. Veljati mora tudi za procese in tehnične identitete, ki delo opravljajo samodejno.

NIST Secure Software Development Framework podobno zahteva, da je dostop do izvorne kode, izvedljive kode in configuration-as-code omejen po načelu najmanjših privilegijev. Med primeri navaja uporabo repozitorijev in nadzora različic za sledljivost sprememb ter pregled in odobritev sprememb s strani odgovorne osebe.

Poverilnica, ki je preživela svoj namen

Pri tehničnih identitetah se hitro pojavi še problem življenjskega cikla. Service principal, ustvarjen za nekdanji projekt, lahko ostane aktiven. PAT, ki ga je nekoč potrebovala avtomatizacija, lahko preživi proces, zaradi katerega je bil ustvarjen. Enako velja za client secret ali certifikat, če njun obstoj ni vezan na jasen postopek pregleda in ukinitve.

Pri pregledu okolja je zato koristno ločiti dve vprašanji: katero identiteto uporablja avtomatizacija in kako se ta identiteta avtenticira.

Service principal oziroma managed identity predstavljata identiteto. Client secret, certifikat, federirano poverilo in PAT pa so različni načini oziroma sredstva, s katerimi je mogoče pridobiti dostop v različnih scenarijih.

Microsoft za nove integracije z Azure DevOps priporoča uporabo Microsoft Entra ID. Za avtomatizacijo, ki teče v Azure, kot najprimernejšo možnost izpostavlja managed identity, ker Azure upravlja identiteto in pridobivanje kratkoživih žetonov, zato ni treba shranjevati in rotirati client secreta. Pri service principalu priporoča certifikate ali federirane pristope in najmanjše potrebne pravice. PAT pa uvršča med bolj tvegane možnosti ter njegovo uporabo omejuje predvsem na začasne, osebne ali podedovane scenarije.

Odstranitev dolgoročne skrivnosti seveda ne popravi preširokih dovoljenj. Identiteta brez gesla ima lahko še vedno več dostopa, kot ga potrebuje. Zmanjša pa število trajnih poverilnic, ki jih mora organizacija ustvarjati, hraniti, rotirati in nekoč preklicati.

OWASP pri CI/CD posebej opozarja tudi na skrivnosti v repozitorijih in konfiguracijskih datotekah. API-ključi, gesla in druge občutljive vrednosti ne bi smeli biti zapisani neposredno v kodo ali konfiguracijo cevovoda, kjer jih je mogoče razkriti skozi zgodovino repozitorija, dnevnike ali druge artefakte.

Sprememba kode je lahko sprememba varnostne meje

Zaščitene veje, pull requesti, pregledi sprememb in nadzor nad urejanjem pipelineov se pogosto obravnavajo predvsem kot razvijalska disciplina. Ko ima isti pipeline dostop do produkcijskega okolja, dobijo ti mehanizmi tudi neposredno varnostno vlogo.

Microsoft je po incidentu Storm-3068 med priporočili navedel obvezne odobritve sprememb kode, zaščito vej, omejevanje neposrednih commitov v kritične veje ter nadzor nad tem, kdo lahko ustvarja, spreminja ali izvaja build in deployment pipeline.

Razlog je praktičen. Če kompromitirana identiteta sama spremeni produkcijski pipeline in ga nato izvede z uporabo privilegirane povezave, je njen dejanski doseg bistveno širši od dovoljenj, ki jih vidimo samo na uporabniškem računu.

Če pa sprememba kode, sprememba pipelinea in uporaba privilegirane povezave zahtevajo različne postopke ali odobritve, kompromis ene identitete še ne zagotavlja neovirane poti naprej.

Podobno velja za revizijsko sled. Microsoftova preiskava ni temeljila samo na podatku, kdo se je prijavil. Preiskovalci so povezovali telemetrijo identitetnih sistemov, razvojne platforme in oblačne infrastrukture ter pri delu preiskave uporabili Azure DevOps audit logs in Git version history.

Za okolja z več privilegiranimi povezavami je zato pomembno, da je mogoče naknadno ugotoviti vsaj, kdo je spremenil pipeline, katera povezava oziroma identiteta je bila uporabljena in kateri ciljni viri so bili doseženi.

Kaj bi pokazal pregled lastnega okolja?

Namesto še enega seznama privilegiranih računov je lahko koristno izbrati kritičen produkcijski proces in mu slediti v nasprotni smeri. Kdo lahko spreminja njegov deployment pipeline? Pri tem štejejo definicija cevovoda, njegove spremenljivke, uporabljeni agenti in povezave do zunanjih virov.

Katero identiteto pipeline uporablja in kako se avtenticira? Gre za service principal, managed identity ali drug mehanizem? Ali uporablja federacijo, certifikat, client secret oziroma PAT?

Kako široka so dovoljenja? Če cevovod namešča eno aplikacijo v en resource group, je vredno preveriti, ali res potrebuje dostop širše od tega.

Katere statične poverilnice še obstajajo? Pri vsaki bi moralo biti jasno, zakaj obstaja, kateri proces jo uporablja, kako širok je njen obseg in kdaj je bila nazadnje preverjena.

Na koncu ostane še vprašanje, ki ga običajna tabela pravic hitro spregleda:

kaj lahko v resnici doseže popolnoma kompromitirana razvojna identiteta, če upoštevamo tudi sisteme, ki ji zaupajo?

Zemljevid, ki ga uporabljata obe strani

Repozitorij danes pogosto vsebuje več kot programsko logiko. Ob njem so Infrastructure as Code, definicije pipelineov, imena okolij, sklici na trezorje skrivnosti, registri artefaktov ter povezave do storitev in infrastrukture.

Microsoft je v primeru Storm-3068 Azure DevOps opisal kot okolje na presečišču identitete, razvoja programske opreme in oblačnih operacij. Repozitoriji, cevovodi, service connections in deployment nastavitve so napadalcu omogočili preslikavo zaupanja in povezanih virov.

To ni posebnost Azure DevOps ali Kubernetesa. Enak problem lahko nastane povsod, kjer avtomatizacija povezuje razvojno okolje z bolj privilegiranim ciljem.

Zato varnosti takega okolja ni mogoče dobro oceniti samo s seznamom posameznih pravic. Potrebujemo tudi sliko njihovih povezav in poti, ki iz njih nastanejo.

Prvo pove, kdo ima ključ.

Drugo pokaže, koliko vrat lahko z njim na koncu odpre.

EVIDENCE PROFILE

Dokazni profil članka

Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.

OSREDNJI DOKAZPri DevOps varnosti je treba poleg neposrednih pravic analizirati tudi poti prek avtomatizacije in tehničnih identitet, ki lahko dosežejo produkcijo.

RAZISKAVE0

DOKUMENTACIJA6

PREDOBJAVE0

UREDNIŠKI PREIZKUSNE

PREVERJENO2026-09-30

Viri

1. 01ADVISORYMicrosoft
   Microsoft Defender Experts Cybersecurity Incident Response. Beyond source code: A path to the keys to the kingdom. Microsoft Security Blog, 29. september 2026.
2. 02PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn.Make your Azure DevOps secure. Azure DevOps security guidance.
3. 03PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn.Authentication methods for Azure DevOps integrations.
4. 04PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn.Access Azure DevOps with Microsoft Entra workload identity.
5. 05PRIMARY DOCUMENTATIONOWASP
   OWASP Cheat Sheet Series.CI/CD Security Cheat Sheet.
6. 06STANDARDNational Institute of Standards and Technology (NIST)
   NIST Special Publication 800-218.Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities.