Codex Security တွင် SAST အစီရင်ခံစာ မပါဝင်ရသည့် အကြောင်းရင်း

ဆယ်စုနှစ်များစွာတိုင်အောင် static application security testing (SAST) သည် လုံခြုံရေးအဖွဲ့များ code review ကို အတိုင်းအတာကြီးမားစွာ ဆောင်ရွက်နိုင်ရန် အထိရောက်ဆုံး နည်းလမ်းများထဲမှ တစ်ခုဖြစ်ခဲ့သည်။ 

သို့သော် Codex Security ကို ကျွန်ုပ်တို့ တည်ဆောက်စဉ်တွင် ရည်ရွယ်ချက်ရှိရှိ ဒီဇိုင်းရွေးချယ်မှုတစ်ခု ပြုလုပ်ခဲ့သည်။ static analysis report ကို တင်သွင်းပြီး အေးဂျင့် ကို ၎င်းကို triage လုပ်ခိုင်းခြင်းဖြင့် မစခဲ့ပါ။ ၎င်းအစား repository ကိုယ်တိုင်—၎င်း၏ architecture၊ trust boundaries နှင့် ရည်ရွယ်ထားသော behavior—မှ စတင်ပြီး၊ လူတစ်ဦးက ၎င်းအပေါ် အချိန်ပေးရန် မတောင်းဆိုမီ တွေ့ရှိချက်များကို အတည်ပြုမည့် စနစ်အဖြစ် ဒီဇိုင်းဆွဲခဲ့သည်။ 

အကြောင်းရင်းက ရိုးရှင်းပါသည်။ အခက်ခဲဆုံးသော အားနည်းချက်များသည် များသောအားဖြင့် dataflow ပြဿနာများ မဟုတ်ကြပါ။ code က security check တစ်ခုကို လိုက်နာစေသလို ထင်ရသော်လည်း၊ ထို check သည် စနစ်က အားကိုးထားသော property ကို အမှန်တကယ် အာမခံမပေးသည့်အခါ၌ ၎င်းတို့ ဖြစ်ပေါ်လာသည်။ တစ်နည်းအားဖြင့် စိန်ခေါ်မှုမှာ data သည် program တစ်ခုအတွင်း မည်သို့ ရွေ့လျားသွားသည်ကို လိုက်ခြေရာခံရုံသာ မဟုတ်ဘဲ၊ code ထဲရှိ ကာကွယ်မှုများသည် အမှန်တကယ် အလုပ်လုပ်သလားဆိုတာကို သတ်မှတ်ရခြင်း ဖြစ်သည်။

SAST ကို မကြာခဏ သန့်ရှင်းသော pipeline တစ်ခုအဖြစ် ဖော်ပြကြသည်။ မယုံကြည်ရသော input source ကို သတ်မှတ်ပါ၊ data ကို program တစ်လျှောက် လိုက်ခြေရာခံပါ၊ ထို့နောက် sanitization မရှိဘဲ sensitive sink တစ်ခုသို့ ရောက်ရှိသွားသည့် အခြေအနေများကို flag လုပ်ပါ။ ၎င်းသည် လှပသေသပ်သော မော်ဒယ် တစ်ခုဖြစ်ပြီး အမှန်တကယ် bug အများအပြားကိုလည်း ဖုံးလွှမ်းပေးနိုင်သည်။

လက်တွေ့တွင် SAST သည် အတိုင်းအတာကြီးမားစွာ အသုံးချနိုင်ရန် approximation များ ပြုလုပ်ရပါသည်—အထူးသဖြင့် indirection၊ dynamic dispatch၊ callbacks၊ reflection နှင့် framework-heavy control flow များပါဝင်သော အမှန်တကယ် codebase များတွင် ပို၍ ထင်ရှားသည်။ ထို approximation များသည် SAST ၏ အားနည်းချက်ဟု ဆိုလိုခြင်းမဟုတ်ပါ။ code ကို execute မလုပ်ဘဲ code ကို ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးသောအခါ ကြုံတွေ့ရသည့် အမှန်တကယ်အခြေအနေဖြစ်သည်။

