GitHub-toimintojen käytännön tietoturvan koventaminen

Etusivu » Python » GitHub-toimintojen käytännön tietoturvan koventaminen

GitHub Actionsista on tullut GitHubissa isännöityjen repositorioiden de facto CI/CD-moottori., joka pyörittää kaikkea yksikkötestauksista tuotantokäyttöönottoihin ja infrastruktuurimuutoksiin. Tähän kätevyyteen liittyy vakava kompromissi: työnkulut toimivat usein laajoilla käyttöoikeuksilla, käsittelevät tehokkaita tokeneita ja salaisuuksia ja voivat tavoittaa suoraan tuotantojärjestelmät. Jos et tarkoituksella vahvista niitä, annat käytännössä jokaiselle virheelliselle kokoonpanolle, riippuvuusvirheelle tai vaarantuneelle tilille pikaväylän putkiisi ja pilvitileillesi.

Tämä opas käy läpi laajan ja mielipiteisiin perustuvan tarkistuslistan GitHub-toimintojen suojaamiseksi alusta loppuun: miten salaisuuksia käsitellään oikein, vältetään komentosarjojen injektointia, lukitaan tokeneita ja triggereitä, arvioidaan kolmansien osapuolten toimia, hallitaan suorittajia ja hyödynnetään sisäänrakennettuja suojausominaisuuksia, kuten koodin skannausta, OIDC:tä, Dependabotia ja tarkastuslokia. Tavoitteena on yhdistää hajallaan olevat parhaat käytännöt, viimeaikaisista tapauksista kovalla työllä saadut opetukset ja GitHubin omat koventamisohjeet yhdeksi käytännölliseksi lähteeksi, jota voit soveltaa oikeissa projekteissa.

GitHub Actionsin todellinen riskiprofiili

Ylemmällä tasolla GitHub Actions -työnkulku on vain YAML-tiedosto .github/workflows joka määrittelee yhden tai useamman työn, joista jokainen koostuu vaiheista. Vaiheet voivat joko suorittaa komentotulkkikomentoja tai käynnistää GitHubin tai yhteisön julkaisemia uudelleenkäytettäviä toimintoja. Työnkulut käynnistyvät tapahtumista, kuten push-pyynnöistä, pull-pyynnöistä, ongelmatoiminnoista, aikatauluista tai manuaalisista lähetyksistä.

Tietoturvan näkökulmasta nämä työnkulut sijaitsevat suoraan ohjelmistotoimitusketjusi päällä.Ne rakentavat ja allekirjoittavat julkaisuartefakteja, lähettävät Docker-kuvia, ottavat käyttöön pilviympäristöissä, tarjoavat infrastruktuuria, suorittavat migraatioita ja paljon muuta. Jos hyökkääjä voi hallita koodia, kokoonpanoa tai ympäristöä, jossa etuoikeutettu työnkulku suoritetaan, hän voi usein:

• Takaoven käännettyjä esineitä (binäärit, säilöt, paketit), jotka myöhemmin lähetät asiakkaille.
• Purkaa tehokkaita, pitkäikäisiä tokeneita ja salaisuuksia muistista, lokeista, välimuistista tai artefakteista.
• Etuoikeutettujen pilviroolien väärinkäyttö myönnetty CI:lle lisäpalveluiden käyttöönottoa, verkon muuttamista tai datan käyttöä varten.
• Myrkytystietokeskukset vaarantamalla avoimen lähdekoodin julkaisuprosessia ja levittämällä troijalaisia ​​saastuttavia julkaisuja.

Viimeaikaiset tosielämän tapaukset ovat korostaneet GitHub Actionsin houkuttelevuutta hyökkäysalustana.Hyökkääjät ovat väärinkäyttäneet haavoittuvia työnkulkuja lisätäkseen kryptolouhijoita julkaistuihin paketteihin, ja suosittu tj-actions/changed-files Toiminta vaarantui monivaiheisessa hyökkäyksessä, jolla yritettiin päästä Coinbaseen. Haitallinen koodi poimi salaisuuksia työnkuluista ja kirjoitti ne lokitiedostoihin, mikä voi luoda ketjureaktion toimitusketjun myöhemmille vaarantumisille.

