Entegrasyona Berdewam û Belavkirina Berdewam (CI/CD) pipelineroleke girîng di hêsankirina pêşveçûna nermalava bilez de dilîzin. Lêbelê, ji ber ku ev pipelineher ku girîngtir dibin, pêwîstiya parastina wan ji lawaziyan bêtir diyar dibe. Ev lêkolîna kûr li ser çareserkirina rîskek berbiçav a ku di OWASP Top-10 de hatî destnîşankirin disekine. CI/CD Rîskên Ewlehiyê: Jehrkirî Pipeline Cihbicîhkirin (PPE).
Çi Jehrî ye Pipeline Cihbicîhkirin (PPE)
Li gorî OWASP Top-10 CI/CD "Rîskên Ewlehiyê,"Bi poz kirin Pipeline Birêverbirî (PPE) rîsk behsa şiyana êrîşkarekî bi gihîştina pergalên kontrola çavkaniyê - û bêyî gihîştina jîngeha avakirinê - dike. ji bo manîpulekirina pêvajoya avakirinê bi derzîkirina kod/fermanên zirardar di avakirinê de pipeline veguherîn, esas 'jehrkirin' pipeline û koda xerabkar wekî beşek ji pêvajoya avakirinê dixebitîne"
Bi çend gotinan, Jehrîkirî Pipeline Cihbicîhkirin (PPE) dema ku tê hilberandin tê hilberandin êrîşkar dikare wê biguherîne pipeline fêhm.
Du hene variants:
- PPE ya rasterast (D-PPE): Di senaryoyek D-PPE de, êrîşkar pelê mîhengê CI diguherîne di depoyekê de ku ew gihîştinê dibînin, an bi şandina guhertinê rasterast bo şaxek dûr a bêparastin li ser depoyê, an jî bi şandina PR-yek bi guhertinê re ji şaxek an forkekê. Ji dema CI ve pipeline bicîhanîn ji hêla fermanên di pelê mîhengê CI ya guhertî de tê destnîşankirin, fermanên xerabkar ên êrîşkar di dawiyê de di girêka avakirinê de dixebitin gava ku avakirin pipeline tê pêxistin.
- PPE ya nerasterast (I-PPE): Di hin rewşan de, îhtîmala D-PPE ji bo dijberê ku gihîştina wê heye tune ye. SCM depo (mînak heke pipeline ji bo kişandina pelê mîhengê CI ji şaxek cuda û parastî di heman depoyê de hatiye mîheng kirin). Di rewşeke wisa de, li şûna jehrîkirina pipeline êrîşkar koda xerabkar dixe nav pelên ku ji hêla pipeline (bo nimûne: skrîptên ku ji hundirê pipeline pelê mîhengkirinê)
Di herdu rewşan de, GitHub dê guherandî bicîh bîne pipeline bêyî hewcedariya nirxandin an pejirandina berê.
Tesbîtkirina zû ya PPE
Em çawa dikarin vê cureyê nexweşiyê tespît bikin?
Ka em vê mînakê bibînin pipeline :
Û naveroka skrîpteke shell a sexte (runtests.sh):
Ew pipeline pir hêsan e: armanca wê ew e ku ji bo nirxandinvan hin serişteyên pêşîn peyda bike. Pull Request (PR) pêvajoya pejirandinê:
- Ew ê li ser were çalakirin pull_request (ango her gava ku PR tê afirandin)
- Ew koda PR (ango koda beşdarbûyî) kontrol dike.
- Ew ê avakirinê çêbike
- Ew ê ceribandinan li ser koda beşdarbûyî bimeşîne (mînak bi pêkanîna skrîptek shell)
Gavên #3 (çêkirina avakirinê) û #4 (ceribandina ceribandinê) dê bi ser nekevin ger kod neyê berhevkirin an jî di ceribandinan de bi ser nekeve. Ji ber vê yekê, ev gav wekî şertek pêwîst, lê ne bes, ji bo qebûlkirina PR tevdigerin. Ger serkeftî be, rêveberê depoyê dê koda beşdarbûyî binirxîne û li gorî wê, ew ê PR qebûl bike/red bike/şîrove bike.
Skanera Xygeni
Xygeni CLI-yek peyda dike ("")Skanera Xygeni") ku dikare di nav de were bicîh kirin pipeline an jî di rêza fermanan de bixebitîne. Xygeni Scanner dê pêvajoyê bike pipelines ji bo kontrolkirina qelsiyan û, heke PAT-ya GitHub-ê were peyda kirin, ew ê bi GitHub-ê ve girêbide da ku qelsiyên di asta org/repo de kifş bike.
Envantera Xygeni
Dema ku em Xygeni Scanner li ser vê depoyê bicîh tînin, ew komek kêrhatî ya çavkaniyan kifş dike (ya Envantera XygeniEnvanter dê bi gelek celebên cûda yên CI/CD tiştan, wekî:
- Ew SCM Sîstem depo li ku tê hilanîn
- Ew SCM Plugins sazkirin/bikaranîn
- Ew Depoya Kodê xwe
- Ew SCM Sazûman depo aîdî ku ye
- Ew CI/CD Pipelines û Kar
- Ew CI/CD Sîstem dimeşîne pipelines
- IaC Çavkanî di depoyê de hatiye destnîşankirin
- Xûkirînî Zehmetiyên
- û ..
Di mînaka me de, em dikarin Envanterê li gorî hin celebê hebûnên taybetî fîltre bikin (SCM- û hebûnên têkildarî CICD), ji ber vê yekê em dikarin bibînin ku:
- SCM Sîstema GitHub Cloud e
- Repo di GitHub Cloud de tê hilanîn û aîdî rêxistinek taybetî ya GitHub e.
- Du hene pipelineji hêla GitHub ve tê xebitandin (CI/CD sîstem)
- Herkes pipeline gaveke taybetî dihewîne
Bi hilbijartina jorîn a pipeline em dikarin hin kêmasiyên cihêreng bibînin:
- At pipeline astê, ew ji her duyan re jî xeternak e Seranser û PPE ya nerasterast.
Em dikarin hûrguliyên wan kesên Jehrîbûyî bibînin Pipeline Lawaziyên bicîhanînê
Xygeni tesbît dike ku ew e ji bo D-PPE xeternak e ji ber ku ew li ser a çalak dibe Pull Request bûyer û kontrolên ewlehiyê yên zêde tune ne, ji ber vê yekê her bikarhênerek depoyê dikare biguherîne pipeline û ew guhertin bêyî ti nirxandin an pejirandinê dê werin bicîhanîn.
Bi heman awayî, Xygeni jî tesbît dike ku ew e ji bo I-PPE xeternak in ji ber gazîkirina skrîptê shell ji pipeline: her bikarhênerê depoyê dikare skrîptê shell biguherîne û ew guhertin bêyî nirxandin an pejirandinê dê werin bicîhanîn.
Ma hûn dixwazin bêtir bizanin?
Bikaranîna PPE
Ji bo sûdwergirtina ji PPE, em senaryoyekê bifikirin ku tê de hene du celeb bikarhênerên repoyê:
- An bikarhênerê navxweyî (pêşdebirê navxweyî yê ku li ser wê depoyê dixebite), bi destûrên nivîsandinê li ser depoyê
- An bikarhênerê derveyî (pêşdebirêkî derveyî ku li ser wê depoyê dixebite lê xwedî destûrên xwendinê li ser depoyê ye), ango destûr nayê dayîn ku depoyê şax bike û neçar e ku li ser forkekê bixebite.
Werin em xeyal bikin ku her du jî êrîşkarên xerabkar in (an jî ji hêla aktorekî xerabkar ve têne teqlîdkirin). Depo hin raz dihewîne û her du jî dixwazin ji bo dizîna sirra depoyê û wê bişînin serverek ku ji hêla hackeran ve tê kontrol kirin. Ji bo vê yekê, ew ê sûdê ji Jehrîbûnê werbigirin Pipeline Lawaziyên bicîhanînê yên pipeline.
Di her du rewşan de (bikarhênerê derveyî û navxweyî), ew vekirinek vedikin Pull Request bi heman guhertinan:
- Ew pipeline û skrîpta shellê têne guhertin ber sirrê bixwîne ji jîngehê û wê bişîne serverek ku ji hêla hackeran ve tê kontrolkirin
Guhertin dikarin wekî jêrîn bin:
Her du bikarhêner dê çêbikin Pull Request bi guhertinênDema avakirina PR, GitHub dê her du guhertinan bicîh bîne (bêyî ku hewcedariya nirxandin an pejirandina berê hebe), di encamê de ev tişt çêdibin:
Ji bo bikarhênerên nivîsandin û xwendinê jî heman tişt e, di her du rewşan de D-PPE û I-PPE têne bicîhanîn, bi wê cudahiyê ku bikarhênerê xwendî nikare bigihîje razên. (!!!!)
Sedem ev e ku, di rewşa PR-ê de ku ji forkekê tê, GitHub destûrê nade gihîştina razên depoyê. Her çend bikarhênerê xwendî nikaribe razên xwe bixwîne jî, ew hîn jî dikare her bernameyek din bixebitîne. Nimûneyek êrîşê ya tîpîk afirandina PR-an e ku madenek krîptoyê dakêşîne, ji ber vê yekê gerînerê GitHub-ê dê madenek krîptoyê dema ku jehrîkirinek pêk tîne bimeşîne. pipeline.
Bê guman, ev ne jîngehek ewle ye!! Ji bo ku jê dûr bikeve, rêveberê depoyê dikare çi bike?
Piştî hin lêgerînên li ser Google-ê, rêveberê depoyê biryar da ku biguherîne pipeline li ser were çalakkirin armanc_daxwaza_kişandinê bûyer. Çima? Ji ber ku pipelines li ser pull_request_target çalak dibin, destûrê nadin bicîhanînê pipeline guherandinan, ango tevî her guhertineke bikarhêner "orjînal" pipeline dê bên îdam kirin.
Piştî mînaka me, êrîş dê wekî berê be. Piştî vê yekê dê çi bibe? pipeline gûhertinî?
Wek hêvî D-PPE nayê bicîhanîn lê, ji ber ku I-PPE hîn jî li wir e, bikarhênerê xwendî niha dikare bigihîje sirra depoyê!!!
Sedema ku bikarhênerê xwendî niha gihîştina razên xwe heye çi ye? Her çend pipeline nayê guhertin, guhertina skrîpta qalikê hîn jî mimkun e. Dema ku pipeline li ser pull_request_target tê çalakkirin, ew ê di moda îmtiyazî de were bicîhanîn. so ew ê di heman demê de skrîpta shell be jî, di encamê de skrîpta shellê gihîştina razên depoyê heye!!
Pêvanîna Parastinê
GitHub hin tedbîran peyda dike da ku li dijî PR-ên xerab biparêze.
Rêgezên parastina şaxan
Bi GitHub hûn dikarin Qanûnên Parastina Şaxan li ser şaxên bijartî destnîşan bikin.
Ji bo şaxên xwe yên parastî, hûn dikarin polîtîkayekê diyar bikin ku hewce dike pull request berî yekbûnê (her wiha şertên zêde yên wekî hejmareke pêwîst a pejirandinan, nirxandinên ji xwediyên kodê, û hwd.)
Çend şertên ku hêjayî baldariyek taybetî ne ev in:
- "Destûrê bide aktorên diyarkirî ku pêwîst derbas bikin pull requests".
- "Destûrê nedin ku mîhengên jorîn werin derbaskirin"
Her çend piraniya mercan siyasetê hişktir dikin jî, ev yek siyasetê sist dike û dibe ku rê li ber çalakiyên xerab veke, bo nimûne, di rewşa ku nasname ji hêla aktorên "îmtiyazdar" ve werin dizîn.
Destûrên GITHUB_TOKEN sînordar bike (îmtiyaza herî kêm)
Destûrên nîşana GitHub tenê bi yên pêwîst sînordar bikin; bi vî rengî, heta di rewşekê de ku êrîşkar di xetereya we de biserkevin jî pipeline, ew ê nikaribin pir tiştî bikin.
Bi karanîna interpolasyona rêzan dûr bisekinin pipeline guherbarên env
Her gava ku hûn di nav xwe de hin guhêrbarên têketinê bikar tînin pipeline, hay ji xwe hebin ku divê ew bi xweber wekî daneyên "ne pêbawer" werin hesibandin (naveroka wan ji hêla bikarhênerê dawîn ve tê kontrol kirin). Binêre Çalakiyên Nepêbawer û Herikînên Kar ên Ewle û Çalakiyên Githubê hîn bibin.
Divê hûn her gav guherbarên jîngehê bikar bînin da ku guherbarên têketinê di hundurê skrîptan de têxin, li şûna ku hûn interpolasyona rêzikan bikar bînin.
Pêdiviyên pejirandinê û rêziknameyên herikîna kar
Bo alenî depoyan, GitHub destûrê dide diyarkirinê çawa bi PR-ên "derveyî" re bixebitin.
Mîhengên Rêxistina GitHub ("Org >> Mîheng >> Çalakî >> Giştî") dihêle ku diyar bikin ka meriv çawa PR-yên derveyî birêve dibe:
Bi xwerû, GitHub dê ji bo beşdarên cara yekem pejirandina PR bixwaze, ku êrîşên daxwazên xerab tevlihevtir dike. Dîsa jî, êrîşkar dikare baweriya parêzvanên projeyê bi dest bixe, mînakî bi beşdarbûna hin bêguneh. pull request berî êrîşa rastîn.
Di vê wateyê de, Vebijêrka 3yemîn (Pêdivî bi pejirandinê ji bo hemî hevkarên derve heye) astek bilindtir a kontrolê zêde dike.
Bo taybet depoyan, GitHub hem di asta rêxistinê de û hem jî di asta depoyê de kontrola kêrhatî peyda dike.
"Herikînên Kar ji Pull Requests"(bi xwerû nehatiye hilbijartin) dihêle ku bikarhêner herikên kar ji PR-yên fork bimeşînin (bi karanîna GITHUB_TOKEN-ek bi destûrên tenê xwendinê û bêyî gihîştina razên veşartî). Bi hilbijartina vê vebijarkê digel ya paşîn ("Ji bo herikînên kar ên PR-ên fork pejirandinê hewce bike"), hûn dikarin bigihîjin siyasetek dişibihe depoyên taybet (wek ku li jor tê nîşandan).
Wekî ku me di îstîsmara PPE-yê de ji bikarhênerek xwendî dît, destûrdayîna xebitandina herikên kar ji forkê pull requests ne ewle ye!!
Vebijarkên mayî ("Nîşaneyên nivîsandinê ji forkê ji bo herikên kar bişîne pull requests"Û"Veşartî û guherbaran ji bo herikên kar ji bo bişîne pull requests") asta ewlehiyê kêm bike ji bo PR-yên fork hatine sepandin.
Hûn dikarin vê polîtîkaya forkê li Asta Rêxistinê an jî li Asta Depoyê pênase bikin. Ger polîtîka li asta rêxistinê neçalak be, ew nikare li asta depoyê were çalak kirin. Lê, heke polîtîka li asta rêxistinê were çalak kirin, ew dikare li asta depoyê were neçalak kirin.
Ji bîr kirin
Em hêvî dikin ku we bandorên hin tiştan dîtine pipeline meyldarê Jehrbûnê Pipeline Cihbicîhkirin. Pir hêsan e ku commit kesekî bêparastin pipeline, û nivîsandina yekî ewle dijwar e.
Ji ber vê yekê pir bi qîmet e ku meriv Xygeni Scanner bikar bîne da ku ji van lawaziyan haydar be.
Heta ku hûn ji hebûna wê haydar nebin, hûn nekarin pirsgirêkeke vulnerabil çareser bikin!!
Lê… Pirsek hîn jî li bendê ye… Meriv çawa ji I-PPE dûr dikeve?
Ev ê mijara nivîsa me ya din be 🙂 … Jehrîbûna Nerasterast Pipeline Cihbicîhkirin (I-PPE) !!