၎င်းတစ်ခုတည်းကြောင့် Codex Security သည် SAST report ဖြင့် မစတင်ခြင်း မဟုတ်ပါ။

ပိုမိုနက်ရှိုင်းသော ပြဿနာမှာ source တစ်ခုမှ sink တစ်ခုသို့ သင် အောင်မြင်စွာ trace လုပ်ပြီးနောက် ဘာဖြစ်လာသလဲဆိုတာ ဖြစ်သည်။

static analysis သည် input ကို function နှင့် layer အများအပြားဖြတ်၍ မှန်ကန်စွာ trace လုပ်နိုင်သည့်တိုင်၊ အားနည်းချက် တကယ်ရှိမရှိကို ဆုံးဖြတ်ပေးမည့် မေးခွန်းကို ဖြေရန် လိုအပ်နေဆဲဖြစ်သည်။

အများတွင် တွေ့ရသော pattern တစ်ခုကို ယူကြည့်ပါ။ code သည် မယုံကြည်ရသော content ကို render မလုပ်မီ sanitize_html() ကဲ့သို့သော function တစ်ခုကို ခေါ်သည်။ static analyzer တစ်ခုက sanitizer run ခဲ့သည်ကို မြင်နိုင်သည်။ သို့သော် သတ်မှတ်ထားသော rendering context၊ template engine၊ encoding behavior နှင့် ပါဝင်သည့် downstream transformation များအတွက် ထို sanitizer သည် အမှန်တကယ် လုံလောက်မှုရှိမရှိကို များသောအားဖြင့် သတ်မှတ်မပေးနိုင်ပါ။

ထိုနေရာမှာပင် အရာများ ရှုပ်ထွေးလာသည်။ ပြဿနာမှာ data သည် sink တစ်ခုသို့ ရောက်သလားဆိုတာသာ မဟုတ်ပါ။ code ထဲရှိ checks များက စနစ်က ထင်မြင်ထားသည့် ပုံစံအတိုင်း တန်ဖိုးကို အမှန်တကယ် ကန့်သတ်ပေးသလားဆိုတာ ဖြစ်သည်။

တစ်နည်းအားဖြင့် “code က sanitizer တစ်ခုကို ခေါ်သည်” နှင့် “စနစ်သည် လုံခြုံသည်” ဆိုသည့်အကြား ကြီးမားသော ကွာခြားချက် ရှိပါသည်။

ဤသည်မှာ အမှန်တကယ် system များတွင် အမြဲတမ်းလိုလို တွေ့ရသော pattern တစ်ခုဖြစ်သည်။

web application တစ်ခုသည် JSON payload တစ်ခုကို လက်ခံရရှိပြီး redirect_url ကို ထုတ်ယူကာ allowlist regex နှင့် validation လုပ်သည်၊ ထို့နောက် URL-decode လုပ်ပြီး ရလာဒ်ကို redirect handler သို့ ပေးပို့သည်။

ပုံမှန် source-to-sink report တစ်ခုက flow ကို ဤသို့ ဖော်ပြနိုင်သည်။

untrusted input → regex check → URL decode → redirect

သို့သော် အမှန်တကယ် မေးခွန်းမှာ check ရှိသလားဆိုတာ မဟုတ်ပါ။ နောက်ပိုင်း transformation များပြီးနောက် ထို check သည် တန်ဖိုးကို ဆက်လက် ကန့်သတ်ပေးနေသေးသလားဆိုတာ ဖြစ်သည်။

regex ကို decoding မလုပ်မီ run လုပ်ပါက၊ redirect handler က အဓိပ္ပာယ်ဖွင့်ဆိုသည့် decoded URL ကို ၎င်းက အမှန်တကယ် ကန့်သတ်ပေးနိုင်သလား။

