CI/CD in GitHub Actions: upravljanje skrivnosti in kontrole dobavne verige

Pregled virov: 13. september 2026. Spodnji postopki in tabele so predlogi za pooblaščen pregled. Sklici utemeljujejo tehnične lastnosti in priporočila virov; ne pomenijo, da vir predpisuje točno ta obseg ali obliko evidence.

Sistemi CI/CD iz spremembe izvorne kode ustvarijo objavljeno ali nameščeno programsko opremo, zato so pomembna meja zaupanja. Potek lahko bere izvorno kodo, prenese odvisnosti, uporabi poverilnice za oblak, podpiše artefakt, objavi paket in namesti storitev. Pri GitHub Actions ni dovolj vprašanje, ali je repozitorij zaseben. Preveriti je treba, kateri dogodek zažene kateri potek, katero kodo izvajalnik zažene, katera identiteta je na voljo in kje se rezultat šteje za zaupanja vreden. 1

Utrjevanje mora ohraniti uporaben postopek dostave. Spodnje kontrole zmanjšajo nepotrebne pravice, določijo zaupanja vredne vhode in preprečujejo, da bi kompromitirana zahteva za združitev ali odvisnost tiho vodila do produkcijske namestitve. Namen je obrambni pregled, ne opis zlorabe. 1

Poteke popišite kot privilegirano avtomatizacijo

Najprej popišite repozitorije, datoteke potekov, ponovno uporabljene poteke, sestavljena dejanja, samostojne izvajalnike, okolja, skrivnosti, spremenljivke, cilje namestitve, registre paketov, vloge v oblaku, ključe za podpisovanje in zunanja dejanja. Pri vsakem poteku zabeležite sprožilec in dejanske pravice. Potek za ročno izdajo ima drugačno tveganje kot potek, ki ga sproži zahteva za združitev, komentar težave, dogodek iz drugega repozitorija ali sprememba kode. 1

Za vsak potek določite, katera koda lahko vpliva na izvajanje. To so datoteke izbrane različice repozitorija, prenesene v delovni prostor z operacijo checkout, vsebina zahteve za združitev, skripte, konfiguracija, manifesti odvisnosti, vsebniki za gradnjo in uporabljena dejanja. Potek z dostopom do poverilnic za namestitev ne sme v istem kontekstu izvajati nezaupanja vredne kode prispevka. Preglejte tudi ponovno uporabljene poteke; centralno vzdrževan potek lahko poenoti pravila, hkrati pa zbere tveganje na enem mestu. 1

Vsak potek naj ima lastnika in rok ponovnega pregleda. Onemogočene ali poskusne datoteke niso neškodljive, saj jih je mogoče kasneje ponovno omogočiti s starimi pravicami ali nepritrjenimi dejanji. Kratek popis omogoča odkriti poteke, ki so po spremembi namena ohranili preširoke pravice pisanja. 1

Uporabite kratkotrajne in omejene poverilnice

Kjer je mogoče, uporabite identiteto delovne obremenitve in kratkotrajne žetone namesto dolgoročnih ključev za oblak, shranjenih med skrivnostmi repozitorija. Identiteta poteka naj dobi samo pravice, ki jih potrebuje posamezno opravilo. Privzete pravice GITHUB_TOKEN nastavite na branje, nato pa v poteku ali opravilu izrecno dodelite samo zahtevane pravice pisanja. 1

Ločite vloge za gradnjo, objavo in namestitev. Opravilo za testiranje ne potrebuje enakih poverilnic kot produkcijska izdaja. Produkcijska okolja zaščitite z obveznimi odobritvami, omejitvami vej ali oznak in določenim lastnikom namestitve. Kadar ponudnik oblaka to omogoča, povežite GitHub Actions in oblak s federirano identiteto. Tako potek pridobi kratkotrajno poverilnico, vezano na repozitorij, vejo, okolje in pogoje poteka. 1 2 3

Pri skrivnostih repozitorija, organizacije in okolja preverite lastnika, obseg, zadnjo uporabo, postopek zamenjave in nadomestno pot. Produkcijske skrivnosti ne sodijo v široko dostopne nastavitve repozitorija samo zato, ker jih lahko potek potrebuje. Za poverilnice, ki morajo doseči produkcijo, uporabite skrivnosti okolja in zaščitena okolja za namestitev. Prikrivanje v dnevnikih pomaga preprečiti nenamerno razkritje, ni pa kontrola avtorizacije; potek, ki lahko bere skrivnost, je treba obravnavati, kot da jo lahko zlorabi. 1

