ဒါက အပိုင်းတစ်ပိုင်းထဲက တတိယမြောက် အပိုင်းပါ ဆောင်းပါးတွဲများ အဖြစ်အများဆုံး ဆော့ဖ်ဝဲလ် ထောက်ပံ့ရေးကွင်းဆက် တိုက်ခိုက်မှုအမျိုးအစားများအကြောင်း- အများပြည်သူမှတ်ပုံတင်ခြင်းကို အလွဲသုံးစားပြုသည့် တိုက်ခိုက်မှုများ open-source ဆော့ဖ်ဝဲလ် အစိတ်အပိုင်းများ။ ယခင်ဇာတ်လမ်းတွဲတွင် ခွဲခြမ်းစိတ်ဖြာပြီးနောက် "အန္တရာယ်ရှိသော အထုပ်များ၏ ခန္ဓာဗေဒ- ခေတ်ရေစီးကြောင်းများကား အဘယ်နည်း။"မကောင်းတဲ့သရုပ်ဆောင်တွေက ထုတ်ဝေထားတဲ့ အစိတ်အပိုင်းအသစ်တွေ ဒါမှမဟုတ် ရှိပြီးသား အစိတ်အပိုင်းတွေထဲကို အန္တရာယ်ရှိတဲ့အပြုအမူတွေ ဘယ်လိုထည့်သွင်းသလဲဆိုတာကို ကြည့်ရင်၊ မီးသတ်ဝတ်စုံတွေ ဝတ်ဆင်ပြီး ဒီလိုနည်းနဲ့ ပေးပို့တဲ့ အန္တရာယ်ရှိတဲ့ဆော့ဖ်ဝဲကို ဘယ်လိုအောင်မြင်စွာ ပိတ်ဆို့နိုင်မလဲ၊ ဒါမှမဟုတ် ကျွန်တော်တို့ မှားယွင်းတဲ့ချဉ်းကပ်မှုကြောင့် ဖြစ်နိုင်ခြေရှိတဲ့ ပြင်းထန်တဲ့ဆိုက်ဘာဖြစ်ရပ်တစ်ခုကို ဘယ်လိုကိုင်တွယ်ဖြေရှင်းနိုင်မလဲဆိုတာကို စစ်ဆေးဖို့ အသင့်ဖြစ်နေပါပြီ။"
လုံခြုံရေးကို သတိထားတဲ့ ပညာရှင်အများစုမှာ ဒီခြိမ်းခြောက်မှုကို ဘယ်လိုကိုင်တွယ်ရမလဲဆိုတဲ့ အကြံဥာဏ်တွေ ရှိပါတယ်။ လုံခြုံရေးမန်နေဂျာတွေက တွန့်ဆုတ်ခြင်းမရှိဘဲ ပြောနေတာကို ကျွန်တော်တို့ ကြားဖူးပါတယ်- SCA tools တွေက package version တစ်ခုဟာ malware ဖြစ်တဲ့အခါ သင့်ကို ပြောပြပြီးသားပါ။ ဒါမှမဟုတ် သူတို့ဟာ လူသိများပြီး အဆင့်မြင့်သုံးသပ်ထားတဲ့ software components တွေပေါ်မှာ မူတည်ပြီး malware တွေကို ချက်ချင်းရှာဖွေတွေ့ရှိပြီး ဖယ်ရှားပစ်နိုင်ပါတယ်။ သူတို့ဟာ vulnerability fix တွေကို အလိုအလျောက်ရရှိဖို့အတွက် open minor/patch version တွေကို အသုံးပြုပြီး open source dependencies တွေအပေါ် အန္တရာယ်ကို လျှော့ချဖို့ အကြံပြုထားတဲ့ နည်းလမ်းဖြစ်ပါတယ်၊ “စောစောပြင်ပါ၊ မကြာခဏပြင်ပါ” နိယာမ။
ဒီအပိုင်းမှာ ဒီအတွေးအခေါ်တွေ ဘာကြောင့်မှားတာလဲ၊ ဒီလိုအထင်အမြင်လွဲမှားမှုတွေက ဒီတိုက်ခိုက်မှုယန္တရားရဲ့ ရေပန်းစားမှုကို ဘယ်လိုအထောက်အကူပြုနေလဲ၊ အဖွဲ့အစည်းတွေ ကြုံတွေ့နေရတဲ့ ကြီးမားတဲ့အန္တရာယ်ကို ဘယ်လိုအထောက်အကူပြုနေလဲဆိုတာကို ပြန်လည်သုံးသပ်သွားပါမယ်။ ဘာတွေအလုပ်ဖြစ်လဲ၊ ဘယ်ဟာက ပါဝင်ပတ်သက်တဲ့ အားထုတ်မှုနဲ့ အရင်းအမြစ်တွေနဲ့ အဆုံးသတ်ပါမယ်။
အဖြစ်များသောအယူအဆများ
ဆော့ဖ်ဝဲလုံခြုံရေးနဲ့ ပတ်သက်တဲ့ ကျွန်ုပ်တို့ရဲ့ ခရီးစဉ်အတွင်းမှာ တိုက်ခိုက်မှုနည်းစနစ်တွေ တိုးတက်ပြောင်းလဲလာတာနဲ့ လုံခြုံရေးကို သတိထားတဲ့သူတွေဆီကနေ ကျယ်ပြန့်တဲ့ အတွေးအခေါ်တွေကို မြင်တွေ့ခဲ့ရပါတယ်။ အဖွဲ့အစည်းတွေဟာ ဒီခြိမ်းခြောက်မှုကို ဘယ်လိုကာကွယ်ရမလဲဆိုတာကို မကြာခဏ အထင်လွဲတတ်ကြတာကြောင့် အရင်ဆုံး ဘာတွေက အလုပ်မလုပ်ဘူးဆိုတာကို စစ်ဆေးကြည့်ပါမယ်။ အဲဒီအထဲမှာ အပြည့်အစုံမဟုတ်ဘဲ အောက်ပါ အထင်အမြင်လွဲမှားမှုစာရင်းကို အကျဉ်းချုပ်ဖော်ပြထားပါတယ်။
အထင်အမြင်လွဲမှားမှု နံပါတ် ၁- SCA tools များသည် malicious component များကို report လုပ်ပြီးသားဖြစ်သည်။
တကယ်ပါပဲ! ဒါပေမယ့် အမှန်တရားပြီးနောက်… ဆော့ဖ်ဝဲလ်တည်ဆောက်မှုတွင် element ကို အသုံးပြုပြီး မကောင်းသောသရုပ်ဆောင်များသည် developer သို့မဟုတ် developer တွင် ခြေကုပ်ယူထားပြီးဖြစ်လျှင် အချိန်နှောင်းသွားဖွယ်ရှိသောအခါ CI/CD host။ လျှို့ဝှက်ချက်များကို ထုတ်ယူပြီးဖြစ်နိုင်သလို၊ malware များကို ထပ်မံဒေါင်းလုဒ်လုပ်ပြီး ထည့်သွင်းပြီးဖြစ်နိုင်သလို၊ ရန်သူသည် ဘေးတိုက်ရွေ့လျားပြီး အခြားနေရာသို့ ဝင်ရောက်နိုင်ပြီလည်း ဖြစ်နိုင်သည်။
ဆော့ဖ်ဝဲလ် ဖွဲ့စည်းမှု ခွဲခြမ်းစိတ်ဖြာခြင်း (SCA) tools များကို ဖြစ်နိုင်ချေရှိသော အားနည်းချက်များကို ဖော်ထုတ်ရန် ဒီဇိုင်းထုတ်ထားသည်။ ခေတ်မီ tools များသည် signal-noise ratio ကို မြှင့်တင်ခြင်းဖြင့်၊ အားနည်းချက်သည် အမှန်တကယ် ရောက်ရှိနိုင်သည် သို့မဟုတ် အသုံးချနိုင်သည်ကို ဆုံးဖြတ်ခြင်းဖြင့် အလွန်ကောင်းမွန်သော အလုပ်တစ်ခုကို လုပ်ဆောင်သည်။ သို့သော် ၎င်းတို့သည် malware အသစ်များကို ဆန့်ကျင်ရာတွင် အသုံးမဝင်ပါ။ malicious component တစ်ခုကို zero-day vulnerability အဖြစ် မှတ်ယူပါ- ၎င်း၏ malicious အပြုအမူကို တွေ့ရှိမှသာ component ကို holding registry သို့ အစီရင်ခံပြီး လုံခြုံရေးအဖွဲ့မှ ပြန်လည်သုံးသပ်ပြီးနောက် malicious အဖြစ် အတည်ပြုပြီး registry မှ ဖယ်ရှားသည်။ [1].
အဲဒီအချိန်မှာ ကမ္ဘာကြီး (အပါအဝင်) SCAs) component (သို့မဟုတ် ရှိပြီးသား component ၏ version(များ) ကို install လုပ်ခြင်း သို့မဟုတ် အသုံးပြုခြင်းသည် ကောင်းသောအရာမဟုတ်ကြောင်း သိရှိသည်။ သို့သော် ဤအခြေအနေသည် component ကို registry မှ မရရှိနိုင်သည့်အခါဖြစ်သည်။ပြင်ပ component တွေမှာ အားနည်းချက်တွေရှိတယ်ဆိုတာ သိရတာကောင်းပါတယ်၊ ဒါမှမဟုတ် registry မှာ အန္တရာယ်ရှိတဲ့ component အဖြစ် အမျိုးအစားခွဲခြားထားတဲ့ component တွေတောင် SCA သို့မဟုတ် အသုံးများသော စာရင်းစစ်ကိရိယာများသည် ဤအခြေအနေတွင် အကူအညီမပေးပါ။ မဟုတ်ရင် SCA/audit tool သည် သင့်အဖွဲ့အစည်းတွင် အသုံးမပြုမီ component တစ်ခုသည် အန္တရာယ်ရှိသော component ဖြစ်ကြောင်း ကြိုတင်သိရှိနိုင်သည်။.
မှတ်ထားပါ၊ အန္တရာယ်ရှိသော open-source component များကို တိုက်ဖျက်သည့် မည်သည့်ဖြေရှင်းချက်မဆို ၎င်းတို့ကို ထောက်လှမ်းရမည် လေယာဉ်ပျံcomponent ကို registry မှာ ထုတ်ဝေတဲ့အချိန်နဲ့ component (version) ကို သင့်အဖွဲ့အစည်းမှာ ပထမဆုံးအသုံးပြုတဲ့အချိန်ကြားကာလကြားမှာပါ။ အဲဒီထဲမှာ transitive component တွေလည်း ပါဝင်ပါတယ်။
မှားယွင်းသောအယူအဆ #၂: တည်ဆောက်ချိန်တွင် ထည့်သွင်းမှု script များကို ထိန်းချုပ်ခြင်းသည် open-source component များမှ အန္တရာယ်ရှိသောအပြုအမူကို ကာကွယ်ပေးသည်
package manager အမျိုးမျိုးသည် script များကို run လုပ်နိုင်စွမ်းကို ပေးစွမ်းသည် (component tarball တွင်ပါဝင်သော) [2]), မတူညီသောပလက်ဖောင်းများတွင် လိုအပ်သောပစ္စည်းများကို စုစည်းခြင်း၊ ကုဒ်ထုတ်လုပ်ခြင်း သို့မဟုတ် စမ်းသပ်မှုများကို လုပ်ဆောင်ခြင်းကဲ့သို့သော တရားဝင်အကြောင်းပြချက်များအတွက်ဖြစ်ပြီး၊ tarball တွင် malicious script များပါဝင်ပါက သို့မဟုတ် attacker သည် ကောင်းမွန်သော script အစား malicious script ကို run စေနိုင်ပါက မကောင်းသောလုပ်ဆောင်သူများက ၎င်းတို့ကို အလွဲသုံးစားလုပ်နိုင်ကြောင်း ကျွန်ုပ်တို့အားလုံးသိသင့်သည်။
ဒါကိုသိရင် package manager ကို script တွေကို လျစ်လျူရှုဖို့ configure လုပ်နိုင်ပါတယ်။ ဥပမာ NPM နဲ့ဆိုရင် –လျစ်လျူရှု-scripts flag (သို့မဟုတ် configuration property တစ်ခု .npmrc file) သည် install လုပ်နေစဉ်အတွင်း script များကို ကျော်သွားပါသည်။ script များကို run ခြင်းသည် ecosystem အများအပြားတွင် အဖြစ်များသောကြောင့် ၎င်းသည် ပြဿနာအချို့ကို ဖြစ်ပေါ်စေနိုင်သည်- အချို့ package manager များသည် script execution ကို disable လုပ်ခြင်းကိုပင် ခွင့်မပြုပါ (အရိပ်အမြွက်- prompt “ဘယ် package manager တွေက install script တွေရဲ့ execution ကို disable မလုပ်ခွင့်ပေးထားလဲ။"သင်အကြိုက်ဆုံး AI မှာ)။ ဒါပေမယ့် ဒါက ယေဘုယျအားဖြင့် ကာကွယ်မှုမပေးပါဘူး (skip disable configuration က နေရာတိုင်းမှာရှိတယ်ဆိုတာ ကျွန်တော်တို့ ပြဋ္ဌာန်းဖို့ လိုအပ်ပါတယ်)။
ပြီးတော့ အန္တရာယ်ရှိတဲ့ အပြုအမူဟာ install scripts တွေမှာ မဟုတ်ဘဲ runtime မှာ execute လုပ်မယ့် software မှာ ရှိနေတဲ့အခါ ဒီ option တစ်ခုတည်းနဲ့ ကျွန်ုပ်တို့ကို မကာကွယ်နိုင်ပါဘူး။
မှားယွင်းသောအယူအဆ #၃: ဗားရှင်း pinning သည် အန္တရာယ်ရှိသော အစိတ်အပိုင်းများကို ထည့်သွင်းခြင်းမှ တားဆီးပေးသည်
အစောပိုင်းနှင့် မကြာခဏ ပြင်ဆင်ခြင်းကြားတွင် အပေးအယူတစ်ခုရှိသည် ပွင့်လင်းသောဗားရှင်းများ (လုံခြုံရေးပြင်ဆင်မှုများအတွက် ရရှိနိုင်သည့်အခါ package manager အား အပ်ဒိတ်အသစ်များကို အလိုအလျောက်ထည့်သွင်းရန် ခွင့်ပြုခြင်း) နှင့် ဗားရှင်းပင်ထိုးခြင်း (fixed version မှာ software အတွက် direct နဲ့ transitive dependencies အားလုံးရှိခြင်း)။ လုံခြုံရေးမူတွေက “စောစောပြင်ဆင်၊ မကြာခဏပြင်ဆင်” တဲ့အခါလို ခေါင်းမာပြီး တစ်ခါတစ်ရံ ဆန့်ကျင်ဘက်ဖြစ်နေတတ်ပါတယ်။ "အဆင့်မြှင့်တင်ခြင်းကို ပေါ့ပေါ့တန်တန် သဘောမထားသင့်ပါ"။ အချို့သော package manager များသည် အကြံပြုထားသည့်အတိုင်း server range များဖြင့် အလိုအလျောက် update များကို ပြုလုပ်ကြသည်။ သင်သည် malicious update များကိုလည်း လက်ခံရယူလိုပါက အလွန်ကောင်းမွန်ပါသည်။ ဟုတ်ကဲ့၊ အားနည်းချက်များကို အမြန်ဆုံးပိတ်ပေးသည့် လုံခြုံရေးပြင်ဆင်မှုများကို လက်ခံရယူရန် components များကို အပ်ဒိတ်လုပ်ရမည်ဖြစ်သော်လည်း … package manager ကို ဤသို့ အလိုအလျောက်လုပ်ဆောင်ခွင့်မပြုပါနှင့်။
မှားယွင်းသောအယူအဆ #၄: ယုံကြည်စိတ်ချရသော အစိတ်အပိုင်းများကို အသုံးပြုခြင်းသည် ဘေးကင်းပါသည်။ မည်သည့်အန္တရာယ်ရှိသော ဗားရှင်းကိုမဆို ချက်ချင်းတွေ့ရှိ၊ ထုတ်ဖော်ပြီး ဖယ်ရှားပစ်မည်ဖြစ်သည်။
အစိတ်အပိုင်းတစ်ခုဟာ ဘာကြောင့် ယုံကြည်စိတ်ချရသလဲ။ ဖြစ်နိုင်ခြေရှိတာက ၎င်းသည် အလွန်ရေပန်းစားသောကြောင့်ဖြစ်ပြီး၊ မျက်လုံးများစွာက အားနည်းချက်များကို ရှာဖွေနေကြသောကြောင့်၊ ပြုပြင်ထိန်းသိမ်းမှုအတွက် ပံ့ပိုးကူညီသူအများအပြားရှိသောကြောင့်၊ အားလုံးကို ဂရုတစိုက် ပြန်လည်သုံးသပ်သော core ပြုပြင်ထိန်းသိမ်းသူများစွာရှိသောကြောင့် ဖြစ်နိုင်သည်။ pull requestsလက်တွေ့အခြေအနေကတော့ အတော်လေး ကွဲပြားပါတယ်။ အရေးကြီးတဲ့ အစိတ်အပိုင်းအချို့ကို အခကြေးငွေမယူတဲ့ developer တစ်ဦးတည်းက ထိန်းသိမ်းထားပါတယ်။ ကျယ်ကျယ်ပြန့်ပြန့် အသုံးပြုနေတဲ့ framework တွေကတော့ ပုံမှန်အလှူရှင်အနည်းငယ်အရေအတွက် လျင်မြန်စွာ လျော့နည်းလာခြင်းနှင့်အတူ commitပြုပြင်ထိန်းသိမ်းသူတစ်ဦးချင်းစီအတွက် s (လူကြိုက်များသော ပရောဂျက်များတွင် drive-by အချို့လုပ်ဆောင်သော ပံ့ပိုးကူညီသူများ၏ ရှည်လျားသောအမြီးရှိသည်) commit ပြီးတော့ ဘယ်တော့မှ ပြန်မလာတော့ဘူး)။ ပြီးတော့ ပြုပြင်ထိန်းသိမ်းသူ တစ်ဦးတည်းနဲ့ လူကြိုက်များတဲ့ ပရောဂျက်တွေ အများကြီးရှိပါတယ်။
မင်းကိုယ်မင်း စိတ်ကူးနဲ့ ပြောကြည့်ပါ "အိုး၊ ကျွန်တော်တို့က Spring Boot / Angular / React / PyTorch / official base Docker image တွေကို သုံးနေတာဆိုတော့ ခင်ဗျားပြောနေတဲ့ အန္တရာယ်က အတော်လေးနည်းပါတယ်။" အဲဒါ မှန်ကောင်းမှန်နိုင်ပါတယ်၊ ကျွန်တော်တို့ လုံခြုံရေး ရောင်းချသူတွေက အမြဲတမ်း ကြောက်လန့်အောင် လုပ်နေကြတာဖြစ်ပြီး၊ အငြင်းပွားဖွယ်ရာ အန္တရာယ်ကို လျှော့ချဖို့ ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့တွေကို ဝင်ရောက်စွက်ဖက်တာက အဓိပ္ပာယ်မရှိပါဘူး။ အန္တရာယ်လက်ခံခြင်း စာပိုဒ် (နောက်အပိုင်းမှာ) ကို ခုန်တက်ပြီး အားလုံးပြီးသွားချင်လာနိုင်ပါတယ်။ ကံမကောင်းစွာပဲ၊ အလွန်ရေပန်းစားတဲ့ အစိတ်အပိုင်းတွေက မကောင်းတဲ့သူတွေရဲ့ ပစ်မှတ်တွေဖြစ်ပြီး၊ ဥပမာအားဖြင့်၊ လူကြိုက်များတဲ့ PyTorch စာကြည့်တိုက်ကို တိုက်ခိုက်ခံခဲ့ရသည် ယခင်တုန်းက။
"ချက်ချင်းတွေ့ရှိ၊ ထုတ်ဖော်ပြီး ဖယ်ရှားပစ်သည်"။ အများပြည်သူမှတ်ပုံတင်ခြင်းမှ အန္တရာယ်ရှိသော အစိတ်အပိုင်းအသစ်တစ်ခုကို ဖယ်ရှားရန် ရက်ပေါင်းများစွာ ကြာပါသည်။ မှတ်ပုံတင်များသည် အစိတ်အပိုင်းဗားရှင်းတစ်ခုကို ဖယ်ရှားရာတွင် ကောင်းကျိုးအတွက် သတိထားကြသည်။ ကျွန်ုပ်တို့၏အတွေ့အကြုံအရ ကျွန်ုပ်တို့ဘက်မှ အစီရင်ခံပြီးသည်နှင့် မှတ်ပုံတင်မှ ထိခိုက်နေသော ဗားရှင်းကို ဖယ်ရှားရန် ပျမ်းမျှအချိန်သည် ၃၉ နာရီဖြစ်ပြီး တစ်ရက်ခွဲကျော်ကြာပါသည်။ မှတ်ပုံတင်တွင် ကျွန်ုပ်တို့၏ ကနဦးအစီရင်ခံပြီးနောက် တစ်ပတ်အကြာတွင် ဖယ်ရှားခြင်းမပြုမီ အန္တရာယ်ရှိသော အစိတ်အပိုင်းများ ရှိပါသည်။ အချို့ကိစ္စများတွင်၊ သားကောင် သို့မဟုတ် ဖြစ်ရပ်တုံ့ပြန်မှုကုမ္ပဏီတစ်ခုမှ အစိတ်အပိုင်းပါဝင်သည့် ဖြစ်ရပ်တစ်ခုကို အစီရင်ခံပြီးမှသာ အစိတ်အပိုင်းကို ဖယ်ရှားပါသည်။
ဘာက အန္တရာယ်ရှိတဲ့ အစိတ်အပိုင်းတွေကို တားဆီးလို့မရတာလဲ
တိကျမှုမရှိသော ချဉ်းကပ်မှုတိုင်းသည် အလွန်ဆိုးရွားစွာ ကျရှုံးလိမ့်မည်။ ဤသည်မှာ သေချာပါသည်၊ ဤခြိမ်းခြောက်မှုနှင့် ဆက်စပ်နေသော အန္တရာယ်အတွက် ထိရောက်သော တန်ပြန်အစီအမံများကို သင်မပေးဆောင်ပါ။
ရိုးရာ SCA tools များသည် သိရှိထားသော malware များအကြောင်း သင့်အား ပြောပြသော်လည်း ထိတွေ့မှုကာလ ကြီးမားသည်။ ၎င်းတို့သည် malware ထောက်လှမ်းမှုကို ကြိုတင်လုပ်ဆောင်ခြင်းမရှိပါက၊ ၎င်းတို့သည် အန္တရာယ်ရှိသော အစိတ်အပိုင်းများကို အတင်းအကြပ်ပိတ်ဆို့ခြင်းဖြင့် လုပ်ဆောင်မည်မဟုတ်ပါ။
installation scripts တွေကို disable လုပ်တာက အထောက်အကူဖြစ်နိုင်ပေမယ့် component တစ်ခုကို install လုပ်ရမယ့်နေရာတိုင်းမှာ enforce လုပ်ဖို့လိုပါတယ်။ version pinning မှာလည်း အတူတူပါပဲ၊ ဘာလို့လဲဆိုတော့ version တွေကို safe initial state ကနေ ထာဝရ pin လုပ်လို့မရလို့ပါ။
ပျက်စီးဆုံးရှုံးမှုများကို ကာကွယ်ရန် ချက်ချင်းနီးပါး ထောက်လှမ်းမှုမရှိဘဲ ထောက်ပံ့ရေးကွင်းဆက်တိုက်ခိုက်မှုတွင် မရည်ရွယ်ဘဲ အပြုအမူများ ထည့်သွင်း၍မရဟု ယူဆခြင်းသည် ရိုးရှင်းပြီး အန္တရာယ်များပါသည်။ သင်သည် အစွန်းတွင် နေထိုင်လိုမည်မဟုတ်ပါ၊ မဟုတ်လား။
ဒီအချိန်မှာ ရပ်လိုက်ရင် အန္တရာယ်လက်ခံခြင်း မင်းလုပ်နိုင်တဲ့ တစ်ခုတည်းသောအရာက ဒါပါcisသင်၏ ခြိမ်းခြောက်မှုပုံစံ/အန္တရာယ်အကဲဖြတ်ချက်တွင် မှတ်တမ်းတင်ရန် လိုအပ်သော အချက်များထဲတွင် အန္တရာယ်ကို လက်ခံရန် အကြောင်းပြချက်နှင့် ၎င်း၏ အလားအလာရှိသော သက်ရောက်မှုများ ပါဝင်သည်။ ၎င်းကို စီမံခန့်ခွဲမှုနှင့် အခြားသက်ဆိုင်ရာ အဖွဲ့အစည်းများသို့ အသိပေးခြင်းဖြင့် အသိပညာပေးပါ။ အချို့ အရေးပေါ် အန္တရာယ်ရှိတဲ့ အစိတ်အပိုင်းတစ်ခုကို သင့်ဆော့ဖ်ဝဲထဲမှာ ထည့်သွင်းထားတဲ့အခါ ဒါမှမဟုတ် ထည့်သွင်းထားတဲ့အခါ စီစဉ်ထားနိုင်ပေမယ့် တိုက်ခိုက်သူတွေမှာ လိုက်နာရမယ့် လမ်းကြောင်းတွေ အများကြီးရှိတာကြောင့် ဒါက ခက်ခဲပါတယ်။ အန္တရာယ်ရှိတဲ့ အစိတ်အပိုင်းတစ်ခုကို အသုံးပြုမှုကို အခြေခံတဲ့ ထောက်ပံ့ရေးကွင်းဆက်တိုက်ခိုက်မှုရဲ့ အသေးစိတ်အချက်အလက်တွေက သင့်အဖွဲ့အစည်းရဲ့ စည်းမျဉ်းစည်းကမ်းဘောင်အောက်မှာ မဖြစ်မနေလိုအပ်တဲ့ ဖြစ်ရပ်ရဲ့ အများပြည်သူကို ထုတ်ဖော်မှုကို သိသိသာသာ ပြောင်းလဲစေပါလိမ့်မယ်။ သင်လည်း ကိုင်တွယ်ဖြေရှင်းနိုင်ပါတယ် လျော်ကြေးပေးခြင်းထိန်းချုပ်မှုများ or လွှဲပြောင်းမှုအန္တရာယ် ဥပမာ အာမခံနှင့်အတူ။
သို့သော်၊ ခြိမ်းခြောက်မှုကို ကိုင်တွယ်ဖြေရှင်းသည့် ထိန်းချုပ်မှုများရှိပြီး အန္တရာယ်လက်ခံခြင်းနှင့် သင်ကျေနပ်မှုမရှိပါက ထည့်သွင်းစဉ်းစားသင့်သည်။ ဆက်လက်ဖတ်ရှုပါ။
Malicious Components တွေကို အသုံးပြုပြီး တိုက်ခိုက်မှုတွေကို ဘာက တားဆီးပေးသလဲ။
ဗားရှင်းတစ်ခုလုံးကို ကိုင်တွယ်ခြင်း
ထိန်းချုပ်ထားပြီး သတင်းအချက်အလက်အပြည့်အစုံပါဝင်သော ဗားရှင်းတိုးတက်မှုများဖြင့် ဗားရှင်းကို pinning လုပ်ခြင်းသည် malware မရရှိဘဲ အားနည်းချက်များကို ဖယ်ရှားရန် လိုအပ်ချက်ကို ဟန်ချက်ညီစေရန် လုပ်ဆောင်ရမည့် နည်းလမ်းဖြစ်သည်။ သို့သော် အထင်အမြင်လွဲမှားမှု #၃ ကို သတိရပါ- ဗားရှင်း pinning တစ်ခုတည်းဖြင့် ဗားရှင်းအသစ်များမှ လာသော အန္တရာယ်ရှိသော ကုဒ်များကို ပိတ်ဆို့ရန် မလုံလောက်ပါ၊ အဘယ်ကြောင့်ဆိုသော် အနာဂတ်တွင် တိုက်ရိုက် သို့မဟုတ် သွယ်ဝိုက်သော မှီခိုမှုဖြင့် ဗားရှင်းများကို အပ်ဒိတ်လုပ်ရန် လိုအပ်သောကြောင့်ဖြစ်သည်။ ထိုအချိန်တွင် ပြုပြင်ထားသော ဗားရှင်းအားလုံးတွင် malware မပါဝင်ကြောင်း လုံလောက်သော အထောက်အထားများ လိုအပ်ပါသည်။
အစောပိုင်းသတိပေးချက်
အန္တရာယ်ရှိတဲ့ အစိတ်အပိုင်းတွေရဲ့ ပြဿနာကို ဖြေရှင်းဖို့ ချဉ်းကပ်မှုတစ်ခုကတော့ ကြိုတင်သတိပေးစနစ် (ဒီမှာ ... လို့ ခေါ်ပါတယ်) တစ်ခုပါပဲ။ မဲလ်ဝဲကြိုတင်သတိပေးချက် သို့မဟုတ် MEW)၊ ထုတ်ဝေထားသော ဗားရှင်းအသစ်များ (အစိတ်အပိုင်းအသစ်များ သို့မဟုတ် ရှိပြီးသား အစိတ်အပိုင်းများအတွက်) ကို ထောက်လှမ်းအင်ဂျင်ဖြင့် ခွဲခြမ်းစိတ်ဖြာသည့်နေရာတွင်၊ လုံလောက်သော အထောက်အထားများ တွေ့ရှိသည့်အခါ ဗားရှင်းအသစ်ကို အန္တရာယ်ရှိနိုင်သော အရာအဖြစ် အမျိုးအစားခွဲခြားနိုင်သည်။
လက်ရှိထုတ်ဝေမှုနှုန်းထားအရ အစိတ်အပိုင်းအသစ်အားလုံးကို ကိုယ်တိုင်ပြန်လည်သုံးသပ်ရန် မဖြစ်နိုင်သောကြောင့် အလိုအလျောက်လုပ်ဆောင်ခြင်းသည် ဤနေရာတွင် အရေးကြီးပါသည်။ ထို့ကြောင့် detection engine သည် static၊ dynamic နှင့် capability analysis၊ user reputation နှင့် component metadata နှင့် tarball contents များအကြား ကွဲလွဲမှုများမှ ထွက်ပေါ်လာသော အထောက်အထားများ သို့မဟုတ် tarball နှင့် component လာသည်ဟု ယူဆရသည့် source repository အကြား အပါအဝင် နည်းပညာအမျိုးမျိုးကို ပေါင်းစပ်ရန် လိုအပ်ပါသည်။
တစ်ဦးရှိပါတယ် မှောင်မိုက်ဇုန် ထုတ်ဝေချိန်နှင့် အင်ဂျင်မှ အစိတ်အပိုင်းပါဝင်ပစ္စည်းများကို ခွဲခြမ်းစိတ်ဖြာသည့်အချိန်ကြားတွင်၊ သို့သော် မိနစ်အနည်းငယ်ထက် မပိုသင့်ပါ။ စနစ်ကို ပြုပြင်နိုင်သည်၊ ဥပမာအားဖြင့် ဆော့ဖ်ဝဲတည်ဆောက်မှုတွင် ထည့်သွင်းအသုံးပြုခွင့်မပြုမီ အစိတ်အပိုင်းအသစ်များကို ခွဲခြမ်းစိတ်ဖြာရန် စောင့်ဆိုင်းခြင်းဖြင့်။ pipelines များ သို့မဟုတ် လိုအပ်သည့်အခါတွင် ၎င်းတို့ကို ခွဲခြမ်းစိတ်ဖြာပါ။ ပေးထားသော ဗားရှင်းတစ်ခုရှိ အစိတ်အပိုင်းတစ်ခုသည် မပြောင်းလဲနိုင်သော အစိတ်အပိုင်းတစ်ခုဖြစ်သည်။ [3]ထို့ကြောင့် ၎င်းကို တစ်ကြိမ်သာ ခွဲခြမ်းစိတ်ဖြာရန် လိုအပ်ပါသည်။
အပြည့်အဝ အလိုအလျောက်လုပ်ဆောင်ခြင်း မဖြစ်နိုင်ပါ၊ ထို့ကြောင့် အန္တရာယ်ရှိနိုင်သော အစိတ်အပိုင်းများအတွက် လုံခြုံရေး ပြန်လည်သုံးသပ်ချက် လိုအပ်ပါသည်။ ဒစ်ဂျစ်တယ် ဆေးဝါးများကို ထောက်ခံသူများကို သတိပြုပါ။သံသယဖြစ်ဖွယ် အစိတ်အပိုင်းတစ်ခုတွင် malware ရှိမရှိ အတည်ပြုရာတွင် AI နှင့် Machine Learning တို့သည် နောက်ဆုံးစကားလုံးကို ရယူနိုင်လောက်အောင် ဖွံ့ဖြိုးပြီးမဟုတ်ပါ။ စက်သင်ယူမှုသည် ထောက်လှမ်းအင်ဂျင်တွင် ဖမ်းယူထားသော raw evidence များမှ input component ကို အမျိုးအစားခွဲခြားရာတွင် အဓိကအခန်းကဏ္ဍမှ ပါဝင်သည်မှာ သေချာပါသည်၊ သို့သော် component ကို "quarantined" လုပ်ပြီးသည်နှင့် နောက်ဆုံးစကားလုံးသည် malicious component များတွင် အတွေ့အကြုံရှိသော လုံခြုံရေးအဖွဲ့မှ manual review တွင် ရှိနေသည်။ ၎င်းသည် မည်သည့် malware ဖြစ်နိုင်ခြေကိုမဆို အတည်ပြုခြင်း သို့မဟုတ် ၎င်းကို ဘေးကင်းသည်ဟု ပြန်လည်အမျိုးအစားခွဲခြားသည်။ အချိန်ကာလသည် နာရီအပိုင်းအခြားအတွင်း ဖြစ်သည်။
မှတ်ပုံတင်ရုံးသည် အန္တရာယ်ရှိသော ဗားရှင်း/အစိတ်အပိုင်းကို အစီရင်ခံပြီး အတည်ပြုရန် ၎င်း၏ ပြန်လည်သုံးသပ်မှုကို လုပ်ဆောင်ကာ အများပြည်သူသို့ ထုတ်ဖော်ခြင်းနှင့် မှတ်ပုံတင်ရုံးမှ ဖယ်ရှားခြင်းတို့ကို ဆက်လက်လုပ်ဆောင်သည်။ အချို့သော မှတ်ပုံတင်ရုံးများသည် လုံခြုံရေး သိမ်းဆည်းထားသော အထုပ်ကို သိမ်းဆည်းထားသည်။ ဤနေရာတွင် အချိန်အပိုင်းအခြားမှာ ထုတ်ဝေပြီးကတည်းက ရက်များ သို့မဟုတ် ရက်သတ္တပတ်များဖြစ်ပြီး၊ ၎င်းသည် 'အချိန်နေပါ'သို့မဟုတ်' 'ထိတွေ့မှု ပြတင်းပေါက်' အန္တရာယ်ရှိတဲ့ အစိတ်အပိုင်းအများစုအတွက်။
component version တစ်ခုဟာ အန္တရာယ်ရှိလားဆိုတာ သိနိုင်ပါသလား။
ဒါကြောင့် အစောပိုင်းသတိပေးမှုအတွက် ဒီမေးခွန်းအတွက် ကျေနပ်လောက်တဲ့အဖြေတစ်ခု ပေးဖို့ လိုအပ်ပါတယ်- စာကြည့်တိုက် ဒါမှမဟုတ် ပက်ကေ့ဂျ်တစ်ခုဟာ အန္တရာယ်ရှိတယ်ဆိုတာ ဘယ်လိုသိနိုင်မလဲ။ အန္တရာယ်ရှိတဲ့အပြုအမူရဲ့ လုံလောက်တဲ့အထောက်အထားကို ဘယ်လိုစုဆောင်းမလဲ။ ဖြစ်နိုင်ပေမယ့် ခက်ခဲပါတယ်၊ ဘာလို့လဲဆိုတော့ ရန်သူတွေက ထောက်လှမ်းမှုကို ရှောင်ရှားဖို့ ဉာဏ်ပညာအများကြီးသုံးကြလို့ပါ။ ချဉ်းကပ်နည်းအမျိုးမျိုးရှိပြီး တစ်ခုချင်းစီမှာ အားသာချက်နဲ့ အားနည်းချက်တွေ ရှိပါတယ်။
အငြိမ်မနေ component ကို run ခြင်းမပြုဘဲ attacker များအသုံးပြုသော techniques များကိုစစ်ဆေးပြီး de-obfuscation သို့မဟုတ် deciphering ကဲ့သို့သော preprocessing task များကိုလုပ်ဆောင်နိုင်သည်။ attacker များသည် ၎င်းတို့၏ မကောင်းမှုများကို ဖုံးကွယ်ရန်ကြိုးစားသောအခါ၊ obfuscation ကြိုးပမ်းမှုများသည် malware ၏ အထောက်အထားများဖြစ်သည် (သို့သော် တရားဝင် component များသည် ဉာဏပစ္စည်းမူပိုင်ခွင့်ကို ထိန်းသိမ်းရန်အတွက် code ကို obfuscate လုပ်သည်ကို သတိပြုပါ၊ "open source ဖြစ်ပြီး”)။ ပြင်းထန်သော မှုန်ဝါးဝါးဖြစ်စေသော အလွန်ရှုပ်ထွေးသော တိုက်ခိုက်မှုအနည်းငယ်သာ sandboxing လိုအပ်သော်လည်း၊ ထိုကဲ့သို့သော ပြင်းထန်သော မှုန်ဝါးဝါးဖြစ်စေခြင်းသည် မကောင်းသောအကြံအစည်၏ လက္ခဏာတစ်ရပ်ဖြစ်သည်။ ရိုးရာအစဉ်အလာကို ကျေးဇူးပြု၍ သတိပြုပါ SAST tool များကို backdoor များကဲ့သို့သော မကောင်းသောရည်ရွယ်ချက်အတွက် မဟုတ်ဘဲ မရည်ရွယ်ဘဲ အားနည်းချက်များအတွက် ဒီဇိုင်းထုတ်ထားသည်။
တက်ကြွစွာ ခွဲခြမ်းစိတ်ဖြာခြင်း။ အစိတ်အပိုင်းကို လည်ပတ်စေပြီး runtime ကို တိုင်းတာခြင်းဖြင့် တုံ့ပြန်မှုကို စစ်ဆေးသည်၊ ပုံမှန်အားဖြင့် sandboxed environment ကို ပံ့ပိုးပေးသည်။ အချို့သောအခြေအနေများအောက်တွင် လှုံ့ဆော်ပေးသော အန္တရာယ်ရှိသော အပြုအမူသည် မတွေ့ရှိဘဲ သွားနိုင်သည်- malware သည် အောက်ပါကဲ့သို့သော ရှောင်ရှားရေးနည်းပညာများကို အသုံးပြုနိုင်ကြောင်း ကျေးဇူးပြု၍ သတိပြုပါ။ Virtualization/Sandbox ရှောင်တိမ်းမှု စစ်ဆေးမှုမရှိသည့်အခါတွင်သာ အသက်ဝင်စေရန်နှင့် မည်သည့် static analysis engine အတွက်မဆို အန္တရာယ်ရှိသော လုပ်ဆောင်ချက်၏ လက္ခဏာတစ်ရပ်လည်း ဖြစ်သည်။
စွမ်းရည်များ ခွဲခြမ်းစိတ်ဖြာခြင်း component တစ်ခု လုပ်ဆောင်သည့်အရာကို ထည့်သွင်းစဉ်းစားသည်- ၎င်းချိတ်ဆက်သည့်နေရာ၊ မည်သည့်ဖိုင်များကို ဝင်ရောက်ကြည့်ရှုသည်၊ မည်သည့် command များ သို့မဟုတ် program များကို run သည်၊ terminal သို့မဟုတ် device I/O ကို လုပ်ဆောင်သည် သို့မဟုတ် မည်သည့် system call များကို invoke လုပ်သည် စသည်ဖြင့်။ ဤအပြုအမူ၏ fingerprinting ကို version များတစ်လျှောက် (ရှိပြီးသား component အတွက်) နှိုင်းယှဉ်နိုင်သောကြောင့် မမျှော်လင့်ထားသော အပြုအမူကို တွေ့ရှိသောအခါ၊ ထိုအထောက်အထားများသည် version အသစ်တွင် ထိုးသွင်းနိုင်သော အန္တရာယ်ရှိသော လုပ်ဆောင်ချက်၏ သံသယကို ဖြစ်ပေါ်စေနိုင်သည်။ ဤချဉ်းကပ်မှုသည် malware ဖြစ်နိုင်ခြေရှိသော အရာများနှင့် ရင်ဆိုင်ရသည့်အခါ လုံခြုံရေး ခွဲခြမ်းစိတ်ဖြာသူများ လိုက်နာသည့် triage အဆင့်များကို လိုက်နာသည်- စစ်ဆေးခြင်းကို အသုံးပြု၍ ညှို့ သို့မဟုတ် အလားတူကိရိယာများ။ ဤနည်းလမ်းသည် လှုံ့ဆော်ပေးသည့်အခြေအနေများ မည်သို့ပင်ရှိစေကာမူ အန္တရာယ်ရှိသောအပြုအမူကို ထောက်လှမ်းပြီး source code မရရှိနိုင်သည့်အခါတွင် အလုပ်လုပ်သည်။
ဆက်စပ်သုံးသပ်ချက် အစိတ်အပိုင်းကို မည်သို့ထုတ်ဝေခဲ့သည်နှင့် မည်သူထုတ်ဝေခဲ့သည်ဆိုသည့် အချက်အလက်များကို စုဆောင်းသည်။ မကောင်းသောသရုပ်ဆောင်များ၏ စည်းရုံးလှုံ့ဆော်ရေးများသည် တင်းကျပ်သော စိစစ်ရေးလုပ်ငန်းစဉ်တစ်ခုမှ မပါဝင်သော အသုံးပြုသူအကောင့်(များ)ကို မကြာခဏအသုံးပြုလေ့ရှိသည်။ အတိတ်လှုပ်ရှားမှုကို ခြေရာခံခြင်းသည် အခြေခံအသုံးပြုသူအကြောင်း ထိုးထွင်းသိမြင်မှုကို ပေးစွမ်းနိုင်ပြီး အများအားဖြင့် အလားအလာရှိသော ညှိနှိုင်းမှုတစ်ခုကို ညွှန်ပြနိုင်သည့် ပုံမှန်မဟုတ်သော အရာများအတွက်ဖြစ်သည်။ ဂုဏ်သတင်းကို ရှာဖွေရန် အလွန်ခက်ခဲပြီး ဆုံးရှုံးရန် အလွန်လွယ်ကူသည်။ အတိတ်လှုပ်ရှားမှုမရှိသော အသုံးပြုသူသည် ကြားနေဖြစ်သော်လည်း ကံတရားသည် မကောင်းသောလုပ်ရပ်ကို လိုက်လံရှာဖွေသည်။ ၎င်းတို့၏ ထုတ်ဝေမှုအထောက်အထားများ ခိုးယူခံရသော ဟက်ကာများ သို့မဟုတ် ပုံမှန်အသုံးပြုသူများကို ဂရုတစိုက်ခြေရာခံသင့်သည်။
နောက်ထပ်ဆက်စပ်အချက်အလက်တစ်ခုကတော့ component tarball ကိုဖန်တီးဖို့အသုံးပြုတယ်လို့ယူဆရတဲ့ source repository နဲ့ tarball ရဲ့ content တွေကြားက ကွဲလွဲမှုတစ်ခုခုပါပဲ။ ပြီးတော့ public registry မှာထုတ်ဝေထားတဲ့ component ရဲ့ version တွေနဲ့ကိုက်ညီတဲ့ source repository မှာ tag တွေ ဒါမှမဟုတ် release တွေဖန်တီးတာလိုမျိုး ကောင်းမွန်တဲ့အလေ့အကျင့်တွေကိုလည်း လိုက်နာရမှာပါ။ source repository ဟာ သတ်မှတ်ထားတဲ့တစ်ခုမှာရှိတဲ့အခါ commit release ဖြင့် tag တပ်ထားပြီး ရုတ်တရက် version တစ်ခုမှ ၎င်းနောက်သို့ မလိုက်နိုင်ခြင်းသည်ပင် component ညစ်ညမ်းနေနိုင်ကြောင်း ခိုင်မာသော သက်သေဖြစ်သည်- မကောင်းသော သရုပ်ဆောင်သည် component ကို ထုတ်ဝေရန်အသုံးပြုသည့် account ကို ခိုးယူသွားနိုင်သော်လည်း source code repository တွင် write permissions မရှိပါ)။ တိုက်ခိုက်မှုများစွာကို ဤစည်းမျဉ်းများကို အသုံးပြု၍ ပုံမှန်တွေ့ရှိရသည်- ဥပမာ၊ စာရင်းတိုက်ခိုက်မှု ဤလမ်းကြောင်းများတစ်လျှောက်တွင် အလွယ်တကူ ရှာဖွေတွေ့ရှိနိုင်ပါသည်။ ထို့ကြောင့် အခြေအနေခွဲခြမ်းစိတ်ဖြာမှုသည် ထုတ်ဝေခြင်းလုပ်ငန်းစဉ်တွင် ထိုကဲ့သို့သော မူမမှန်မှုများကို ဖော်ထုတ်ပေးပါသည်။
မှီခိုမှု firewall အသုံးပြုခြင်း
ကွဲပြားတဲ့ ချဉ်းကပ်မှုတစ်ခုကတော့ သင့်ဆော့ဖ်ဝဲမှာ အသုံးပြုတဲ့ dependency graph အားလုံးအတွက် component တွေရဲ့ ပြည့်စုံတဲ့ whitelist တစ်ခု ရှိဖို့ပါပဲ၊ ဒါကြောင့် ဘယ် build မှာမဆို pipeline သင့်အဖွဲ့အစည်းတွင် လုပ်ဆောင်ခြင်းကို အတည်ပြုထားသော အစိတ်အပိုင်းဗားရှင်းများကိုသာ ထည့်သွင်းအသုံးပြုနိုင်သည်။ “firewall က” ကို ခွင့်ပြုထားသော အစိတ်အပိုင်းဗားရှင်းများအတွက် tarball များကို ဝန်ဆောင်မှုပေးသည့် (cached သို့မဟုတ် proxied) internal registry ကို အသုံးပြု၍ ပြဋ္ဌာန်းထားသည်။ whitelist တွင် ထည့်သွင်းနိုင်ရန် ဗားရှင်းအသစ်တစ်ခုခုကို ကျိုးကြောင်းဆီလျော်စွာ ဘေးကင်းသည်ဟု အမျိုးအစားခွဲခြားနိုင်သည့် နည်းပညာမရှိပါက မည်သည့် whitelist မဆို အလုပ်မလုပ်နိုင်ကြောင်း ကျေးဇူးပြု၍ သတိပြုပါ။
အစောပိုင်းသတိပေးချက် (ဗားရှင်းအသစ်ထုတ်ဝေပြီးနောက် အမြန်ဆုံး လျင်မြန်စွာသိရှိနိုင်ခြင်း) ကို တည်ဆောက်မှုအပေါ် သက်ရောက်မှုရှိသော အစိတ်အပိုင်းကို ပိတ်ဆို့ရန် ထိုအချက်အလက်ကို ကြိုတင်အသုံးပြုနည်းအချို့နှင့် ပေါင်းစပ်ရန် လိုအပ်ကြောင်း ကျေးဇူးပြု၍ သတိပြုပါ။ pipelines သို့မဟုတ် developer များ၏ စက်များ [4]။ ကျွန်ုပ်တို့က ဒါကို "မှီခိုမှု firewall”: အလိုအလျောက်တည်ဆောက်ထားသော build များကို အန္တရာယ်ရှိသော package များမှ ကာကွယ်ရန်အတွက် quarantine ယန္တရားတစ်ခု။ အတွင်းပိုင်း package များနှင့် image registry များသည် အဖွဲ့အစည်းများကို ပြင်ပမကောင်းဆိုးဝါးများမှ ကာကွယ်ရန် ကောင်းမွန်သော်လည်း၊ quarantine ထိရောက်စေရန်အတွက် လုံလောက်သော ခိုင်မာသည့်အထောက်အထားများ လိုအပ်ပါသည်။
Runtime Sandboxing
ထုတ်ဝေချိန်တွင် ထောက်လှမ်းရန် အခြားနည်းလမ်းတစ်ခုမှာ runtime တွင် အပြုအမူကို ခွဲခြမ်းစိတ်ဖြာရန်ဖြစ်သည်။ ရည်ရွယ်ချက်မှာ ဆော့ဖ်ဝဲမှ မျှော်လင့်ထားသော အပြုအမူကို ဖမ်းယူရန်နှင့် တွေ့ရှိရသည့် မူမမှန်မှုများကို ထောက်လှမ်း (သို့မဟုတ် ပိတ်ဆို့) ရန်ဖြစ်သည်။ ဤလုပ်ဆောင်ချက်လမ်းကြောင်းတွင် စောင့်ကြည့်ခြင်း သို့မဟုတ် ပိတ်ဆို့ခြင်းအတွက် runtime ကို ကိရိယာတန်ဆာပလာများ တပ်ဆင်ရန် ပြဿနာရှိပြီး ၎င်းသည် အန္တရာယ်ရှိသော အစိတ်အပိုင်းပိုးမွှားများကို ကာကွယ်ရေးယန္တရားများ၏ လက်နက်တိုက်တွင် ထည့်သွင်းမည့် အလားအလာကောင်းသော အကြံဥာဏ်တစ်ခုဖြစ်သည်။
ပြည့်စုံသော မဟာဗျူဟာတစ်ခု ချမှတ်ခြင်း
အကြံပြုထားသော ဗျူဟာသည် ဆော့ဖ်ဝဲလ်ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်တွင် မတူညီသောနည်းပညာများကို ပေါင်းစပ်ရန်၊ ဝင်ရောက်လာသော အန္တရာယ်ရှိသော အစိတ်အပိုင်းများကို ပိတ်ဆို့ရန် ဗားရှင်းအပ်ဒိတ်များကို ထိန်းချုပ်ရန် လိုအပ်ပါသည်။ အရေးကြီးသော အားနည်းချက်များအတွက် ပြင်ဆင်မှုများရရှိရန် အပ်ဒိတ်လုပ်ထားသော ဗားရှင်းများဖြင့် အလိုအလျောက် ကူးစက်မှုကို ရှောင်ရှားရန် ဗားရှင်းပင်နယ်တီကို ကျွန်ုပ်တို့ လိုက်လျောညီထွေဖြစ်အောင် လုပ်ဆောင်ရမည်ဖြစ်ပြီး၊ ဗားရှင်းအပ်ဒိတ်များအတွင်း တိုက်ရိုက်နှင့် သွယ်ဝိုက်သော မှီခိုမှုများကို မြန်ဆန်ထိရောက်စွာ အကဲဖြတ်ရမည်ဖြစ်ပြီး ၎င်းတို့သည် malware မရှိကြောင်း လုံလောက်သော အထောက်အထားရှိရမည်။ သိရှိထားသော အန္တရာယ်ရှိသော အစိတ်အပိုင်းများအပေါ် မှီခိုသော ဆော့ဖ်ဝဲလ်များ၏ တည်ဆောက်မှုများကို ပိတ်ဆို့ရမည်။ အားလုံးကို အကောင်အထည်ဖော်ရမည်။
ဖြစ်နိုင်ရင် version pinning ကိုသုံးပါ၊ ဘာလို့လဲဆိုတော့ build တွေကို ပိုပြီး reproduce လုပ်လို့ရလို့ပါ။ ထိန်းချုပ်ထားသော၊ လက်ဖြင့် အတည်ပြုထားသော ဗားရှင်း တိုးတိုးလေးများဖြင့် ဗားရှင်းပင်ထိုးခြင်းနှင့် အထောက်အကူပြုနည်းပညာဖြင့် ပံ့ပိုးပေးထားသည်အပ်ဒိတ်သည် malware ယူဆောင်လာခြင်း သို့မဟုတ် software ကို ပျက်စီးစေခြင်း ရှိ၊ မရှိ အကဲဖြတ်သင့်ပြီး အားနည်းချက်များကို ပြုပြင်ရန် အပ်ဒိတ်လုပ်ခြင်းနှင့် malware ကူးစက်မှုကို ရှောင်ရှားခြင်းတို့ကို ညှိနှိုင်းသင့်သည်။ Tooling သည် ဤနေရာတွင် (1) မည်သည့်အားနည်းချက်များသည် အမှန်တကယ်အရေးကြီးသည်ကို ဦးစားပေးခြင်းဖြင့် (တိုက်ခိုက်သူများ၏ ပစ်မှတ်ထားခံရနိုင်ခြေမြင့်မားသော)၊ (2) လက်ရှိ component အသုံးပြုမှုနှင့် ကိုက်ညီပြီး software ကို ပျက်စီးစေခြင်းမရှိသော target version များကို ရွေးချယ်ခြင်း၊ (3) malicious behavior မပါဝင်သော target version များကို ရွေးချယ်ခြင်းနှင့် (4) လျင်မြန်စွာ အတည်ပြုနိုင်သော manifest files များတွင် ပြောင်းလဲမှုများကို အကြံပြုခြင်းဖြင့် direct နှင့် indirect dependency များအတွက် version update ကို လျင်မြန်စွာ ပြုလုပ်ခြင်းဖြင့် ကူညီပေးနိုင်ပါသည်။ အဆင့် (3) သည် malicious component များအကြောင်း ၎င်းတို့၏ ထုတ်ဝေချိန်နှင့် တတ်နိုင်သမျှ နီးကပ်စွာ သီးခြားအချက်အလက်များ လိုအပ်ပါသည်။
ဒီ dependency တွေကို update လုပ်တဲ့ လုပ်ငန်းစဉ်က ဒီလိုဖြစ်ရမယ်။ ပြဌာန်း နှင့် မှန်ကန်ကြောင်းအတည်ပြု နေရာတိုင်းတွင်။ လုပ်ငန်းစဉ်ကို မှတ်တမ်းတင်ထားရမည်ဖြစ်ပြီး ပါဝင်ပတ်သက်သူအားလုံးကို လေ့ကျင့်သင်ကြားပေးသင့်သည်၊ အဘယ်ကြောင့်ဆိုသော် ဖွံ့ဖြိုးတိုးတက်မှုနှင့် ဆော့ဖ်ဝဲတည်ဆောက်ခြင်း/ဖြန့်ကျက်ခြင်းကို မကြာခဏ ပြင်ပသို့ ဖြန့်ဝေလေ့ရှိသောကြောင့်ဖြစ်သည်။ CI/CD pipelines ကို လိုက်လျောညီထွေဖြစ်အောင် ပြုပြင်သင့်သည်၊ ထို့ကြောင့် အလိုအလျောက်လုပ်ဆောင်ခြင်းဖြင့် အန္တရာယ်ရှိသော သွယ်ဝိုက်သော မှီခိုမှုကို တည်ဆောက်မှုထဲသို့ ခိုးဝင်ခွင့်မပြုပါ။ guardrails dependency တစ်ခုမှာ malware ဖြစ်နိုင်ချေရှိတဲ့ အထောက်အထား လုံလောက်စွာရှိရင် build ကို block လုပ်တာက အကြံပြုထားတဲ့ နည်းလမ်းပါ။
သင့်အဖွဲ့အစည်းတွင် ခွင့်ပြုထားသော အစိတ်အပိုင်းဗားရှင်းများကို သိမ်းဆည်းရန်အတွက် လုံခြုံရေး proxy အဖြစ် လုပ်ဆောင်သည့် အတွင်းပိုင်းမှတ်ပုံတင်တစ်ခုရှိပါက၊ တောင်းဆိုထားသော အစိတ်အပိုင်းကို ခွင့်ပြုစာရင်းတွင် မထည့်သွင်းမီ စိစစ်ရန်အတွက် (အခြားစံနှုန်းများအပြင်) အန္တရာယ်ရှိသော အစိတ်အပိုင်းများအကြောင်း ထောက်လှမ်းရေးကို ရယူရမည်။
open-source software ကို ဘေးကင်းစွာအသုံးပြုခြင်းသည် မလွယ်ကူပါ၊ malware အချက်ကိုလည်း အပြည့်အဝထည့်သွင်းစဉ်းစားရမည်ဖြစ်ပြီး အားနည်းချက်ကိုင်တွယ်မှုတွင်လည်း အလားတူကြိုးပမ်းအားထုတ်ရမည်ဖြစ်သည်။
နောက်ဆုံးမှတ်စုတစ်ခု အရင်းအမြစ်ရင်းမြစ်component တည်ဆောက်ချိန်တွင် ထုတ်ပေးသော software attestations ပုံစံဖြင့် ၎င်းသည် artifact (component tarball) ကို sources နှင့် build process တို့ဖြင့် ခြေရာခံရန် ကြိုးပမ်းမှုတွင် နောက်ထပ် အဓိက အစိတ်အပိုင်းတစ်ခုဖြစ်သည်။ source snapshot + build environment နှင့် ဆက်စပ် software artifact (trusted build system မှ လက်မှတ်ရေးထိုးထားသည်) အကြား ဤချိတ်ဆက်မှုသည် component တွင် malicious behavior မပါဝင်ကြောင်း ඉදිරියට မကာကွယ်သော်လည်း malware ထိုးသွင်းရန် မကောင်းသူများ ပိုမိုခက်ခဲစေကြောင်း သတိပြုပါ။ open source component များကို သုံးစွဲရန်အတွက် provenance validation ကို ဘုံလိုအပ်ချက်တစ်ခုအဖြစ် ပြုလုပ်ခြင်းသည် အချိန်ကြာမြင့်မည်ဖြစ်ပြီး မကြာသေးမီက NPM တွင်ထည့်သွင်းထားသည်။ ယုံကြည်စိတ်ချရသော တည်ဆောက်မှုနှင့် ဖြန့်ကျက်စနစ်များကို ကျူးကျော်ဝင်ရောက်မှုမှ ကင်းဝေးစေခြင်း သို့မဟုတ် တည်ဆောက်မှုတွင် မည်သည့်ကျူးကျော်ဝင်ရောက်မှုကိုမဆို ထောက်လှမ်းနိုင်စေခြင်းမှာ ဤပို့စ်၏ အတိုင်းအတာပြင်ပတွင် ကွဲပြားသောဇာတ်လမ်းတစ်ပုဒ်ဖြစ်သည်။
နောက်ထပ်ဖတ်ရန်
နောက်ဇာတ်လမ်းတွဲ ပွင့်လင်းသောရင်းမြစ် အန္တရာယ်ရှိသော အထုပ်များ- Xygeni ချဉ်းကပ်မှု Xygeni မှာ ကျွန်ုပ်တို့ လိုက်နာတဲ့ မဟာဗျူဟာကို တင်ပြပါမယ် မဲလ်ဝဲကြိုတင်သတိပေးချက် (MEW) စနစ်။ အများသုံးပက်ကေ့ဂျ်နှင့် ရုပ်ပုံမှတ်ပုံတင်များတွင် ပက်ကေ့ဂျ်ဗားရှင်းအသစ်များကို စကင်ဖတ်စစ်ဆေးပြီး static၊ dynamic၊ capabilities နှင့် contextual analysis တို့ကို ပေါင်းစပ်အသုံးပြု၍ အထောက်အထားများကို ရယူသည်။ အထောက်အထားများကို အသုံးပြုသူဂုဏ်သတင်းနှင့် source code repositories များတွင် ပြောင်းလဲမှုများ၏ သမိုင်းကြောင်းတို့နှင့် ပေါင်းစပ်ခြင်းဖြင့် အစိတ်အပိုင်းတစ်ခုကို အန္တရာယ်များသောနှင့် အန္တရာယ်ရှိနိုင်သော အမျိုးအစားများအဖြစ် အလိုအလျောက်ခွဲခြားနိုင်စေပါသည်။ စနစ်သည် ပက်ကေ့ဂျ်များမှ စုဆောင်းရရှိသော ယခင်အထောက်အထားများမှ သင်ယူပြီး false positives များကို အနည်းဆုံးဖြစ်အောင် လျှော့ချပေးသည်။
စာရင်းသွင်းထားသော အဖွဲ့အစည်းများသည် အန္တရာယ်ရှိသော ဗားရှင်းတစ်ခုကို အမျိုးအစားခွဲခြားသောအခါ ၎င်းတို့အသုံးပြုနေသော အစိတ်အပိုင်းများအတွက် တိုက်ရိုက် သို့မဟုတ် သွယ်ဝိုက်၍ သတိပေးအကြောင်းကြားချက်ကို ရရှိပါသည်။ ထို့နောက် ကျွန်ုပ်တို့၏ ခွဲခြမ်းစိတ်ဖြာသူများက လက်စွဲခွဲခြမ်းစိတ်ဖြာမှုကို ပြုလုပ်ပြီး အမျိုးအစားခွဲခြားမှုကို အတည်ပြုခြင်း သို့မဟုတ် ငြင်းပယ်ခြင်း ပြုလုပ်ပါသည်။ အတည်ပြုထားသော malware အတွက်၊ အများပြည်သူမှတ်ပုံတင်ခြင်းအား ၎င်း၏ကိုယ်ပိုင်ခွဲခြမ်းစိတ်ဖြာမှုကို လုပ်ဆောင်နိုင်ပြီး အန္တရာယ်ရှိသော ဗားရှင်းကို ဖယ်ရှားခြင်း သို့မဟုတ် သက်ဆိုင်ရာအသုံးပြုသူအကောင့်ကို ပိတ်ဆို့ခြင်း သို့မဟုတ် ဖယ်ရှားခြင်းကဲ့သို့သော အပိုဆောင်းလုပ်ဆောင်ချက်များ ပြုလုပ်နိုင်စေရန် အကြောင်းကြားပါသည်။
open source ecosystem မှာရှိတဲ့ NPM၊ PyPI၊ GitHub နဲ့ အခြား key infrastructure တွေကို malware အတည်ပြုပြီး registry ကနေ ဖယ်ရှားတဲ့အထိ dwell time ကို လျှော့ချဖို့ ဘယ်လိုကူညီပေးနေလဲဆိုတာ ရှင်းပြပါမယ်။ ပြီးတော့ open source component တွေပါဝင်တဲ့ software supply chain တိုက်ခိုက်မှုတွေကနေ MEW system ကနေ အဖွဲ့အစည်းတွေ ဘယ်လိုအကျိုးကျေးဇူးရရှိနိုင်မလဲ။
- [1] ဘာပဲဖြစ်ဖြစ်၊ component tarball ကို အသုံးပြုသူများသည် component tarball ကို cache လုပ်ထားခြင်း သို့မဟုတ် တစ်နေရာရာတွင် မှတ်ပုံတင်ထားခြင်း ရှိ၊ မရှိ၊ ဥပမာ internal registry တွင် စစ်ဆေးရန် လိုအပ်ပြီး ရောဂါကို ဖယ်ရှားပေးပါသည်။
- [2] ထုပ်ပိုးထားသော အစိတ်အပိုင်းတွင် ၎င်း၏ အကြောင်းအရာများနှင့် metadata၊ source သို့မဟုတ် compiled code၊ installation scripts နှင့် test suites ကဲ့သို့သော အပိုပစ္စည်းများကို packaging format နှင့် compressed form အရ ကြေညာသည့် manifest တစ်ခု ပါဝင်သည်။ ၎င်းကို “component tarball” ဟုခေါ်သည်။
- [3] registry မှာ ချိုးဖောက်မှုကြောင့် ထုတ်ဝေထားတဲ့ အစိတ်အပိုင်းတစ်ခုကို malicious activator က ပြင်ဆင်နိုင်ရင်တောင်မှ၊ ရိုးရိုး cryptographic digest က analysis လုပ်ပြီးတဲ့အခါ tarball မှာ ပြောင်းလဲမှုတွေကို ထောက်လှမ်းနိုင်ပါတယ်။
- [4] အချို့သော အန္တရာယ်ရှိသော အစိတ်အပိုင်းများသည် install လုပ်ချိန်တွင် လုပ်ဆောင်ကြောင်း သတိရပါ၊ ထို့ကြောင့် ၎င်းသည် X ကို အန္တရာယ်ရှိသော အစိတ်အပိုင်းဖြင့် “npm install X” ကို မသိလိုက်ဘဲ လုပ်ဆောင်သော developer node များကို ထိခိုက်နိုင်သည်။