ထိုမေးခွန်းကို ဖြေရန် transformation chain တစ်လျှောက်လုံးကို ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးရမည်။ regex က ဘာကို ခွင့်ပြုသလဲ၊ decoding နှင့် normalization တို့က မည်သို့ အလုပ်လုပ်သလဲ၊ URL parsing က edge case များကို မည်သို့ ကိုင်တွယ်သလဲ၊ redirect logic က schemes နှင့် authorities များကို မည်သို့ ဖြေရှင်းသလဲ စသည်တို့ ဖြစ်သည်။

လက်တွေ့တွင် အရေးကြီးသည့် အားနည်းချက်များစွာသည် ဤပုံစံမျိုးဖြစ်သည်။ order-of-operations အမှားများ၊ partial normalization၊ parsing ambiguity များနှင့် validation နှင့် interpretation ကြား မကိုက်ညီမှုများ ဖြစ်သည်။ dataflow ကို မြင်နိုင်သည်။ အားနည်းချက်က constraints များသည် transformation chain တစ်လျှောက် မည်သို့ ဆက်လက်သက်ရောက်သလဲ—သို့မဟုတ် မသက်ရောက်ဘဲ ပျက်ကွက်သွားသလဲ—ဆိုသည့်နေရာတွင် ရှိသည်။

ဤသည်မှာ သီအိုရီသက်သက် pattern မဟုတ်ပါ။ CVE-2024-29041⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) တွင် Express သည် malformed URL များက redirect target များကို encode လုပ်ပြီးနောက် အဓိပ္ပာယ်ဖွင့်ဆိုသည့် နည်းလမ်းကြောင့် common allowlist implementation များကို ကျော်လွှားနိုင်သည့် open redirect ပြဿနာတစ်ခု၏ သက်ရောက်မှုကို ခံခဲ့ရသည်။ dataflow သည် ရိုးရှင်းခဲ့သည်။ ပိုခက်ခဲသည့် မေးခွန်း—နှင့် bug အမှန်တကယ်ရှိမရှိကို ဆုံးဖြတ်ပေးသည့် မေးခွန်း—မှာ transformation chain ပြီးနောက် validation သည် ဆက်လက် ခိုင်မာနေသေးသလားဆိုတာ ဖြစ်သည်။

Codex Security ကို ရိုးရှင်းသော ရည်မှန်းချက်တစ်ခုအပေါ် အခြေခံ၍ တည်ဆောက်ထားသည်။ ပိုမိုခိုင်မာသော အထောက်အထားရှိသည့် issue များကို ဖော်ထုတ်ပေးခြင်းဖြင့် triage ကို လျှော့ချရန် ဖြစ်သည်။ product ထဲတွင် ၎င်းသည် repo-specific context (threat model အပါအဝင်) ကို အသုံးပြုပြီး high-signal issue များကို isolated environment တစ်ခုအတွင်း validate လုပ်ပြီးမှ surface လုပ်ခြင်းကို ဆိုလိုသည်။ 

Codex Security သည် “validation” သို့မဟုတ် “sanitization” ဟု ထင်ရသည့် boundary တစ်ခုကို တွေ့သောအခါ၊ ၎င်းကို checkbox တစ်ခုလို မဆက်ဆံပါ။ code က ဘာကို အာမခံရန် ကြိုးစားနေသည်ကို နားလည်ရန် ကြိုးစားပြီး၊ ထို့နောက် ထိုအာမခံချက်ကို ချိုးဖောက်နိုင်ကြောင်း သက်သေပြရန် ကြိုးစားသည်။

လက်တွေ့တွင် ဤသည်မှာ အောက်ပါတို့ ရောနှောပါဝင်သည့် ပုံစံမျိုး ဖြစ်လေ့ရှိသည်။