Keskeinen ajatus on, että useimmat GitHub Actions -hyökkäykset perustuvat "todennäköisyyteen × vaikutukseen".Haluat vähentää haitallisten tai virheellisten komponenttien (kolmannen osapuolen toiminnot, epävarmat suoritusohjelmat, riskialttiit käynnistimet) käyttöönoton todennäköisyyttä ja samalla rajoittaa merkittävästi räjähdyksen sädettä, jos jokin yksittäinen komponentti vaarantuu.

Salaisuuksien lukitseminen GitHub Actionsissa

Salaisuudet ovat yleensä houkuttelevin kohde missä tahansa CI/CD-järjestelmässäGitHub Actionsissa ne näkyvät tietovaraston, organisaation tai ympäristön salaisuuksina ja ad-hoc-arvoina, joita saatat vahingossa dumpata kokoonpanoihin, lokeihin, välimuisteihin tai artefakteihin.

Ensimmäinen sisäistettävä asia on käyttöoikeusmalli: kuka tahansa, jolla on kirjoitusoikeudet tietovarastoon, voi tehokkaasti lukea kaikkia tietovarastotason salaisuuksia.He voivat yksinkertaisesti muokata olemassa olevaa työnkulkua suojaamattomassa haarassa, lisätä lokitietoja tai vuotokoodia ja suorittaa kyseisen työnkulun tulostaakseen tai vuotaakseen salaisuuksia. GitHubin lokien peittäminen on paras mahdollinen puolustuskeino, ei erehtymätön takuu.

Jotta salaisuudet pysyisivät hengissä tuossa mallissa, noudata näitä perussääntöjä:

• Käytä vähiten etuoikeuksien periaatettaTyönkulussa käytettävillä tunnistetiedoilla on oltava vain ehdottoman välttämättömät vähimmäiskäyttöoikeudet. Vältä yleiskäyttöisten järjestelmänvalvojan tunnuksien jakamista työnkulun salaisuuksina.
• Suosi ympäristösalaisuuksia arkaluonteisten arvojen kohdalla tietovaraston tai organisaation salaisuuksien sijaanYmpäristösalaisuudet ovat käytettävissä vain töissä, jotka määrittävät kyseisen ympäristön, ja voit suojata niitä lisäominaisuuksilla, kuten pakollisilla tarkistajilla ja haararajoituksilla.
• Älä koskaan tallenna salaisuuksia selkotekstimuodossa työnkulun YAML-tiedostoihin tai koodissa, joka on tallennettu repoon. Kaiken arkaluontoisen tulisi kulkea GitHub Secrets -mekanismin tai ulkoisen salaisuuksien hallinnan kautta.
• Vältä strukturoitujen blobien (JSON, YAML, XML) käyttöä yhtenä salaisuutena.Maskaus perustuu pitkälti tarkkaan merkkijonojen yhteensovittamiseen; monikenttäisiä blobeja on paljon vaikeampi poistaa luotettavasti. Jaa sen sijaan arkaluontoiset tiedot useisiin erillisiin salaisiin merkintöihin.
• Rekisteröi kaikki johdetut salaisuudet eksplisiittisestiJos muunnat salaisuuden (Base64, URL-koodaus, JWT-allekirjoitus jne.) ja tulos saattaa joskus osua lokitietoihin, rekisteröi muunneltu arvo omaksi salaisuudekseen, jotta GitHub voi yrittää peittää sen.

Rotaatio ja hygienia ovat aivan yhtä tärkeitä kuin alkuperäinen kokoonpanoTarkista säännöllisesti, mitä salaisuuksia on olemassa, kuka ja mikä niitä vielä tarvitsee, ja poista tai kierrätä vanhentuneet. Jos epäillään altistumista (esimerkiksi salaisuus, joka tulostuu lokeihin muokkaamattomana tai jota käytetään vaarantuneessa toiminnossa), poista välittömästi kyseiset lokit, peruuta tunnistetiedot ja luo uudet.

Skriptien injektoinnin ja vaarallisen interpoloinnin välttäminen

