दशकांपासून, स्टॅटिक ऍप्लिकेशन सुरक्षा चाचणी (SAST) ही सुरक्षा संघांसाठी कोड पुनरावलोकन वाढवण्याच्या सर्वात प्रभावी मार्गांपैकी एक राहिली आहे.
पण जेव्हा आम्ही Codex सुरक्षा तयार केले, तेव्हा आम्ही एक ठराविक डिझाइन निर्णय घेतला: आम्ही स्थिर विश्लेषण अहवाल आयात करून आणि एजंटला त्याचे वर्गीकरण करण्यास सांगून सुरुवात केली नाही. आम्ही प्रणालीची रचना रिपॉझिटरीच्या स्थापनेपासूनच सुरू होईल अशी केली—तिची वास्तुकला, विश्वास सीमारेषा, आणि अपेक्षित वर्तन—आणि ती जे शोधते ते पडताळून पाहण्यासाठी मानवी व्यक्तीला त्यावर वेळ खर्च करण्याची विनंती करण्यापूर्वी.
कारण सोपे आहे: सर्वात कठीण असुरक्षा सहसा dataflow समस्या नसतात. हे तेव्हा घडते जेव्हा कोड सुरक्षा तपासणी लागू करत असल्यासारखा दिसतो, पण ती तपासणी प्रणाली ज्या गुणधर्मावर अवलंबून आहे त्याची प्रत्यक्षात हमी देत नाही. इतर शब्दांत, हे आव्हान फक्त डेटा एखाद्या प्रोग्रॅममधून कसा प्रवास करतो याचा मागोवा घेणे नाही—तर कोडमधील संरक्षणे खरोखर काम करतात का हे ठरवणे आहे.
SAST ला अनेकदा एक स्वच्छ पाइपलाइन म्हणून मांडले जाते: अविश्वसनीय इनपुटचा स्रोत ओळखा, प्रोग्राममधून डेटा ट्रॅक करा, आणि तो डेटा संवेदनशील ठिकाणी sanitization शिवाय पोहोचतो अशा प्रकरणांना फ्लॅग करा. हे एक सुबक मॉडेल आहे आणि ते अनेक वास्तविक बग्स समाविष्ट करते.
व्यवहारात, SAST ला मोठ्या प्रमाणावर हाताळण्याजोगे राहण्यासाठी अंदाज बांधावे लागतात—विशेषतः प्रत्यक्ष कोडबेसमध्ये जिथे अप्रत्यक्ष संदर्भ, डायनॅमिक डिस्पॅच, कॉलबॅक, रिफ्लेक्शन आणि फ्रेमवर्क-प्रधान नियंत्रण प्रवाह असतात. ती अंदाजे मोजदाद SAST वर टीका नाही; कोड चालविल्याशिवाय त्याबद्दल तर्क लावण्याचा प्रयत्न करण्याची ती वस्तुस्थिती आहे.
ते, स्वतःहून, Codex सुरक्षा SAST रिपोर्टने सुरू करत नाही याचे कारण नाही.
खरी खोल समस्या ही आहे की तुम्ही सोर्सला सिंकपर्यंत यशस्वीपणे ट्रेस केल्यानंतर काय होते.
स्टॅटिक विश्लेषणाने एकाधिक फंक्शन्स आणि लेयर्समधून इनपुटचा योग्यरीत्या मागोवा घेतला तरीही, असुरक्षा अस्तित्वात आहे का हे ठरवणाऱ्या प्रश्नाचे उत्तर देणे त्याला तरीही आवश्यक असते:
एक सामान्य पॅटर्न घ्या: अविश्वसनीय सामग्री रेंडर करण्यापूर्वी कोड sanitize_html() सारखे काहीतरी कॉल करतो. स्थिर विश्लेषक पाहू शकतो की सॅनिटायझर चालला. साधारणपणे, ते जे ठरवू शकत नाही ते म्हणजे तो सॅनिटायझर संबंधित विशिष्ट रेंडरिंग संदर्भ, टेम्पलेट इंजिन, एन्कोडिंग वर्तन, आणि सहभागी डाउनस्ट्रीम ट्रान्सफॉर्मेशन्ससाठी प्रत्यक्षात पुरेसा आहे की नाही.
इथेच गोष्टी कठीण होतात. समस्या फक्त डेटा सिंकपर्यंत पोहोचतो का याबद्दल नाही. कोडमधील तपासण्या प्रत्यक्षात मूल्यावर प्रणाली ज्या प्रकारे गृहीत धरते त्या पद्धतीनेच बंधन घालतात की नाही, हेच ते आहे.
दुसऱ्या शब्दांत सांगायचे तर: “कोड स्वच्छता साधन (sanitizer) कॉल करतो” आणि “सिस्टम सुरक्षित आहे.”यामध्ये मोठा फरक आहे.
खऱ्या सिस्टममध्ये सतत दिसून येणारा हा एक नमुना आहे.
एक वेब अनुप्रयोग JSON पेलोड प्राप्त करतो, त्यातून redirect_url काढतो, त्याला परवानगी यादीतील regex ने वैधता तपासतो, URL-डिकोड करतो आणि निकाल रीडायरेक्ट हँडलरकडे पाठवतो.
एक क्लासिक स्रोत-ते-सिंक अहवाल प्रवाहाचे वर्णन करू शकतो:
अविश्वसनीय इनपुट → regex तपासणी → URL डिकोड → पुनर्निर्देशित
पण खरा प्रश्न हा नाही की तपासणी अस्तित्वात आहे की नाही. पुढे होणाऱ्या ट्रान्सफॉर्मेशन्सनंतरही ती तपासणी त्या मूल्यावर अजूनही बंधने घालते का, हाच मुद्दा आहे.
जर regex डिकोडिंग करण्यापूर्वी चालत असेल, तर तो प्रत्यक्षात रीडायरेक्ट हँडलर ज्या प्रकारे डिकोड केलेल्या URL चा अर्थ लावतो त्या प्रकारे बंधन आणतो का?
त्याचे उत्तर देण्यासाठी संपूर्ण परिवर्तन साखळीबद्दल रीझनिंग करणे आवश्यक आहे: रेगएक्स काय परवानगी देतो, डीकोडिंग आणि नॉर्मलायझेशन कसे कार्य करतात, URL पार्सिंग काठाच्या प्रकरणांना कसे हाताळते, आणि रीडायरेक्ट लॉजिक स्कीम्स आणि ऑथॉरिटीज कसे ठरवते.
प्रत्यक्षात महत्त्वाच्या ठरणाऱ्या अनेक असुरक्षा अशा दिसतात: ऑपरेशन्सच्या क्रमातील चुका, अपूर्ण नॉर्मलायझेशन, पार्सिंगमधील अस्पष्टता, आणि वैधता तपासणी आणि अर्थ लावणे यांमधील विसंगती. डेटाफ्लो दृश्यमान आहे. कमकुवतपणा हा यात आहे की निर्बंध रूपांतरण साखळीमधून कसे प्रसारित होतात—किंवा प्रसारित होण्यात कसे अपयशी ठरतात—यामध्ये.
हा केवळ एक सैद्धांतिक पॅटर्न नाही. CVE-2024-29041(नवीन विंडोमध्ये उघडेल) मध्ये, Express वर open redirect समस्येचा परिणाम झाला होता, जिथे चुकीच्या स्वरूपातील URLs मुळे सामान्य allowlist अंमलबजावण्या बायपास करता येत होत्या कारण redirect targets कसे एन्कोड केले गेले आणि नंतर कसे अर्थ लावले गेले. डेटाफ्लो सरळ होता. अधिक कठीण प्रश्न—आणि बग अस्तित्वात होता की नाही हे ठरवणारा—हा होता की ट्रान्सफॉर्मेशन चेननंतरही व्हॅलिडेशन वैध राहिले का.
Codex सुरक्षा एका साध्या उद्दिष्टाभोवती तयार केलेले आहे: अधिक मजबूत पुराव्यांसह समस्या ओळखून ट्रायाज कमी करणे. प्रॉडक्टमध्ये, याचा अर्थ रेपो-विशिष्ट संदर्भ (थ्रेट मॉडेलसह) वापरणे आणि उच्च-सिग्नल समस्यांची वेगळ्या वातावरणात पडताळणी करणे, त्यानंतर त्या समस्या समोर आणणे.
जेव्हा Codex सुरक्षा “पडताळणी” किंवा “डेटा स्वच्छता” यांसारखी दिसणारी एखादी सीमा भेटते, तेव्हा ते तिला चेकबॉक्स म्हणून हाताळत नाही. तो कोड काय हमी देण्याचा प्रयत्न करत आहे हे समजून घेतो—आणि मग त्या हमीला खोटं ठरवतो.
प्रत्यक्षात, ते सहसा यासारख्या मिश्रणासारखे दिसते:
- पूर्ण रिपॉझिटरी संदर्भासह संबंधित कोड पथ वाचणे, जसे सुरक्षा संशोधक वाचतात, आणि उद्देश व अंमलबजावणी यामधील विसंगती शोधणे. यात टिप्पण्या समाविष्ट आहेत, पण मॉडेल आवश्यक तेवढ्या टिप्पण्यांवर विश्वास ठेवत नाही, त्यामुळे तुमच्या कोडच्या वर //Halvar says: this is not a bug जोडल्यास, खरोखर बग असल्यास, ते गोंधळीत नाही.
- समस्या सर्वात लहान चाचणीयोग्य भागापर्यंत (उदाहरणार्थ, एका इनपुटभोवतीची ट्रान्सफॉर्मेशन पाइपलाइन) मर्यादित करणे, जेणेकरून उर्वरित प्रणाली अडथळा न ठरता तुम्ही तिच्याबद्दल तर्क करू शकता. या अर्थाने, Codex सुरक्षा लहान कोड स्लाइस वेगळे काढते आणि त्यांच्यासाठी मायक्रो-फझर्स तयार करते.
- प्रत्येक तपासणीला स्वतंत्रपणे हाताळण्याऐवजी, ट्रान्सफॉर्मेशन्समध्ये कॉन्स्ट्रेंट्सवर रीझनिंग करणे. योग्य ठिकाणी, यात समाधानक्षमतेचा प्रश्न म्हणून औपचारिकीकरण समाविष्ट असू शकते. दुसऱ्या शब्दांत सांगायचे तर, आम्ही मॉडेलला z3-solver असलेल्या Python वातावरणात प्रवेश देतो आणि विशेषतः गुंतागुंतीच्या इनपुट कन्स्ट्रेंट समस्येचे उत्तर देताना जसे मानवाला करावे लागेल तसे, गरज पडल्यास ते वापरण्यात ते चांगले आहे. अमानक आर्किटेक्चर्सवर इंटिजर ओव्हरफ्लोज किंवा तत्सम बग्स पाहण्यासाठी हे विशेषतः उपयुक्त आहे.
- शक्य असल्यास, “ही समस्या असू शकते” आणि “ही समस्या आहे” यांमध्ये फरक करण्यासाठी सँडबॉक्स केलेल्या वैधता वातावरणांमध्ये परिकल्पना अंमलात आणणे. डीबग मोडमध्ये कोड कंपाइल करून केलेल्या पूर्ण एंड-टू-एंड PoCपेक्षा चांगला पुरावा नाही.
हा मुख्य बदल आहे: “एक तपासणी अस्तित्वात आहे” इथपर्यंत थांबण्याऐवजी, प्रणाली “इनव्हेरिएंट लागू आहे (किंवा नाही), आणि इथे पुरावा आहे” याकडे ढकलते. आणि मॉडेल त्या कामासाठी सर्वोत्तम साधन निवडते.
एक वाजवी प्रतिक्रिया अशी आहे: मग दोन्ही का करू नये? SAST अहवालापासून सुरुवात करा, मग सखोल विचार करण्यासाठी एजंट वापरा.
अशा काही परिस्थिती असतात जिथे पूर्वगणित निष्कर्ष उपयुक्त ठरतात, विशेषतः अरुंद, परिचित बग वर्गांसाठी. परंतु संदर्भात असुरक्षितता शोधण्यासाठी आणि पडताळणी करण्यासाठी डिझाइन केलेल्या एजंटसाठी, SAST अहवालापासून सुरुवात केल्यास तीन पूर्वानुमान करता येण्याजोगे अपयश मोड्स निर्माण होतात.
प्रथम, ते अकाली मर्यादित होण्यास प्रोत्साहन देऊ शकते. फाइंडिंग्ज यादी म्हणजे टूलने आधीच कुठे पाहिले आहे याचा नकाशा. जर तुम्ही त्याला प्रारंभिक बिंदू म्हणून वागवलात, तर तुम्ही सिस्टमला त्याच प्रदेशांमध्ये असमतोल प्रमाणात प्रयत्न खर्च करण्यासाठी, त्याच अब्स्ट्रॅक्शनचा वापर करण्यासाठी, आणि टूलच्या वर्ल्डव्ह्यूमध्ये बसत नाहीत अशा समस्या-वर्गांना चुकवण्यासाठी झुकवू शकता.
दुसरे म्हणजे, ते उलगडणे कठीण अशा अप्रत्यक्ष निर्णयांना जन्म देऊ शकते. अनेक SAST निष्कर्षांमध्ये स्वच्छता, सत्यापन किंवा विश्वासाच्या सीमा याबद्दल गृहितके एन्कोड केलेली असतात. जर ती गृहीतके चुकीची असतील किंवा अपूर्ण असतील, तर ती रीझनिंग लूपमध्ये घातल्याने एजंट 'तपासा' वरून 'पुष्टी करा किंवा फेटाळा' कडे वळू शकतो, जे एजंटने करणे अपेक्षित नाही.
तिसरे, यामुळे रीझनिंग प्रणालीचे मूल्यांकन करणे अधिक कठीण होऊ शकते. जर पाइपलाइन SAST आउटपुटपासून सुरू होत असेल, तर एजंटने स्वतःच्या विश्लेषणातून काय शोधले आहे आणि दुसऱ्या टूलकडून काय वारशाने मिळाले आहे हे वेगळे करणे कठीण होते. ती वेगळेपणाची विभागणी महत्त्वाची आहे, जर तुम्हाला प्रणालीची क्षमता अचूकपणे मोजायची असेल, जे प्रणालीला कालांतराने सुधारण्यासाठी आवश्यक आहे.
म्हणून आम्ही Codex सुरक्षा तयार केली, जिथून सुरक्षा संशोधन सुरू होते: कोड आणि प्रणालीच्या हेतूपासून. मानवी हस्तक्षेप करण्यापूर्वी आत्मविश्वासाची पातळी उंचावण्यासाठी व्हॅलिडेशनचा वापर केला जातो.
SAST साधने त्यांना ज्यासाठी डिझाइन केले आहे त्यात उत्कृष्ट ठरू शकतात: सुरक्षित कोडिंग मानकांची अंमलबजावणी करणे, सोर्स-टू-सिंक प्रकारच्या सरळसोट समस्या पकडणे, आणि अंदाज करता येण्याजोग्या तडजोडींंसह मोठ्या प्रमाणावर ज्ञात पॅटर्न्स ओळखणे. ते सखोल संरक्षणाचा एक मजबूत भाग असू शकतात.
ही पोस्ट अधिक मर्यादित आहे: वर्तनाबद्दल तर्कशक्तीने विचार करणे आणि निष्कर्ष सत्यापित करणे यासाठी डिझाइन केलेल्या एजंटने स्थिर निष्कर्षांच्या यादीला आधार मानून तुमचे काम सुरू करू नये याबद्दल.
शुद्ध स्रोत-ते-सिंक विचारसरणीची एक संबंधित मर्यादा देखील अधोरेखित करण्यासारखी आहे: प्रत्येक असुरक्षा ही डेटाफ्लो समस्या नसते. अनेक वास्तविक अपयशे ही स्थिती आणि इन्व्हेरिएंट समस्यांशी संबंधित असतात—कार्यप्रवाह बायपास, अधिकृतता तफावत, आणि “प्रणाली चुकीच्या स्थितीत आहे” प्रकारचे बग. या प्रकारच्या बग्ससाठी, tainted value एका एकमेव “dangerous sink” पर्यंत पोहोचत नाही. जोखीम या गोष्टीत आहे की कार्यक्रम जे नेहमीच खरे असेल असे गृहीत धरतो.
सुरक्षा टूलिंग इकोसिस्टम सतत सुधारत राहील; स्टॅटिक अॅनालिसिस, फझिंग, रनटाइम गार्ड्स आणि एजंटिक वर्कफ्लोज यामध्ये महत्त्वाची भूमिका असेल.
Codex सुरक्षा कडून आम्हाला जे सर्वात चांगले करून घ्यायचे आहे ते म्हणजे सुरक्षा संघांसाठी सर्वाधिक खर्चिक असलेला भाग: “हे संशयास्पद दिसते” याचे रूपांतर “हे खरे आहे, ते कसे अपयशी ठरते ते इथे आहे, आणि प्रणालीच्या उद्देशाशी जुळणारी दुरुस्ती इथे आहे.” असे करण्यात
Codex सुरक्षा रिपॉझिटरी कशा स्कॅन करते, निष्कर्षांची पडताळणी करते आणि दुरुस्त्या सुचवते याबद्दल अधिक जाणून घ्या, आमचे दस्तऐवजीकरण(नवीन विंडोमध्ये उघडेल) पहा.
