CI/CD-tietoturva
Tietovuotojen estäminen GitHub Actionsista egress-käytännöllä
CI-jobilla on hallussaan salaisuuksia, ja se ajaa koodia, jonka se latasi minuutti sitten: actioneita, paketteja ja niiden asennusskriptejä. Jos mikä tahansa siitä koodista on haitallista, helpoin tapa varastaa salaisuudet on lähettää ne palvelimelle. Egress-käytäntö päättää, mihin palvelimiin jobi saa ottaa yhteyttä, ja estää loput.
Päivitetty
Miten salaisuudet vuotavat CI-jobista
Jobilla on pääsy repositorion tokeniin, sille välitettyihin salaisuuksiin ja kaikkiin pilvitunnuksiin, joita se käyttää. Jobissa ajettava koodi voi lukea ne. Sen jälkeen koodi voi viedä ne ulos muutamalla tavalla:
- Verkon kautta. Pyyntö hyökkääjän hallitsemalle palvelimelle. Tämän kanavan egress-käytäntö sulkee.
- Lokien kautta. Salaisuuksien tulostaminen jobin lokiin, usein koodattuina. Maaliskuussa 2025 CISA raportoi, että murrettu tj-actions/changed-files-action paljasti salaisuuksia tällä tavalla.
- Tuotosten kautta. Artefaktit, välimuistit tai jobin tokenilla pushatut commitit.
Koodin ei tarvitse olla haitallinen paketti. Työnkulussa toimivan tekoälyagentin voi kaapata issueen tai pull requestiin piilotetulla prompt injectionilla, minkä jälkeen se voi käyttää samoja kanavia.
Mitä egress-käytäntö tekee
Useimpien jobien tarvitsee päästä vain lyhyeen listaan kohteita: pakettirekistereihin, konttirekistereihin, lähdekoodipalveluihin ja muutamaan palveluun. Egress-käytäntö sallii tämän listan ja estää kaiken muun. Oletuksena estävällä käytännöllä pyyntö tuntemattomaan kohteeseen epäonnistuu, ja salaisuudet pysyvät jobissa.
Se ei sulje jokaista ovea:
- Se ei estä salaisuuksien tulostamista lokeihin. Pidä lokit yksityisinä ja kiinnitä actionit commit-SHA:ihin.
- Sallimasi kohde voi silti viedä dataa ulos, joten pidä sallittujen lista suppeana.
- Se ei kerro, mitkä paketit olivat haitallisia. Se on pakettien seulonnan ja SBOM:n tehtävä.
Kolme tapaa valvoa käytäntöä
- Agentti runnerilla. StepSecurity Harden-Runner lisätään jobin ensimmäiseksi vaiheeksi. Se yhdistää jokaisen yhteyden sen avanneeseen vaiheeseen, rakentaa perustason audit-tilassa ja estää lähtevän liikenteen kaikkiin kohteisiin, jotka eivät ole sallittujen listalla.
- Runneri, johon käytäntö on sisäänrakennettu. CRACI valvoo käytäntöä runnerina itse. Myös muut runneritarjoajat tarjoavat verkkokontrolleja, kuten lähtevän liikenteen suodatuksen Depotin Linux-runnereilla ja estävät tai neuvoa-antavat egress-käytännöt Namespacessa.
- Oma verkkosi. Itse ylläpidetyt runnerit palomuurin tai välityspalvelimen takana, jonka konfiguroit ja ylläpidät itse.
Käyttöönotto rikkomatta buildeja
- Tarkkaile. Tallenna jokainen yhteys, jonka jobi avaa muutaman ajon aikana.
- Salli. Rakenna sallittujen lista sen pohjalta, mitä jobi todella tarvitsee.
- Estä. Siirry oletuksena estävään käytäntöön ja seuraa rikkomuksia.
- Arvioi. Käsittele jokainen uusi rikkomus joko puuttuvana lähteenä tai tietoturvapoikkeamana.
Miten CRACI tekee sen
CRACI:ssa egress-käytäntö on osa runneria. Se validoidaan ennen jobin alkua, tuntemattomat kentät hylätään, ja virhetilanteessa liikenne estetään (fail closed). Valmiit esiasetukset kattavat yleiset pakettilähteet, ja mukautetut lähteet ja yhteydet lisäävät loput. Jobin jälki luettelee jokaisen yhteyden ja jokaisen estetyn yhteyden rikkomuksena syineen. Koska välityspalvelin tunnistaa paketit, samasta tallenteesta tulee jobin SBOM. API palauttaa SBOM:t, verkkojäljet ja alkuperätiedot (provenance).
CRACI:ssa ei vielä ole erillistä audit-tilaa; se on tiekartalla. Ilman verkkokäytäntöä jobin liikenne sallitaan ja tallennetaan jälkeen, joten näet, mitä käytäntö tarvitsee, ennen kuin otat sen käyttöön. CRACI ajaa GitHub Actions -jobeja Linuxilla. Katso CI/CD-tietoturvatyökalut vertailussa ja CRACI vs. StepSecurity.
Egress-käytännöt CI:ssä: usein kysytyt kysymykset
Mikä on egress-käytäntö CI:ssä?
Sääntöjoukko lähteville verkkoyhteyksille, joita CI-jobi saa avata. Jobi pääsee tarvitsemiinsa pakettirekistereihin ja palveluihin, ja kaikki muut kohteet estetään.
Olisiko egress-käytäntö pysäyttänyt tj-actions-murron?
Ei yksinään. CISA:n mukaan salaisuudet paljastuivat siinä tapauksessa työnkulun lokien kautta, eikä niitä lähetetty ulkopuoliselle palvelimelle. Egress-käytäntö sulkee verkkokanavan; actionien kiinnittäminen commit-SHA:ihin ja lokien pitäminen yksityisinä sulkevat lokikanavan.
Rikkooko lähtevän liikenteen estäminen buildeja?
Voi rikkoa, jos käytännöstä puuttuu lähde, jota buildi tarvitsee. Aloita tallentamalla, mihin jobi ottaa yhteyttä, rakenna sallittujen lista sen pohjalta ja ota esto vasta sitten käyttöön. CRACI:ssa valmiit esiasetukset kattavat yleiset pakettilähteet, ja estetty yhteys näkyy jobin jäljessä syineen.
Voinko käyttää egress-käytäntöä GitHubin ylläpitämillä runnereilla?
Kyllä, kun jobiin lisätään agentti, kuten StepSecurity Harden-Runner. Tai siirrä jobi runnerille, joka valvoo käytäntöä itse, kuten CRACI.
Laita yksi jobi egress-käytännön taakse
Aja yksi työnkulku CRACI:ssa ja näe jokainen sen avaama yhteys, kohteet, jotka se tarvitsisi sallittujen listalle, ja SBOM siitä, mitä se haki.
Varaa demo