Yksi yleisimmistä, mutta hienovaraisimmista GitHub Actions -virheistä on komentosarjojen injektointi lausekkeiden kautta.GitHub tarjoaa monipuolisia ”konteksteja”, kuten github, env, secrets ja tapahtumien hyötykuormat, joihin viittaat työnkuluissa käyttämällä ${{ ... }} syntaksi. GitHub arvioi nämä lausekkeet ennen kuoriaskeleesi kulkee.

Kun upotat epäluotettavan kontekstin suoraan komentotulkkikomentoon, kutsut komennon injektion.Esimerkiksi, jos teet näin:

run: echo "new issue ${{ github.event.issue.title }} created"

ja hyökkääjä voi hallita ongelman otsikkoa, he voivat lähettää otsikon, kuten $(id)Lausekkeen laskemisen jälkeen vaiheesta tulee:

echo "new issue $(id) created"

joka toteuttaa id juoksijallaMikään määrä lainausmerkkien säätämistä tai yksinkertaisen validoinnin lisäämistä komentotulkissa ei luotettavasti pelasta sinua tältä kaavalta.

GitHubin suosittelema turvallinen malli on käyttää välivaiheen ympäristömuuttujaa:

env:
TITLE: ${{ github.event.issue.title }}
run: |
echo "new issue \"$TITLE\" created"

Tässä potentiaalisesti haitallinen arvo pysyy muistissa ympäristömuuttujanaja kuori näkee vain $TITLE, ei dynaamisesti rakennettu komentorivi. Tarvitset edelleen normaalia komentotulkin hygieniaa (muuttujien lainausmerkit, tarpeettoman eval-funktion välttäminen jne.), mutta vaarallinen interpolointivaihe poistetaan.

Aina kun tunnet kiusausta upottaa ${{ github.* }} tai muita käyttäjän hallitsemia tietoja suoraan run: lohkot, pysäytä ja työnnä se läpi env: sen sijaanTämä yksi tapa poistaa kokonaisen luokan komentosarjojen injektointiin liittyviä ongelmia kaikista työnkuluistasi.

Käyttöoikeuksien ja tokenien turvallinen määrittäminen

RFID lukija NFC lukija GITHUB_TOKEN jonka GitHub lisää jokaiseen työnkulkuun, on uskomattoman tehokas, jos se jätetään oletusarvoihinSe voi lukea ja kirjoittaa sisältöä, avata ja päivittää pull-pyyntöjä ja olla vuorovaikutuksessa repositorion kanssa monin tavoin. Historiallisesti monilla organisaatioilla oli oletuksena luku- ja kirjoitusoikeus, vaikka he eivät olisi huomanneet sitä.

Ensimmäisen suojauksen varmistamisen vaiheen tulisi olla työnkulun token-oikeuksien oletusarvoisen asettaminen vain luku -tilaan. organisaatio- ja/tai tietovarastotasolla. Tälle on oma asetus Toiminnot-määrityksissä. Sieltä voit valikoivasti myöntää lisäoikeuksia työnkulku- tai työkohtaisesti, esimerkiksi:

permissions:
contents: read
pull-requests: write

Tämä "oletuksena estä, tarvittaessa salli" -malli rajoittaa merkittävästi sitä, mitä hyökkääjä voi tehdä vaarantuneella työnkululla.Se myös pakottaa kirjoittajat miettimään, mitä ominaisuuksia heidän työnsä todella vaatii, sen sijaan, että he perisivät kaikenkattavan tunnuksen.

Jos organisaatiosi on luotu ennen vuoden 2023 alkua, sinun tulee auditoida nämä oletusarvot erikseen.Monilla vanhemmilla organisaatioilla on edelleen kirjoituskelpoisia työnkulkutunnisteita, koska ne ovat vanhempia kuin turvallisempi oletusarvo, eivätkä ne ole koskaan ottaneet muutosta käyttöön.

Tunnusten laajuusalueiden lisäksi ole erittäin varovainen asetuksissa, jotka antavat GitHub Actionsin hyväksyä tai luoda pull-pyyntöjä.Työnkulkujen salliminen PR-pyyntöjen kumileimasimille avaa väärinkäytöspolkuja, joissa vaarantuneet työt yhdistävät haitallista koodia ilman ihmisen tarkistusta. Ellei sinulla ole vahvaa käyttötapausta ja tiukkoja suojakaiteita, pidä tämä ominaisuus pois käytöstä.