• သက်ဆိုင်ရာ code path ကို repository context အပြည့်အစုံဖြင့် လုံခြုံရေးသုတေသီတစ်ဦး ဖတ်ရှုမည့်ပုံစံအတိုင်း ဖတ်ရှုပြီး intent နှင့် implementation ကြား မကိုက်ညီမှုများကို ရှာဖွေခြင်း။ ၎င်းတွင် comments များပါဝင်သော်လည်း မော်ဒယ် သည် comments များကို အလိုအလျောက် မယုံကြည်ပါ။ ထို့ကြောင့် သင့် code အပေါ်တွင် //Halvar says: this is not a bug ဟု ထည့်ရေးထားခြင်းက အမှန်တကယ် bug ရှိနေပါက ၎င်းကို မရှုပ်ထွေးစေပါ။
• ပြဿနာကို စမ်းသပ်နိုင်သည့် အငယ်ဆုံးအပိုင်းသို့ လျှော့ချခြင်း (ဥပမာ input တစ်ခုတည်းပတ်လည် transformation pipeline) ဖြင့် ကျန် system ၏ အနှောင့်အယှက်မရှိဘဲ ၎င်းကို ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးနိုင်ရန် လုပ်ဆောင်ခြင်း။ ဤအဓိပ္ပာယ်ဖြင့် Codex Security သည် code slice သေးသေးလေးများကို ထုတ်ယူပြီး ထိုအပိုင်းများအတွက် micro-fuzzer များကို ရေးသားသည်။
• check တစ်ခုချင်းစီကို သီးခြားစီ ဆက်ဆံမည့်အစား transformation များတစ်လျှောက် constraints များကို ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးခြင်း။ လိုအပ်သည့်အခါ satisfiability question အဖြစ် formalization လုပ်ခြင်းလည်း ပါဝင်နိုင်သည်။ တစ်နည်းအားဖြင့် ကျွန်ုပ်တို့သည် မော်ဒယ် ကို z3-solver ပါသော Python environment တစ်ခု အသုံးပြုခွင့်ပေးထားပြီး၊ အထူးရှုပ်ထွေးသော input constraint ပြဿနာတစ်ခုကို လူတစ်ဦး ဖြေရှင်းရမည့်အတိုင်း လိုအပ်သည့်အခါ ၎င်းကို ကောင်းစွာ အသုံးပြုနိုင်သည်။ ၎င်းသည် non-standard architecture များတွင် integer overflow ကဲ့သို့သော bug များကို စစ်ဆေးရာတွင် အထူးအသုံးဝင်သည်။
• ဖြစ်နိုင်သည့်အခါ hypotheses များကို sandboxed validation environment တစ်ခုအတွင်း execute လုပ်ခြင်းဖြင့် “ဤအရာသည် ပြဿနာ ဖြစ်နိုင်သည်” နှင့် “ဤအရာသည် ပြဿနာ အမှန်တကယ် ဖြစ်သည်” တို့ကို ခွဲခြားနိုင်ရန် လုပ်ဆောင်ခြင်း။ debug mode ဖြင့် compile လုပ်ထားသော code အတွက် end-to-end PoC အပြည့်အစုံထက် ပိုကောင်းသော သက်သေ မရှိပါ။ 

ဤသည်မှာ အဓိက ပြောင်းလဲမှုဖြစ်သည်။ “check တစ်ခု ရှိသည်” ဆိုသည့်နေရာတွင် ရပ်မနေဘဲ စနစ်သည် “invariant သည် ခိုင်မာသည် (သို့မဟုတ် မခိုင်မာပါ)၊ ၎င်းအတွက် အထောက်အထားက ဒီမှာပါ” ဆိုသည့်အဆင့်သို့ တွန်းပို့သည်။ ထိုအလုပ်အတွက် အကောင်းဆုံး tool ကိုလည်း မော်ဒယ် က ရွေးချယ်သည်။

သင့်တင့်သည့် တုံ့ပြန်မှုတစ်ခုက “နှစ်မျိုးလုံး လုပ်လို့ ဘာဖြစ်မလဲ” ဟူ၍ ဖြစ်နိုင်သည်။ SAST report တစ်ခုဖြင့် စတင်ပြီးနောက် အေးဂျင့် ကို ပိုမိုနက်ရှိုင်းစွာ ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးခိုင်းမည်။

