Codex Security లో SAST రిపోర్ట్ ఎందుకు ఉండదు

దశాబ్దాలుగా, స్టాటిక్ అప్లికేషన్ సెక్యూరిటీ టెస్టింగ్ (SAST) సెక్యూరిటీ టీమ్స్ కోడ్ రివ్యూను స్కేల్ చేయడానికి అత్యంత ప్రభావవంతమైన పద్ధతుల్లో ఒకటి.

కానీ Codex Security ను నిర్మించినప్పుడు, మేము ఒక ఉద్దేశపూర్వక డిజైన్ ఎంపిక చేశాము: స్టాటిక్ అనాలిసిస్ రిపోర్ట్‌ను ఇంపోర్ట్ చేసి, ఏజెంట్‌ను దాన్ని ట్రయాజ్ చేయమని అడగడం తో ప్రారంభించలేదు. మేము సిస్టమ్‌ను రిపోజిటరీతోనే ప్రారంభమయ్యేలా డిజైన్ చేశాము—దాని ఆర్కిటెక్చర్, ట్రస్ట్ బౌండరీలు మరియు ఉద్దేశించిన బిహేవియర్ ఆధారంగా—మరియు అది కనుగొన్న విషయాలను మనిషి సమయం ఖర్చు చేసే ముందు వాలిడేట్ చేస్తుంది.

కారణం సులభం: అత్యంత క్లిష్టమైన వల్నరబిలిటీస్ సాధారణంగా డేటాఫ్లో సమస్యలు కావు. కోడ్ ఒక సెక్యూరిటీ చెక్‌ను అమలు చేస్తున్నట్లు కనిపించినా, ఆ చెక్ నిజంగా సిస్టమ్ ఆధారపడే ప్రాపర్టీని హామీ ఇవ్వని సమయంలో అవి జరుగుతాయి. మరో మాటలో చెప్పాలంటే, సవాలు కేవలం డేటా ప్రోగ్రామ్‌లో ఎలా కదులుతుందో ట్రాక్ చేయడం మాత్రమే కాదు—కోడ్‌లోని డిఫెన్సెస్ నిజంగా పనిచేస్తున్నాయా అనేది నిర్ణయించడం.

SAST ను సాధారణంగా ఒక క్లియర్ పైప్‌లైన్‌గా చూపిస్తారు: నమ్మదగని ఇన్‌పుట్ సోర్స్‌ను గుర్తించడం, ప్రోగ్రామ్‌లో డేటా ఎలా ప్రయాణిస్తుందో ట్రాక్ చేయడం, మరియు శుభ్రపరచకుండా ఆ డేటా సెన్సిటివ్ సింక్‌కు చేరిన సందర్భాలను ఫ్లాగ్ చేయడం. ఇది ఒక ఎలిగెంట్ మోడల్, మరియు ఇది చాలా నిజమైన బగ్స్‌ను కవర్ చేస్తుంది.

ప్రాక్టీస్‌లో, పెద్ద స్థాయిలో పని చేయడానికి SAST కొన్ని అప్రాక్సిమేషన్స్ చేయాల్సి వస్తుంది—ప్రత్యేకంగా ఇండైరెక్షన్, డైనమిక్ డిస్పాచ్, కాల్‌బ్యాక్స్, రిఫ్లెక్షన్ మరియు ఫ్రేమ్‌వర్క్-హెవీ కంట్రోల్ ఫ్లో ఉన్న నిజమైన కోడ్‌బేస్‌లలో. ఆ అప్రాక్సిమేషన్స్ SAST లో లోపం కాదు; కోడ్‌ను ఎగ్జిక్యూట్ చేయకుండా దానిపై రీజన్ చేయడానికి ప్రయత్నించడం యొక్క వాస్తవ పరిస్థితి.

అది ఒక్కటే కారణం కాదు Codex Security SAST రిపోర్ట్‌తో ప్రారంభించకపోవడానికి.

అసలు లోతైన సమస్య ఏమిటంటే, మీరు సోర్స్ నుంచి సింక్ వరకు ట్రేస్ చేసిన తర్వాత ఏమి జరుగుతుందనేది.

స్టాటిక్ అనాలిసిస్ అనేక ఫంక్షన్స్ మరియు లేయర్స్‌లో ఇన్‌పుట్‌ను సరిగ్గా ట్రేస్ చేసినప్పటికీ, వాస్తవంగా వల్నరబిలిటీ ఉందో లేదో నిర్ణయించే ప్రశ్నకు ఇంకా సమాధానం చెప్పాల్సి ఉంటుంది:

ఒక సాధారణ ప్యాటర్న్‌ను తీసుకుందాం: నమ్మకంలేని కంటెంట్‌ను రెండర్ చేయడానికి ముందు కోడ్ sanitize_html() వంటి ఫంక్షన్‌ను కాల్ చేస్తుంది. ఒక స్టాటిక్ అనాలైజర్ ఆ సానిటైజర్ నడిచిందని గుర్తించగలదు. కానీ అది సాధారణంగా నిర్ణయించలేనిది ఏమిటంటే, ఆ సానిటైజర్ నిజంగా నిర్దిష్ట రెండరింగ్ కాంటెక్స్ట్, టెంప్లేట్ ఇంజిన్, ఎన్‌కోడింగ్ బిహేవియర్ మరియు తరువాతి ట్రాన్స్‌ఫార్మేషన్స్‌కు సరిపోతుందా అన్నది.

ఇక్కడే విషయం క్లిష్టంగా మారుతుంది. సమస్య కేవలం డేటా సింక్‌కు చేరుతుందా అన్నది మాత్రమే కాదు. కోడ్‌లో ఉన్న చెక్స్ నిజంగా సిస్టమ్ అనుకున్న విధంగా విలువను నియంత్రిస్తున్నాయా అన్నదే అసలు ప్రశ్న.

మరో విధంగా చెప్పాలంటే: “కోడ్ ఒక సానిటైజర్‌ను కాల్ చేస్తుంది” మరియు “సిస్టమ్ సురక్షితంగా ఉంది” మధ్య పెద్ద తేడా ఉంది.

నిజమైన సిస్టమ్స్‌లో తరచుగా కనిపించే ఒక ప్యాటర్న్ ఇది.

ఒక వెబ్ అప్లికేషన్ JSON పేలోడ్‌ను స్వీకరిస్తుంది, అందులోని redirect_url ను తీసుకుని allowlist రెగ్యెక్స్‌తో వాలిడేట్ చేస్తుంది, తర్వాత URL డీకోడ్ చేసి ఫలితాన్ని రీడైరెక్ట్ హ్యాండ్లర్‌కు పంపిస్తుంది.

ఒక క్లాసిక్ సోర్స్-టు-సింక్ రిపోర్ట్ ఈ ఫ్లోను వివరిస్తుంది:

నమ్మదగని ఇన్‌పుట్ → రెగ్యెక్స్ చెక్ → URL డీకోడ్ → రీడైరెక్ట్

కానీ అసలు ప్రశ్న ఆ చెక్ ఉందా లేదా అన్నది కాదు. దాని తర్వాత జరిగే ట్రాన్స్‌ఫార్మేషన్స్ తర్వాత కూడా ఆ చెక్ నిజంగా ఆ విలువను నియంత్రిస్తుందా అన్నదే అసలు విషయం.

రెగ్యెక్స్ డీకోడ్ చేసే ముందు నడిస్తే, అది డీకోడ్ చేసిన URL ను రీడైరెక్ట్ హ్యాండ్లర్ ఎలా అర్థం చేసుకుంటుందో ఆ విధంగా నిజంగా నియంత్రిస్తుందా?

దీనికి సమాధానం చెప్పాలంటే మొత్తం ట్రాన్స్‌ఫార్మేషన్ చైన్ గురించి రీజన్ చేయాలి: రెగ్యెక్స్ ఏమి అనుమతిస్తుంది, డీకోడింగ్ మరియు నార్మలైజేషన్ ఎలా పనిచేస్తాయి, URL పార్సింగ్ ఎడ్జ్ కేసులను ఎలా పరిగణిస్తుంది, అలాగే రీడైరెక్ట్ లాజిక్ స్కీమ్స్ మరియు అథారిటీస్‌ను ఎలా రిజాల్వ్ చేస్తుంది.

ప్రాక్టీస్‌లో ముఖ్యమైన అనేక వల్నరబిలిటీస్ ఇలానే కనిపిస్తాయి: ఆర్డర్-ఆఫ్-ఆపరేషన్స్‌లో పొరపాట్లు, పాక్షిక నార్మలైజేషన్, పార్సింగ్‌లో అస్పష్టతలు, మరియు వాలిడేషన్, ఇంటర్‌ప్రిటేషన్ మధ్య పొంతన లేకపోవడం. డేటాఫ్లో కనిపిస్తుంది. ట్రాన్స్‌ఫర్మేషన్ చైన్‌లో కన్‌స్ట్రెయింట్స్ ఎలా వ్యాపిస్తాయో—లేదా వ్యాపించడంలో విఫలమవుతాయో—అదే అసలైన బలహీనత.