Evidenca kontrol identitete za uvajanje

Sledite eni poti uvajanja od odobrene različice izvorne kode do ciljne vloge ali storitvene identitete. Spodnja tabela je zapis za pregled, ne produkcijska konfiguracija. Namenoma ne vsebuje dejanskih imen vlog, identifikatorjev računov v oblaku ali vrednosti zaupanja. 1

OIDC lahko odpravi potrebo po dolgoročni skrivnosti za oblak v GitHubu, ne odpravi pa potrebe po preverjanju vseh pogojev zaupanja in dejanskih pravic vloge v oblaku. 1 2 3

Zunanja dejanja in odvisnosti so koda

Vsako zunanje dejanje je koda, ki se izvede v okolju gradnje. Dejanja pripnite na pregledane polne identifikatorje commit SHA namesto na premikajoče se oznake ter določite seznam dovoljenih izdajateljev ali postopek odobritve. Pripenjanje omeji tveganje spremembe, ne dokazuje pa varnosti dejanja. Preglejte njegove pravice, omrežno vedenje, vzdrževanje in podatke, ki jih prejme. 1

Enaka disciplina velja za odvisnosti paketov, gradbene slike, nastavitvene skripte in orodja za izdajo. Kjer ekosistem to podpira, uporabite datoteke z zaklenjenimi različicami odvisnosti (lockfiles). Spremembe odvisnosti naj bodo pregledane v zahtevi za združitev, spremembe konfiguracije izdaje ali virov odvisnosti pa naj zahtevajo človeški pregled. Kadar je to smiselno glede na distribucijski model, ustvarjajte in hranite popis sestavin programske opreme ter metapodatke o gradnji. 1

Izvor gradnje je uporaben, kadar ga lahko prejemnik preveri. Določite, katero okolje gradnje, različico izvorne kode, pot odobritve in identiteto za podpisovanje organizacija zaupa za izdajo. Ključi ali pravica za podpisovanje naj bodo ločeni od običajnih testnih opravil. Če artefakte podpisujete, pravilo izdaje ne sme dovoliti, da poljubna sprememba poteka uporabi podpisnik. 1

Varno oblikujte avtomatizacijo zahtev za združitev

Zahteva za združitev je vhod za sodelovanje, ni pa samodejno zaupanja vredna koda. Pri vsakem poteku, ki se odzove na zahtevo ali komentar, preverite pomen sprožilca. Za nezaupanja vredne prispevke uporabite omejen kontekst in jim ne posredujte skrivnosti repozitorija ali poverilnic za namestitev. Preverjanja, ki potrebujejo privilegiran dostop, naj delujejo na pregledani zaupanja vredni kodi ali v ločenem postopku z omejenimi podatki. 1

Ne prenašajte nezaupanja vredne kode iz repozitorija v delovni prostor z operacijo checkout, če jo bo opravilo izvajalo s privilegiranim žetonom ali dostopom za namestitev. To je posebej pomembno pri privilegiranih kontekstih pull_request_target in workflow_run. Vpliv je lahko posreden: izvajanje lahko spremeni ukaz gradnje, testna konfiguracija, skripta paketa ali ustvarjena konfiguracijska datoteka. Opravilo obravnavajte kot računalnik, ki izvaja navodila iz repozitorija, saj je to njegova dejanska funkcija. 1

Za datoteke potekov, manifeste za namestitev, ponovno uporabljene poteke in infrastrukturno kodo zahtevajte zaščitene veje in pregled. CODEOWNERS določi ustrezne pregledovalce; njihova odobritev je obvezna le, če zaščita veje zahteva pregled lastnikov kode. Zaščitite datoteko CODEOWNERS in veljavna pravila zaščite vej, pregledovalna skupina pa naj ima dovolj neodvisnosti, da zazna napako. Enak model naj velja za čakalne vrste združevanja, izdaje in samodejne posodobitve odvisnosti. 1 4

Zaščitite izvajalnike in artefakte

Izvajalniki, ki jih upravlja GitHub, zmanjšajo skrbniško delo. Samostojni izvajalniki so lahko potrebni zaradi dostopa do zasebnega omrežja, posebne strojne opreme ali licenc. Pri njih so potrebne strožje kontrole: ločite jih po ravni zaupanja, preprečite, da bi repozitorij z nižjim zaupanjem dosegel izvajalnik za produkcijo, posodabljajte operacijski sistem, kjer je izvedljivo omejite odhodni promet in po opravilu odstranite delovni prostor ter poverilnice. 1

