Codex Security яагаад SAST тайланг агуулдаггүй вэ

Олон арван жилийн турш статик хэрэглээний аюулгүй байдлын тест (SAST) нь аюулгүй байдлын багууд кодын хяналтыг өргөжүүлэх хамгийн үр дүнтэй аргуудын нэг байсаар ирсэн.

Гэхдээ бид Codex Security-ийг бүтээхдээ зориудын нэг архитектурын сонголт хийсэн: бид статик шинжилгээний тайлан импортлоод агент-аар түүнийг ангилуулах замаар эхлээгүй. Харин системийг репозитор өөрөөс нь—түүний архитектур, итгэлийн хил хязгаар, зориулагдсан үйлдлээс—эхэлж, олсон зүйлээ хүнд цаг зарцуулахыг хүсэхээсээ өмнө баталгаажуулахаар зохион бүтээсэн.

Шалтгаан нь энгийн: хамгийн хэцүү эмзэг байдал ихэвчлэн өгөгдлийн урсгалын асуудал байдаггүй. Код нь аюулгүй байдлын шалгалт хийж байгаа мэт харагддаг ч тэр шалгалт нь системийн тулгуурладаг шинж чанарыг үнэндээ баталгаажуулдаггүй үед тэд үүсдэг. Өөрөөр хэлбэл, сорилт нь зөвхөн өгөгдөл програм дундуур хэрхэн хөдөлж байгааг мөрдөхөд биш—код дахь хамгаалалтууд үнэхээр ажиллаж байгаа эсэхийг тогтооход байдаг.

SAST-ийг ихэвчлэн цэвэр дамжлага гэж тайлбарладаг: найдвартай бус оролтын эх үүсвэрийг тодорхойлох, өгөгдлийг програм дундуур мөрдөх, дараа нь тэр өгөгдөл ариутгалгүйгээр мэдрэмтгий sink-д хүрсэн тохиолдлыг тэмдэглэх. Энэ нь дэгжин загвар бөгөөд бодит олон алдааг хамардаг.

Практикт SAST нь цар хүрээтэйгээр хэрэгжихийн тулд ойролцоолол хийхээс өөр аргагүй—ялангуяа дам заалт, динамик диспетчер, callback, reflection, framework ихтэй удирдлагын урсгал бүхий бодит кодын сангуудад. Эдгээр ойролцоолол нь SAST-ийн сул тал биш; кодыг ажиллуулахгүйгээр түүний тухай дүгнэх оролдлогын бодит нөхцөл юм.

Гэхдээ зөвхөн энэ нь Codex Security яагаад SAST тайлангаас эхэлдэггүй шалтгаан биш.

Илүү гүн асуудал нь эх үүсвэрээс sink хүртэлх замыг амжилттай мөрдсөний дараа юу болдогт оршдог.

Статик шинжилгээ оролтыг олон функц, давхаргаар зөв мөрдсөн байсан ч эмзэг байдал үнэхээр байгаа эсэхийг тодорхойлдог гол асуултад хариулах ёстой:

Түгээмэл хэв маяг авч үзье: код найдвартай бус агуулгыг дүрслэхийн өмнө sanitize_html() шиг зүйлийг дууддаг. Статик анализатор ариутгагч ажилласныг харж чадна. Гэхдээ тухайн ариутгагч нь тухайн дүрслэх контекст, template engine, кодчлолын үйлдэл, дараах хөрвүүлэлтүүдэд үнэхээр хангалттай эсэхийг ихэнхдээ тогтоож чаддаггүй.

Эндээс л асуудал төвөгтэй болдог. Асуудал нь зөвхөн өгөгдөл sink-д хүрч байгаа эсэхэд биш. Харин код дахь шалгалтууд утгыг системийн таамаглаж буй байдлаар үнэхээр хязгаарлаж байна уу гэдэгт бий.

Өөрөөр хэлбэл: “код ариутгагч дууддаг” ба “систем аюулгүй” гэдэг хоёрын хооронд том ялгаа бий.

Энд бодит системүүдэд байнга гардаг нэг хэв маяг байна.

Вэб аппликейшн JSON payload хүлээн авч, redirect_url-ийг салгаж, allowlist regex-ээр шалгаад, URL decode хийж, дараа нь үр дүнг redirect handler руу дамжуулдаг.

Сонгодог эх үүсвэрээс sink хүртэлх тайлан урсгалыг ингэж тайлбарлаж чадна:

найдваргүй оролт → regex шалгалт → URL decode → redirect

Гэхдээ жинхэнэ асуулт нь шалгалт байгаа эсэх биш. Харин дараах хөрвүүлэлтүүдийн дараа тэр шалгалт утгыг мөн л хязгаарлаж хэвээр байна уу гэдэг юм.

Хэрэв regex нь decode хийхээс өмнө ажилладаг бол redirect handler-ийн тайлбарладаг decode хийгдсэн URL-ийг үнэхээр зөв хязгаарлаж чаддаг уу?