ఇది కేవలం సిద్ధాంతపరమైన ప్యాటర్న్ మాత్రమే కాదు. CVE-2024-29041⁠(కొత్త విండోలో తెరుచుకుంటుంది)లో, Express ఒక ఓపెన్ రీడైరెక్ట్ సమస్యకు గురైంది, అక్కడ తప్పుగా రూపొందించిన URLs సాధారణ allowlist అమలు విధానాలను దాటిపోయాయి, ఎందుకంటే రీడైరెక్ట్ టార్గెట్లు ఎలా ఎన్‌కోడ్ చేయబడి తర్వాత ఎలా అర్థం చేసుకున్నారో దాని వల్ల. డేటాఫ్లో సూటిగా ఉంది. అసలు కఠినమైన ప్రశ్న—అలాగే బగ్ నిజంగా ఉందా లేదా అన్నది నిర్ణయించిన ప్రశ్న—ట్రాన్స్‌ఫార్మేషన్ చైన్ తర్వాత కూడా వాలిడేషన్ అలాగే నిలిచిందా అన్నదే.

Codex Security ఒక సింపుల్ లక్ష్యంతో నిర్మించబడింది: బలమైన సాక్ష్యాలతో ఇష్యూస్‌ను చూపిస్తూ ట్రయాజ్‌ను తగ్గించడం. ప్రోడక్ట్‌లో, దీని అర్థం repo-స్పెసిఫిక్ కాంటెక్స్ట్ (థ్రెట్ మోడల్ సహా)ను ఉపయోగించి, హై-సిగ్నల్ ఇష్యూస్‌ను బయటకు చూపించే ముందు ఐసోలేటెడ్ ఎన్విరాన్‌మెంట్‌లో వాలిడేట్ చేయడం.

Codex Security “వాలిడేషన్” లేదా “సానిటైజేషన్”లా కనిపించే బౌండరీని చూసినప్పుడు, దాన్ని కేవలం చెక్‌బాక్స్‌గా పరిగణించదు. కోడ్ ఏ గ్యారంటీ ఇవ్వడానికి ప్రయత్నిస్తుందో అర్థం చేసుకుని—తర్వాత ఆ గ్యారంటీని తప్పు అని నిరూపించడానికి ప్రయత్నిస్తుంది.

ప్రాక్టీస్‌లో, ఇది సాధారణంగా ఈ వాటి మిశ్రమంలా ఉంటుంది:

• పూర్తి రిపోజిటరీ కాంటెక్స్ట్‌తో సంబంధిత కోడ్ పాత్‌ను చదవడం, సెక్యూరిటీ రీసెర్చర్‌లా విశ్లేషించడం, మరియు ఉద్దేశ్యం మరియు అమలు మధ్య తేడాలను గుర్తించడం. ఇందులో కామెంట్స్ కూడా ఉంటాయి, కానీ మోడల్ కామెంట్స్‌ను తప్పనిసరిగా నమ్మదు కాబట్టి మీ కోడ్ పై //Halvar చెబుతున్నాడు: ఇది బగ్ కాదు అని చేర్చినా, నిజంగా బగ్ ఉంటే అది మోడల్‌ను గందరగోళానికి గురి చేయదు.
• సమస్యను చిన్నగా టెస్ట్ చేయగల స్లైస్‌గా తగ్గించడం (ఉదాహరణకు, ఒకే ఇన్‌పుట్ చుట్టూ ఉన్న ట్రాన్స్‌ఫార్మేషన్ పైప్‌లైన్), తద్వారా మిగతా సిస్టమ్ అడ్డంకి లేకుండా దానిపై రీజన్ చేయగలగడం. ఈ విధంగా, Codex Security చిన్న కోడ్ స్లైస్‌లను తీసుకుని, వాటి కోసం మైక్రో-ఫజర్స్‌ను రాస్తుంది.
• ప్రతి చెక్‌ను విడిగా చూడకుండా, ట్రాన్స్‌ఫర్మేషన్స్ అంతటా కన్‌స్ట్రెయింట్స్‌పై రీజనింగ్ చేయడం. అవసరమైనప్పుడు, దీనిని సాటిస్‌ఫైయబిలిటీ ప్రశ్నగా ఫార్మలైజేషన్ చేయవచ్చు. మరో విధంగా చెప్పాలంటే, మేము మోడల్‌కు z3-solver ఉన్న Python ఎన్విరాన్‌మెంట్‌కు యాక్సెస్ ఇస్తాము, మరియు అవసరమైనప్పుడు దాన్ని బాగా ఉపయోగిస్తుంది—ప్రత్యేకంగా క్లిష్టమైన ఇన్‌పుట్ కన్‌స్ట్రెయింట్ సమస్యను పరిష్కరించేటప్పుడు ఒక మనిషి ఎలా ఉపయోగిస్తాడో అలా. ఇది ముఖ్యంగా నాన్-స్టాండర్డ్ ఆర్కిటెక్చర్స్‌లో integer ఓవర్‌ఫ్లోస్ లేదా ఇలాంటి బగ్స్‌ను పరిశీలించడానికి చాలా ఉపయోగపడుతుంది.
• సాధ్యమైనప్పుడు, sandbox చేసిన వాలిడేషన్ ఎన్విరాన్‌మెంట్‌లో హైపోతెసిస్‌ను ఎగ్జిక్యూట్ చేసి “ఇది సమస్య కావచ్చు” మరియు “ఇది నిజంగా సమస్య” మధ్య తేడాను గుర్తించడం. కోడ్‌ను డీబగ్ మోడ్‌లో కంపైల్ చేసి పూర్తి ఎండ్-టు-ఎండ్ PoC చూపించడం కంటే మెరుగైన సాక్ష్యం లేదు.