Kolmannen osapuolen toimintojen valitseminen ja kiinnittäminen

Jokainen käyttämäsi ulkoinen toiminto on etäkoodinpätkä, joka suoritetaan samoilla oikeuksilla kuin muu työsi.Jos toiminnasta tulee haitallinen, se vaarantuu tai se hylätään haavoittuvien riippuvuuksien vuoksi, siitä tulee valmis jalansija prosessissasi.

Kolmannen osapuolen toimien käsittelyssä on useita puolustuskerroksia.:

• Aloita pienestä, luotettavasta sallittujen listastaGitHubin ylläpitämät toiminnot (kuten actions/checkout, actions/setup-node) ja vahvistettujen luojien markkinapaikkatoiminnot ovat yleensä turvallisempi lähtökohta kuin satunnaiset repot. Monet organisaatiot valvovat tätä organisaatiotasolla valitsemalla ”Salli määritetyt toiminnot ja uudelleenkäytettävät työnkulut”.
• Suosi suosittuja, aktiivisesti ylläpidettyjä toimiaTutkimukset osoittavat, että monilla markkinapaikkatoiminnoilla on alhaiset OpenSSF Scorecard -pisteet, yksi ylläpitäjä ja lyhytikäiset tai hyvin nuoret omistajatilit. Laajasti käytetyt toiminnot keräävät yleensä enemmän huomiota ja nopeampia korjauksia.
• Tarkkaile suurta määrää avoimia Dependabot-PR:iä toiminnon arkistossaSe on usein merkki siitä, että ylläpitäjä ei asenna tietoturvapäivityksiä, jolloin transitiiviset haavoittuvuudet jäävät korjaamatta.
• Suosi toimintoja, joilla on useampi kuin yksi ylläpitäjä ja arkistoimaton, aktiivinen koodikantaSatoja markkinoilla olevia toimintoja arkistoidaan, mikä tarkoittaa, ettei uusia korjauksia tai yhteensopivuuspäivityksiä tule ja että riski kasvaa ajan myötä.

Versioiden kiinnittäminen on toinen tärkeä aiheJos määrität toiminnon vain tunnisteen perusteella, kuten some-org/some-action@v2, luotat siihen, että tagi ei koskaan siirry haitalliseen koodiin. Tagit voidaan kohdistaa uudelleen, jos ylläpitäjän tili tai arkisto vaarantuu.

Nykyään puolustuskeinoisin lähestymistapa on kiinnittää se täyteen commit-SHA:han.:

uses: some-org/some-action@247835779184621ab13782ac328988703583285a

SHA-tiedostoon kiinnittäminen tekee koodista käytännössä muuttumattoman sinun näkökulmastasi. (paitsi SHA-1-törmäyshyökkäys Git-objekteihin). Haittapuoli on toiminnallinen: sinun on päivitettävä SHA, kun haluat uusia ominaisuuksia tai korjauksia, ja eri työnkulut voivat ajautua eri SHA:ihin, jos et ole varovainen.

Tämän kivun helpottamiseksi jotkut tiimit keskittävät kolmannen osapuolen toimintojen käytön jaettuihin tai yhdistettyihin työnkulkuihin.Yksittäiset säilötiedot viittaavat näihin jaettuihin työnkulkuihin tunnisteiden avulla, kun taas jaetut työnkulut kiinnittävät pohjana olevat toiminnot tarkistettuihin SHA-tiedostoihin ja päivittyvät kontrolloidusti, joskus työkaluilla, jotka avaavat PR-tiedostoja uusille SHA-tiedostoille.

Valitsemastasi strategiasta riippumatta muista, että kiinnittäminen ei ole taikapalomuuriToiminto voi edelleen hakea koodia dynaamisesti suorituksen aikana (esimerkiksi kautta) curl | bash kuvioita) ja ohittaa PIN-koodisi. Sinun on silti silmäiltävä lähdekoodia ilmeisen vaarallisten kuvioiden varalta, ennen kuin luotat toimintoon, jossa on salaisuuksia tai kirjoituskelpoisia tokeneita.

