Codex Security ஏன் SAST அறிக்கையைச் சேர்ப்பதில்லை

பல தசாப்தங்களாக, பாதுகாப்புக் குழுக்கள் குறியீட்டு மதிப்பாய்வை விரிவுபடுத்துவதற்கான மிகவும் பயனுள்ள வழிகளில் ஒன்றாக நிலையான பயன்பாட்டுப் பாதுகாப்புச் சோதனை (SAST) இருந்து வருகிறது. 

ஆனால் நாங்கள் Codex Security-ஐ உருவாக்கியபோது, நாங்கள் திட்டமிட்ட ஒரு வடிவமைப்பு தேர்வை எடுத்தோம்: ஒரு நிலையான பகுப்பாய்வு அறிக்கையை இறக்குமதி செய்து அதை முடிவுபடி ஏஜென்ட்டிடம் கேட்பதிலிருந்து நாங்கள் தொடங்கவில்லை. நாங்கள் இந்த அமைப்பை ரிபாசிட்டரியிலிருந்தே—அதன் கட்டமைப்பு, நம்பிக்கை எல்லைகள், மற்றும் நோக்கமிட்ட நடத்தை—தொடங்கும் வகையில் வடிவமைத்தோம்; மேலும் அது கண்டுபிடிப்பதை ஒரு மனிதன் அதில் நேரம் செலவிடுமாறு கேட்பதற்கு முன் சரிபார்க்கும் வகையிலும் வடிவமைத்தோம். 

காரணம் எளிது: மிகக் கடினமான பாதிப்புகள் பொதுவாக தரவு ஓட்டப் பிரச்சனைகள் அல்ல. குறியீடு ஒரு பாதுகாப்பு சரிபார்ப்பை அமல்படுத்துவது போலத் தோன்றும் போது இவை நிகழ்கின்றன, ஆனால் அந்த சரிபார்ப்பு அமைப்பு நம்பியிருக்கும் பண்பை உண்மையில் உறுதிப்படுத்தாது. வேறு வார்த்தைகளில் சொன்னால், சவால் என்பது ஒரு நிரலின் வழியாகத் தரவு எவ்வாறு நகர்கிறது என்பதைக் கண்காணிப்பது மட்டுமல்ல—குறியீட்டிலுள்ள பாதுகாப்புகள் உண்மையாகவே செயல்படுகிறதா என்பதைத் தீர்மானிப்பதுதான்.

SAST என்பது பெரும்பாலும் ஒரு தூய்மையான செயல்முறையாக முன்வைக்கப்படுகிறது: நம்பத்தகாத உள்ளீட்டின் மூலத்தைக் கண்டறிதல், நிரல் முழுவதும் தரவைக் கண்காணித்தல், மற்றும் அந்தத் தரவு சுத்திகரிக்கப்படாமல் ஒரு முக்கியத் தரவைச் சென்றடையும் நிகழ்வுகளைக் கொடியிடுதல் ஆகியவை இதன் நோக்கங்களாகும். இது ஒரு அழகிய மாடல், மேலும் இது பல உண்மையான பிழைகளை உள்ளடக்குகிறது.

நடைமுறையில், SAST அளவிலான அளவீட்டில் கையாளத்தக்கதாக இருக்க அணுகுமுறை மதிப்பீடுகளைச் செய்ய வேண்டி வருகிறது—குறிப்பாக மறைமுகம், டைனமிக் டிஸ்பாச், கால்பேக்குகள், ரிஃப்ளெக்ஷன், மற்றும் கட்டமைப்பு-அதிகமான கட்டுப்பாட்டு ஓட்டம் கொண்ட நிஜ கோட்பேஸ்களில். அந்த அணுகுமுறை மதிப்பீடுகள் SAST மீது குற்றச்சாட்டு அல்ல; அதை இயக்காமல் குறியீட்டை பற்றி காரணம் காண முயல்வதின் யதார்த்தமே அது.

அது, தனியாகவே, Codex பாதுகாப்பு SAST அறிக்கையின் மூலம் தொடங்காததற்கான காரணம் அல்ல.

முக்கியமான பிரச்சினை, நீங்கள் ஒரு மூலத்திலிருந்து ஒரு இலக்கை வெற்றிகரமாகக் கண்டறிந்த பிறகு என்ன நடக்கிறது என்பதுதான்.

நிலையான பகுப்பாய்வு பல செயல்பாடுகள் மற்றும் அடுக்குகளுக்கு அப்பாலும் உள்ளீட்டை சரியாகப் பின்தொடர்ந்தாலும், ஒரு பலவீனம் உள்ளது என்பதை உண்மையில் தீர்மானிக்கும் கேள்விக்கு அதற்கும் இன்னும் பதிலளிக்க வேண்டும்:

ஒரு பொதுவான முறைமையை எடுத்துக்கொள்ளுங்கள்: நம்பத்தகாத உள்ளடக்கத்தை ரெண்டர் செய்வதற்கு முன், குறியீடு sanitize_html() போன்ற ஒன்றை அழைக்கிறது. ஒரு நிலையான பகுப்பாய்வி, சுத்திகரிப்பான் செயல்பட்டதை காண முடியும். அது பொதுவாகத் தீர்மானிக்க முடியாதது என்னவெனில், அந்த சுத்திகரிப்பான் குறிப்பிட்ட ரெண்டரிங் சூழல், டெம்ப்ளேட் என்ஜின், குறியாக்க நடத்தை மற்றும் தொடர்புடைய டவுன்ஸ்ட்ரீம் மாற்றங்களுக்கு உண்மையில் போதுமானதா என்பதே.

அங்கே தான் விஷயங்கள் சிக்கலாக மாறுகின்றன. பிரச்சினை என்பது தரவு ஒரு சிங்கை அடைகிறதா என்பதிலேயே இல்லை. அது, கோடில் உள்ள சரிபார்ப்புகள் சிஸ்டம் கருதும் விதத்தில் மதிப்பை உண்மையில் கட்டுப்படுத்துகிறதா என்பதிலேயே உள்ளது.

வேறுவிதமாகக் கூறினால்: “விதிமுறை கிருமிநாசினியைப் பரிந்துரைக்கிறது” என்பதற்கும் “அமைப்பு பாதுகாப்பானது” என்பதற்கும் இடையே மிகப்பெரிய வேறுபாடு உள்ளது.

இது உண்மையான அமைப்புகளில் அடிக்கடி காணப்படும் ஒரு மாதிரியாகும்.

ஒரு வலை பயன்பாடு ஒரு JSON payload ஐ பெறுகிறது, அதிலிருந்து redirect_url ஐ பிரித்தெடுக்கிறது, அதை allowlist regex க்கு எதிராக சரிபார்க்கிறது, URL-decode செய்கிறது, மற்றும் முடிவை redirect handler க்கு அனுப்புகிறது.

ஒரு பாரம்பரிய source-to-sink அறிக்கை ஓட்டத்தை விவரிக்க முடியும்

நம்பத்தகாத உள்ளீடு → ரெகுலர் எக்ஸ்பிரஷன் சரிபார்ப்பு → URL டிகோட் → வழிமாற்றம்

ஆனால் உண்மையான கேள்வி சரிபார்ப்பு இருக்கிறதா என்பதல்ல. அதன் பிந்தைய மாற்றங்கள் நடந்த பிறகும் அந்த சரிபார்ப்பு இன்னும் அந்த மதிப்பை கட்டுப்படுத்துகிறதா என்பதுதான்.

regex decoding க்கு முன் இயக்கப்பட்டால், மறுவழிமாற்றி கையாளி (redirect handler) அதை புரிந்துகொள்ளும் விதத்தில், அது உண்மையில் decoding செய்யப்பட்ட URL ஐ கட்டுப்படுத்துகிறதா?

அதற்குப் பதிலளிப்பது என்பது முழு உருமாற்றச் சங்கிலியையும் பற்றிப் ரீஸனிங் ஆகும்: அதாவது, ரெகுலர் எக்ஸ்பிரஷன் (regex) எதை அனுமதிக்கிறது, டிகோடிங் மற்றும் நார்மலைசேஷன் எவ்வாறு செயல்படுகின்றன, URL பார்சிங் விளிம்புநிலைச் சூழல்களை (edge cases) எவ்வாறு கையாளுகிறது, மற்றும் வழிமாற்றுத் தர்க்கம் (redirect logic) ஸ்கீமாக்களையும் அத்தாரிட்டிகளையும் (schemes and authorities) எவ்வாறு தீர்க்கிறது என்பனவற்றையெல்லாம் ஆராய்வதாகும்.

நடைமுறையில் முக்கியமான பல பலவீனங்கள் இப்படி தோன்றும்: செயல்பாட்டு வரிசை (order-of-operations) தவறுகள், பகுதி இயல்பாக்கம், பார்சிங் தெளிவின்மைகள், மற்றும் சரிபார்த்தல் மற்றும் விளக்கம் இடையிலான பொருந்தாமைகள். தரவு ஓட்டம் தெளிவாக தெரிகிறது. பலவீனம் என்பது, கட்டுப்பாடுகள் மாற்றம் சங்கிலி முழுவதும் எவ்வாறு பரவுகின்றன அல்லது பரவத் தவறுகின்றன என்பதில் உள்ளது.