ఇదే కీలక మార్పు: “ఒక చెక్ ఉంది” వద్ద ఆగిపోకుండా, “ఇన్వేరియంట్ నిలుస్తుంది (లేదా నిలవదు), మరియు ఇదిగో సాక్ష్యం” అనే దిశగా సిస్టమ్ ముందుకు సాగుతుంది. ఆ పనికి సరైన టూల్‌ను మోడల్ స్వయంగా ఎంచుకుంటుంది.

సహజంగా వచ్చే ప్రశ్న ఇది: రెండూ ఎందుకు చేయకూడదు? ముందుగా SAST రిపోర్ట్‌తో ప్రారంభించి, తర్వాత ఏజెంట్‌ను ఉపయోగించి మరింత లోతుగా రీజన్ చేయవచ్చు.

ముందుగానే లభించిన ఫైండింగ్స్ ఉపయోగపడే సందర్భాలు ఉన్నాయి—ప్రత్యేకంగా పరిమితమైన, ఇప్పటికే తెలిసిన బగ్ క్లాసెస్‌లో. కానీ కాంటెక్స్ట్‌లో వల్నరబిలిటీస్‌ను కనుగొని వాలిడేట్ చేయడానికి రూపొందించిన ఏజెంట్ విషయంలో, SAST రిపోర్ట్‌తో ప్రారంభించడం మూడు ముందే ఊహించగల ఫెయిల్యూర్ మోడ్స్‌ను సృష్టిస్తుంది.

మొదటిగా, అది చాలా త్వరగా పరిధిని కుదించేలా ప్రోత్సహించవచ్చు. ఫైండింగ్స్ లిస్ట్ అనేది ఒక టూల్ ఇప్పటికే ఎక్కడ చూసిందో చూపించే మ్యాప్‌లాంటిది. దానిని ప్రారంభ బిందువుగా తీసుకుంటే, సిస్టమ్ అదే ప్రాంతాలపై అసమానంగా ఎక్కువ శ్రమ పెట్టేలా, అదే అబ్స్ట్రాక్షన్స్‌ను ఉపయోగించేలా, అలాగే టూల్ దృష్టికోణానికి సరిపోని ఇష్యూ క్లాసెస్‌ను మిస్ అయ్యేలా బైస్ కలగవచ్చు.

రెండవది, అది సులభంగా తొలగించలేని అంతర్లీన నిర్ణయాలను తీసుకురావచ్చు. చాలా SAST ఫైండింగ్స్ సానిటైజేషన్, వాలిడేషన్, లేదా ట్రస్ట్ బౌండరీల గురించి కొన్ని అంచనాలను కలిగి ఉంటాయి. ఆ అంచనాలు తప్పుగా ఉన్నా—లేదా అసంపూర్ణంగా ఉన్నా—వాటిని రీజనింగ్ లూప్‌లో ఇవ్వడం వల్ల ఏజెంట్ “ఇన్వెస్టిగేట్ చేయడం” నుంచి “కన్‌ఫర్మ్ చేయడం లేదా డిస్మిస్ చేయడం” వైపు మారిపోవచ్చు, కానీ ఏజెంట్ అలా పనిచేయాలని మేము కోరుకోవడం లేదు.