ကြိုတင်တွက်ချက်ထားသော findings များသည်—အထူးသဖြင့် ကန့်သတ်ထားသော၊ သိထားပြီးသား bug class များအတွက်—အသုံးဝင်နိုင်သည့် အခြေအနေများ ရှိပါသည်။ သို့သော် context အတွင်း အားနည်းချက်များကို ရှာဖွေပြီး validate လုပ်ရန် ဒီဇိုင်းဆွဲထားသော အေးဂျင့် တစ်ခုအတွက် SAST report မှ စတင်ခြင်းက ကြိုတင်မှန်းဆနိုင်သော failure mode သုံးမျိုးကို ဖန်တီးပေးသည်။

ပထမအချက်အနေဖြင့် ၎င်းသည် စောလွန်းစွာ နယ်ပယ်ကျဉ်းမြောင်းသွားရန် အားပေးနိုင်သည်။ findings list တစ်ခုသည် tool တစ်ခုက ရှာဖွေပြီးသား နေရာများ၏ map တစ်ခုဖြစ်သည်။ ၎င်းကို စတင်ရာအမှတ်အဖြစ် ဆက်ဆံပါက စနစ်သည် တူညီသော နေရာဒေသများတွင် တူညီသော abstraction များဖြင့် အချိုးမမျှစွာ အားစိုက်သွားနိုင်ပြီး၊ tool ၏ worldview နှင့် မကိုက်ညီသော issue class များကို လွတ်သွားနိုင်သည်။

ဒုတိယအချက်အနေဖြင့် ၎င်းသည် ပြန်လည်ဖြုတ်ရခက်သော implicit judgment များကို ထည့်သွင်းပေးနိုင်သည်။ SAST findings များစွာတွင် sanitization၊ validation သို့မဟုတ် trust boundary များအပေါ် assumption များ ပါဝင်နေတတ်သည်။ ထို assumption များက မှားနေပါက—သို့မဟုတ် မပြည့်စုံပါက—၎င်းတို့ကို reasoning loop ထဲသို့ ထည့်ပေးခြင်းက အေးဂျင့် ကို “စုံစမ်းပါ” ဆိုသည့်အနေအထားမှ “အတည်ပြု သို့မဟုတ် ပယ်ချပါ” ဆိုသည့်အနေအထားသို့ ရွှေ့ပေးနိုင်ပြီး၊ ၎င်းသည် ကျွန်ုပ်တို့ လိုချင်သည့် အေးဂျင့် ၏ လုပ်ဆောင်ပုံ မဟုတ်ပါ။

တတိယအချက်အနေဖြင့် ၎င်းသည် reasoning system ကို အကဲဖြတ်ရန် ပိုမိုခက်ခဲစေနိုင်သည်။ pipeline သည် SAST output ဖြင့် စတင်ပါက အေးဂျင့် က ၎င်း၏ ကိုယ်ပိုင် analysis မှတစ်ဆင့် ရှာဖွေတွေ့ရှိခဲ့သည်များနှင့် အခြား tool တစ်ခုမှ အမွေဆက်ခံလာသည်များကို ခွဲခြားရန် ခက်ခဲသွားသည်။ ထိုခွဲခြားမှုသည် စနစ်၏ စွမ်းရည်များကို တိတိကျကျ တိုင်းတာလိုပါက အရေးကြီးပြီး၊ ထိုတိုင်းတာမှုကပင် စနစ်သည် အချိန်ကြာလာသည်နှင့်အမျှ တိုးတက်လာရန် လိုအပ်သော အရာဖြစ်သည်။

ထို့ကြောင့် ကျွန်ုပ်တို့သည် Codex Security ကို လုံခြုံရေးသုတေသန စတင်သည့် နေရာမှ စတင်ရန် တည်ဆောက်ခဲ့သည်။ code နှင့် စနစ်၏ intent မှ စတင်ပြီး၊ လူတစ်ဦးကို အနှောင့်အယှက်မပြုမီ confidence bar ကို မြှင့်တင်ရန် validation ကို အသုံးပြုသည်။