Үүнд хариулахын тулд бүх хөрвүүлэлтийн гинжийг авч үзэн дүгнэх шаардлагатай: regex юу зөвшөөрдөг, decode ба normalization хэрхэн ажилладаг, URL parsing захын тохиолдлуудыг яаж авч үздэг, мөн redirect логик scheme ба authority-г хэрхэн шийддэг зэрэг.

Практикт чухал эмзэг байдлуудын олонх нь ийм байдаг: үйлдлийн дарааллын алдаа, хэсэгчилсэн normalization, parsing-ийн хоёрдмол байдал, баталгаажуулалт ба тайлбарлалтын хоорондын зөрүү. Өгөгдлийн урсгал нь харагдаж байдаг. Харин сул тал нь хязгаарлалтууд хөрвүүлэлтийн гинжээр хэрхэн дамждаг—эсвэл дамжиж чаддаггүйд байдаг.

Энэ нь зүгээр онолын хэв маяг биш. CVE-2024-29041⁠(шинэ цонхонд нээгдэнэ)-д Express нь malformed URL-ууд redirect зорилтыг кодолж дараа нь тайлбарлах аргаас шалтгаалан нийтлэг allowlist хэрэгжүүлэлтүүдийг тойрч чаддаг байсан open redirect асуудалд өртсөн. Өгөгдлийн урсгал нь ойлгомжтой байсан. Харин илүү хэцүү асуулт—мөн алдаа үнэхээр байсан эсэхийг шийдсэн зүйл—нь хөрвүүлэлтийн гинжийн дараа баталгаажуулалт хүчинтэй хэвээр байсан уу гэдэг байв.

Codex Security нь нэг энгийн зорилгын эргэн тойронд бүтээгдсэн: илүү хүчтэй нотолгоотой асуудлыг гаргаж ирснээр triage-ийг багасгах. Бүтээгдэхүүн дээр энэ нь репозиторын онцлог контекстийг (аюулын загвар зэрэг) ашиглаж, өндөр дохиотой асуудлуудыг тусгаарлагдсан орчинд баталгаажуулсны дараа л гаргаж ирнэ гэсэн үг.

Codex Security “баталгаажуулалт” эсвэл “ариутгал” мэт харагдах хил хязгаартай тулгарах үедээ үүнийг зүгээр нэг checkbox гэж үздэггүй. Код юу баталгаажуулах гэж оролдож байгааг ойлгохыг хичээдэг—дараа нь тэр баталгааг няцаахыг оролддог.

Практикт энэ нь ихэвчлэн дараах зүйлсийн хослол шиг харагддаг:

• Холбогдох кодын замыг репозиторын бүрэн контексттэйгээр, яг аюулгүй байдлын судлаач шиг уншиж, санаархал ба хэрэгжилтийн хоорондын зөрүүг хайх. Үүнд сэтгэгдлүүд ч орно, гэхдээ загвар нь сэтгэгдэлд заавал итгэдэггүй тул кодын дээр //Halvar says: this is not a bug гэж нэмсэн ч үнэхээр алдаа байвал төөрөгдөхгүй.
• Асуудлыг туршиж болох хамгийн жижиг хэсэг хүртэл бууруулах (жишээлбэл, нэг оролтын эргэн тойрны хөрвүүлэлтийн pipeline), ингэснээр системийн бусад хэсэг саад болохгүйгээр түүн дээр дүгнэж болно. Энэ утгаараа Codex Security кодын маш жижиг хэсгүүдийг сугалж аваад, дараа нь тэдгээрт зориулсан micro-fuzzer бичдэг.
• Шалгалт бүрийг тусгаарлан үзэхийн оронд хөрвүүлэлтүүд дамнасан хязгаарлалтуудын талаар сэтгэн бодох. Тохиромжтой үед үүнд satisfiability асуудал болгон томьёолох ч орж болно. Өөрөөр хэлбэл, бид загварт z3-solver бүхий Python орчинд хандах боломж олгодог бөгөөд онцгой төвөгтэй оролтын хязгаарлалтын асуудалд хүн ашиглах ёстойтой адил шаардлагатай үедээ үүнийг сайн ашигладаг. Энэ нь ялангуяа стандарт бус архитектур дээрх integer overflow зэрэг алдааг харахад хэрэгтэй.
• Боломжтой үед таамгуудыг sandboxed баталгаажуулалтын орчинд ажиллуулж, “энэ асуудал байж магадгүй” гэдгийг “энэ бол асуудал мөн” гэдгээс ялгах. Кодыг debug mode-д хөрвүүлсэн бүрэн end-to-end PoC-оос илүү сайн нотолгоо гэж үгүй.

Энэ бол гол өөрчлөлт: “шалгалт байна” дээр зогсохын оронд систем “invariant хадгалагдаж байна (эсвэл үгүй), харин энд нотолгоо нь байна” руу түлхдэг. Мөн загвар энэ ажлын хамгийн зөв хэрэгслийг сонгодог.

Эндээс гарах боломжит хариу нь: яагаад хоёуланг нь ашиглаж болохгүй гэж? SAST тайлангаас эхлээд, дараа нь агент-аар илүү гүн сэтгэн бодож болно шүү дээ.

