စဉ်ဆက်မပြတ် ပေါင်းစည်းခြင်းနှင့် စဉ်ဆက်မပြတ် ဖြန့်ကျက်ခြင်း (CI/CD) pipelineချောမွေ့သော ဆော့ဖ်ဝဲလ် ဖွံ့ဖြိုးတိုးတက်မှုကို လွယ်ကူချောမွေ့စေရာတွင် አዲስ အခန်းကဏ္ဍမှ ပါဝင်ပါသည်။ သို့သော်၊ ဤအရာများသည် pipelineအားနည်းချက်များသည် ပိုမိုအရေးကြီးလာသည်နှင့်အမျှ ၎င်းတို့ကို အားနည်းချက်များမှ ကာကွယ်ရန် မရှိမဖြစ်လိုအပ်ချက်သည် ပိုမိုထင်ရှားလာသည်။ ဤနက်ရှိုင်းသော စုံစမ်းစစ်ဆေးမှုသည် OWASP ထိပ်တန်း ၁၀ တွင် ဖော်ထုတ်ထားသော ထင်ရှားသောအန္တရာယ်တစ်ခုကို ဖြေရှင်းရန် အာရုံစိုက်သည်။ CI/CD လုံခြုံရေးအန္တရာယ်များ- အဆိပ်သင့်ခြင်း Pipeline အကောင်အထည်ဖော်မှု (PPE)။
ဘာကို အဆိပ်ခတ်ထားလဲ Pipeline အကောင်အထည်ဖော်မှု (PPE)
OWASP ထိပ်တန်း ၁၀ စာရင်းအရ CI/CD လုံခြုံရေးအန္တရာယ်များ"အဆိပ် Pipeline သတ်ခြင်း (PPE) အန္တရာယ်ဆိုသည်မှာ source control system များကို ဝင်ရောက်ခွင့်ရှိပြီး build environment ကို ဝင်ရောက်ခွင့်မရှိဘဲ attacker ၏ စွမ်းရည်ကို ရည်ညွှန်းသည်။ တည်ဆောက်မှုလုပ်ငန်းစဉ်ထဲသို့ အန္တရာယ်ရှိသော ကုဒ်/အမိန့်များကို ထိုးသွင်းခြင်းဖြင့် ခြယ်လှယ်ရန် pipeline configuration များမရှိမဖြစ်လိုအပ်ပါတယ်။ 'အဆိပ်ခတ်ခြင်း' pipeline နှင့် တည်ဆောက်မှုလုပ်ငန်းစဉ်၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် အန္တရာယ်ရှိသော ကုဒ်ကို လုပ်ဆောင်ခြင်း”
စကားအနည်းငယ်ပြောရရင် အဆိပ်သင့်သွားတယ် Pipeline အကောင်အထည်ဖော်မှု (PPE) ကို ထုတ်လုပ်သည့်အခါ တိုက်ခိုက်သူသည် ပြုပြင်နိုင်သည် pipeline တက္ဏဗေဒ.
နှစ်ခုရှိတယ် မျိုးကွဲ:
- တိုက်ရိုက် PPE (D-PPED-PPE အခြေအနေမှာ တိုက်ခိုက်သူသည် CI config ဖိုင်ကို ပြုပြင်မွမ်းမံသည်။ repository တစ်ခုမှာ သူတို့ဝင်ရောက်ခွင့်ရှိပါတယ်၊ repo ပေါ်က အကာအကွယ်မဲ့ remote branch ကို ပြောင်းလဲမှုကို တိုက်ရိုက် push လုပ်ခြင်းအားဖြင့်ဖြစ်စေ၊ branch ဒါမှမဟုတ် fork ကနေ ပြောင်းလဲမှုနဲ့အတူ PR ကို submit လုပ်ခြင်းအားဖြင့်ဖြစ်စေ။ CI ကတည်းက pipeline ပြုပြင်ထားသော CI configuration ဖိုင်ရှိ command များဖြင့် execution ကို သတ်မှတ်ပြီး၊ attacker ၏ malicious command များသည် build node တွင် နောက်ဆုံးတွင် run ပါသည်။ pipeline လှုံ့ဆော်ပေးပါသည်။
- သွယ်ဝိုက်သော PPE (I-PPE): အချို့သောကိစ္စများတွင်၊ D-PPE ဖြစ်နိုင်ခြေကို ဝင်ရောက်ခွင့်ရှိသော ရန်သူအတွက် မရရှိနိုင်ပါ။ SCM သိုလှောင်ရုံ (ဥပမာ အကယ်၍ pipeline တူညီသော repository ရှိ သီးခြား၊ ကာကွယ်ထားသော branch တစ်ခုမှ CI configuration file ကို ဆွဲယူရန် configure လုပ်ထားသည်)။ ဒီလိုအခြေအနေမျိုးမှာ အဆိပ်ခတ်မယ့်အစား pipeline တိုက်ခိုက်သူသည် ၎င်းကိုယ်တိုင်က ရည်ညွှန်းထားသော ဖိုင်များထဲသို့ အန္တရာယ်ရှိသော ကုဒ်ကို ထိုးသွင်းသည် pipeline (ဥပမာ- အတွင်းမှ ရည်ညွှန်းထားသော script များ pipeline ဖွဲ့စည်းပုံဖိုင်)
ဖြစ်ရပ်နှစ်ခုလုံးတွင် GitHub သည် ပြုပြင်ထားသောအရာကို လုပ်ဆောင်ပါမည် pipeline ယခင်ပြန်လည်သုံးသပ်ချက် သို့မဟုတ် အတည်ပြုချက် မလိုအပ်ဘဲ.
PPE ကို စောစီးစွာ သိရှိနိုင်ခြင်း
ဒီလို အားနည်းချက်မျိုးကို ဘယ်လို ရှာဖွေတွေ့ရှိနိုင်မလဲ။
ဒီဥပမာကိုကြည့်ရအောင် pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_SECRET
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.login }}" "${{ github.workflow }}"
echo Tests executed.
ပြီးတော့ dummy shell script (runtests.sh) ရဲ့ အကြောင်းအရာကတော့ -
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
အဆိုပါ pipeline အတော်လေးရိုးရှင်းပါတယ်- ၎င်း၏ရည်ရွယ်ချက်မှာ ပြန်လည်သုံးသပ်သူအား ကနဦးအရိပ်အမြွက်အချို့ပေးရန်ဖြစ်သည် Pull Request (PR) လက်ခံမှုလုပ်ငန်းစဉ်-
- ၎င်းကို စတင်ဖွင့်ပေးပါမည် တောင်းဆိုချက်_ဆွဲယူခြင်း (ဆိုလိုသည်မှာ PR တစ်ခု ဖန်တီးတိုင်း)
- ၎င်းသည် PR ကုဒ် (ဆိုလိုသည်မှာ ပံ့ပိုးထားသော ကုဒ်) ကို စစ်ဆေးသည်။
- တည်ဆောက်မှုကို ဖြစ်စေလိမ့်မယ်
- ၎င်းသည် ပံ့ပိုးပေးထားသော ကုဒ်များတွင် စမ်းသပ်မှုများကို လုပ်ဆောင်ပါမည် (ဥပမာ shell script တစ်ခုကို လုပ်ဆောင်ခြင်းဖြင့်)
အဆင့် #၃ (တည်ဆောက်မှုပြုလုပ်ပါ) နှင့် #၄ (စမ်းသပ်မှုလုပ်ဆောင်ပါ) သည် ကုဒ်သည် စုစည်းမှုမပြုလုပ်ပါက သို့မဟုတ် စမ်းသပ်မှုများကို မအောင်မြင်ပါက မအောင်မြင်ပါ။ ထို့ကြောင့် ဤအဆင့်များသည် PR ကိုလက်ခံရန် လိုအပ်သော်လည်း လုံလောက်သောအခြေအနေမဟုတ်ပါ။ အောင်မြင်ပါက repo admin သည် ပံ့ပိုးပေးထားသော ကုဒ်ကို ပြန်လည်သုံးသပ်ရန် ဆက်လက်လုပ်ဆောင်မည်ဖြစ်ပြီး ထိုအပေါ်အခြေခံ၍ သူ/သူမသည် PR ကို လက်ခံ/ငြင်းပယ်/မှတ်ချက်ပေးမည်ဖြစ်သည်။
Xygeni စကင်နာ
ဆိုက်ဂျီနီ CLI တစ်ခု ("Xygeni စကင်နာ") ထဲသို့ ထည့်သွင်းနိုင်သော pipeline သို့မဟုတ် command-line တွင် run ပါ။ Xygeni Scanner သည် ၎င်းကို လုပ်ဆောင်ပေးလိမ့်မည် pipelineအားနည်းချက်များကို စစ်ဆေးရန်ဖြစ်ပြီး GitHub PAT ပေးထားပါက org/repo အဆင့်ရှိ အားနည်းချက်များကို ရှာဖွေရန် GitHub သို့ ချိတ်ဆက်လိမ့်မည်။
Xygeni စာရင်း
ဒီ repo မှာ Xygeni Scanner ကို execute လုပ်တဲ့အခါ အသုံးဝင်တဲ့ assets တွေကို ရှာဖွေတွေ့ရှိပါတယ် (the) Xygeni စာရင်း)။ စာရင်းတွင် အမျိုးအစားများစွာဖြင့် ဖြည့်သွင်းထားမည်ဖြစ်သည် CI/CD ပိုင်ဆိုင်မှု, ကဲ့သို့:
- အဆိုပါ SCM စံနစ် repo ကိုဘယ်မှာသိမ်းဆည်းထားလဲ
- အဆိုပါ SCM plugins တွေကို တပ်ဆင်ထား/အသုံးပြုပြီး
- အဆိုပါ Code Repository သူ့ဟာသူ
- အဆိုပါ SCM အဖှဲ့အစညျး repo က ဘယ်မှာလဲ
- အဆိုပါ CI/CD Pipelines နှင့် အလုပ်အကိုင်များ
- အဆိုပါ CI/CD စံနစ် ကို run pipelines
- IaC အရင်းအမြစ်များ repo မှာ သတ်မှတ်ထားတဲ့
- ပြင်ပ မှီခို
- စသည်တို့ ..
ကျွန်ုပ်တို့၏ ဥပမာတွင်၊ ကျွန်ုပ်တို့သည် Inventory ကို သတ်မှတ်ထားသော ပိုင်ဆိုင်မှုအမျိုးအစားအချို့ဖြင့် filter လုပ်နိုင်သည် (SCM- နှင့် CICD နှင့် ဆက်စပ်သော ပိုင်ဆိုင်မှုများ)၊ ထို့ကြောင့် ကျွန်ုပ်တို့ မြင်နိုင်သည်မှာ-
- SCM စနစ်က GitHub Cloud ပါ
- Repo ကို GitHub Cloud တွင်သိမ်းဆည်းထားပြီး သတ်မှတ်ထားသော GitHub အဖွဲ့အစည်းနှင့်သက်ဆိုင်သည်
- နှစ်ခုရှိတယ် pipelineGitHub မှ ပံ့ပိုးပေးသည် (CI/CD စနစ်)
- တိုင်း pipeline သီးခြားအဆင့်တစ်ခု ပါဝင်သည်
အထက်ပါအတိုင်း ရွေးချယ်ခြင်းဖြင့် pipeline အားနည်းချက်အချို့ကို ကျွန်ုပ်တို့ မြင်တွေ့နိုင်ပါသည်-
- At pipeline အဆင့်၊ နှစ်မျိုးလုံးအတွက် အားနည်းချက်ရှိသည် တိုက်ရိုက် နှင့် သွယ်ဝိုက်သော PPE။
အဆိပ်သင့်သူတွေရဲ့ အသေးစိတ်အချက်အလက်တွေကို ကျွန်တော်တို့ မြင်နိုင်ပါတယ် Pipeline အကောင်အထည်ဖော်မှု အားနည်းချက်များ
Xygeni က ဒါကို ထောက်လှမ်းမိပြီး D-PPE ကို ခံနိုင်ရည်မရှိသူများ ဘာဖြစ်လို့လဲဆိုတော့ ၎င်းကို တစ်ခုမှာ လှုံ့ဆော်ပေးလို့ပါပဲ Pull Request event ဖြစ်ပြီး နောက်ထပ်လုံခြုံရေးထိန်းချုပ်မှုများ မရှိသောကြောင့် repo အသုံးပြုသူတိုင်းသည် ၎င်းကို ပြင်ဆင်နိုင်သည်။ pipeline ထို့အပြင် ထိုပြုပြင်မွမ်းမံမှုများကို မည်သည့်ပြန်လည်သုံးသပ်ချက် သို့မဟုတ် ခွင့်ပြုချက်မျှမပါဘဲ လုပ်ဆောင်သွားမည်ဖြစ်သည်။
တူညီတဲ့သဘောအရ၊ Xygeni ကလည်း ၎င်းဟာ I-PPE ကို ခံနိုင်ရည်မရှိသူများ shell script ကို ခေါ်ယူမှုကြောင့် pipeline: မည်သည့် repo အသုံးပြုသူမဆို shell script ကို ပြင်ဆင်နိုင်ပြီး ထိုပြင်ဆင်မှုများကို မည်သည့်ပြန်လည်သုံးသပ်မှု သို့မဟုတ် အတည်ပြုချက်မှ မပါဘဲ လုပ်ဆောင်မည်ဖြစ်သည်။
သင်ပိုမိုသိရှိလိုပါသလား။
PPE ကို အသုံးချခြင်း
PPE ကို အသုံးချဖို့အတွက် အောက်ပါအခြေအနေတွေကို စဉ်းစားကြည့်ရအောင်။ repo အသုံးပြုသူနှစ်မျိုး:
- An အတွင်းပိုင်းအသုံးပြုသူ (ထို repo တွင် လုပ်ဆောင်နေသော အတွင်းပိုင်း developer တစ်ဦး)၊ repo တွင် ရေးသားခွင့်ပြုချက်များဖြင့်
- An ပြင်ပအသုံးပြုသူ (repo မှာ အလုပ်လုပ်နေပေမယ့် repo ကို ဖတ်ရှုခွင့်ရှိတဲ့ outsourced developer တစ်ယောက်)၊ ဆိုလိုတာက repo ကို branch လုပ်ခွင့်မရှိပဲ fork မှာ အလုပ်လုပ်ခိုင်းတာမျိုး။
နှစ်ယောက်စလုံးဟာ အန္တရာယ်ရှိတဲ့ တိုက်ခိုက်သူတွေ (ဒါမှမဟုတ် အန္တရာယ်ရှိတဲ့ လုပ်ရပ်တစ်ခုရဲ့ အယောင်ဆောင်သူ) ဖြစ်တယ်လို့ မြင်ယောင်ကြည့်ရအောင်။ repo မှာ လျှို့ဝှက်ချက်တချို့ ပါဝင်ပြီး နှစ်ယောက်စလုံးက repo လျှို့ဝှက်ချက်ကို ခိုးယူရန် ပြီးတော့ ဟက်ကာထိန်းချုပ်ထားတဲ့ ဆာဗာကို ပို့ပါ။ ဒါကိုလုပ်ဖို့အတွက် သူတို့ဟာ Poisoned ကို အခွင့်ကောင်းယူကြလိမ့်မယ်။ Pipeline အကောင်အထည်ဖော်မှု အားနည်းချက်များ pipeline.
နှစ်ခုစလုံးသောကိစ္စများတွင် (ပြင်ပနှင့် အတွင်းပိုင်းအသုံးပြုသူ)၊ ၎င်းတို့သည် ဖွင့်လှစ်သည် Pull Request တူညီသောပြုပြင်မွမ်းမံမှုများနှင့်အတူ-
- အဆိုပါ pipeline နှင့် shell script ကို ပြုပြင်ထားသည် သို့ လျှို့ဝှက်ချက်ကိုဖတ်ပါ ပတ်ဝန်းကျင်နှင့် ဟက်ကာထိန်းချုပ်ထားသော server သို့ပို့ပါ
ပြုပြင်မွမ်းမံမှုများသည် အောက်ပါအတိုင်းဖြစ်နိုင်သည်။
အသုံးပြုသူနှစ်ဦးစလုံးက ဖန်တီးကြလိမ့်မယ် Pull Request ပြုပြင်မွမ်းမံမှုများနှင့်အတူPR ဖန်တီးပြီးသည်နှင့် GitHub သည် ပြုပြင်မွမ်းမံမှုနှစ်ခုလုံးကို လုပ်ဆောင်ပါမည် (ယခင်ပြန်လည်သုံးသပ်ခြင်း သို့မဟုတ် အတည်ပြုချက် မလိုအပ်ပါ)၊ ရလဒ်အနေဖြင့် အောက်ပါအတိုင်းဖြစ်သည်-
ရေးသားသူနှင့် ဖတ်ရှုသူများအတွက်လည်း အတူတူပင်ဖြစ်သည်၊ နှစ်ခုစလုံးတွင် D-PPE နှင့် I-PPE ကို လုပ်ဆောင်သည်, ထိုကွာခြားချက်နှင့်အတူ ဖတ်ပြီးသော အသုံးပြုသူသည် လျှို့ဝှက်ချက်များကို ဝင်ရောက်ကြည့်ရှု၍မရပါ။ (!!!!)
ဒီအကြောင်းပြချက်က ဘာလို့လဲဆိုတော့၊ PR တစ်ခုသည် fork မှလာသည့်ကိစ္စတွင် GitHub သည် repo လျှို့ဝှက်ချက်များကို ဝင်ရောက်ကြည့်ရှုခွင့်မပြုပါ။ ဖတ်ပြီးသားအသုံးပြုသူသည် လျှို့ဝှက်ချက်များကို မဖတ်နိုင်သော်လည်း သူ/သူမသည် အခြားပရိုဂရမ်များကို လည်ပတ်နိုင်ဆဲဖြစ်သည်။ ပုံမှန်တိုက်ခိုက်မှုဥပမာတစ်ခုမှာ crypto miner တစ်ခုကို ဒေါင်းလုဒ်လုပ်သည့် PR များဖန်တီးခြင်းဖြစ်ပြီး၊ ထို့ကြောင့် GitHub runner သည် poisoned တစ်ခုကို လည်ပတ်သည့်အခါ crypto miner ကို execute လုပ်လိမ့်မည်။ pipeline.
ဒါက ဘေးကင်းတဲ့ပတ်ဝန်းကျင်တော့ မဟုတ်ဘူးပေါ့!! ဒါကိုရှောင်ရှားဖို့ repo admin ဘာလုပ်မလဲ။
Google မှာ ရှာကြည့်ပြီးတဲ့နောက် repo admin က ပြင်ဆင်ဖို့ ဆုံးဖြတ်လိုက်တယ်။ pipeline ပေါ်တွင် လှုံ့ဆော်ရန် pull_request_target ဖြစ်ရပ်။ ဘာကြောင့်လဲ။ ဘာလို့လဲဆိုတော့ pipelinepull_request_target မှာ trigger လုပ်ထားတဲ့ s တွေက execute လုပ်ခွင့်မပေးပါဘူး။ pipeline ပြုပြင်မွမ်းမံဆိုလိုသည်မှာ အသုံးပြုသူမှ မည်သည့်ပြုပြင်မွမ်းမံမှုမျှ ပြုလုပ်ထားသော်လည်း "မူရင်း" pipeline ကွပ်မျက်ခံရလိမ့်မည်။
ကျွန်ုပ်တို့ရဲ့ ဥပမာကို လိုက်လုပ်မယ်ဆိုရင် တိုက်ခိုက်မှုက အရင်လိုပဲ ဖြစ်ပါလိမ့်မယ်။ ဒီနောက်မှာ ဘာတွေဆက်ဖြစ်မလဲ။ pipeline ပြုပြင်မွမ်းမံခြင်း?
မျှော်လင့်ထားသည့်အတိုင်း D-PPE ကို မလုပ်ဆောင်ပါ ဒါပေမယ့် I-PPE ရှိနေသေးတဲ့အတွက် ဖတ်ပြီးသား အသုံးပြုသူဟာ repo လျှို့ဝှက်ချက်ကို ဝင်ရောက်ကြည့်ရှုနိုင်ပါပြီ။
ဖတ်ရှုသူဟာ လျှို့ဝှက်ချက်တွေကို ဘာကြောင့် ဝင်ရောက်ကြည့်ရှုနိုင်တာလဲ။ pipeline ပြင်ဆင်၍မရပါ၊ shell script ကို ပြင်ဆင်နိုင်ဆဲဖြစ်သည်။ အခါ pipeline pull_request_target မှာ trigger လုပ်ရင် privileged mode မှာ execute လုပ်ပါလိမ့်မယ်။ so ၎င်းသည် shell script လည်းဖြစ်လိမ့်မည်ရလဒ်အနေနဲ့ shell script ဟာ repo လျှို့ဝှက်ချက်တွေကို ဝင်ရောက်ကြည့်ရှုနိုင်စေပါတယ်။
ကြိုတင်ကာကွယ်မှုဆောင်ရွက်ချက်များ
GitHub သည် အန္တရာယ်ရှိသော PR များမှကာကွယ်ရန် အစီအမံအချို့ကို ပေးဆောင်သည်။
ဌာနခွဲကာကွယ်စောင့်ရှောက်ရေးစည်းမျဉ်းများ
GitHub မှာ ရွေးချယ်ထားတဲ့ branch တွေမှာ Branch Protection Rules တွေကို သတ်မှတ်နိုင်ပါတယ်။
သင့်ရဲ့ ကာကွယ်ထားတဲ့ ဌာနခွဲတွေအတွက်၊ သင်ဟာ မူဝါဒတစ်ခုကို သတ်မှတ်နိုင်ပါတယ်။ လိုအပ်သည် pull request ပေါင်းစည်းခြင်းမပြုမီ (လိုအပ်သော အတည်ပြုချက်အရေအတွက်၊ ကုဒ်ပိုင်ရှင်များထံမှ သုံးသပ်ချက်များ စသည်တို့ကဲ့သို့သော အပိုဆောင်းအခြေအနေများအပြင်)
အထူးစဉ်းစားသင့်သော အခြေအနေအချို့မှာ-
- "သတ်မှတ်ထားသော သရုပ်ဆောင်များကို လိုအပ်သည်များကို ကျော်သွားရန် ခွင့်ပြုပါ pull requests"။
- "အထက်ပါဆက်တင်များကို ကျော်ဖြတ်ခွင့်မပြုပါနှင့်"
အခြေအနေအများစုသည် မူဝါဒကို တင်းကျပ်စွာ ထည့်သွင်းပေးသော်လည်း၊ ဤအခြေအနေများသည် မူဝါဒကို ဖြေလျှော့ပေးပြီး “အခွင့်ထူးခံ” လှုပ်ရှားသူများက အထောက်အထားများကို ခိုးယူသည့်အခါတွင် မကောင်းသော လုပ်ဆောင်ချက်များအတွက် တံခါးဖွင့်ပေးသလို ဖြစ်စေနိုင်သည်။
GITHUB_TOKEN ခွင့်ပြုချက်များကို ကန့်သတ်ပါ (အနည်းဆုံး အခွင့်ထူး)
GitHub token permission များကို လိုအပ်သော permission များအတွက်သာ ကန့်သတ်ပါ။ ဤနည်းအားဖြင့် တိုက်ခိုက်သူများသည် သင့်လုံခြုံရေးကို ထိခိုက်အောင် လုပ်ဆောင်နိုင်ခဲ့သည့်တိုင် pipeline, သူတို့ ဘာမှ သိပ်လုပ်နိုင်မှာ မဟုတ်ဘူး။
အသုံးပြုခြင်းဖြင့် string interpolation ကို ရှောင်ရှားပါ pipeline env variable များ
သင့်ရဲ့ input variable အချို့ကို အသုံးပြုတဲ့အခါတိုင်း pipeline၎င်းတို့ကို မူရင်းအားဖြင့် "မယုံကြည်ရသော" ဒေတာအဖြစ် သတ်မှတ်သင့်ကြောင်း သတိပြုပါ (၎င်းတို့၏ အကြောင်းအရာကို အသုံးပြုသူမှ ထိန်းချုပ်ထားသည်)။ ကြည့်ပါ။ မယုံကြည်ရသော လုပ်ဆောင်ချက်များနှင့် လုပ်ငန်းလည်ပတ်မှုများ လုံခြုံပါသည် နှင့် Github လုပ်ဆောင်ချက်များကို လေ့လာပါ။
string interpolation ကိုသုံးမယ့်အစား script တွေထဲမှာ input variable တွေထည့်ဖို့အတွက် environment variable တွေကို အမြဲသုံးသင့်ပါတယ်။
လုပ်ငန်းလည်ပတ်မှုနှင့် ခွင့်ပြုချက်လိုအပ်ချက်များ
ဘို့ အများပြည်သူ repos များ၊ GitHub သည် သတ်မှတ်ရန် ခွင့်ပြုသည် “ပြင်ပ” PR များနှင့် မည်သို့အလုပ်လုပ်ရမည်နည်း.
GitHub Organization settings (“Org >> Settings >> Actions >> General”) သည် ပြင်ပ PR များကို မည်သို့စီမံခန့်ခွဲရမည်ကို သတ်မှတ်ပေးပါသည်။
မူရင်းအားဖြင့် GitHub သည် ပထမဆုံးအကြိမ် ပံ့ပိုးကူညီသူများအတွက် PR ခွင့်ပြုချက် လိုအပ်မည်ဖြစ်ပြီး၊ ၎င်းသည် malicious request တိုက်ခိုက်မှုများကို ပိုမိုရှုပ်ထွေးစေသည်။ ထိုသို့ပင်၊ တိုက်ခိုက်သူသည် ပရောဂျက်ထိန်းသိမ်းသူများ၏ ယုံကြည်မှုကို ရရှိနိုင်သည်၊ ဥပမာအားဖြင့်၊ အပြစ်ကင်းသော အချက်အလက်များကို ပံ့ပိုးကူညီခြင်းဖြင့် pull request တကယ့်တိုက်ခိုက်မှုမတိုင်ခင်။
ဤသဘောအရ၊ တတိယရွေးချယ်မှု (ပြင်ပပူးပေါင်းဆောင်ရွက်သူအားလုံး၏ ခွင့်ပြုချက်လိုအပ်ခြင်း) သည် ပိုမိုမြင့်မားသောထိန်းချုပ်မှုအဆင့်ကို ထည့်သွင်းပေးသည်။
ဘို့ ကိုယ်ပိုင် repos များတွင်၊ GitHub သည် အဖွဲ့အစည်းနှင့် Repo အဆင့် နှစ်မျိုးလုံးတွင် အထောက်အကူဖြစ်စေသော ထိန်းချုပ်မှုကိုလည်း ပေးပါသည်။
"Workflow များကို စတင်ပါ Pull Requests” (default အနေနဲ့ check မလုပ်ထားပါဘူး) က user တွေကို fork PR တွေကနေ workflow တွေကို run ခွင့်ပြုပါတယ် (GITHUB_TOKEN ကို read-only permissions နဲ့ secrets တွေကို access မလုပ်ဘဲ)။ ဒီ option ကို နောက်ဆုံး option နဲ့ တွဲပြီး ရွေးချယ်ခြင်းအားဖြင့် (“fork PR workflow များအတွက် ခွင့်ပြုချက် လိုအပ်သည်”)၊ အထက်တွင်ပြထားသည့်အတိုင်း ပုဂ္ဂလိက repos များနှင့် အလားတူမူဝါဒကို သင်ရရှိနိုင်သည်။
PPE exploit မှာ ကျွန်တော်တို့ မြင်တွေ့ခဲ့ရတဲ့အတိုင်း user တစ်ယောက်ရဲ့ read ကနေ၊ fork မှ workflow များကို လုပ်ဆောင်ခွင့်ပြုခြင်း pull requests မလုံခြုံဘူး!!
ကျန်ရှိသော ရွေးချယ်စရာများ ("fork မှ workflow များသို့ write token များပို့ပါ pull requests"နှင့်"for မှ workflow များသို့ လျှို့ဝှက်ချက်များနှင့် variable များပေးပို့ပါ pull requests") လုံခြုံရေးအဆင့်ကို လျှော့ချပါ fork PR များတွင် အသုံးပြုခဲ့သည်။
ဒီ fork မူဝါဒကို Organization Level ဒါမှမဟုတ် Repo-level မှာ သတ်မှတ်နိုင်ပါတယ်။ မူဝါဒကို org-level မှာ ပိတ်ထားရင် repo level မှာ ဖွင့်လို့မရပါဘူး။ ဒါပေမယ့် မူဝါဒကို org-level မှာ ဖွင့်ထားရင် repo-level မှာ ပိတ်လို့ရပါတယ်။
ပြန်လည်စုစည်းမှု
သင်အချို့ရှိခြင်းရဲ့ အကျိုးဆက်တွေကို မြင်တွေ့ပြီးပြီလို့ မျှော်လင့်ပါတယ် pipeline အဆိပ်သင့်လွယ်သော Pipeline ကွပ်မျက်ခြင်း။ အလွန်လွယ်ကူလွန်းသည် commit အားနည်းသူ pipelineပြီးတော့ ဘေးကင်းတဲ့ တစ်ခုကို ရေးဖို့ ခက်ခဲပါတယ်။
ဒါကြောင့် ဒီလို အားနည်းချက်တွေကို သိရှိနိုင်ဖို့ Xygeni Scanner ကို အသုံးပြုဖို့ အလွန်တန်ဖိုးရှိပါတယ်။
vuln ရှိနေမှန်း မသိရင် vuln ကို ဖြေရှင်းလို့ မရပါဘူး။
ဒါပေမယ့်... မေးခွန်းတစ်ခု ကျန်နေသေးတယ်... I-PPE ကို ဘယ်လိုရှောင်ရှားမလဲ။
ဒါက ကျွန်တော်တို့ရဲ့ နောက်ပို့စ်ရဲ့ အကြောင်းအရာ ဖြစ်လိမ့်မယ် 🙂 … သွယ်ဝိုက်၍ အဆိပ်သင့်ခြင်း Pipeline အကောင်အထည်ဖော်မှု (I-PPE) !!