இது ஒரு கோட்பாட்டுப் பாங்கு மட்டும் அல்ல. CVE-2024-29041⁠(புதிய சாளரத்தில் திறக்கும்)-ல், திருப்பிவிடல் இலக்குகள் எவ்வாறு குறியாக்கம் செய்யப்பட்டு பின்னர் விளக்கப்பட்டன என்பதனால், தவறாக வடிவமைக்கப்பட்ட URL-கள் வழக்கமான allowlist செயலாக்கங்களை மீறிச் செல்லக்கூடிய ஓபன் ரீடைரக்ட் பிரச்சினையால் Express பாதிக்கப்பட்டது. தரவோட்டம் எளிமையானதாக இருந்தது. கடினமான கேள்வி—பிழை இருந்ததா என்பதைத் தீர்மானித்த கேள்வி—உருமாற்றச் சங்கிலிக்குப் பிறகும் சரிபார்ப்பு நிலைத்திருந்ததா என்பதுதான்.

Codex Security ஒரு எளிய இலக்கை அடிப்படையாகக் கொண்டு உருவாக்கப்பட்டுள்ளது: வலுவான ஆதாரத்துடன் பிரச்சினைகளை வெளிக்கொண்டு வந்து, triage (ஆரம்ப வகைப்படுத்தல்/முன்னுரிமை நிர்ணயம்) பணியை குறைப்பது. தயாரிப்பில், இதன் பொருள்: ரெப்போ-சார்ந்த சூழலை (அச்சுறுத்தல் மாடல் உட்பட) பயன்படுத்துவது, மேலும் பிரச்சினைகளை வெளிப்படுத்துவதற்கு முன் அதிக சிக்னல் கொண்ட பிரச்சினைகளை தனிமைப்படுத்தப்பட்ட சூழலில் சரிபார்ப்பது. 

Codex Security “சரிபார்த்தல் (validation)” அல்லது “சுத்திகரித்தல் (sanitization)” போலத் தோன்றும் ஒரு எல்லையை சந்திக்கும் போது, அதை வெறும் ஒரு செக் பாக்ஸ் போலக் கருதாது. குறியீடு எந்த உத்தரவாதத்தை வழங்க முயற்சிக்கிறது என்பதை இது புரிந்துகொள்ள முயற்சிக்கிறது—பின்னர் அந்த உத்தரவாதம் தவறானது என்பதை நிரூபிக்க முயற்சிக்கிறது.

நடைமுறையில், அது பொதுவாக இவற்றின் கலவையாக இப்படித் தோன்றும்:

• முழு ரிபாசிட்டரி சூழலுடன் தொடர்புடைய குறியீட்டு பாதையை ஒரு பாதுகாப்பு ஆராய்ச்சியாளர் செய்வதைப் போல வாசித்து, நோக்கமும் செயலாக்கமும் இடையிலான பொருந்தாமைகளைத் தேடுவது. இதில் கருத்துரைகளும் அடங்கும், ஆனால் மாடல் அவற்றை அவசியமாக நம்புவதில்லை. எனவே உண்மையில் பிழை இருந்தால், உங்கள் குறியீட்டின் மேல் //Halvar says: this is not a bug என்பதைச் சேர்த்தாலும் அது குழப்பப்படாது.
• பிரச்சனையை மிகச் சிறிய சோதிக்கக்கூடிய பகுதியாக (எடுத்துக்காட்டாக, ஒரு ஒற்றை உள்ளீட்டைச் சுற்றியுள்ள transformation pipeline) சுருக்குவது, இதனால் மீதமுள்ள அமைப்பு இடையில் தடையாக இல்லாமல் அதை நீங்கள் காரணம் கூற முடியும். இந்த அர்த்தத்தில், Codex பாதுகாப்பு சிறிய குறியீட்டு துண்டுகளை பிரித்து எடுத்து, பின்னர் அவற்றிற்காக மைக்ரோ-பஸர்கள் எழுதுகிறது.
• ஒவ்வொரு சோதனையையும் தனித்தனியாகக் கருதுவதற்குப் பதிலாக, மாற்றங்களின் முழுவதும் கட்டுப்பாடுகள் பற்றிய ரீஸனிங். பொருத்தமான இடங்களில், இதை திருப்திகரத்தன்மை (satisfiability) கேள்வியாக முறைப்படுத்துவதையும் இதில் சேர்க்கலாம். மற்ற வார்த்தைகளில், z3-solver உடன் ஒரு Python சூழலுக்கு மாடலுக்கு அணுகலை நாங்கள் வழங்குகிறோம், மேலும் குறிப்பாக சிக்கலான உள்ளீட்டு கட்டுப்பாட்டு பிரச்சினைக்கு பதிலளிக்கும் போது ஒரு மனிதர் தேவையெனில் அதை பயன்படுத்த வேண்டியிருப்பதுபோலவே, தேவையான நேரத்தில் அதை பயன்படுத்துவதில் இது திறமையாக உள்ளது. அசாதாரண கட்டமைப்புகளில் முழு எண் ஓவர்ஃப்ளோ அல்லது அதுபோன்ற பிழைகளைப் பார்ப்பதற்கு இது குறிப்பாக பயனுள்ளதாகும்.
• சாத்தியமான இடங்களில், “இது ஒரு சிக்கலாக இருக்கலாம்” என்பதையும் “இது ஒரு சிக்கல்தான்” என்பதையும் பிரித்தறிய, சாண்ட்பாக்ஸ் செய்யப்பட்ட சரிபார்ப்பு சூழலில் கருதுகோள்களை இயக்குவது. பிழைத்திருத்த முறையில் குறியீடு கம்பைல் செய்யப்பட்ட தொடக்கம் முதல் முடிவுவரை முழுமையான PoC-ஐ விட சிறந்த ஆதாரம் எதுவும் இல்லை. 