Урьдчилан тооцоолсон findings зарим тохиолдолд, ялангуяа нарийн тодорхой мэдэгдсэн алдааны ангиллуудад, ашигтай байж болно. Гэхдээ контекст дотор эмзэг байдал илрүүлж, баталгаажуулахаар бүтээгдсэн агентын хувьд SAST тайлангаас эхлэх нь урьдчилан таамаглаж болох гурван алдааны горим үүсгэдэг.

Нэгдүгээрт, энэ нь хэт эрт нарийсгах хандлага төрүүлж болно. Findings жагсаалт нь хэрэгсэл аль хэдийн хаашаа харсны газрын зураг юм. Хэрэв та түүнийг эхлэх цэг болговол, систем ижил бүсүүдэд, ижил хийсвэрлэл ашиглан, хэт их хүчин чармайлт зарцуулах хандлагатай болж, тухайн хэрэгслийн ертөнцийг харах өнцөгт багтдаггүй асуудлын ангиллуудыг алдаж болно.

Хоёрдугаарт, үүнийг буцааж салгахад хэцүү далд шүүлтүүдийг оруулж болно. Олон SAST findings нь ариутгал, баталгаажуулалт, эсвэл итгэлийн хил хязгаарын талаархи таамаглал агуулдаг. Хэрэв тэдгээр таамаг буруу—эсвэл зүгээр л дутуу—байвал, тэдгээрийг сэтгэн бодох гогцоонд оруулах нь агент-ыг “судал” горимоос “баталгаажуул эсвэл үгүйсгэ” горим руу шилжүүлж болно, харин энэ нь бидний хүсэж буй зүйл биш.

Гуравдугаарт, энэ нь сэтгэн бодох системийг үнэлэхийг илүү хэцүү болгодог. Хэрэв дамжлага SAST гаралтаас эхэлбэл, агент өөрийн шинжилгээгээр юу нээсэн, өөр хэрэгслээс юу өвлөж авсныг салгаж ойлгоход төвөгтэй болно. Системийн чадварыг үнэн зөв хэмжихийг хүсвэл энэ ялгалт маш чухал бөгөөд ингэж初ноор систем цаг хугацааны явцад сайжрах боломжтой болдог.

Тиймээс бид Codex Security-ийг аюулгүй байдлын судалгаа эхэлдэг цэгээс эхлэхээр бүтээсэн: код болон системийн зорилгоос, мөн хүнийг тасалдуулахаасаа өмнө итгэлийн босгыг өсгөхийн тулд баталгаажуулалтыг ашигладаг байдлаар.

SAST хэрэгслүүд өөрсдөд нь зориулсан зүйлдээ маш сайн байж чадна: аюулгүй кодчиллын стандартыг мөрдүүлэх, энгийн эх үүсвэрээс sink хүртэлх асуудлуудыг барих, мөн мэдэгдсэн хэв маягуудыг урьдчилан таамаглаж болох солилцоотойгоор цар хүрээтэйгээр илрүүлэх. Тэд defense-in-depth-ийн хүчтэй хэсэг байж чадна.

Энэ нийтлэл илүү нарийн хүрээтэй: энэ нь үйлдлийн талаар сэтгэн бодож, findings-ийг баталгаажуулахаар бүтээгдсэн агент яагаад ажлаа статик findings жагсаалтад түшиглэн эхлүүлэх ёсгүй тухай юм.

Мөн цэвэр эх үүсвэрээс sink хүртэлх сэтгэлгээний холбоотой нэг хязгаарлалтыг онцлох нь зүйтэй: эмзэг байдал бүр өгөгдлийн урсгалын асуудал биш. Бодит олон эвдрэл нь төлөв ба invariant-ын асуудал байдаг—workflow bypass, authorization gap, мөн “систем буруу төлөвт байна” төрлийн алдаа. Ийм төрлийн алдаанд бохирдсон утга ганц “аюултай sink”-д хүрдэггүй. Эрсдэл нь програм юу үргэлж үнэн байна гэж таамаглаж байгаад оршдог.

Аюулгүй байдлын хэрэгслүүдийн экосистем цаашид ч сайжирсаар байна гэж бид үзэж байна: статик шинжилгээ, fuzzing, runtime guard, agentic workflow бүгд өөр өөр үүрэгтэй байх болно.

Бидний хүсэж буй зүйл бол Codex Security-ийг аюулгүй байдлын багуудад хамгийн их өртөгтэй хэсэгт сайн болгох: “энэ сэжигтэй харагдаж байна”-г “энэ бодит, ингэж эвдэрдэг, мөн системийн зорилгод нийцсэн засвар нь энд байна” болгон хувиргах.

Хэрэв та Codex Security репозиторуудад хэрхэн скан хийдэг, findings-ийг хэрхэн баталгаажуулдаг, мөн засвар хэрхэн санал болгодгийг илүү их мэдэхийг хүсвэл манай баримт бичгийг⁠(шинэ цонхонд нээгдэнэ) үзнэ үү.