Turvallisempien työnkulkujen ja töiden suunnittelu

Työnkulkujen ja töiden jäsentäminen vaikuttaa voimakkaasti kompromissin räjähdyssäteeseenYleinen anti-pattern on yksittäinen jättimäinen työ, joka tarkistaa koodin, kääntää, testaa, pakkaa ja ottaa käyttöön, ja jolla on kaikki laajat käyttöoikeudet ja pääsy tuotantosalaisuuksiin.

Työn jakaminen erillisiin töihin ja jopa erillisiin työnkulkuihin tarjoaa sekä erillisyyttä että selkeyttäSinulla voi esimerkiksi olla:

• A rakennus- ja testaustyö joka toimii minimaalisilla käyttöoikeuksilla ja ilman käyttöönottosalaisuuksia.
• A pakettityö joka tuottaa allekirjoitettuja esineitä, mutta ei silti kommunikoi tuotannon kanssa.
• A käyttöönottotyö joka on riippuvainen muista ja on ainoa, jolla on oikeus käyttää ympäristön salaisuuksia ja ottaa pilvirooleja.

GitHubin isännöimissä suoritusohjelmissa jokainen työnkulun työ suoritetaan uudessa virtuaalikoneessa., mikä antaa sinulle tietynasteisen eristyksen töiden välille. Se ei vastaa kovetettua hiekkalaatikkoa, ja on olemassa tunnettuja töiden välisiä vektoreita (kuten jaetut haaravälimuistit), mutta töiden jakaminen pakottaa hyökkääjät silti työskentelemään kovemmin ja vähentää salaisuuksien vahingossa tapahtuvaa vuotamista toisiinsa liittymättömiin vaiheisiin.

Käytä ympäristöjä yhdistääksesi herkät vaiheet suojauksiinKäyttöönottotehtävä voi määrittää:

environment: production

ja production ympäristö voidaan sitten määrittää hyväksymään käyttöönotot vain suojatusta haarasta, mahdollisesti pakollisilla manuaalisilla hyväksynnöillä. Yhdistämällä tämän tiukkoihin sivukonttorin suojaussääntöihin (pakolliset tarkistukset, ei pikatoimituksia, vanhentuneen hyväksynnän hylkääminen) pääset lähelle neljän silmän periaatetta tuotantomuutoksille.

Lopuksi, ole varovainen esineiden, kätköjen ja lokien kanssaNe ovat käteviä tapoja jakaa tietoja töiden ja työnkulkujen välillä, mutta:

• Älä niputa salaisuuksia välimuisteihinvarsinkaan vähemmän tunnetuissa paikoissa, kuten ~/.docker/config.json jotka voivat sisältää tavallisia Docker-tunnistetietoja.
• Vältä salaisuuksien kirjaamista lokitiedostoihin tai kokonaisten kontekstien tallentamista lokitiedostoihin., koska tämä voi estää peittämisen tai paljastaa johdettuja arvoja, joita GitHub ei osaa sensuroi.
• Muista, että kuka tahansa, jolla on lukuoikeudet repositorioon, voi yleensä ladata esineitä ja selata lokeja., mukaan lukien ulkopuoliset yhteistyökumppanit, jos myönnät heille käyttöoikeuden.

OIDC ja lyhytaikaiset pilvitunnistetiedot

Yksi vaikuttavimmista muutoksista, joita voit tehdä, on lopettaa kokonaan pitkäaikaisten pilvipalveluntarjoajan tunnistetietojen tallentaminen GitHub-salaisuuksina.Käytä sen sijaan OpenID Connectia (OIDC) saadaksesi lyhytikäisiä, tarkasti rajattuja tokeneita, jotka on sidottu tiettyyn työnkulun identiteettiin.

Korkean tason virtaus on yksinkertainen:

