AI အေးဂျင့် ထောက်ပံ့ရေးကွင်းဆက် လုံခြုံရေးဟာ အရင်တုန်းက ရိုးရှင်းခဲ့ပါတယ်၊ အဓိကအားဖြင့် လူသားတစ်ယောက်က package name နဲ့ build ကြားမှာ အမြဲရှိနေခဲ့လို့ပါ။ အနှစ်နှစ်ဆယ်လုံးလုံး အဲဒါက မော်ဒယ်တစ်ခုလုံးပါပဲ- တစ်ယောက်ယောက်က နာမည်ကို မထည့်ခင် ဖတ်ပါတယ်။ အမြဲတမ်း ဂရုတစိုက်တော့ မဟုတ်ပါဘူး။ ဒါပေမယ့် တစ်ယောက်ယောက်က ဖတ်ပါတယ်။
အခုတော့ အဲဒါပျောက်သွားပါပြီ။ AI မော်ဒယ်ကို library တစ်ခုတောင်းကြည့်ရင် အကြံပြုထားတဲ့ package ငါးခုမှာ တစ်ခုလောက်က မရှိပါဘူး။ တိုက်ခိုက်သူတွေက ဒါကိုသိတဲ့အတွက် အဲဒီနာမည်တွေကို အရင် register လုပ်ကြပါတယ်။ agent တစ်ယောက်က သူတို့ကို install လုပ်ပြီး စမ်းသပ်တယ်၊ ပြီးတော့ ဆက်သွားပေမယ့် ဘယ်သူမှ အဲဒီကြားထဲမှာ ဘာမှမဖတ်ပါဘူး။ ဒါက AI agent supply chain security အခုအချိန်မှာ ကျရှုံးနေတဲ့နေရာပါပဲ။ အနာဂတ်အခြေအနေမှာ မဟုတ်ဘဲ pipelineဒီနေ့ ပြေးနေပါတယ်။
ဒီလုပ်ငန်းဟာ ဖတ်ရှု၊ ပြန်လည်သုံးသပ်ပြီး ဆုံးဖြတ်တဲ့ developer တစ်ယောက်ကို အခြေခံပြီး ထိန်းချုပ်မှုတွေ တည်ဆောက်ဖို့ ဆယ်စုနှစ်နှစ်ခုကြာခဲ့ပါတယ်။ အဲဒီ developer ဟာ dependency တစ်ခု တည်ဆောက်မှုထဲ မဝင်ခင် နောက်ဆုံး checkpoint မဟုတ်တော့ပါဘူး။ ဒါကြောင့် တကယ့်မေးခွန်းက agent AI က အန္တရာယ်အသစ်တွေကို မိတ်ဆက်ပေးသလားဆိုတာ မဟုတ်ဘဲ လူသား checkpoint ပျောက်ကွယ်သွားတဲ့အခါ တကယ်တမ်း ကျန်ရှိနေတဲ့အရာပါ။
“AI အကြံပြုချက်များ” မှ “AI လုပ်ဆောင်ချက်များ” အထိ
လွန်ခဲ့တဲ့ နှစ်နှစ်က copilot တစ်ယောက်က code block တစ်ခုကို အဆိုပြုခဲ့ပြီး developer က ဖတ်ပြခဲ့ပြီး developer က ဆက်ထားသင့် မသင့် ဆုံးဖြတ်ခဲ့ပါတယ်။ အဲဒီ workflow ကတော့ အများစု ပျောက်ကွယ်သွားပါပြီ။ Agentic tools တွေက အခုဆိုရင် dependencies တွေကို install လုပ်၊ containers တွေကို လည်ပတ်၊ trigger လုပ်ပါတယ်။ pipeline အဆင့်များကို ၎င်းတို့ဘာသာ လုပ်ဆောင်ပြီး၊ အချက်အလက်ရရှိပြီးမှသာ နှင့် တစ်စုံတစ်ခု မှားယွင်းသွားမှသာ ပြန်လည်အစီရင်ခံလေ့ရှိသည်။
ပြောင်းလဲမှုဟာ အဆင့်ဆင့်ဖြစ်ပျက်ခဲ့ပြီး အဖွဲ့အများစုဟာ သူတို့ရဲ့ ရေးသားထားတဲ့ လုံခြုံရေးမူဝါဒက ဝန်ခံထားတာထက် ပိုဝေးဝေးမှာ ရှိနေကြပါတယ်။ အစောပိုင်း agent tools တွေဟာ ပြောင်းလဲမှုတိုင်းမတိုင်ခင်မှာ ခွင့်ပြုချက်တောင်းခံခဲ့ကြပြီး developer တွေက “ဟုတ်ကဲ့” ကို မကြာခဏ နှိပ်ခဲ့ကြတာကြောင့် အတည်ပြုချက်အဆင့်ဟာ ဘာမှ အဓိပ္ပာယ်မရှိတော့ပါဘူး။ ဒီနေ့ခေတ် agent တွေက လုံးဝမမေးကြပါဘူး။ သူတို့ဟာ shell script ကို run တာနဲ့ ပုံမှန်လုပ်ဆောင်ချက်တွေအတွက်ပဲ interrupt လုပ်ကြပါတယ်။ pull request agent တစ်ခုမှ ထုတ်လုပ်လိုက်သော ကုဒ်သည် ပေါင်းစည်းခြင်းမပြုမီ လူသားတစ်ဦးတစ်ယောက်မျှ အစမှအဆုံးအထိ မဖတ်သော လိုင်းထောင်ပေါင်းများစွာထဲသို့ ရောက်သွားနိုင်သည်။
ခွင့်ပြုချက်ပြဿနာက ဒါကို ပိုဆိုးစေပါတယ်။ setup အများစုမှာ agent ဟာ developer အနေနဲ့ ရိုးရှင်းစွာ လုပ်ဆောင်ပြီး developer ရဲ့ စက်က ရောက်ရှိနိုင်တဲ့ အရာအားလုံးကို ဝင်ရောက်ကြည့်ရှုနိုင်ပါတယ်- environment variable တွေ၊ cloud token တွေ၊ registry credential တွေ၊ SSH key တွေ။ agent တစ်ခုက တစ်ခုခုကို install လုပ်ပြီး install လုပ်နေစဉ် script တစ်ခု fire လုပ်တဲ့အခါ သူတုပထားတဲ့ လူသားရဲ့ full blast radius ကို အမွေဆက်ခံပါတယ်။ ဒီနေရာမှာ AI agent supply chain security ဟာ မူဝါဒမေးခွန်းတစ်ခု မဟုတ်တော့ဘဲ ခွင့်ပြုချက်မေးခွန်းတစ်ခု ဖြစ်လာပါတယ်- agent ဟာ exploit အသစ်တစ်ခု မလိုအပ်ပါဘူး၊ သူ့မှာ ရှိပြီးသား access ကိုပဲ လိုအပ်ပါတယ်။
ဆိပ်ကမ်းကပ် ကပ္ပတိန် မိုဟာမက်-အလီ အာရာဘီတူညီသော ဆွေးနွေးပွဲတွင် ပြောကြားရာတွင် ရှင်းရှင်းလင်းလင်း ပြောကြားခဲ့သည်- "ဆော့ဖ်ဝဲရေးသားသူဟာ အခုဆိုရင် တိုက်ခိုက်မှုမျက်နှာပြင်ရဲ့ အစိတ်အပိုင်းတစ်ခုလို့ ကျွန်တော်ထင်ပါတယ်။"
ဒါက ဘာကို အစားထိုးခဲ့လဲဆိုတာနဲ့ ပတ်သက်ပြီး ရိုးသားစွာ ဝန်ခံသင့်ပါတယ်။ စာဖတ်နေတဲ့ လူသားတစ်ယောက် package.json diff သည် အားနည်းသော ထိန်းချုပ်မှုတစ်ခုဖြစ်နှင့်ပြီးဖြစ်သည်။ ပြောင်းလဲမှုတစ်ခုကို အတည်မပြုမီ transitive dependency တိုင်းကို မည်သူမျှ အမှန်တကယ် အတည်မပြုနိုင်ပါ။ အေးဂျင့်များသည် ခိုင်မာသောစနစ်ကို ချိုးဖျက်ရန် မလိုအပ်ပါ။ အားနည်းသောစနစ်အတွက် နောက်ဆုံးဆင်ခြေကို ၎င်းတို့ ဖယ်ရှားခဲ့သည်။ ပြောင်းလဲသွားသည်မှာ အန္တရာယ်သည် အသစ်အဆန်းမဟုတ်ဘဲ ယခုအခါ လုံးဝကွဲပြားသော မြန်နှုန်းဖြင့် ရွေ့လျားနေခြင်းဖြစ်သည်- ခန့်မှန်းချက်အချို့က ပြီးခဲ့သည့်နှစ်၏ ထောက်ပံ့ရေးကွင်းဆက်တိုက်ခိုက်မှုပမာဏကို ယခင်နှစ်ထက် ငါးဆခန့်ရှိသည်ဟု ဖော်ပြထားပြီး မျဉ်းကွေးသည် မျဉ်းဖြောင့်ထက် အဆပေါင်းများစွာ မြင့်မားပုံရသည်။
ထည့်သွင်းချိန်- ဘယ်သူမှ မကြည့်တဲ့အခါ ဘာတွေပြောင်းလဲသွားလဲ
အာရုံလွဲခြင်း ပြီးတော့ အန္တရာယ်ရှိတဲ့ package အမည်တွေက အသစ်အဆန်း မဟုတ်ပါဘူး။ စာပို့ လူသားစာရိုက်အမှားများကို နှစ်ပေါင်းများစွာ အခွင့်ကောင်းယူခဲ့သည်- စာလုံးတစ်လုံးမှားသွားသည်နှင့် ဆော့ဖ်ဝဲရေးသားသူက မှားယွင်းသောအရာကို ထည့်သွင်းလိုက်ပါသည်။ ယခုကွာခြားချက်မှာ လူမဟုတ်ဘဲ မော်ဒယ်တစ်ခုက အမည်ကို ဦးစွာတီထွင်ပြီး ၎င်းသည် ကြိုတင်ခန့်မှန်းနိုင်သည့်အတိုင်း ပြုလုပ်ခြင်းဖြစ်သည်။
ကိန်းဂဏန်းတွေက ဒါကို စူးစမ်းလိုစိတ်မဟုတ်ဘဲ စီးပွားရေးလုပ်ငန်းတစ်ခု ဖြစ်စေပါတယ်။ open-source မော်ဒယ်တွေက အကြံပြုထားတဲ့ package ၂၀% လောက်ဟာ မရှိပါဘူး (စီးပွားဖြစ် မော်ဒယ်တွေအတွက် ၅% နီးပါး)၊ လေ့လာထားတဲ့ လိမ်ညာထားတဲ့ နာမည်တွေမှာ ၄၃% ဟာ ထပ်ခါတလဲလဲ query ဆယ်ခုမှာ အတူတူပဲ ပြန်ပေါ်လာပါတယ်။ အဲဒီ ထပ်ခါတလဲလဲ လုပ်ဆောင်နိုင်စွမ်းက တိုက်ခိုက်မှုပုံစံကို farmable ဖြစ်စေတာပါပဲ- attacker တစ်ယောက်ဟာ developer တစ်ယောက် ဘာရိုက်ထည့်မယ်ဆိုတာ ခန့်မှန်းစရာမလိုပါဘူး။ မော်ဒယ်က သူတို့ကို အခမဲ့ ယုံကြည်စိတ်ချစွာ ပြောပြပါတယ်။
HalluSquatting ဟုခေါ်သော အသစ်ထွက်ရှိလာသော မျိုးကွဲတစ်ခုသည် ပိုမိုတွန်းအားပေးသည်။ စိတ်ကူးယဉ်ဆန်သော အမည်ဖြင့် အန္တရာယ်ရှိသော package တစ်ခုကို ထုတ်ဝေမည့်အစား၊ တိုက်ခိုက်သူသည် README၊ skill file သို့မဟုတ် MCP server description ထဲတွင် အန္တရာယ်ရှိသော ညွှန်ကြားချက်များကို ထည့်သွင်းပြီးနောက်၊ agent တစ်ဦးက တူညီသော repository သို့မဟုတ် tool name ကို စိတ်ကူးယဉ်ဆန်ပြီး ဆွဲထုတ်ရန် စောင့်ဆိုင်းသည်။ ၎င်းကို prompt injection ဖြင့် ချိတ်ဆက်ထားသော မကြာသေးမီက စာတမ်းတစ်ခုတွင် አዲስ project များအတွက် အတုအယောင် repository name များ၏ ပြီးပြည့်စုံသော ခန့်မှန်းချက်နှင့် Cursor၊ Windsurf နှင့် Copilot အပါအဝင် အစစ်အမှန် coding assistant များကို ကုဒ်အပြည့်အစုံ အကောင်အထည်ဖော်မှုတို့ကို ဖော်ပြခဲ့သည်။ payload သည် executable code မဟုတ်ဘဲ plain text ဖြစ်သောကြောင့်၊ scanning tool အများစုတွင် flag လုပ်ရန် ဘာမှမရှိပါ။
Xygeni အနေနဲ့ သုတေသနအရာရှိ Luis Rodríguez ဆွေးနွေးမှုအတွင်း ၎င်းကို ထည့်သွင်းပါ- "ကျွန်တော်တို့ဟာ malicious code တွေကို ကာကွယ်ဖို့ နှစ်ပေါင်းများစွာ အချိန်ပေးခဲ့ပါတယ်။ Signatures, sandboxes, behavior analysis တွေပါ။ HalluSquatting မှာ ဒါတွေ မလိုအပ်ပါဘူး။ ယုံကြည်လောက်တဲ့ README တစ်ခုပဲ လိုအပ်ပါတယ်။" အေးဂျင့်တစ်ဦးသည် ယုံကြည်ရသော နောက်ခံအခြေအနေအဖြစ် ဖတ်သည့် ရိုးရိုးစာသားညွှန်ကြားချက်များသည် လုပ်ဆောင်နိုင်သောအရာကို ဖမ်းယူရန် တည်ဆောက်ထားသော စကင်နာများကို တန်းပြီး ဖြတ်သန်းသွားသည်။
အဲဒါက AppSec tooling အများစု မမြင်နိုင်အောင် တည်ဆောက်ထားတဲ့ အလွှာပါ၊ အဲဒါက ကြိုတင်တည်ဆောက်ထားတာပါcisဘာလို့ Xygeni ရဲ့ မဲလ်ဝဲကြိုတင်သတိပေးချက် (MEW) ချဉ်းကပ်မှုသည် platform level တွင်ရှိသည်- npm၊ PyPI နှင့် Maven ကဲ့သို့သော registry များတစ်လျှောက် မကြာသေးမီကထုတ်ဝေထားသော package များကို စဉ်ဆက်မပြတ်၊ အချိန်နှင့်တပြေးညီ ခွဲခြမ်းစိတ်ဖြာခြင်း၊ CVE မှ ရက်အနည်းငယ်အကြာတွင် လိုက်မီရန်စောင့်ဆိုင်းမည့်အစား public signature မရှိသေးမီ အန္တရာယ်ရှိသောအပြုအမူကို ဖမ်းယူရန်တည်ဆောက်ထားသည်။
ကွန်တိန်နာ, CI/CDနှင့် မူရင်းဒေသ- သင့်တည်ဆောက်ပုံတွင် အဘယ်အရာပါဝင်သည်ကို သက်သေပြနိုင်ပါသလား။
အေးဂျင့်တစ်ယောက်ဟာ လိုင်းတစ်ခုထည့်တဲ့နေရာမှာ ရှားရှားပါးပါးပဲ ရပ်လေ့ရှိပါတယ်။ package.json၎င်းသည် Dockerfiles များကို တည်းဖြတ်သည်၊ multi-stage builds များကို ပြန်လည်ဖွဲ့စည်းသည်၊ နှင့် touches များကို လုပ်ဆောင်သည် pipeline source tree ထဲသို့ တိုက်ရိုက်ဝင်ရောက်မည့်အစား build system ကိုယ်တိုင်သို့ ဝင်ရောက်ကာ configuration ကို တိုက်ရိုက်လုပ်ဆောင်ပါ။
ဒါက ထောက်ပံ့ရေးကွင်းဆက်အန္တရာယ်အတွက် လုပ်ငန်းရဲ့အဖြေပဲ၊ SBOMs နှင့် SLSA provenance, ကို ထိန်းသိမ်းထားရန် ရည်ရွယ်ခဲ့သည်။ ထို့နောက် ၂၀၂၆ ခုနှစ် မေလတွင် တိုက်ခိုက်သူတစ်ဦးသည် ပြုပြင်ထိန်းသိမ်းသူတစ်ဦးကို phishing လုပ်ခဲ့ပြီး ခိုးယူခံရသော token ကို အသုံးပြု၍ “မိဘမဲ့” တစ်ခုကို ထုတ်ဝေခဲ့သည်။ commit ပရောဂျက်ရဲ့ ရာဇဝင်မှာ မိဘမရှိဘဲ build cache ကို အဆိပ်ခတ်ဖို့ အသုံးပြုခဲ့ပါတယ်။ ရလဒ်အနေနဲ့ package ရှစ်ဆယ့်လေးခုဟာ အပြည့်အဝ တရားဝင်ပြီး စနစ်တကျ လက်မှတ်ရေးထိုးထားတဲ့ ထိပ်တန်းရင်းမြစ်နဲ့ ပို့ဆောင်ခံခဲ့ရပါတယ်။ အလိုအလျောက်စစ်ဆေးမှုတိုင်း အောင်မြင်ခဲ့ပါတယ်။ malware ဟာ အစစ်အမှန်ဖြစ်တာကြောင့် နည်းပညာပိုင်းအရ စာရွက်စာတမ်းတွေက ဘယ်လိုတည်ဆောက်ခဲ့တယ်ဆိုတာကို သက်သေပြနေပါတယ်။
မသက်မသာဖြစ်စေသော အချက်မှာ- ပေးအပ်ထားသည့်အရာဖြင့် တည်ဆောက်မှုတစ်ခု လုပ်ဆောင်ခဲ့သည်ကို သက်သေပြခြင်းမဟုတ်ဘဲ၊ ပေးအပ်ထားသည့်အရာသည် ယုံကြည်မှုထိုက်တန်ကြောင်း သက်သေပြခြင်းဖြစ်သည်။ ရှေးဟောင်းပစ္စည်းမတည်ရှိမီ ထည့်သွင်းမှုကို အဆိပ်ခတ်ပါက၊ အတည်ပြုချက်သည် မရိုးသားသော တည်ဆောက်မှု၏ ရိုးသားပြီး အတည်ပြုနိုင်သော မှတ်တမ်းတစ်ခုဖြစ်သည်။ AI အေးဂျင့် ထောက်ပံ့ရေးကွင်းဆက်လုံခြုံရေးကို မော်ဒယ်မဟုတ်ဘဲ လူသားတစ်ဦးမှ တည်ဆောက်မှုထဲသို့ မည်သည့်အရာပါဝင်သည်ကို ဆုံးဖြတ်သည့် ကမ္ဘာအတွက် တည်ဆောက်ထားသော အတည်ပြုကိရိယာများသို့ အပြည့်အဝ လွှဲအပ်၍မရပါ။
လက်တွေ့ကျတဲ့ လျော့ပါးသက်သာစေမှုတစ်ခုကတော့ ဆွဲဆောင်မှုမရှိပေမယ့် ထိရောက်မှုရှိပါတယ်- package ဗားရှင်းအသစ်ထုတ်ဝေပြီး ရက်အနည်းငယ်စောင့်ပြီးမှ လက်ခံအသုံးပြုပါ။ တက်ကြွတဲ့ ထောက်ပံ့ရေးကွင်းဆက်ဖြစ်ရပ်အများစုကို အဲဒီအစောပိုင်းကာလအတွင်းမှာ flag လုပ်ပြီး ထုတ်ဖော်လေ့ရှိတာကြောင့် ငါးရက်နှောင့်နှေးခြင်းက ပြီးခဲ့တဲ့နှစ်ရဲ့ အဓိပ္ပာယ်ရှိတဲ့ ဝေစုကို ပျက်ပြယ်စေမှာပါ။ တုတ်ကောင်ပုံစံတိုက်ခိုက်မှုများချက်ချင်းမှလွဲ၍ မည်သည့်အရာ၏ အဖိုးအခဖြင့်မျှiacy.
Git၊ Review နှင့် ကျုံ့သွားသော လူသားစစ်ဆေးရေးဂိတ်
ကုဒ်ပြန်လည်သုံးသပ်ခြင်းနှင့် commit သမိုင်းကြောင်းက “တစ်ယောက်ယောက်က ဒါကိုကြည့်ခဲ့တယ်” ဆိုတဲ့အတွက် ယုံကြည်မှုကျောက်ဆူးအဖြစ် ကြာမြင့်စွာ တာဝန်ထမ်းဆောင်ခဲ့ပါတယ်။ အေးဂျင့်တွေလုပ်တဲ့အခါ အဲဒီကျောက်ဆူးဟာ ပိုတုန်ခါလာပါတယ်။ commitဖြစ်ပျက်ချိန်တွင် လူသားတစ်ဦးတစ်ယောက်မျှ မပါဘဲ တိုး၍တိုး၍ ပေါင်းစည်းလာကြသည်။
package တစ်ခုကို install လုပ်တဲ့ agent တစ်ယောက်ဟာ Stack Overflow အဖြေကို copy လုပ်တဲ့ developer တစ်ယောက်နဲ့ ယုံကြည်မှုပြဿနာ အတူတူပါပဲ။ နှစ်ခုစလုံးက မူရင်းကုဒ်ကို မရေးကြပေမယ့်လည်းပေါ့။ Stack Overflow snippet တစ်ခုကို တကယ့်လူတစ်ယောက်က ရေးသားခဲ့ပြီး upvotes နဲ့ downvotes တွေကနေတစ်ဆင့် တရားဝင်မဟုတ်တဲ့ peer-reviewed လုပ်ထားပါတယ်။ AI-generated recommendation ဆိုတာ probabilistic output တစ်ခုဖြစ်ပြီး probabilistic output တစ်ခုဖြစ်ပြီး developer က ကိုယ်တိုင် copy လုပ်တဲ့အခါ package name၊ နောက်ဆုံး update လုပ်တဲ့ရက်စွဲ၊ open issues တွေကို ကြည့်နေဆဲပါ။ install လုပ်တဲ့ agent တစ်ယောက်ဟာ တစ်ခုခုကို pause လုပ်ဖို့ ရှင်းရှင်းလင်းလင်း တည်ဆောက်ထားခြင်းမရှိရင် အဲဒါတွေထဲက ဘာအတွက်မှ pause မလုပ်ပါဘူး။
အဲဒါက တကယ့် ဘယ်ဘက်ရွှေ့တဲ့ ပြဿနာပါ။ ရိုးရာ ဘယ်ဘက်ရွှေ့တဲ့စနစ်က အမြန်ဆုံးရွေ့လျားနေတဲ့အရာကို ယူဆပါတယ် pipeline သည် လေ့ကျင့်ပေးခြင်း၊ တွန်းအားပေးခြင်းနှင့် ပြန်လည်သုံးသပ်ခြင်းတို့ကို ပြုလုပ်နိုင်သော developer တစ်ခုဖြစ်သည်။ အလျင်မြန်ဆုံးရွေ့လျားနေသည့်အရာသည် autonomous agent တစ်ခုဖြစ်နေသည့်အခါ၊ shift-left security ကို agent မှ ၎င်း၏လမ်းကြောင်းကို မပြောနိုင်သည့် checkpoints များဆီသို့ ပြန်လည်ချိတ်ဆက်ရမည်- sandboxing၊ egress control နှင့် cooldown windows များ၊ မည်သူမျှ အတင်းအကြပ်မလုပ်ဆောင်သော မူဝါဒစာရွက်စာတမ်းတစ်ခုထက်။
AI အေးဂျင့် ထောက်ပံ့ရေးကွင်းဆက် လုံခြုံရေး- မည်မျှလုံခြုံသော အေးဂျင့်တစ်ဦးဖြစ်သည် Pipeline အမှန်တကယ်လိုအပ်သည်
ဒီ worm အမျိုးအစားအသစ်ကို ကျော်လွှားနိုင်ဖို့ ပထမနေ့မှာတင် ထိန်းချုပ်မှု ကိုးခုကို ပြီးပြည့်စုံစွာ အကောင်အထည်ဖော်ဖို့ မလိုအပ်ပါဘူး။ အရင်းအမြစ် အကန့်အသတ်ရှိတဲ့ အဖွဲ့အတွက် နှစ်ခုက ကျန်တာထက် ပိုအရေးကြီးပါတယ်။
- အေးဂျင့်ကို အမြဲတမ်း Sandbox လုပ်ပါ။ လက်ရှိ ပရောဂျက် directory ကိုသာ mount လုပ်ထားသော microVM သို့မဟုတ် container တွင် run ပါ။ ထို့ကြောင့် compromised agent သည် host ၏ tokens၊ credentials သို့မဟုတ် files များသို့ path မရှိပါ။ ၎င်းသည် ရရှိနိုင်သော အသက်သာဆုံး control ဖြစ်ပြီး ကျော်သွားရန် အနည်းဆုံး အကြောင်းပြချက်ရှိသော control တစ်ခုဖြစ်သည်။
- package ဗားရှင်းအသစ်များကို ထည့်သွင်းခြင်းမပြုမီ cooldown window တစ်ခုထည့်ပါ။ တိုက်ရိုက်ထောက်ပံ့ရေးကွင်းဆက်တိုက်ခိုက်မှုတစ်ခုသည် သင့်တည်ဆောက်မှုသို့မရောက်မီ ပေါ်ပေါက်လာပြီး ဖော်ထုတ်ခံရရန် ရက်အနည်းငယ်သည် မကြာခဏ လုံလောက်ပါသည်။
တတိယအချက်အနေနဲ့၊ အဲဒါကို တိုးချဲ့နိုင်တဲ့ အဖွဲ့တွေအတွက်- CVE နဲ့ malware မြင်နိုင်စွမ်းကို တိုက်ရိုက်တည်ဆောက်ပါ pipelinecontainer image ကို scan ဖတ်ပြီး (source code တစ်ခုတည်းမဟုတ်ဘဲ၊ base image မှာ vulnerability အများကြီးရှိတာကြောင့်) ရလဒ်တွေကို အောက်ပါအတိုင်း ပေါ်လာစေပါတယ် pull request developer များသည် ပေါင်းစည်းခြင်းမပြုမီ အမှန်တကယ်မြင်တွေ့ရသော မှတ်ချက်များ။
မကြာသေးမီက ဖြစ်ရပ်တစ်ခုကြောင့် အန္တရာယ်တွေက ခိုင်မာလာပါတယ်။ ၂၀၂၆ ခုနှစ် ဇူလိုင်လမှာ အတွင်းပိုင်း အကဲဖြတ်မှုအောက်က AI မော်ဒယ်တစ်ခုဟာ သူ့ရဲ့ sandbox ရဲ့ တစ်ခုတည်းသော ခွင့်ပြုထားတဲ့ ကွန်ရက်လမ်းကြောင်းဖြစ်တဲ့ package-cache proxy မှာရှိတဲ့ zero-day ကို အသုံးချပြီး open internet ကို ရောက်ရှိစေခဲ့ပြီး benchmark ရည်မှန်းချက်ကို လိုက်စားဖို့ လူသားတစ်ယောက်ယောက်က ညွှန်ကြားချက်မပေးဘဲ ပြင်ပ infrastructure ကို ထိခိုက်စေခဲ့ပါတယ်။ Escape route ကတော့ dependency infrastructure ပါ - sandbox တိုင်းက ဖြတ်သန်းခွင့်ပြုဖို့ တည်ဆောက်ထားတဲ့ တစ်ခုတည်းသော connection ပါ။ သင့်ရဲ့ agent ဟာ package registry ကို လုပ်ဆောင်ဖို့ လိုအပ်ရင် အဲဒီ connection ဟာ သင့်ရဲ့ security model ရဲ့ ဘေးထွက်အသေးစိတ်အချက်အလက် မဟုတ်ပါဘူး။ ဒါဟာ security model ပါ။ အဲဒီ escape တကယ်ဖြစ်ပျက်ခဲ့ပုံကို Xygeni ရဲ့ အပြည့်အစုံ ခွဲခြမ်းစိတ်ဖြာချက်က ဖတ်ရကျိုးနပ်ပါတယ်။ ဒီဇိုင်းအားဖြင့် လိမ်လည်သူ.
Key ကို Takeaways
- နောက်ဆုံး လူသားစစ်ဆေးရေးဂိတ်ဟာ အားနည်းသွားတာမဟုတ်ဘဲ ပျောက်ကွယ်သွားပါတယ်။ package name ကို ဖတ်တဲ့သူအပေါ် မူတည်မနေစေတဲ့ control တွေကို ဒီဇိုင်းဆွဲပါ။
- Slopsquatting နှင့် HalluSquatting တို့ကို မွေးမြူနိုင်သည်၊ သီအိုရီအရ မဟုတ်ပါ။ ထပ်ခါတလဲလဲ အာရုံချောက်ချားစေသော အမည်များနှင့် plain-text prompt injection များကို သဘာဝတွင် အသုံးချနေကြပြီဖြစ်သည်။
- မူလဇာစ်မြစ်နှင့် SBOMအဆောက်အဦတစ်ခုက ဘာကိုကျွေးမွေးတယ်ဆိုတာ မဟုတ်ဘဲ ဘာလုပ်တယ်ဆိုတာကို သက်သေပြပါတယ်။ ထိပ်တန်းအတည်ပြုချက်ကို လိုအပ်သလို သဘောထားပါ၊ လုံလောက်သည်ဟု မဆိုလိုပါ။
- လက်ရှိတွင် အတားအဆီးကို ထိန်းထားနိုင်သောအရာမှာ ထောက်လှမ်းခြင်းမဟုတ်ဘဲ ထိန်းချုပ်ခြင်းဖြစ်သည်။ Sandboxing၊ egress control နှင့် cooldown windows များသည် signature-based scanning မလုပ်ပေးနိုင်သော အချိန်ကို ဝယ်ယူပေးပါသည်။
- သင့်အေးဂျင့်များ အမှန်တကယ်ရရှိနိုင်သည့်အရာများကို စာရင်းပြုစုပါ။ မူဝါဒစာရွက်စာတမ်း မဟုတ်ဘူး။ တကယ့်တိုကင်တွေ၊ တကယ့်အထောက်အထားတွေ၊ တကယ့်ကွန်ရက်ထွက်ခွာမှု။
ဤဆောင်းပါးသည် Xygeni ၏ SafeDev Talk မှ ဆွေးနွေးချက်ကို အခြေခံထားသည်”AI Agent များသည် Dependencies များကို ထည့်သွင်းသည့်အခါ” Docker Captain Mohammad-Ali A'râbi ပါဝင်သရုပ်ဆောင်ထားသည်။ သူ၏ ကိုးခုပါ ထိန်းချုပ်မှု မာကျောစေသည့် မူဘောင်အပြည့်အစုံကို သူ၏ သတင်းလွှာ၊ Docker Security Dispatch နှင့် Xygeni ရှိ Luis Rodriguez သုတေသနအရာရှိတို့တွင် ပိုမိုနက်ရှိုင်းစွာ ဖော်ပြထားသည်။
မကြာခဏမေးလေ့ရှိသောမေးခွန်းများ- AI အေးဂျင့် ထောက်ပံ့ရေးကွင်းဆက်လုံခြုံရေး
package တစ်ခုကို agent တစ်ယောက်က install လုပ်နေတာ Stack Overflow suggestion ကို copy လုပ်နေတဲ့ developer တစ်ယောက်က package တစ်ခုကို ကူးယူနေတာနဲ့ လုံးဝကွဲပြားတဲ့ trust ပြဿနာတစ်ခုလား၊ ဒါမှမဟုတ် တူညီတဲ့ version ရဲ့ ပိုမြန်တဲ့ version တစ်ခုတည်းကိုပဲ သုံးနေတာလား။
နှစ်ခုစလုံးဟာ အချိုးအစားကွဲပြားပါတယ်။ ယန္တရားက ပိုမြန်ပေမယ့် ယုံကြည်မှုကွာဟချက်ကလည်း ဖွဲ့စည်းပုံအရ ပိုကျယ်ပြန့်ပါတယ်- Stack Overflow အဖြေကို လူတစ်ယောက်က ရေးသားပြီး အလွတ်သဘော peer-review လုပ်ထားပြီး AI-generated package recommendation ကတော့ ညီမျှတဲ့ review မရှိတဲ့ probabilistic output တစ်ခုဖြစ်ပြီး developer က ကိုယ်တိုင်ကူးယူပြီး casual scrutiny ကို အသုံးပြုပေမယ့် audience မရှိတဲ့ agent က လုံးဝကျော်သွားပါတယ်။
တစ်ခုအတွက် ဘာတွေလိုအပ်မလဲ SBOM “အေးဂျင့်တစ်ယောက်က ဒါကို ထည့်လိုက်တယ်၊ ဘာကြောင့်လဲဆိုတာ ဒါပဲ” လို့ ယုံကြည်စိတ်ချစွာ မှတ်တမ်းတင်ဖို့။
ယနေ့ SBOM နှင့် မူလဇစ်မြစ် standardလူသားတစ်ဦးသည် မှီခိုမှုတစ်ခုချင်းစီကို ပြုလုပ်သည်ဟူသော အယူအဆပေါ်တွင် အခြေခံ၍ တည်ဆောက်ထားခဲ့သည်။cision ရှိပြီး၊ သူတို့မှာ ဘယ်အေးဂျင့်၊ ဘယ်မော်ဒယ်ဗားရှင်း ဒါမှမဟုတ် ဘယ် prompt က ပေးထားတဲ့ပြောင်းလဲမှုကို ထုတ်လုပ်ပေးခဲ့တယ်ဆိုတဲ့ နယ်ပယ်မရှိသေးပါဘူး။ အဲဒီကွာဟချက်ကို ပိတ်ဖို့ လက်ရှိအတည်ပြုချက်ပုံစံတွေကို တိုးချဲ့ဖို့ ဒါမှမဟုတ် de ကိုဖမ်းယူနိုင်တဲ့ သီးခြားအေးဂျင့်သိရှိတဲ့ audit trail တစ်ခု လိုအပ်ပါတယ်။cisတည်ဆောက်မှုဇာစ်မြစ်နှင့်အတူ အိုင်းယွန်းဇာစ်မြစ်။
ထဲမှာ အမြန်ဆုံးအရာဖြစ်နေချိန်မှာ အလုပ်လုပ်နေဆဲဖြစ်တဲ့ “shift-left” ဗားရှင်းရှိပါသလား။ pipeline developer မဟုတ်ဘူးလား၊ autonomous agent လား။
ဟုတ်ကဲ့၊ ဒါပေမယ့် အချိန်ကိုက်ရုံတင်မကဘဲ checkpoint ကိုပြောင်းရပါမယ်။ လူသားပြန်လည်သုံးသပ်ခြင်းကို အခြေခံပြီးတည်ဆောက်ထားတဲ့ shift-left ဟာ agent ရဲ့အမြန်နှုန်းနဲ့ မညီမျှပါဘူး။ sandboxing၊ egress restrictions နဲ့ install cooldowns တွေကို အခြေခံပြီးတည်ဆောက်ထားတဲ့ shift-left ဟာ compromised agent ရဲ့လုပ်ဆောင်ချက်တွေ production မရောက်ခင်မှာ ဖမ်းယူနိုင်ပါသေးတယ်၊ ဘာလို့လဲဆိုတော့ အဲဒီထိန်းချုပ်မှုတွေဟာ ဘာမှဖတ်နေတဲ့သူအပေါ်မှာ မူတည်မနေလို့ပါ။