இதுவே முக்கிய மாற்றம்: “ஒரு சரிபார்ப்பு உள்ளது” என்பதில் நிற்பதற்குப் பதிலாக, அமைப்பு “மாறாத விதி பொருந்துகிறது (அல்லது பொருந்தவில்லை), மேலும் இதோ ஆதாரம்” என்பதைக் நோக்கித் தள்ளுகிறது. மேலும் அந்த மாடல் அந்த வேலைக்கு சிறந்த கருவியைத் தேர்வு செய்கிறது.

ஒரு நியாயமான எதிர்வினை: ஏன் இரண்டையும் செய்யக்கூடாது? SAST அறிக்கையிலிருந்து தொடங்கவும், பின்னர் ஆழமாக பகுத்தறிவு செய்ய ஏஜென்ட்டைப் பயன்படுத்தவும்.

முன்னமே கணக்கிடப்பட்ட கண்டறிதல்கள் உதவியாக இருக்கும் சில சந்தர்ப்பங்கள் உள்ளன, குறிப்பாக குறுகிய, அறியப்பட்ட பிழை வகைகளுக்கு. ஆனால் சூழலில் பாதிப்புகளைக் கண்டறிந்து சரிபார்க்க வடிவமைக்கப்பட்ட ஒரு ஏஜென்டிற்காக, SAST அறிக்கையிலிருந்து தொடங்குவது முன்கூட்டியே கணிக்கக்கூடிய மூன்று தோல்வி முறைகளை உருவாக்குகிறது.

முதலில், இது முன்கூட்டியே குறுகலுக்கான ஊக்கத்தை வழங்கக்கூடும். கண்டுபிடிப்புகள் பட்டியல் என்பது ஒரு கருவி ஏற்கனவே பார்த்த இடங்களின் வரைபடமாகும். நீங்கள் இதை தொடக்கப் புள்ளியாகக் கருதினால், அதே பிராந்தியங்களில் சமமற்ற முயற்சிகளைச் செலவிடவும், அதே அப்ஸ்ட்ராக்ஷன்களைப் பயன்படுத்தவும், மேலும் கருவியின் பார்வைக்கு பொருந்தாத பிரச்சினைகளை தவறவிடவும் சிஸ்டத்தை நீங்கள் சார்புபடுத்தலாம்.

இரண்டாவதாக, அதை அவிழ்க்க சிரமமான மறைமுக மதிப்பீடுகளை உருவாக்கக்கூடும். பல SAST கண்டுபிடிப்புகள் சுத்திகரிப்பு, சரிபார்ப்பு அல்லது நம்பிக்கை எல்லைகள் பற்றிய அனுமானங்களை குறியாக்குகின்றன. அந்த முன்கணிப்புகள் தவறாக இருந்தால் அல்லது முழுமையற்றதாக இருந்தால், அவற்றை ரீஸனிங் லூப்பில் சேர்ப்பதால், ஏஜென்ட் 'ஆராயவும்' என்பதிலிருந்து 'உறுதிப்படுத்து அல்லது நிராகரி' என்பதற்குத் திசைமாறலாம்; இது ஏஜென்ட் செய்யவேண்டிய செயலாக இல்லை.