SAST tool များသည် ၎င်းတို့ ဒီဇိုင်းဆွဲထားသည့် အလုပ်များတွင် အလွန်ကောင်းနိုင်သည်။ secure coding standards များကို အတည်ပြုလိုက်နာစေခြင်း၊ ရိုးရှင်းသော source-to-sink issue များကို ဖမ်းယူခြင်းနှင့် သိထားပြီးသော pattern များကို ကြိုတင်ခန့်မှန်းနိုင်သော tradeoff များဖြင့် အတိုင်းအတာကြီးမားစွာ detect လုပ်ခြင်းတို့ ဖြစ်သည်။ ၎င်းတို့သည် defense-in-depth ၏ အားကောင်းသော အစိတ်အပိုင်းတစ်ခု ဖြစ်နိုင်သည်။

ဤ post ၏ အာရုံစိုက်ရာက ပိုကျဉ်းမြောင်းသည်။ behavior အပေါ် ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးပြီး findings များကို validate လုပ်ရန် ဒီဇိုင်းဆွဲထားသော အေးဂျင့် တစ်ခုသည် static findings list တစ်ခုကို အခြေခံအမှတ်အဖြစ် မစတင်သင့်သည့် အကြောင်းကို ဆွေးနွေးထားခြင်း ဖြစ်သည်။

pure source-to-sink thinking ၏ ဆက်စပ်သော ကန့်သတ်ချက်တစ်ခုကိုလည်း ဖော်ပြသင့်ပါသည်။ အားနည်းချက်တိုင်းသည် dataflow ပြဿနာ မဟုတ်ပါ။ အမှန်တကယ် ဖြစ်ပွားသည့် fail များစွာမှာ state နှင့် invariant ပြဿနာများဖြစ်သည်—workflow bypass များ၊ authorization gap များနှင့် “စနစ်က မှားယွင်းသော state ထဲတွင် ရှိနေသည်” ဆိုသည့် bug များ ဖြစ်သည်။ ဤ bug အမျိုးအစားများတွင် tainted value တစ်ခုသည် “dangerous sink” တစ်ခုတည်းသို့ မရောက်ရှိပါ။ အန္တရာယ်မှာ program က အမြဲတမ်း မှန်နေရမည်ဟု ထင်မြင်ထားသည့် အရာများထဲတွင် ရှိသည်။ 

လုံခြုံရေး tooling ecosystem သည် ဆက်လက် တိုးတက်လာမည်ဟု ကျွန်ုပ်တို့ မျှော်လင့်ပါသည်။ static analysis၊ fuzzing၊ runtime guard များနှင့် agentic workflow များသည် အားလုံးတွင် မိမိတို့၏ အခန်းကဏ္ဍများ ရှိနေမည်ဖြစ်သည်။

Codex Security ကို ကျွန်ုပ်တို့ ကောင်းမွန်စေချင်သည့် အပိုင်းမှာ လုံခြုံရေးအဖွဲ့များအတွက် အကုန်အကျများဆုံး အပိုင်းဖြစ်သည်။ “ဒါက သံသယဖြစ်ဖွယ်လိုပဲ” ကို “ဒါက အမှန်တကယ် ဖြစ်တယ်၊ ဘယ်လိုပျက်ကွက်သလဲက ဒီမှာ၊ ပြီးတော့ စနစ်၏ intent နှင့် ကိုက်ညီသော fix က ဒီမှာ” ဟူ၍ ပြောင်းလဲပေးခြင်း ဖြစ်သည်။ 

Codex Security သည် repository များကို မည်သို့ scan လုပ်သလဲ၊ findings များကို မည်သို့ validate လုပ်သလဲ၊ နှင့် fix များကို မည်သို့ propose လုပ်သလဲဆိုတာကို ပိုမိုလေ့လာလိုပါက ကျွန်ုပ်တို့၏ documentation⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ကို ကြည့်ပါ။