Oznake izvajalnikov usmerjajo opravila na ustrezne izvajalnike; same ne omejujejo dostopa. Dostop uveljavite prek identitete repozitorija, registracije in identitete izvajalnika, pravil dostopa do skupin izvajalnikov ter dovoljenj, ki so na voljo izvajalniku. Preverite, kdo lahko doda izvajalnik, ga dodeli repozitorijem, spremeni oznake in uredi njegov omrežni dostop. Uspešen zadnji potek ni dokaz, da je izvajalnik čist. Gre za izvajalno okolje s programsko opremo, predpomnilniki in podatki, ki potrebuje določen model ponastavitve. 1 5 6

Za artefakte določite pravila celovitosti in hrambe. Omejite, kdo jih lahko naloži, prenese, potrdi za izdajo ali namesti. Nezaupanja vredne izhode gradnje in kandidate za izdajo ločite po imenih in skladiščih. Namestitev naj uporabi artefakt, ki ga je mogoče povezati z odobreno različico izvorne kode in nadzorovanim postopkom gradnje, ne pa naj ob namestitvi znova zgradi poljubne kode. 1

Spremljanje, pregled in odziv

Kjer je izvedljivo, dnevnike revizij GitHub in potekov pošljite v okolje za spremljanje. Preverjajte spremembe datotek potekov, skrivnosti, okolij, skupin izvajalnikov, pravil organizacije, dovoljenj repozitorijev in sklicev na zunanja dejanja. Opozorila naj imajo prednost pri spremembah, ki razširijo pravice izvajanja, na primer nov odobritelj produkcijskega okolja, širše pravice žetona, nov samostojni izvajalnik ali spremenjeno pravilo zaščitene veje. 1

Postopek za sum razkritja poverilnic CI/CD ali nepooblaščeno spremembo poteka naj določa, kako potek onemogočiti, preklicati ali zamenjati poverilnice, osamiti izvajalnik, popisati artefakte iz prizadetega obdobja in obvestiti lastnike namestitev. Postopek preverite z nadzorovano vajo, da ga med izdajo ali incidentom ni treba sestavljati na novo. 1

Vrstni red odprave

Najprej popišite poteke ter odstranite neuporabljene skrivnosti, pravice, izvajalnike in sklice na dejanja. Nato nastavite omejujoče privzete pravice žetona, produkcijski dostop premaknite v zaščitena okolja in dolgoročne ključe oblaka, kjer je mogoče, zamenjajte s kratkotrajno omejeno identiteto. Pripnite in preglejte zunanja dejanja, zaščitite datoteke potekov in namestitev ter ločite nezaupanja vredne teste zahtev za združitev od privilegiranega dela izdaje. 1

Nato uredite izvor artefaktov, ločitev izvajalnikov, osrednje beleženje in postopek obnovitve. Ponovni pregled mora potrditi dejanske pravice pri vsakem sprožilcu, da zaščitena opravila ne morejo izvajati neodobrene kode in da je mogoče artefakt izdaje slediti od različice izvorne kode do odobritve namestitve. 1

Pogosta vprašanja

Ali zaseben repozitorij pomeni varne poteke?

Ne. Tudi zaseben repozitorij lahko dobi kompromitiran račun, nevarno odvisnost, napačne pravice ali notranjo napako. Praktično avtoriteto poteka določata sprožilec in razpoložljive poverilnice. 1

Ali prikrivanje skrivnosti v dnevnikih zadošča?

Ne. Prikrivanje zmanjša možnost, da se skrivnost po nesreči prikaže v dnevniku. Ne prepreči kodi, ki skrivnost prejme, da jo pošlje drugam ali uporabi za nedovoljeno dejanje. 1

Ali moramo vsa dejanja vzdrževati sami?

Ne. Zunanja dejanja so lahko primerna, kadar so njihov izvor, vzdrževanje, pripeta različica, pravice in postopek posodobitev razumljeni in pregledani. 1

Notranje povezave: Strokovno področje varnosti oblaka · Kontekst AWS · Kontekst vsebnikov · Priprava na penetracijski test

Sources / Viri

1. GitHub Actions: Secure use reference — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.
2. GitHub Actions: OpenID Connect concepts — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.

3. GitHub Actions: OIDC reference — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.

4. GitHub Docs: About code owners — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.

5. GitHub Docs: Using labels with self-hosted runners — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.
6. GitHub Docs: Managing access to self-hosted runners using groups — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.