மூன்றாவதாக, ரீஸனிங் அமைப்பை மதிப்பீடு செய்வதை இது மேலும் கடினமாக்கலாம். பைப்லைன் SAST வெளியீட்டுடன் தொடங்கினால், ஏஜென்ட் தனது சொந்த பகுப்பாய்வின் மூலம் கண்டறிந்ததை மற்றொரு கருவியிலிருந்து மரபாக பெற்றதிலிருந்து பிரித்தறிவது கடினமாகிறது. அமைப்பின் திறன்களை துல்லியமாக அளவிட விரும்பினால் அந்தப் பிரித்தல் முக்கியம்; அது, அமைப்பு காலப்போக்கில் மேம்படவும் தேவையானது.

அதனால், பாதுகாப்பு ஆய்வு தொடங்கும் இடத்திலிருந்தே தொடங்கும் வகையில் நாங்கள் Codex Security ஐ உருவாக்கினோம்: குறியீடும் அமைப்பின் நோக்கமும் என்பவற்றிலிருந்து தொடங்கி, ஒரு மனிதரை இடைமறிப்பதற்கு முன் நம்பிக்கை அளவுக்கான தரநிலையை உயர்த்த சரிபார்ப்பை பயன்படுத்துகிறோம்.

SAST கருவிகள் அவை வடிவமைக்கப்பட்ட பணிகளில் சிறந்ததாக இருக்கலாம்: பாதுகாப்பான குறியீட்டல் தரநிலைகளை அமல்படுத்துவது, எளிய source-to-sink சிக்கல்களைப் பிடிப்பது, மேலும் கணிக்கக்கூடிய சமநிலைகளுடன் பெரிய அளவில் அறியப்பட்ட வடிவமைப்புகளை கண்டறிவது. அவை ஆழமான பாதுகாப்பின் ஒரு வலுவான பகுதியாக இருக்கலாம்.

இந்த பதிவு இன்னும் குறுகியது: நடத்தை பற்றி காரணமிடவும், கண்டுபிடிப்புகளைச் சரிபார்க்கவும் வடிவமைக்கப்பட்ட ஒரு ஏஜென்ட், நிலையான “findings” பட்டியலை அடிப்படையாகக் கொண்டு தன் பணியைத் தொடங்கக் கூடாது என்பதையே இது விளக்குகிறது.

தூய source-to-sink சிந்தனையின் தொடர்புடைய ஒரு வரம்பையும் குறிப்பிட வேண்டியது மதிப்பிற்குரியது: ஒவ்வொரு பாதிப்பும் dataflow பிரச்சினை அல்ல. பல உண்மையான தோல்விகள் state மற்றும் invariant பிரச்சினைகள்—workflow தாண்டல்கள், authorization இடைவெளிகள், மற்றும் “system தவறான state இல் உள்ளது” போன்ற பிழைகள். இந்த வகையான பிழைகளில், மாசுபட்ட மதிப்பு ஒரு “ஆபத்தான சிங்க்.”-ஐ எட்டவில்லை. அபாயம் என்பது நிகழ்ச்சி எப்போதும் உண்மையாக இருக்கும் என்று கருதுவதில்தான் உள்ளது. 

பாதுகாப்பு கருவி அமைப்பு தொடர்ந்து மேம்படும் என்று நாங்கள் எதிர்பார்க்கிறோம்: நிலையான பகுப்பாய்வு, fuzzing, runtime பாதுகாப்புகள், மற்றும் agentic பணிச்சூழல்கள் அனைத்தும் தங்களது பங்குகளை வகிக்கும்.

பாதுகாப்புக் குழுக்களுக்கு அதிக செலவை ஏற்படுத்தும் ஒரு விஷயத்தில்தான் Codex செக்யூரிட்டி சிறந்து விளங்க வேண்டும் என நாங்கள் விரும்புகிறோம்: அதாவது, “இது சந்தேகமாகத் தெரிகிறது” என்பதை, “இது உண்மையானது, இது எவ்வாறு தோல்வியடைகிறது, மேலும் கணினியின் நோக்கத்துடன் பொருந்தக்கூடிய ஒரு தீர்வு இதோ” என்பதாக மாற்றுவது. 

Codex Security எவ்வாறு ரிபாசிட்டரிகளை ஸ்கேன் செய்கிறது, கண்டறிதல்களைச் சரிபார்க்கிறது, மற்றும் சரிசெய்தல்களை முன்மொழிகிறது என்பதைக் குறித்து மேலும் அறிய, எங்கள் ஆவணங்களை⁠(புதிய சாளரத்தில் திறக்கும்) பார்க்கவும்.