പതിറ്റാണ്ടുകളായി, സ്റ്റാറ്റിക് ആപ്ലിക്കേഷൻ സുരക്ഷാ പരിശോധന (SAST) എന്നത് സുരക്ഷാ ടീമുകൾക്ക് കോഡ് റിവ്യൂ വിപുലമായി സ്കെയിൽ ചെയ്യാനുള്ള ഏറ്റവും ഫലപ്രദമായ മാർഗങ്ങളിലൊന്നാണ്.
എന്നിരുന്നാലും Codex സെക്യൂരിറ്റി ഞങ്ങൾ നിർമ്മിച്ചപ്പോൾ, ഞങ്ങൾ മനഃപൂർവ്വം ഒരു ഡിസൈൻ തീരുമാനം എടുത്തു: ഒരു സ്റ്റാറ്റിക് അനാലിസിസ് റിപ്പോർട്ട് ഇമ്പോർട്ട് ചെയ്ത് അത് ട്രയാജ് ചെയ്യാൻ ഏജന്റ്-നോട് ആവശ്യപ്പെടുന്നതിൽ നിന്നല്ല ഞങ്ങൾ തുടങ്ങിയത്. ഞങ്ങൾ സിസ്റ്റത്തെ റിപ്പോസിറ്ററിയിൽ നിന്നുതന്നെ ആരംഭിക്കുന്ന തരത്തിൽ രൂപകൽപ്പന ചെയ്തു—അതിന്റേ ആർക്കിടെക്ചർ, വിശ്വാസത്തിന്റെ പരിധികള്, ഉദ്ദേശിച്ച പ്രവർത്തനം എന്നിവ—അതും, മനുഷ്യൻ അതിൽ സമയം ചെലവഴിക്കണമെന്ന് ആവശ്യപ്പെടുന്നതിന് മുമ്പ്, അത് കണ്ടെത്തുന്നതിനെ സാധൂകരിക്കാൻ വേണ്ടി.
കാരണം ലളിതമാണ്: ഏറ്റവും പ്രയാസമുള്ള ദുർബലതകൾ സാധാരണയായി ഡാറ്റാഫ്ലോ പ്രശ്നങ്ങളല്ല. കോഡ്, സിസ്റ്റം ആശ്രയിക്കുന്ന ഗുണധർമ്മംനടപ്പിലാക്കും എന്ന് ഉറപ്പില്ലാത്ത ഒരു സുരക്ഷാ പരിശോധന നടപ്പിലാക്കുമ്പോള് ആണ് ഇവ സംഭവിക്കുന്നത്. മറ്റൊരു രീതിയിൽ പറഞ്ഞാൽ, വെല്ലുവിളി ഒരു പ്രോഗ്രാമിലൂടെ ഡാറ്റ എങ്ങനെ നീങ്ങുന്നു എന്ന് ട്രാക്ക് ചെയ്യുന്നതു മാത്രമല്ല—കോഡിലെ പ്രതിരോധങ്ങൾ പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് നിർണ്ണയിക്കുന്നതുമാണ്.
SAST പലപ്പോഴും ഒരു ശുദ്ധമായ പൈപ്പ്ലൈൻ ആയി കാണപ്പെടുന്നു: വിശ്വസനീയമല്ലാത്ത ഇൻപുട്ടിന്റെ ഒരു ഉറവിടം തിരിച്ചറിയുക, പ്രോഗ്രാമിലൂടെ ഡാറ്റയെ ട്രാക്ക് ചെയ്യുക, കൂടാതെ സാനിറ്റൈസേഷൻ ഇല്ലാതെ ആ ഡാറ്റ ഒരു സെൻസിറ്റീവ് സിങ്കിലേക്ക് എത്തുന്ന സാഹചര്യങ്ങൾ ഫ്ലാഗ് ചെയ്യുക തുടങ്ങിയ രീതികളില്. ഇത് ഒരു സുന്ദരമായ മോഡൽ ആണ്, കൂടാതെ ഇത് യഥാർത്ഥ ലോകത്തിലെ നിരവധി പിഴവുകൾ ഉൾക്കൊള്ളുന്നു.
പ്രായോഗികമായി, സ്കെയിലിൽ കൈകാര്യം ചെയ്യാവുന്ന രീതിയിൽ നിലനിർത്താൻ SAST ഏകദേശമാക്കലുകൾ നടത്തേണ്ടിവരും, പ്രത്യേകിച്ച് ഇൻഡിറെക്ഷൻ, ഡൈനാമിക് ഡിസ്പാച്ച്, കോൾബാക്കുകൾ, റിഫ്ലെക്ഷൻ, ഫ്രെയിംവർക്കുകൾ ശക്തമായി ആശ്രയിക്കുന്ന നിയന്ത്രണ പ്രവാഹം എന്നിവയുള്ള യഥാർത്ഥ കോഡ്ബേസുകളിൽ. ആ അനുമാനങ്ങൾ SAST-നെ വിമർശിക്കുന്നതല്ല. അത് കോഡ് പ്രവർത്തിപ്പിക്കാതെ അതിനെക്കുറിച്ച് നിഗമനം നടത്താൻ ശ്രമിക്കുന്നതിന്റെ യാഥാർത്ഥ്യമാണ്.
Codex സെക്യൂരിറ്റി ഒരു SAST റിപ്പോർട്ടുമായി ആരംഭിക്കാത്തതിന്റെ കാരണം അത് മാത്രമല്ല.
കൂടുതൽ ആഴത്തിലുള്ള പ്രശ്നം, നിങ്ങൾ ഒരു സോഴ്സിനെ ഒരു സിങ്കിലേക്ക് വിജയകരമായി ട്രേസ് ചെയ്തതിന് ശേഷം എന്താണ് സംഭവിക്കുന്നത് എന്നതാണ്.
സ്റ്റാറ്റിക് വിശകലനം ഒന്നിലധികം ഫങ്ഷനുകളിലൂടെയും ലെയറുകളിലൂടെയും ഇൻപുട്ടിനെ ശരിയായി പിന്തുടർന്നാലും, ഒരു ദൗർബല്യം യഥാർത്ഥത്തിൽ നിലനിൽക്കുന്നുണ്ടോ എന്ന് നിർണ്ണയിക്കുന്ന പ്രധാന ചോദ്യത്തിന് ഉത്തരം നൽകേണ്ടതുണ്ട്:
ഒരു സാധാരണ പാറ്റേൺ എടുത്താൽ: വിശ്വസനീയമല്ലാത്ത ഉള്ളടക്കം റെൻഡർ ചെയ്യുന്നതിന് മുമ്പ് കോഡ് sanitize_html() പോലൊരു കാര്യം വിളിക്കുന്നു. ഒരു സ്റ്റാറ്റിക് അനലൈസറിന് സാനിറ്റൈസർ പ്രവർത്തിച്ചതാണെന്ന് കാണാൻ കഴിയാം. അതിന് സാധാരണയായി നിർണ്ണയിക്കാൻ കഴിയാത്തത്, ആ സാനിറ്റൈസർ ഉൾപ്പെട്ടിരിക്കുന്ന പ്രത്യേക റെൻഡറിംഗ് കോൺടെക്സ്റ്റ്, ടെംപ്ലേറ്റ് എഞ്ചിൻ, എൻകോഡിംഗ് പെരുമാറ്റം, കൂടാതെ ഡൗൺസ്ട്രീം ട്രാൻസ്ഫോർമേഷനുകൾ എന്നിവയ്ക്കായി യഥാർത്ഥത്തിൽ മതിയാകുന്നുണ്ടോ എന്നതാണ്.
അവിടെയാണ് കാര്യങ്ങൾ ബുദ്ധിമുട്ടാകുന്നത്. പ്രശ്നം ഡാറ്റ ഒരു സിങ്കിൽ എത്തുമോ എന്നതു മാത്രമല്ല. കോഡിലെ പരിശോധനകൾ സിസ്റ്റം ആഗ്രഹിക്കുന്ന രീതിയിൽ മൂല്യം യഥാർത്ഥത്തിൽ നിയന്ത്രിക്കുന്നുണ്ടോ എന്നതാണ് വിഷയം.
മറ്റൊരു രീതിയിൽ പറയുകയാണെങ്കിൽ: “കോഡ് ഒരു സാനിറ്റൈസറെ വിളിക്കുന്നു” എന്നതിനും “സിസ്റ്റം സുരക്ഷിതമാണ്”എന്നതിനും തമ്മിൽ വലിയ വ്യത്യാസമുണ്ട്.
യഥാർത്ഥ സിസ്റ്റങ്ങളിൽ എല്ലായ്പ്പോഴും കാണപ്പെടുന്ന ഒരു മാതൃക ഇതാ.
ഒരു വെബ് ആപ്ലിക്കേഷൻ ഒരു JSON പേലോഡ് സ്വീകരിച്ച്, അതിൽ നിന്ന് redirect_url പുറത്തെടുക്കുന്നു, അത് ഒരു allowlist regex-നെതിരെ പരിശോധിച്ച് സാധൂകരിക്കുന്നു, URL-ഡീകോഡ് ചെയ്യുന്നു, പിന്നെ ഫലം റീഡയറക്ട് ഹാൻഡ്ലറിലേക്ക് കൈമാറുന്നു.
ഒരു ക്ലാസിക് സോഴ്സ്-ടു-സിങ്ക് റിപ്പോർട്ട് ഒഴുക്ക് ഇതിനു വിശദീകരിക്കാൻ കഴിയും
വിശ്വസനീയമല്ലാത്ത ഇൻപുട്ട് → റെഗുലർ എക്സ്പ്രഷൻ പരിശോധന → URL ഡീകോഡ് → റീഡയറക്ട്
എന്നാൽ യഥാർത്ഥ ചോദ്യം പരിശോധന നിലവിലുണ്ടോ എന്നതല്ല. അതിനുശേഷം നടക്കുന്ന പരിവർത്തനങ്ങൾക്കു ശേഷം ആ പരിശോധന ഇപ്പോഴും മൂല്യത്തെ നിയന്ത്രിക്കുന്നുണ്ടോ എന്നതാണ് കാര്യം.
റീജെക്സ് ഡീകോഡിംഗ് ചെയ്യുന്നതിന് മുമ്പ് പ്രവർത്തിക്കുന്നുവെങ്കിൽ, റീഡയറക്ട് ഹാൻഡ്ലർ വ്യാഖ്യാനിക്കുന്ന രീതിയിൽ ഡീകോഡ് ചെയ്ത URL നെ യഥാർത്ഥത്തിൽ നിയന്ത്രിക്കുന്നുണ്ടോ?
അതിന് ഉത്തരം പറയുക എന്നത് റീസണിംഗ് മുഴുവൻ പരിവർത്തന ശൃംഖലയെക്കുറിച്ച് വിശദമായി ചിന്തിക്കുക എന്നാണ് അര്ത്ഥമാക്കുന്നത്: regex (ഒരു പ്രത്യേക പാറ്റേൺ കണ്ടെത്താൻ ഉപയോഗിക്കുന്ന ഒരു രീതി) എന്താണ് അനുവദിക്കുന്നത്, ഡികോഡിംഗും നോർമലൈസേഷനും എങ്ങനെ പ്രവർത്തിക്കുന്നു, URL പാഴ്സിംഗ് എഡ്ജ് കേസുകളെ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു, കൂടാതെ റീഡൈറക്ട് ലജിക് സ്കീമുകളും അതോറിറ്റികളും എങ്ങനെ പരിഹരിക്കുന്നു.
പ്രായോഗികമായി പ്രസക്തമായ പല ദുർബലതകളും ഇങ്ങനെ തന്നെയാണ് കാണപ്പെടുന്നത്: പ്രവർത്തനക്രമത്തിലെ പിഴവുകൾ, ഭാഗിക നോർമലൈസേഷൻ, പാഴ്സിംഗ് അവ്യക്തതകൾ, മൂല്യനിർണയവും വ്യാഖ്യാനവും തമ്മിലുള്ള പൊരുത്തക്കേടുകൾ. ഡാറ്റാഫ്ലോ ദൃശ്യമാകുന്നു. പരിവർത്തന ശൃംഖലയിലൂടെ നിയന്ത്രണങ്ങൾ എങ്ങനെ പ്രചരിക്കുന്നു—അഥവാ പ്രചരിക്കാൻ പരാജയപ്പെടുന്നു—എന്നതിലാണു ദൗർബല്യം.
ഇത് വെറും സൈദ്ധാന്തിക പാറ്റേൺ മാത്രമല്ല. CVE-2024-29041(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)-ൽ, റീഡയറക്റ്റ് ലക്ഷ്യങ്ങൾ എന്കോഡ് ചെയ്തതും പിന്നീട് വ്യാഖ്യാനിച്ചതുമായ രീതിയുടെ കാരണം, പിഴവ് വന്ന URL-കൾക്ക് സാധാരണ allowlist നടപ്പാക്കലുകൾ മറികടക്കാൻ കഴിയും എന്ന ഓപ്പന് റീഡയറക്റ്റ് പ്രശ്നം Express-നെ ബാധിച്ചു. ഡാറ്റാഫ്ലോ ലളിതമായിരുന്നു. കൂടുതൽ ബുദ്ധിമുട്ടുള്ള ചോദ്യം—അതും ബഗ് ഉണ്ടായിരുന്നോയെന്ന് നിർണ്ണയിച്ച ചോദ്യം—പരിവർത്തന ശൃംഖലക്ക് ശേഷവും ആ പരിശോധന സാധുവായി തുടർന്നുണ്ടോ എന്നത് ആയിരുന്നു.
Codex സെക്യൂരിറ്റി ഒരു ലളിതമായ ലക്ഷ്യത്തെ ചുറ്റിപ്പറ്റി നിർമ്മിച്ചിരിക്കുന്നു: കൂടുതൽ ശക്തമായ തെളിവുകളോടെ പ്രശ്നങ്ങളെ മുന്നിൽ കൊണ്ടുവന്ന് ട്രയാജ് കുറയ്ക്കുക. ഉൽപ്പന്നത്തിൽ, അതിന്റെ അർത്ഥം റിപോ-നിർദ്ദിഷ്ട സന്ദർഭം (ഭീഷണി മോഡൽ ഉൾപ്പെടെ) ഉപയോഗിക്കുകയും, അവയെ പുറത്ത് കൊണ്ടുവരുന്നതിന് മുമ്പ്, ഒറ്റപ്പെട്ട ഒരു പരിതസ്ഥിതിയിൽ ഉയർന്ന സിഗ്നൽ ഉള്ള പ്രശ്നങ്ങൾ സാധൂകരിക്കുകയും ചെയ്യുന്നതാണ്.
Codex സെക്യൂരിറ്റി “validation” അല്ലെങ്കിൽ “sanitization” എന്ന് തോന്നുന്ന ഒരു പരിധിയിലെത്തുമ്പോള്, അതിനെ അത് ഒരു ചെക്ക്ബോക്സായി പരിഗണിക്കുന്നില്ല. ഇത് കോഡ് എന്താണ് ഉറപ്പാക്കാൻ ശ്രമിക്കുന്നത് എന്ന് മനസ്സിലാക്കാൻ ശ്രമിക്കുന്നു—അതിനുശേഷം ആ ഉറപ്പ് തെറ്റിക്കാനുള്ള ശ്രമവും ചെയ്യുന്നു.
പ്രായോഗികമായി, അത് സാധാരണയായി ഇവയുടെ ഒരു മിശ്രിതം പോലെ തോന്നും:
- പൂർണ്ണ റിപ്പോസിറ്ററി സന്ദർഭത്തിൽ പ്രസക്തമായ കോഡ് പാത വായിച്ച്, ഒരു സുരക്ഷാ ഗവേഷകൻ ചെയ്യുന്നതുപോലെ, ഉദ്ദേശ്യവും നടപ്പാക്കലും തമ്മിലുള്ള പൊരുത്തക്കേടുകൾ അന്വേഷിക്കുന്നു. ഇതിൽ കമന്റുകളും ഉൾപ്പെടുന്നു, പക്ഷേ മോഡൽ കമന്റുകളെ അനിവാര്യമായി വിശ്വസിക്കണമെന്നില്ല. അതിനാൽ നിങ്ങളുടെ കോഡിന്റെ മുകളിൽ //Halvar says: this is not a bug ചേർക്കുന്നത്, യഥാർത്ഥത്തിൽ ഒരു ബഗ് ഉണ്ടെങ്കിൽ, മോഡലിനെ ആശയക്കുഴപ്പപ്പെടുത്തില്ല.
- പ്രശ്നത്തെ ഏറ്റവും ചെറിയ പരീക്ഷിക്കാവുന്ന ഭാഗത്തേക്ക് ചുരുക്കുക (ഉദാഹരണത്തിന്, ഒരു ഒറ്റ ഇൻപുട്ടിനെ ചുറ്റിയുള്ള ട്രാൻസ്ഫോർമേഷൻ പൈപ്പ്ലൈൻ), അതുവഴി സിസ്റ്റത്തിന്റെ ബാക്കി ഭാഗങ്ങൾ ഇടപെടാതെ നിങ്ങൾക്ക് അതിനെക്കുറിച്ച് ചിന്തിക്കാൻ കഴിയും. ഈ അര്ഥത്തില്, Codex സെക്യൂരിറ്റി ചെറിയ കോഡ് ഭാഗങ്ങള് വേര്പെടുത്തുകയും പിന്നീട് അവയ്ക്കായി മൈക്രോ-ഫസ്സറുകള് എഴുതുകയും ചെയ്യുന്നു.
- ഓരോ ചെക്കും സ്വതന്ത്രമായി പരിശോധിക്കുന്നതിന് പകരം, പരിവർത്തനങ്ങളിലുടനീളം പരിമിതികളെ കുറിച്ച് റീസണിംഗ് നടത്തുക. ഉചിതമായിടത്ത്, ഇത് ത്രിപ്തിക്ക് വേണ്ടിയുള്ള ചോദ്യമായി ഔപചാരികമാക്കാം. മറ്റൊരുവിധത്തിൽ പറഞ്ഞാൽ, z3-solver ഉള്ള Python പരിസ്ഥിതിയിലേക്ക് മോഡൽ ആക്സസ് നൽകുന്നു, സങ്കീർണ്ണമായ ഇൻപുട്ട് നിയന്ത്രണ പ്രശ്നങ്ങൾക്ക് ഉത്തരം നൽകുമ്പോൾ ഒരു മനുഷ്യൻ ചെയ്യുന്നതുപോലെ അത് ഉപയോഗിക്കുന്നു. ഇത് പ്രത്യേകിച്ച് non-standard ആർക്കിടെക്ചറുകളിൽ സംഖ്യ പരിധി കടക്കുന്ന (ഇന്റേജർ ഓവർഫ്ലോ)അല്ലെങ്കിൽ സമാനമായ ബഗുകൾ കണ്ടെത്താൻ വളരെ പ്രയോജനകരമാണ്.
- സാധ്യമായിടത്തോളം, “ഇത് ഒരു പ്രശ്നമായിരിക്കാം” എന്നതിനെ “ഇത് ഒരു പ്രശ്നമാണ്” എന്നതിൽ നിന്ന് വേർതിരിക്കാൻ സാൻഡ്ബോക്സ്ഡ് വാലിഡേഷൻ പരിതസ്ഥിതികളിൽ ഹൈപ്പോത്തസിസുകൾ നടപ്പിലാക്കുന്നു. ഡീബഗ് മോഡിൽ കോഡ് കോംപൈൽ ചെയ്ത ഒരു പൂർണ്ണ എൻഡ്-ടു-എൻഡ് PoC-നെക്കാൾ മികച്ച തെളിവൊന്നുമില്ല.
ഇതാണ് പ്രധാന മാറ്റം: “ഒരു ചെക്ക് നിലവിലുണ്ട്” എന്നതിൽ നിൽക്കുന്നതിനുപകരം, സിസ്റ്റം “ഇൻവേറിയന്റ് നിലനിൽക്കുന്നു (അല്ലെങ്കിൽ നിലനിൽക്കുന്നില്ല), ഇതാ തെളിവ്” എന്നതിലേക്കാണ് നീങ്ങുന്നത്. അതിന് അനുയോജ്യമായ ജോലിക്ക് മോഡൽ ഏറ്റവും മികച്ച ഉപകരണം തിരഞ്ഞെടുക്കുന്നു.
യുക്തിസഹമായ ഒരു പ്രതികരണം ഇതാണ്: രണ്ടും ചെയ്യാതെിരിക്കേണ്ടത് എന്തിന്? SAST റിപ്പോർട്ടോടെ ആരംഭിക്കുക, തുടർന്ന് കൂടുതൽ ആഴത്തിൽ റീസൺ ചെയ്യാൻ ഏജന്റിനെ ഉപയോഗിക്കുക.
മുന്കൂട്ടി കണക്കാക്കിയ കണ്ടെത്തലുകൾ ചില സാഹചര്യങ്ങളിൽ സഹായകരമാണ്, പ്രത്യേകിച്ച് ചുരുങ്ങിയതും അറിയപ്പെടുന്നതുമായ ബഗ് ക്ലാസുകൾക്കായി. എന്നാൽ സന്ദർഭത്തിൽ ദുർബലതകൾ കണ്ടെത്താനും സാധൂകരിക്കാനും രൂപകൽപ്പന ചെയ്ത ഒരു ഏജന്റിനായി, SAST റിപ്പോർട്ടിൽ നിന്ന് തുടങ്ങുന്നത് മൂന്നു പ്രവചനീയമായ പരാജയ മോഡുകൾ സൃഷ്ടിക്കുന്നു.
ആദ്യം, ഇത് നേരത്തെയുള്ള ചുരുക്കൽ പ്രോത്സാഹിപ്പിക്കാം. കണ്ടെത്തലുകളുടെ ഒരു ലിസ്റ്റ് എന്നത് ഒരു ടൂൾ ഇതിനകം പരിശോധിച്ച ഇടങ്ങള് എവിടെയാണെന്ന് കാണിക്കുന്ന ഒരു മാപ്പാണ്. നിങ്ങൾ അതൊരു തുടക്കമായി കരുതുമ്പോള്, അതേ പ്രദേശങ്ങളിലേക്കാണ് സിസ്റ്റം കൂടുതൽ പരിശ്രമം ചെലവഴിക്കാൻ പ്രേരിപ്പിക്കപെടുന്നത്, അതേ അബ്സ്ട്രാക്ഷനുകൾ ഉപയോഗിച്ച്, ടൂളിന്റെ ലോകദർശനത്തിന് ചേരാത്ത പ്രശ്നങ്ങളുടെ തരങ്ങൾ ശ്രദ്ധയിൽപ്പെടാതെ പോകുകയും ചെയ്യും.
രണ്ടാമതായി, ഇത് പിരിച്ചെടുക്കാൻ ബുദ്ധിമുട്ടുള്ള അവ്യക്തമായ വിധിനിർണയങ്ങൾ അവതരിപ്പിക്കാൻ ഇടയാക്കും. പല SAST കണ്ടെത്തലുകളും സാനിറ്റൈസേഷൻ, വാലിഡേഷൻ, അല്ലെങ്കിൽ ട്രസ്റ്റ് ബൗണ്ടറികൾ സംബന്ധിച്ച അനുമാനങ്ങൾ എൻകോഡ് ചെയ്യുന്നു. ആ അനുമാനങ്ങൾ തെറ്റായതാണെങ്കിൽ—അല്ലെങ്കിൽ വെറും അപൂർണ്ണമാണെങ്കിൽ—അവയെ റീസണിംഗ് ലൂപ്പിലേക്ക് നൽകുന്നത് ഏജന്റിനെ “അന്വേഷിക്കുക” എന്നതിൽ നിന്ന് “സ്ഥിരീകരിക്കുക അല്ലെങ്കിൽ തള്ളിക്കളയുക” എന്നതിലേക്കു മാറ്റും, എന്നാൽ ഏജന്റ് ചെയ്യേണ്ടത് അതല്ല.
മൂന്നാമതായി, ഇത് റീസണിംഗ് സിസ്റ്റത്തെ വിലയിരുത്തുന്നത് കൂടുതൽ പ്രയാസകരമാക്കാം. പൈപ്പ്ലൈൻ SAST ഔട്ട്പുട്ടോടെ ആരംഭിക്കുകയാണെങ്കിൽ, ഏജന്റ് സ്വന്തം വിശകലനത്തിലൂടെ കണ്ടെത്തിയതും മറ്റൊരു ടൂളിൽ നിന്ന് പാരമ്പര്യമായി ലഭിച്ചതും വേർതിരിക്കുന്നത് പ്രയാസകരമാകും. സിസ്റ്റത്തിന്റെ കഴിവുകൾ കൃത്യമായി അളക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ ആ വേർതിരിവ് പ്രധാനമാണ്; സിസ്റ്റം കാലക്രമേണ മെച്ചപ്പെടുന്നതിനായി അത് ആവശ്യമാണ്.
അതുകൊണ്ട്, മനുഷ്യനെ ഇടപെടലിന് തടസ്സപ്പെടുത്തുന്നതിന് മുമ്പ് ആത്മവിശ്വാസത്തിന്റെ നിലവാരം ഉയർത്താൻ സാധൂകരണത്തെ ഉപയോഗിച്ച്, കോഡിലും സിസ്റ്റത്തിന്റെ ഉദ്ദേശത്തിലും നിന്ന്—സുരക്ഷാ ഗവേഷണം ആരംഭിക്കുന്നിടത്ത് നിന്നുതന്നെ—ആരംഭിക്കാൻ ഞങ്ങൾ Codex സെക്യൂരിറ്റിയെ നിർമ്മിച്ചു.
SAST ഉപകരണങ്ങൾ അവ രൂപകൽപ്പന ചെയ്തിരിക്കുന്ന കാര്യങ്ങളിൽ അത്യുത്തമമാകാം: സുരക്ഷിത കോഡിംഗ് മാനദണ്ഡങ്ങൾ നടപ്പിലാക്കൽ, നേരിയ സോഴ്സ് മുതല് സിങ്ക് വരെയുള്ള പ്രശ്നങ്ങളെ പിടികൂടൽ, പ്രവചിക്കാവുന്ന ട്രേഡ്ഓഫുകളോടെ വലിയ തോതിൽ അറിയപ്പെടുന്ന പാറ്റേണുകൾ കണ്ടെത്തൽ എന്നിവയില്. അവ ആഴത്തിലുള്ള പ്രതിരോധത്തിന്റെ ശക്തമായ ഭാഗവും ആകാം.
ഈ പോസ്റ്റ് കൂടുതൽ പരിമിതമാണ്: പെരുമാറ്റത്തെക്കുറിച്ച് ചിന്തിക്കാനും കണ്ടെത്തലുകൾ സാധൂകരിക്കാനും രൂപകൽപ്പന ചെയ്ത ഒരു ഏജന്റ് തന്റെ പ്രവർത്തനം ഒരു സ്ഥിരമായ കണ്ടെത്തൽ പട്ടികയിൽ ആങ്കർ ചെയ്തുകൊണ്ട് ആരംഭിക്കരുതാത്തതിന്റെ കാരണമെന്തെന്നതാണ് ഇത്.
സോഴ്സ് മുതല് സിങ്ക് വരെഉള്ള ഒഴുക്ക് മാത്രം ചിന്തിക്കുന്നതിന്റെ ഒരു പരിമിതിയും ചൂണ്ടിക്കാണിക്കേണ്ടതാണ്: എല്ലാ ദുർബലതകളും ഡാറ്റ ഫ്ലോ പ്രശ്നങ്ങൾ അല്ല. പല യഥാർത്ഥ പരാജയങ്ങളും state-യും invariant-മായ പ്രശ്നങ്ങളാണ്—wവർക്ക്ഫ്ലോ ബൈപാസുകളും authorization ഗ്യാപുകളും, കൂടാതെ “സിസ്റ്റം തെറ്റായ state-ലാണ്” എന്ന തരത്തിലുള്ള പിഴവുകൾ. ഈ തരത്തിലുള്ള പിഴവുകളിൽ, ഒരു tainted വാല്യൂ ഒരൊറ്റ “ഡേഞ്ചറസ് സിങ്ക്” വരെ എത്തുന്നില്ല. അപകടസാധ്യത പ്രോഗ്രാം എപ്പോഴും സത്യമാണെന്ന് കരുതുന്ന കാര്യത്തിലാണ്.
സുരക്ഷാ ടൂളിംഗ് ഇക്കോസിസ്റ്റം തുടർന്നും മെച്ചപ്പെടുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു: സ്റ്റാറ്റിക് വിശകലനം, ഫസ്സിംഗ്, റൺടൈം ഗാർഡുകൾ, ഏജന്റിക് പ്രവാഹങ്ങൾ എന്നിവയ്ക്കെല്ലാം പങ്കുണ്ടാകും.
സുരക്ഷാ ടീമുകൾക്ക് ഏറ്റവും കൂടുതൽ ചെലവാകുന്ന ഭാഗം—“ഇത് സംശയാസ്പദമാണെന്ന് തോന്നുന്നു” എന്നതിനെ “ഇത് യഥാർത്ഥമാണ്, ഇത് എങ്ങനെ പരാജയപ്പെടുന്നു, സിസ്റ്റത്തിന്റെ ഉദ്ദേശ്യത്തോട് പൊരുത്തപ്പെടുന്ന ഒരു പരിഹാരം ഇതാ” എന്നതാക്കി മാറ്റുന്നത്—Codex Security നന്നായി ചെയ്യണമെന്നാണ് ഞങ്ങൾ ആഗ്രഹിക്കുന്നത്.
Codex സെക്യൂരിറ്റി റിപ്പോസിറ്ററികൾ എങ്ങനെ സ്കാൻ ചെയ്യുന്നു, കണ്ടെത്തലുകൾ സാധൂകരിക്കുന്നു, പരിഹാരങ്ങൾ നിർദേശിക്കുന്നു എന്നിവയെക്കുറിച്ച് കൂടുതൽ അറിയാൻ ഞങ്ങളുടെ ഡോക്യുമെന്റേഷൻ(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) കാണുക.