మూడవది, ఇది రీజనింగ్ సిస్టమ్‌ను అంచనా వేయడం మరింత కష్టతరం చేయవచ్చు. పైప్‌లైన్ SAST అవుట్‌పుట్‌తో ప్రారంభమైతే, ఏజెంట్ తన స్వంత అనాలిసిస్ ద్వారా ఏమి కనుగొన్నది మరియు మరో టూల్ నుండి ఏమి తీసుకున్నది అనే తేడాను గుర్తించడం కష్టమవుతుంది. సిస్టమ్ సామర్థ్యాలను ఖచ్చితంగా కొలవాలంటే ఈ తేడా చాలా ముఖ్యం, ఎందుకంటే కాలక్రమేణా సిస్టమ్ మెరుగుపడటానికి ఇది అవసరం.

అందుకే మేము Codex Security‌ను సెక్యూరిటీ రీసెర్చ్ ప్రారంభమయ్యే చోట నుంచే ప్రారంభమయ్యేలా రూపొందించాము: కోడ్ మరియు సిస్టమ్ ఉద్దేశం నుండి, అలాగే మనిషిని మధ్యలో ఇన్‌టరప్ట్ చేసే ముందు కాన్ఫిడెన్స్ స్థాయిని పెంచేందుకు వాలిడేషన్‌ను ఉపయోగిస్తూ.

SAST టూల్స్ వాటి కోసం రూపొందించిన పనుల్లో అద్భుతంగా పనిచేస్తాయి: సెక్యూర్ కోడింగ్ స్టాండర్డ్స్‌ను అమలు చేయడం, సింపుల్ సోర్స్-టు-సింక్ ఇష్యూలను పట్టుకోవడం, మరియు తెలిసిన ప్యాటర్న్స్‌ను స్కేల్‌లో గుర్తించడం—అంచనా వేయగల ట్రేడ్‌ఆఫ్స్‌తో. ఇవి డిఫెన్స్-ఇన్-డెప్త్‌లో బలమైన భాగంగా ఉండగలవు.

ఈ పోస్ట్ మరింత స్పెసిఫిక్‌గా ఉంది: బిహేవియర్‌పై రీజన్ చేసి ఫైండింగ్స్‌ను వాలిడేట్ చేయడానికి రూపొందించిన ఏజెంట్ తన పని స్టాటిక్ ఫైండింగ్స్ లిస్ట్‌తో ప్రారంభించకూడదనే విషయంపై ఇది దృష్టి పెడుతుంది.

ప్యూర్ సోర్స్-టు-సింక్ థింకింగ్‌కు సంబంధించిన ఒక పరిమితిని కూడా గుర్తించాలి: ప్రతి వల్నరబిలిటీ డేటాఫ్లో సమస్య కాదు. అనేక నిజమైన ఫెయిల్యర్స్ స్టేట్ మరియు ఇన్వేరియంట్ సమస్యలు—వర్క్‌ఫ్లో బైపాస్‌లు, ఆథరైజేషన్ గ్యాప్‌లు, మరియు “సిస్టమ్ తప్పు స్టేట్‌లో ఉంది” అనే బగ్స్. ఈ రకమైన బగ్స్‌లో, టెయింటెడ్ విలువ ఒకే “డేంజరస్ సింక్” వరకు చేరదు. రిస్క్ అనేది ప్రోగ్రామ్ ఎప్పుడూ నిజమేనని అనుకునే అంశాల్లో ఉంటుంది.

సెక్యూరిటీ టూలింగ్ ఎకోసిస్టమ్ ఇంకా మెరుగుపడుతుందని మేము ఆశిస్తున్నాము: స్టాటిక్ అనాలిసిస్, ఫజ్జింగ్, రన్‌టైమ్ గార్డ్స్, మరియు ఏజెంటిక్ వర్క్‌ఫ్లోస్ అన్నీ తమ పాత్రలు పోషిస్తాయి.

Codex Security బాగా చేయాలి అనుకునేది సెక్యూరిటీ టీమ్స్‌కు అత్యంత ఖర్చు అయ్యే భాగం: “ఇది అనుమానాస్పదంగా కనిపిస్తోంది” అన్న దాన్ని “ఇది నిజమైన సమస్య, ఇది ఎలా ఫెయిల్ అవుతుంది, మరియు సిస్టమ్ ఉద్దేశానికి సరిపోయే పరిష్కారం ఇదే”గా మార్చడం.

Codex Security రిపోజిటరీలను ఎలా స్కాన్ చేస్తుంది, ఫైండింగ్స్‌ను ఎలా వాలిడేట్ చేస్తుంది, మరియు ఫిక్సెస్‌ను ఎలా సూచిస్తుంది అన్న విషయాల గురించి మరింత తెలుసుకోవాలంటే, మా డాక్యుమెంటేషన్⁠(కొత్త విండోలో తెరుచుకుంటుంది)ను చూడండి.