• Pilvipalveluntarjoajasi (AWS, Azure, GCP jne.) on määritetty luottamaan GitHubin OIDC-palveluntarjoajaan.
• Määrittelet identiteettikäytännön, jonka mukaan "hyväksy tokeneita vain tästä organisaatiosta/repositoriosta/haarasta tai ympäristöstä".
• Työn aikana GitHub voi pyytää OIDC-tokenia ja työnkulkusi käyttää pilvikohtaista toimintoa (esimerkiksi aws-actions/configure-aws-credentials) vaihtaakseen sen lyhytaikaiseen rooli- tai palvelutilin tunnukseen.

Luottamusehto on se, missä voi mennä hyvin yksityiskohtaisestiAWS:n tyypillinen käytäntö voi sisältää seuraavat:

"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:Org/Repo:ref:refs/heads/main"
}

Tämä varmistaa, että vain tietyn säilön ja haaran työnkulut voivat ottaa roolin.Jos haluat vieläkin tarkemman rajauksen, voit sitoa roolin tiettyyn ympäristöön haaran sijaan ja vaatia sitten kyseistä ympäristöä vain käyttöönottotyössä. Vaarantunut kolmannen osapuolen toiminto muussa kuin käyttöönottotyössä havaitsee, että OIDC-kutsut yksinkertaisesti epäonnistuvat.

OIDC:n käyttö ei poista pienimpien oikeuksien roolikäytäntöjen tarvetta pilvessä., mutta se poistaa GitHub Secrets -tiedostoissa olevat staattiset käyttöavaimet, joista ne voitaisiin varastaa ja käyttää uudelleen loputtomiin GitHubin ulkopuolelta.

Haarautumissuojaus, sääntöjoukot ja ympäristöt toimivat yhdessä

Monet GitHub Actionsin pelottavista hyökkäyspoluista tiivistyvät siihen, että "hyökkääjä lisää haitallisia muutoksia suojattuun haaraan".Haaran suojaus ja sääntöjoukot ovat siellä tärkein puolustuslinjasi.

Oksilla, kuten main or productionhaluat yleensä ainakin:

• Vaadi pull-pyyntö ennen yhdistämistä – estä suorat työntöliikkeet.
• Vaadi vähintään yksi (usein useampi) hyväksyvä arvostelu joltakulta muulta kuin viimeiseltä työntäjältä.
• Hylkää vanhentuneet hyväksynnät, kun uusia committeja lisätään – jotta hyökkääjät eivät voi hiipiä koodiin tarkistuksen jälkeen.
• Vaadi viimeisimmän tarkistettavan työntöpyynnön hyväksyntä – estää hyökkääjää kaappaamasta jonkun toisen PR:ää, levittämästä huonoa koodia ja hyväksymästä itseään.

Voit sitten yhdistää nämä suojaukset ympäristöihin. Esimerkiksi a production ympäristö saattaa hyväksyä käyttöönotot vain kohteesta main haara, ja ehkä vaatia myös manuaalisen hyväksynnän pieneltä joukolta tarkistajia (jolloin ”itsetarkistuksen estämistoiminto” on käytössä). Tällä tavoin yksittäinen vaarantunut osallistujatili ei voi lähettää mielivaltaista koodia tuotantoon ilman jonkun toisen nimenomaista osallistumista.

Ole varovainen ympäristösääntöjen kanssa, jotka ovat riippuvaisia ​​​​itse käyttöönotoista (esimerkiksi ”edellytä käyttöönottojen onnistumista ennen tunnistepäivitysten sallimista”). Jos rakenne on huono, voit luoda kehäriippuvuuksia tai näennäiskontrolleja, jotka yhteistyökumppani voi ohittaa muokkaamalla työnkulkuja. Turvallisin malli on edelleen: vahva haarautumissuojaus → tarkasti rajatut ympäristöt → näiden ympäristöjen eksplisiittinen käyttö vain niissä vähimmäistehtävissä, jotka niitä todella tarvitsevat.

Juoksijoittajien hallinta: GitHubissa isännöity vs. itse isännöity

Juoksijat ovat koneita, jotka itse asiassa suorittavat työnkulkujasi.GitHubin isännöimät suorituspalvelimet ovat GitHubin hallinnoimia lyhytaikaisia ​​virtuaalikoneita; itse isännöidyt suorituspalvelimet ovat koneita tai säilöjä, joita sinä valmistelet ja hallitset.

GitHubin ylläpitämät suorituspalvelimet ovat yleensä oletusarvoisesti paljon turvallisempia:

• Ne ovat lyhytaikaisia ​​ja nollautuvat jokaista työtä varten, joten juoksujen välillä ei ole pysyvää kompromissia.
• GitHub julkaisee SBOM-tiedostoja vakiokuville (Ubuntu, Windows, macOS), jonka avulla voit analysoida esiasennettuja ohjelmistoja haavoittuvuuksien varalta.
• Tietyt haitalliset isännät estetään heti alkuunsa (esimerkiksi tunnetut kryptolouhintapoolet) kautta /etc/hosts kokoonpano.

Itseohjautuvat juoksijat ovat voimakkaita mutta vaarallisia jos et kohtele niitä kuin tuotantopalvelimia:

• Ne eivät yleensä ole lyhytaikaisia, ellet itse rakenna niitä, joten mikä tahansa haitallinen työnkulku voi yrittää jatkuvuutta, sivuttaisliikettä tai tietovarkautta.
• Heillä on usein laajempi verkkoyhteys ja paikallisia salaisuuksia (SSH-avaimet, pilvipohjaiset komentorivilinkit, metatietopalvelut), jotka nostavat minkä tahansa kompromissin panoksia.
• Julkisten arkistojen ei tulisi juuri koskaan käyttää itse isännöityjä suorittimia, koska kuka tahansa voi avata pull-pyynnön, joka lopulta suorittaa koodia infrastruktuurissasi.

Jos sinun on pakko käyttää itse isännöityjä juoksijoita, jaa ne luottamusrajojen mukaan.Käytä juoksijaryhmiä ja rajoituksia siten, että:

• Julkisilla ja yksityisillä hankkeilla ei koskaan ole samaa osallistujajoukkoa.
• Herkillä arkistoilla (esimerkiksi tuotantoinfrastruktuurilla) on omat tarkasti kontrolloidut juoksijansa.
• Vain tietyt tietovarastot tai organisaatiot voivat lähettää töitä tietylle ryhmälle.

Voit pienentää riskiä entisestään REST API:n kautta valmistelluilla just-in-time (JIT) -ajoprosesseilla.Nämä suoritusohjelmat rekisteröityvät dynaamisesti, suorittavat korkeintaan yhden työn ja poistetaan sitten automaattisesti. Sinun on silti varmistettava, että alla oleva isäntä puhdistetaan tai tuhotaan, mutta se kaventaa ikkunaa, jossa vaarantunut työ voi vaikuttaa seuraaviin töihin.

Käsittele itse isännöityjä juoksijoita kuten mitä tahansa muuta tuotantojärjestelmää: valvo prosessien toimintaa, lukitse lähtevät verkkoreitit, pidä käyttöjärjestelmä ja työkalut ajan tasalla ja oleta, että kaikilla käyttäjillä, joilla on oikeus käynnistää työnkulkuja, on tehokas koodin suorittaminen kyseisellä koneella.

Sisäänrakennetut turvaominaisuudet: koodin skannaus, tuloskortit ja Dependabot

GitHub tarjoaa useita ensiluokkaisia ​​ominaisuuksia, jotka on erityisesti tarkoitettu työnkulkuihin ja riippuvuuksiin liittyvien riskien havaitsemiseen.ja ne ovat pienten asennuskustannustensa arvoisia.

Koodin skannaus (esimerkiksi CodeQL:llä) voi nyt analysoida itse GitHub Actions -työnkulkuja, ei vain sovelluksesi lähdekoodia. Säännöt, kuten ”Liiallinen salaisuuksien paljastuminen”, voivat havaita kaavoja, joissa GitHub ei pysty määrittämään, mitkä salaisuudet vaaditaan (esimerkiksi dynaamiset secrets[myKey] käyttö matriisikoonnuksissa), mikä johtaa siihen, että se lataa työmuistiin enemmän salaisuuksia kuin on tarpeen.

OpenSSF-tuloskortit ja tuloskorttitoiminto lisäävät uuden tason luokittelemalla riippuvuuksiesi tietoturvatilanteenMarkkinapaikoilla tapahtuvien toimien osalta tuloskortit voivat merkitä toimitusketjun vaarallisia käytäntöjä, kuten:

• Ei kiinnitetä riippuvuuksia.
• Puuttuvat haarautumissuojaukset tai koodin tarkistusvaatimukset.
• Tietoturvapolitiikan tai haavoittuvuuksiin reagointiprosessien puute.

Dependabotilla on tässä kaksi roolia:

• Dependabot-hälytykset varoittaa sinua, kun toimintojesi tai työnkulkujesi riippuvuudessa on tunnettu haavoittuvuus GitHubin neuvoa-antavan tietokannan perusteella.
• Dependabot-versio ja tietoturvapäivitykset voi automaattisesti avata PR:iä korjauspäivityksiä varten ja korjata haavoittuvia julkaisuja.

Työnkulkujen riippuvuuskaavio on toinen aliarvostettu ominaisuusGitHub käsittelee työnkulkutiedostojasi manifesteinä ja voi näyttää sinulle:

• Mistä toiminnoista ja uudelleenkäytettävistä työnkuluista olet riippuvainen.
• Mitkä tilit tai organisaatiot omistavat ne.
• Mihin versioihin tai SHA-tiedostoihin olet kiinnittänyt tiedostot.

Tämä helpottaa vastaamista kysymyksiin, kuten "Missä käytämme tätä vaarannettua toimenpidettä?" kun uusia tiedotteita tulee, ja suunnitella laajamittaista korjaamista.

Seuranta, tarkastus ja hallinto

Tietoturva ei pääty konfigurointiin; tarvitset myös näkyvyyttä siihen, mitä ajan kuluessa tapahtuu.GitHub tarjoaa tarkastuslokeja ja tietoturvalokeja sekä käyttäjä- että organisaatiotasolla.

Toiminnan näkökulmasta on useita asioita, joita kannattaa seurata:

• Salaisuuksiin liittyvät tapahtumat, Kuten org.update_actions_secret tai tietovaraston salaisuuksien muutokset. Nämä osoittavat arkaluonteisten tunnistetietojen luomisen, päivittämisen tai poistamisen.
• Työnkulun ja sääntöjoukkojen muutokset: kuka muokkasi suojaussääntöjä, kuka muokkasi käyttöönottotyönkulkuja, kuka muutti ympäristön suojauksia.
• Uudet tai muokatut markkinapaikkatoiminnot ja GitHub-sovellukset asennettu organisaatioon, erityisesti ne, joille on myönnetty laajat tietovarasto- tai organisaatiokäyttöoikeudet.

Voit täydentää GitHubin omia hallintatoimintoja käytäntöjen valvontasovelluksilla, kuten OpenSSF:n Allstarilla., joka tarkistaa jatkuvasti, että tietovarastot ovat organisaatiosi tietoturvavaatimusten mukaisia ​​(haarasuojaukset, koodin skannauksen käyttöönotto, pakolliset tarkistukset jne.).

"Käynnissä olevien työnkulkujen" osalta pidä silmällä kaavoja, jotka saattavat viitata väärinkäyttöönepätavallisia piikkejä töiden suoritusajoissa, odottamatonta lähtevää liikennettä suorittajilta tai töitä, jotka usein epäonnistuvat salaisuuksia tai OIDC-tokeneja käsittelevien vaiheiden ympärillä. Nämä eivät aina ole haitallisia, mutta ne ovat hyviä paikkoja aloittaa tutkimukset.

Kaiken tämän yhdistäminen tarkoittaa GitHub Actionsin ajattelemista osana ydintoimintaympäristöäsi., ei vain "liimausskriptejä". Huolellisesti määritellyillä salaisuuksilla ja tokeneilla, tiukoilla haara- ja ympäristösuojauksilla, kolmansien osapuolten toimien varovaisella käytöllä, kovetetuilla suorittajilla ja jatkuvalla valvonnalla työkaluilla, kuten CodeQL, Scorecards ja Dependabot, annat organisaatiollesi mahdollisuuden torjua kasvavaa CI/CD- ja toimitusketjuhyökkäysten luokkaa, jotka kohdistuvat nimenomaisesti itse GitHub-työnkulkuihin.