DevSecOps-നോടുള്ള ഭയവും വെറുപ്പും

ഞങ്ങൾക്ക് 2 കോഡ് അനലൈസറുകൾ, 4 ഡൈനാമിക് ടെസ്റ്റിംഗ് ടൂളുകൾ, ഞങ്ങളുടെ സ്വന്തം കരകൗശലവസ്തുക്കൾ, 250 സ്ക്രിപ്റ്റുകൾ എന്നിവ ഉണ്ടായിരുന്നു. നിലവിലെ പ്രക്രിയയിൽ ഇതെല്ലാം ആവശ്യമാണെന്നല്ല, നിങ്ങൾ DevSecOps നടപ്പിലാക്കാൻ തുടങ്ങിയാൽ, നിങ്ങൾ അവസാനം വരെ പോകേണ്ടതുണ്ട്.

ഉറവിടം. കഥാപാത്രങ്ങളുടെ സ്രഷ്ടാക്കൾ: ജസ്റ്റിൻ റോയ്‌ലൻഡും ഡാൻ ഹാർമനും.

എന്താണ് SecDevOps? DevSecOps-ന്റെ കാര്യമോ? എന്താണ് വ്യത്യാസങ്ങൾ? ആപ്ലിക്കേഷൻ സുരക്ഷ - ഇത് എന്തിനെക്കുറിച്ചാണ്? എന്തുകൊണ്ടാണ് ക്ലാസിക് സമീപനം പ്രവർത്തിക്കാത്തത്? ഈ ചോദ്യങ്ങൾക്കെല്ലാം ഉത്തരം അറിയാം യൂറി ഷബാലിൻ നിന്ന് വാൾ മത്സ്യം സുരക്ഷ. യൂറി എല്ലാത്തിനും വിശദമായി ഉത്തരം നൽകുകയും ക്ലാസിക്കൽ ആപ്ലിക്കേഷൻ സെക്യൂരിറ്റി മോഡലിൽ നിന്ന് DevSecOps പ്രക്രിയയിലേക്കുള്ള പരിവർത്തനത്തിന്റെ പ്രശ്നങ്ങൾ വിശകലനം ചെയ്യുകയും ചെയ്യും: DevOps പ്രക്രിയയിലേക്ക് സുരക്ഷിത വികസന പ്രക്രിയയുടെ സംയോജനത്തെ എങ്ങനെ ശരിയായി സമീപിക്കാം, ഒന്നും തകർക്കരുത്, പ്രധാന ഘട്ടങ്ങളിലൂടെ എങ്ങനെ പോകാം സുരക്ഷാ പരിശോധന, ഏതൊക്കെ ടൂളുകൾ ഉപയോഗിക്കാം, അവയിൽ വ്യത്യാസങ്ങൾ എന്തൊക്കെയാണെന്നും അപകടങ്ങൾ ഒഴിവാക്കാൻ അവ എങ്ങനെ ശരിയായി ക്രമീകരിക്കാമെന്നും.

സ്പീക്കറെ കുറിച്ച്: യൂറി ഷബാലിൻ - കമ്പനിയിലെ ചീഫ് സെക്യൂരിറ്റി ആർക്കിടെക്റ്റ് വാൾ മത്സ്യം സുരക്ഷ. ഒരു ഏകീകൃത വികസനവും പരിശോധനാ ആവാസവ്യവസ്ഥയുമായി ആപ്ലിക്കേഷൻ വിശകലന ടൂളുകളുടെ മൊത്തത്തിലുള്ള സംയോജനത്തിന് SSDL നടപ്പിലാക്കുന്നതിനുള്ള ഉത്തരവാദിത്തം. വിവര സുരക്ഷയിൽ 7 വർഷത്തെ പരിചയം. സോഫ്റ്റ്‌വെയർ വികസിപ്പിക്കുകയും സേവനങ്ങൾ നൽകുകയും ചെയ്യുന്ന Alfa-Bank, Sberbank, Positive Technologies എന്നിവിടങ്ങളിൽ ജോലി ചെയ്തു. അന്താരാഷ്ട്ര കോൺഫറൻസുകളിൽ സ്പീക്കർ ZerONights, PHDays, RISSPA, OWASP.

ആപ്ലിക്കേഷൻ സുരക്ഷ: ഇത് എന്തിനെക്കുറിച്ചാണ്?

അപ്ലിക്കേഷൻ സുരക്ഷ - ഇത് ആപ്ലിക്കേഷൻ സുരക്ഷയുടെ ഉത്തരവാദിത്തമുള്ള സുരക്ഷാ വിഭാഗമാണ്. ഇത് ഇൻഫ്രാസ്ട്രക്ചറിനോ നെറ്റ്‌വർക്ക് സുരക്ഷയ്‌ക്കോ ബാധകമല്ല, മറിച്ച് ഞങ്ങൾ എഴുതുന്നതിനും ഡെവലപ്പർമാർ പ്രവർത്തിക്കുന്നതിനും - ഇവ ആപ്ലിക്കേഷന്റെ തന്നെ പോരായ്മകളും കേടുപാടുകളും ആണ്.

ദിശ SDL അല്ലെങ്കിൽ SDLC - സുരക്ഷാ വികസന ജീവിതചക്രം - മൈക്രോസോഫ്റ്റ് വികസിപ്പിച്ചത്. ഡയഗ്രം കാനോനിക്കൽ SDLC മോഡൽ കാണിക്കുന്നു, ആവശ്യകതകൾ മുതൽ റിലീസ്, ഉൽപ്പാദനം വരെയുള്ള വികസനത്തിന്റെ ഓരോ ഘട്ടത്തിലും സുരക്ഷയുടെ പങ്കാളിത്തമാണ് ഇതിന്റെ പ്രധാന ദൌത്യം. വ്യവസായത്തിൽ വളരെയധികം ബഗുകളുണ്ടെന്നും അവയിൽ കൂടുതൽ ഉണ്ടെന്നും അതിനെക്കുറിച്ച് എന്തെങ്കിലും ചെയ്യേണ്ടതുണ്ടെന്നും മൈക്രോസോഫ്റ്റ് മനസ്സിലാക്കി, അവർ ഈ സമീപനം നിർദ്ദേശിച്ചു, അത് കാനോനിക്കൽ ആയി മാറി.

ആപ്ലിക്കേഷൻ സെക്യൂരിറ്റിയും SSDL ഉം സാധാരണയായി വിശ്വസിക്കുന്നത് പോലെ കേടുപാടുകൾ കണ്ടുപിടിക്കാൻ ലക്ഷ്യമിട്ടുള്ളതല്ല, മറിച്ച് അവ സംഭവിക്കുന്നത് തടയുകയാണ്. കാലക്രമേണ, മൈക്രോസോഫ്റ്റിന്റെ കാനോനിക്കൽ സമീപനം മെച്ചപ്പെടുത്തുകയും വികസിപ്പിക്കുകയും ആഴത്തിലുള്ളതും കൂടുതൽ വിശദമായതുമായ ഡൈവിലേക്ക് അവതരിപ്പിക്കുകയും ചെയ്തു.

കാനോനിക്കൽ SDLC വിവിധ രീതികളിൽ വളരെ വിശദമായി വിവരിച്ചിരിക്കുന്നു - OpenSAMM, BSIMM, OWASP. രീതികൾ വ്യത്യസ്തമാണ്, പക്ഷേ പൊതുവെ സമാനമാണ്.

മെച്യൂരിറ്റി മോഡലിൽ ബിൽഡിംഗ് സെക്യൂരിറ്റി

എനിക്കത് ഏറ്റവും ഇഷ്ടമാണ് ബിഎസ്ഐഎംഎം - മെച്യൂരിറ്റി മോഡലിൽ ബിൽഡിംഗ് സെക്യൂരിറ്റി. ആപ്ലിക്കേഷൻ സെക്യൂരിറ്റി പ്രക്രിയയെ 4 ഡൊമെയ്‌നുകളായി വിഭജിക്കുന്നതാണ് രീതിശാസ്ത്രത്തിന്റെ അടിസ്ഥാനം: ഭരണം, ഇന്റലിജൻസ്, SSDL ടച്ച് പോയിന്റുകൾ, വിന്യാസം. ഓരോ ഡൊമെയ്‌നിനും 12 സമ്പ്രദായങ്ങളുണ്ട്, അവ 112 പ്രവർത്തനങ്ങളായി പ്രതിനിധീകരിക്കുന്നു.

112 പ്രവർത്തനങ്ങളിൽ ഓരോന്നിനും ഉണ്ട് പക്വതയുടെ 3 ലെവലുകൾ: തുടക്കക്കാരൻ, ഇന്റർമീഡിയറ്റ്, അഡ്വാൻസ്ഡ്. നിങ്ങൾക്ക് എല്ലാ 12 പ്രാക്ടീസുകളും സെക്ഷൻ പ്രകാരം പഠിക്കാം, നിങ്ങൾക്ക് പ്രധാനപ്പെട്ട കാര്യങ്ങൾ തിരഞ്ഞെടുക്കാം, അവ എങ്ങനെ നടപ്പിലാക്കണം എന്ന് കണ്ടെത്തുകയും ക്രമേണ ഘടകങ്ങൾ ചേർക്കുകയും ചെയ്യാം, ഉദാഹരണത്തിന്, സ്റ്റാറ്റിക്, ഡൈനാമിക് കോഡ് വിശകലനം അല്ലെങ്കിൽ കോഡ് അവലോകനം. തിരഞ്ഞെടുത്ത പ്രവർത്തനങ്ങൾ നടപ്പിലാക്കുന്നതിന്റെ ഭാഗമായി നിങ്ങൾ ഒരു പ്ലാൻ എഴുതുകയും അതിനനുസരിച്ച് ശാന്തമായി പ്രവർത്തിക്കുകയും ചെയ്യുക.

എന്തുകൊണ്ട് DevSecOps

DevOps എന്നത് സുരക്ഷ കണക്കിലെടുക്കേണ്ട ഒരു പൊതു, വലിയ പ്രക്രിയയാണ്.

തുടക്കത്തിൽ DevOps സുരക്ഷാ പരിശോധനകളിൽ ഉൾപ്പെട്ടു. പ്രായോഗികമായി, സെക്യൂരിറ്റി ടീമുകളുടെ എണ്ണം ഇപ്പോഴത്തേതിനേക്കാൾ വളരെ കുറവായിരുന്നു, അവർ ഈ പ്രക്രിയയിൽ പങ്കാളികളായല്ല, മറിച്ച് ആവശ്യകതകൾ ചുമത്തുകയും റിലീസിന്റെ അവസാനം ഉൽപ്പന്നത്തിന്റെ ഗുണനിലവാരം പരിശോധിക്കുകയും ചെയ്യുന്ന ഒരു നിയന്ത്രണ, സൂപ്പർവൈസറി ബോഡിയായി പ്രവർത്തിച്ചു. ഇത് ഒരു ക്ലാസിക് സമീപനമാണ്, അതിൽ സുരക്ഷാ ടീമുകൾ വികസനത്തിൽ നിന്ന് മതിലിന് പിന്നിലായിരുന്നു, ഈ പ്രക്രിയയിൽ പങ്കെടുക്കുന്നില്ല.

വിവര സുരക്ഷ വികസനത്തിൽ നിന്ന് വ്യത്യസ്തമാണ് എന്നതാണ് പ്രധാന പ്രശ്നം. സാധാരണയായി ഇത് ഒരുതരം വിവര സുരക്ഷാ സർക്യൂട്ടാണ്, അതിൽ 2-3 വലുതും ചെലവേറിയതുമായ ഉപകരണങ്ങൾ അടങ്ങിയിരിക്കുന്നു. ഓരോ ആറുമാസത്തിലൊരിക്കൽ, പരിശോധിക്കേണ്ട സോഴ്‌സ് കോഡോ ആപ്ലിക്കേഷനോ വരുന്നു, വർഷത്തിലൊരിക്കൽ അവ നിർമ്മിക്കപ്പെടുന്നു പെന്റസ്റ്റുകൾ. ഇതെല്ലാം വ്യവസായത്തിന്റെ റിലീസ് തീയതി വൈകുന്നു എന്ന വസ്തുതയിലേക്ക് നയിക്കുന്നു, കൂടാതെ ഡവലപ്പർ ഓട്ടോമേറ്റഡ് ടൂളുകളിൽ നിന്നുള്ള ധാരാളം കേടുപാടുകൾക്ക് വിധേയമാകുന്നു. ഇതെല്ലാം ഡിസ്അസംബ്ലിംഗ് ചെയ്യുകയും നന്നാക്കുകയും ചെയ്യുന്നത് അസാധ്യമാണ്, കാരണം കഴിഞ്ഞ ആറ് മാസത്തെ ഫലങ്ങൾ ക്രമീകരിച്ചിട്ടില്ല, പക്ഷേ ഇതാ ഒരു പുതിയ ബാച്ച്.

ഞങ്ങളുടെ കമ്പനിയുടെ പ്രവർത്തനത്തിനിടയിൽ, എല്ലാ മേഖലകളിലെയും വ്യവസായങ്ങളിലെയും സുരക്ഷ ഒരേ ചക്രത്തിൽ വികസനം നേടാനും കറങ്ങാനുമുള്ള സമയമാണെന്ന് മനസ്സിലാക്കുന്നത് ഞങ്ങൾ കാണുന്നു. ദുശ്ശീലം. എല്ലാ റിലീസുകളിലും ആവർത്തനങ്ങളിലും ചടുലമായ വികസന രീതി, നടപ്പിലാക്കൽ, പിന്തുണ, പങ്കാളിത്തം എന്നിവയുമായി DevSecOps മാതൃക തികച്ചും യോജിക്കുന്നു.

DevSecOps-ലേക്കുള്ള മാറ്റം

സുരക്ഷാ വികസന ജീവിതചക്രത്തിലെ ഏറ്റവും പ്രധാനപ്പെട്ട വാക്ക് "പ്രക്രിയ". ഉപകരണങ്ങൾ വാങ്ങുന്നതിനെക്കുറിച്ച് ചിന്തിക്കുന്നതിനുമുമ്പ് നിങ്ങൾ ഇത് മനസ്സിലാക്കണം.

DevOps പ്രോസസിലേക്ക് ടൂളുകൾ ഉൾപ്പെടുത്തിയാൽ മാത്രം പോരാ-പ്രോസസ് പങ്കാളികൾ തമ്മിലുള്ള ആശയവിനിമയവും ധാരണയും പ്രധാനമാണ്.

ആളുകളാണ് കൂടുതൽ പ്രധാനം, ഉപകരണങ്ങളല്ല.

മിക്കപ്പോഴും, സുരക്ഷിതമായ ഒരു വികസന പ്രക്രിയയ്‌ക്കായുള്ള ആസൂത്രണം ഒരു ഉപകരണം തിരഞ്ഞെടുത്ത് വാങ്ങുന്നതിലൂടെ ആരംഭിക്കുന്നു, കൂടാതെ ടൂളിനെ നിലവിലെ പ്രക്രിയയിലേക്ക് സംയോജിപ്പിക്കാനുള്ള ശ്രമങ്ങളിൽ അവസാനിക്കുന്നു, അത് ശ്രമങ്ങളായി തുടരുന്നു. ഇത് നിർഭാഗ്യകരമായ അനന്തരഫലങ്ങളിലേക്ക് നയിക്കുന്നു, കാരണം എല്ലാ ഉപകരണങ്ങൾക്കും അവരുടേതായ സവിശേഷതകളും പരിമിതികളും ഉണ്ട്.

സെക്യൂരിറ്റി ഡിപ്പാർട്ട്‌മെന്റ് വിശാലമായ കഴിവുകളുള്ള ഒരു നല്ല, ചെലവേറിയ ഉപകരണം തിരഞ്ഞെടുത്ത് ഡെവലപ്പർമാരുടെ അടുത്ത് വന്ന് അത് പ്രക്രിയയിൽ സംയോജിപ്പിക്കുന്നതാണ് ഒരു സാധാരണ കേസ്. എന്നാൽ ഇത് പ്രവർത്തിക്കുന്നില്ല - ഇതിനകം വാങ്ങിയ ഉപകരണത്തിന്റെ പരിമിതികൾ നിലവിലെ മാതൃകയുമായി പൊരുത്തപ്പെടാത്ത വിധത്തിലാണ് പ്രക്രിയ ക്രമീകരിച്ചിരിക്കുന്നത്.

ആദ്യം, നിങ്ങൾക്ക് എന്ത് ഫലമാണ് വേണ്ടതെന്നും പ്രക്രിയ എങ്ങനെയായിരിക്കുമെന്നും വിവരിക്കുക. ഈ പ്രക്രിയയിൽ ഉപകരണത്തിന്റെയും സുരക്ഷയുടെയും റോളുകൾ മനസ്സിലാക്കാൻ ഇത് സഹായിക്കും.

ഇതിനകം ഉപയോഗത്തിലുള്ളവയിൽ നിന്ന് ആരംഭിക്കുക

വിലയേറിയ ഉപകരണങ്ങൾ വാങ്ങുന്നതിനുമുമ്പ്, നിങ്ങൾക്ക് ഇതിനകം ഉള്ളത് നോക്കുക. എല്ലാ കമ്പനികൾക്കും വികസനത്തിന് സുരക്ഷാ ആവശ്യകതകളുണ്ട്, പരിശോധനകളും പെന്റസ്റ്റുകളും ഉണ്ട് - എന്തുകൊണ്ട് ഇതെല്ലാം എല്ലാവർക്കും മനസ്സിലാക്കാവുന്നതും സൗകര്യപ്രദവുമായ ഒരു രൂപമാക്കി മാറ്റിക്കൂടാ?

സാധാരണയായി ആവശ്യകതകൾ ഒരു ഷെൽഫിൽ കിടക്കുന്ന ഒരു പേപ്പർ ടാൽമുഡാണ്. ഞങ്ങൾ ഒരു കമ്പനിയിൽ പ്രോസസുകൾ നോക്കാൻ വന്നപ്പോൾ സോഫ്റ്റ്വെയറിന്റെ സുരക്ഷാ ആവശ്യകതകൾ കാണാൻ ആവശ്യപ്പെട്ടപ്പോൾ ഒരു കേസ് ഉണ്ടായിരുന്നു. ഇത് കൈകാര്യം ചെയ്ത സ്പെഷ്യലിസ്റ്റ് വളരെക്കാലം തിരഞ്ഞു:

- ഇപ്പോൾ, കുറിപ്പുകളിൽ എവിടെയോ ഈ പ്രമാണം കിടക്കുന്ന ഒരു പാത ഉണ്ടായിരുന്നു.

തൽഫലമായി, ഒരാഴ്ചയ്ക്ക് ശേഷം ഞങ്ങൾക്ക് പ്രമാണം ലഭിച്ചു.

ആവശ്യകതകൾക്കും പരിശോധനകൾക്കും മറ്റ് കാര്യങ്ങൾക്കുമായി ഒരു പേജ് സൃഷ്ടിക്കുക ഉദാ. സംഗമം - ഇത് എല്ലാവർക്കും സൗകര്യപ്രദമാണ്.

നിങ്ങൾക്ക് ഇതിനകം ഉള്ളത് വീണ്ടും ഫോർമാറ്റ് ചെയ്യാനും ആരംഭിക്കുന്നതിന് അത് ഉപയോഗിക്കാനും എളുപ്പമാണ്.

സുരക്ഷാ ചാമ്പ്യൻമാരെ ഉപയോഗിക്കുക

സാധാരണഗതിയിൽ, 100-200 ഡെവലപ്പർമാരുള്ള ഒരു ശരാശരി കമ്പനിയിൽ, നിരവധി പ്രവർത്തനങ്ങൾ നിർവ്വഹിക്കുന്ന ഒരു സുരക്ഷാ സ്പെഷ്യലിസ്റ്റ് ഉണ്ട്, കൂടാതെ എല്ലാം പരിശോധിക്കാൻ ശാരീരികമായി സമയമില്ല. അവൻ പരമാവധി ശ്രമിച്ചാലും, വികസനം സൃഷ്ടിക്കുന്ന എല്ലാ കോഡുകളും അദ്ദേഹം മാത്രം പരിശോധിക്കില്ല. അത്തരം സന്ദർഭങ്ങളിൽ, ഒരു ആശയം വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട് - സുരക്ഷാ ചാമ്പ്യന്മാർ.

നിങ്ങളുടെ ഉൽപ്പന്നത്തിന്റെ സുരക്ഷയിൽ താൽപ്പര്യമുള്ള ഡെവലപ്‌മെന്റ് ടീമിലെ ആളുകളാണ് സുരക്ഷാ ചാമ്പ്യന്മാർ.

സെക്യൂരിറ്റി ചാമ്പ്യൻ ഡെവലപ്‌മെന്റ് ടീമിലേക്കുള്ള ഒരു എൻട്രി പോയിന്റാണ്, കൂടാതെ ഒരു സുരക്ഷാ സുവിശേഷകൻ ഒന്നായി ചുരുട്ടി.

സാധാരണയായി, ഒരു സെക്യൂരിറ്റി സ്പെഷ്യലിസ്റ്റ് ഒരു ഡെവലപ്‌മെന്റ് ടീമിന്റെ അടുത്ത് വന്ന് കോഡിലെ ഒരു പിശക് ചൂണ്ടിക്കാണിച്ചാൽ, അയാൾക്ക് ആശ്ചര്യകരമായ ഒരു ഉത്തരം ലഭിക്കും:

- പിന്നെ നിങ്ങൾ ആരാണ്? ഞാൻ നിന്നെ ആദ്യമായി കാണുന്നു. എന്റെ കാര്യത്തിൽ എല്ലാം ശരിയാണ് - കോഡ് അവലോകനത്തിൽ എന്റെ മുതിർന്ന സുഹൃത്ത് എനിക്ക് “അപേക്ഷിക്കുക” നൽകി, ഞങ്ങൾ മുന്നോട്ട് പോകുന്നു!

ഇതൊരു സാധാരണ സാഹചര്യമാണ്, കാരണം ഡെവലപ്പർ ജോലിസ്ഥലത്തും കോഡ് അവലോകനത്തിലും നിരന്തരം ഇടപഴകുന്ന മുതിർന്നവരിലോ ടീമംഗങ്ങളിലോ കൂടുതൽ വിശ്വാസമുണ്ട്. സുരക്ഷാ ഉദ്യോഗസ്ഥന് പകരം സുരക്ഷാ ചാമ്പ്യൻ തെറ്റും അനന്തരഫലങ്ങളും ചൂണ്ടിക്കാണിച്ചാൽ, അവന്റെ വാക്കിന് കൂടുതൽ ഭാരം ഉണ്ടാകും.

കൂടാതെ, ഡെവലപ്പർമാർക്ക് അവരുടെ കോഡ് ഏതൊരു സുരക്ഷാ വിദഗ്ദ്ധനെക്കാളും നന്നായി അറിയാം. ഒരു സ്റ്റാറ്റിക് അനാലിസിസ് ടൂളിൽ കുറഞ്ഞത് 5 പ്രോജക്ടുകളെങ്കിലും ഉള്ള ഒരു വ്യക്തിക്ക്, എല്ലാ സൂക്ഷ്മതകളും ഓർക്കാൻ സാധാരണയായി ബുദ്ധിമുട്ടാണ്. സെക്യൂരിറ്റി ചാമ്പ്യൻമാർക്ക് അവരുടെ ഉൽപ്പന്നം അറിയാം: എന്താണ് സംവദിക്കുന്നത്, എന്താണ് ആദ്യം നോക്കേണ്ടത് - അവ കൂടുതൽ ഫലപ്രദമാണ്.

അതിനാൽ സെക്യൂരിറ്റി ചാമ്പ്യൻസ് നടപ്പിലാക്കുന്നതും നിങ്ങളുടെ സുരക്ഷാ ടീമിന്റെ സ്വാധീനം വിപുലീകരിക്കുന്നതും പരിഗണിക്കുക. ചാമ്പ്യനും ഇത് ഉപയോഗപ്രദമാണ്: ഒരു പുതിയ മേഖലയിലെ പ്രൊഫഷണൽ വികസനം, അവന്റെ സാങ്കേതിക ചക്രവാളങ്ങൾ വികസിപ്പിക്കുക, സാങ്കേതിക, മാനേജുമെന്റ്, നേതൃത്വ കഴിവുകൾ നവീകരിക്കുക, വിപണി മൂല്യം വർദ്ധിപ്പിക്കുക. ഇത് സോഷ്യൽ എഞ്ചിനീയറിംഗിന്റെ ചില ഘടകങ്ങളാണ്, വികസന ടീമിലെ നിങ്ങളുടെ "കണ്ണുകൾ".

ടെസ്റ്റിംഗ് ഘട്ടങ്ങൾ

മാതൃക 20 മുതൽ 80 വരെ 20% പരിശ്രമം 80% ഫലം പുറപ്പെടുവിക്കുന്നുവെന്ന് പറയുന്നു. ഈ 20% ആപ്ലിക്കേഷൻ വിശകലന രീതികളാണ്, അത് യാന്ത്രികമാക്കാനും കഴിയും. അത്തരം പ്രവർത്തനങ്ങളുടെ ഉദാഹരണങ്ങളാണ് സ്റ്റാറ്റിക് വിശകലനം - SAST, ചലനാത്മക വിശകലനം - DAST и ഓപ്പൺ സോഴ്സ് നിയന്ത്രണം. പ്രവർത്തനങ്ങളെക്കുറിച്ചും ടൂളുകളെക്കുറിച്ചും കൂടുതൽ വിശദമായി ഞാൻ നിങ്ങളോട് പറയും, ഈ പ്രക്രിയയിൽ അവ അവതരിപ്പിക്കുമ്പോൾ ഞങ്ങൾ സാധാരണയായി നേരിടുന്ന സവിശേഷതകൾ, അത് എങ്ങനെ ശരിയായി ചെയ്യണം.

ഉപകരണങ്ങളുടെ പ്രധാന പ്രശ്നങ്ങൾ

എല്ലാ ഉപകരണങ്ങൾക്കും പ്രസക്തവും ശ്രദ്ധ ആവശ്യമുള്ളതുമായ പ്രശ്നങ്ങൾ ഞാൻ ഹൈലൈറ്റ് ചെയ്യും. കൂടുതൽ ആവർത്തിക്കാതിരിക്കാൻ ഞാൻ അവയെ കൂടുതൽ വിശദമായി വിശകലനം ചെയ്യും.

നീണ്ട വിശകലന സമയം. എല്ലാ ടെസ്റ്റുകൾക്കും അസംബ്ലിക്കും കമ്മിറ്റ് മുതൽ റിലീസ് ചെയ്യാൻ 30 മിനിറ്റ് എടുക്കുമെങ്കിൽ, വിവര സുരക്ഷാ പരിശോധനകൾക്ക് ഒരു ദിവസമെടുക്കും. അതിനാൽ ആരും ഈ പ്രക്രിയയെ മന്ദഗതിയിലാക്കില്ല. ഈ സവിശേഷത കണക്കിലെടുക്കുകയും നിഗമനങ്ങളിൽ എത്തിച്ചേരുകയും ചെയ്യുക.

തെറ്റായ നെഗറ്റീവ് അല്ലെങ്കിൽ ഫാൾസ് പോസിറ്റീവിന്റെ ഉയർന്ന തലം. എല്ലാ ഉൽപ്പന്നങ്ങളും വ്യത്യസ്തമാണ്, എല്ലാം വ്യത്യസ്ത ചട്ടക്കൂടുകളും സ്വന്തം കോഡിംഗ് ശൈലിയും ഉപയോഗിക്കുന്നു. വ്യത്യസ്‌ത കോഡ്‌ബേസുകളിലും സാങ്കേതികവിദ്യകളിലും, ഉപകരണങ്ങൾ തെറ്റായ നെഗറ്റീവ്, ഫാൾസ് പോസിറ്റീവ് എന്നിവയുടെ വ്യത്യസ്ത തലങ്ങൾ കാണിച്ചേക്കാം. അതിനാൽ കൃത്യമായി എന്താണ് ഉള്ളതെന്ന് നോക്കുക вашей കമ്പനികൾക്കും വേണ്ടി നിങ്ങളുടെ അപ്ലിക്കേഷനുകൾ നല്ലതും വിശ്വസനീയവുമായ ഫലങ്ങൾ കാണിക്കും.

നിലവിലുള്ള ഉപകരണങ്ങളുമായി സംയോജനങ്ങളൊന്നുമില്ല. നിങ്ങൾ ഇതിനകം ഉപയോഗിക്കുന്നവയുമായി സംയോജനത്തിന്റെ അടിസ്ഥാനത്തിൽ ടൂളുകൾ നോക്കുക. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് Jenkins അല്ലെങ്കിൽ TeamCity ഉണ്ടെങ്കിൽ, നിങ്ങൾ ഉപയോഗിക്കാത്ത GitLab CI ഉപയോഗിച്ചല്ല, ഈ സോഫ്റ്റ്‌വെയറുമായുള്ള ടൂളുകളുടെ സംയോജനം പരിശോധിക്കുക.

കസ്റ്റമൈസേഷന്റെ അഭാവം അല്ലെങ്കിൽ അമിതമായ സങ്കീർണ്ണത. ഒരു ടൂളിന് API ഇല്ലെങ്കിൽ, എന്തുകൊണ്ട് അത് ആവശ്യമാണ്? ഇന്റർഫേസിൽ ചെയ്യാൻ കഴിയുന്നതെല്ലാം API വഴി ലഭ്യമാകണം. മികച്ച രീതിയിൽ, ഉപകരണത്തിന് പരിശോധനകൾ ഇഷ്ടാനുസൃതമാക്കാനുള്ള കഴിവ് ഉണ്ടായിരിക്കണം.

ഉൽപ്പന്ന വികസന റോഡ്മാപ്പ് ഇല്ല. വികസനം നിശ്ചലമായി നിൽക്കുന്നില്ല, ഞങ്ങൾ എല്ലായ്പ്പോഴും പുതിയ ചട്ടക്കൂടുകളും പ്രവർത്തനങ്ങളും ഉപയോഗിക്കുന്നു, പഴയ കോഡ് പുതിയ ഭാഷകളിലേക്ക് മാറ്റിയെഴുതുന്നു. ഞങ്ങൾ വാങ്ങുന്ന ഉപകരണം പുതിയ ചട്ടക്കൂടുകളെയും സാങ്കേതികവിദ്യകളെയും പിന്തുണയ്ക്കുമെന്ന് ഉറപ്പാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. അതിനാൽ, ഉൽപ്പന്നത്തിന് യഥാർത്ഥവും ശരിയുമുണ്ടെന്ന് അറിയേണ്ടത് പ്രധാനമാണ് റോഡ്മാപ്പിലേക്ക് വികസനം.

പ്രോസസ് സവിശേഷതകൾ

ഉപകരണങ്ങളുടെ സവിശേഷതകൾ കൂടാതെ, വികസന പ്രക്രിയയുടെ സവിശേഷതകൾ കണക്കിലെടുക്കുക. ഉദാഹരണത്തിന്, വികസനം തടസ്സപ്പെടുത്തുന്നത് ഒരു സാധാരണ തെറ്റാണ്. മറ്റ് സവിശേഷതകൾ എന്തൊക്കെയാണ് കണക്കിലെടുക്കേണ്ടതെന്നും സുരക്ഷാ ടീം എന്താണ് ശ്രദ്ധിക്കേണ്ടതെന്നും നോക്കാം.

വികസനം നഷ്‌ടപ്പെടുത്താതിരിക്കാനും സമയപരിധി റിലീസ് ചെയ്യാനും, സൃഷ്‌ടിക്കുക വ്യത്യസ്ത നിയമങ്ങൾ വ്യത്യസ്തവും ഷോ സ്റ്റോപ്പറുകൾ - കേടുപാടുകളുടെ സാന്നിധ്യത്തിൽ നിർമ്മാണ പ്രക്രിയ നിർത്തുന്നതിനുള്ള മാനദണ്ഡം - വ്യത്യസ്ത പരിതസ്ഥിതികൾക്കായി. ഉദാഹരണത്തിന്, നിലവിലെ ബ്രാഞ്ച് ഡെവലപ്‌മെന്റ് സ്റ്റാൻഡിലേക്കോ UAT-ലേക്കോ പോകുന്നുവെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുന്നു, അതിനർത്ഥം ഞങ്ങൾ നിർത്താതെ പറയുക:

"നിങ്ങൾക്ക് ഇവിടെ കേടുപാടുകൾ ഉണ്ട്, നിങ്ങൾ ഇനി എവിടെയും പോകില്ല!"

ഈ സമയത്ത്, ശ്രദ്ധിക്കേണ്ട സുരക്ഷാ പ്രശ്‌നങ്ങളുണ്ടെന്ന് ഡെവലപ്പർമാരോട് പറയേണ്ടത് പ്രധാനമാണ്.

കൂടുതൽ പരിശോധനയ്ക്ക് കേടുപാടുകളുടെ സാന്നിധ്യം ഒരു തടസ്സമല്ല: മാനുവൽ, ഇന്റഗ്രേഷൻ അല്ലെങ്കിൽ മാനുവൽ. മറുവശത്ത്, ഞങ്ങൾ എങ്ങനെയെങ്കിലും ഉൽപ്പന്നത്തിന്റെ സുരക്ഷ വർദ്ധിപ്പിക്കേണ്ടതുണ്ട്, അതിനാൽ ഡെവലപ്പർമാർ സുരക്ഷിതമെന്ന് കരുതുന്നവ അവഗണിക്കരുത്. അതിനാൽ, ചിലപ്പോൾ ഞങ്ങൾ ഇത് ചെയ്യുന്നു: സ്റ്റാൻഡിൽ, അത് വികസന പരിതസ്ഥിതിയിലേക്ക് വ്യാപിപ്പിക്കുമ്പോൾ, ഞങ്ങൾ വികസനത്തെ അറിയിക്കുന്നു:

- സുഹൃത്തുക്കളേ, നിങ്ങൾക്ക് പ്രശ്നങ്ങളുണ്ട്, ദയവായി അവ ശ്രദ്ധിക്കുക.

UAT ഘട്ടത്തിൽ ഞങ്ങൾ വീണ്ടും അപകടസാധ്യതകളെക്കുറിച്ചുള്ള മുന്നറിയിപ്പുകൾ കാണിക്കുന്നു, റിലീസ് ഘട്ടത്തിൽ ഞങ്ങൾ പറയുന്നു:

- സുഹൃത്തുക്കളേ, ഞങ്ങൾ നിങ്ങൾക്ക് നിരവധി തവണ മുന്നറിയിപ്പ് നൽകി, നിങ്ങൾ ഒന്നും ചെയ്തില്ല - ഇത് നിങ്ങളെ ഞങ്ങൾ പുറത്തുവിടില്ല.

നമ്മൾ കോഡിനെയും ഡൈനാമിക്സിനെയും കുറിച്ച് സംസാരിക്കുകയാണെങ്കിൽ, ഈ സവിശേഷതയിൽ ഇപ്പോൾ എഴുതിയിട്ടുള്ള ഫീച്ചറുകളുടെയും കോഡിന്റെയും കേടുപാടുകൾ മാത്രം കാണിക്കുകയും മുന്നറിയിപ്പ് നൽകുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്. ഒരു ഡെവലപ്പർ ഒരു ബട്ടൺ 3 പിക്സലുകൾ നീക്കിയാൽ, അയാൾക്ക് അവിടെ ഒരു SQL ഇഞ്ചക്ഷൻ ഉണ്ടെന്നും അതിനാൽ അത് അടിയന്തിരമായി പരിഹരിക്കേണ്ടതുണ്ടെന്നും ഞങ്ങൾ അവനോട് പറയുകയാണെങ്കിൽ, ഇത് തെറ്റാണ്. ഇപ്പോൾ എഴുതിയിരിക്കുന്നതും ആപ്ലിക്കേഷനിൽ വരുന്ന മാറ്റവും മാത്രം നോക്കുക.

ഞങ്ങൾക്ക് ഒരു പ്രത്യേക പ്രവർത്തന വൈകല്യമുണ്ടെന്ന് പറയാം - ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കാൻ പാടില്ലാത്ത രീതി: പണം കൈമാറ്റം ചെയ്യപ്പെടുന്നില്ല, നിങ്ങൾ ഒരു ബട്ടണിൽ ക്ലിക്കുചെയ്യുമ്പോൾ അടുത്ത പേജിലേക്ക് പരിവർത്തനം ഉണ്ടാകില്ല, അല്ലെങ്കിൽ ഉൽപ്പന്നം ലോഡ് ചെയ്യുന്നില്ല. സുരക്ഷാ വൈകല്യങ്ങൾ - ഇവ ഒരേ വൈകല്യങ്ങളാണ്, പക്ഷേ ആപ്ലിക്കേഷൻ പ്രവർത്തനത്തിന്റെ കാര്യത്തിലല്ല, സുരക്ഷയിലാണ്.

എല്ലാ സോഫ്റ്റ്‌വെയർ ഗുണനിലവാര പ്രശ്നങ്ങളും സുരക്ഷാ പ്രശ്നങ്ങളല്ല. എന്നാൽ എല്ലാ സുരക്ഷാ പ്രശ്നങ്ങളും സോഫ്റ്റ്വെയർ ഗുണനിലവാരവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. ഷെരീഫ് മൻസൂർ, എക്സ്പീഡിയ.

എല്ലാ കേടുപാടുകളും ഒരേ വൈകല്യങ്ങൾ ആയതിനാൽ, എല്ലാ വികസന വൈകല്യങ്ങളും സ്ഥിതി ചെയ്യുന്ന അതേ സ്ഥലത്ത് അവ സ്ഥിതിചെയ്യണം. അതിനാൽ ആരും വായിക്കാത്ത റിപ്പോർട്ടുകളും ഭയപ്പെടുത്തുന്ന PDF-കളും മറക്കുക.

ഞാൻ ഒരു ഡെവലപ്‌മെന്റ് കമ്പനിയിൽ ജോലി ചെയ്യുമ്പോൾ, സ്റ്റാറ്റിക് അനാലിസിസ് ടൂളുകളിൽ നിന്ന് എനിക്ക് ഒരു റിപ്പോർട്ട് ലഭിച്ചു. ഞാൻ അത് തുറന്നു, പരിഭ്രാന്തരായി, കാപ്പി ഉണ്ടാക്കി, 350 പേജുകൾ ലീഫ് ചെയ്തു, അത് അടച്ച് ജോലി തുടർന്നു. വലിയ റിപ്പോർട്ടുകൾ മരണ റിപ്പോർട്ടുകളാണ്. സാധാരണയായി അവർ എവിടെയും പോകില്ല, അക്ഷരങ്ങൾ ഇല്ലാതാക്കപ്പെടും, മറന്നുപോയി, നഷ്ടപ്പെടും, അല്ലെങ്കിൽ ബിസിനസ്സ് പറയുന്നത് അപകടസാധ്യതകൾ സ്വീകരിക്കുന്നു.

എന്തുചെയ്യും? ഞങ്ങൾ കണ്ടെത്തിയ സ്ഥിരീകരിച്ച വൈകല്യങ്ങളെ വികസനത്തിന് സൗകര്യപ്രദമായ ഒരു ഫോമിലേക്ക് പരിവർത്തനം ചെയ്യുന്നു, ഉദാഹരണത്തിന്, ഞങ്ങൾ അവയെ ജിറയിൽ ഒരു ബാക്ക്‌ലോഗിൽ ഇടുന്നു. പ്രവർത്തന വൈകല്യങ്ങളും പരിശോധനാ വൈകല്യങ്ങളും സഹിതം ഞങ്ങൾ വൈകല്യങ്ങൾക്ക് മുൻഗണന നൽകുകയും മുൻഗണനാ ക്രമത്തിൽ അവ ഇല്ലാതാക്കുകയും ചെയ്യുന്നു.

സ്റ്റാറ്റിക് അനാലിസിസ് - SAST

ഇത് കേടുപാടുകൾക്കുള്ള ഒരു കോഡ് വിശകലനമാണ്., എന്നാൽ ഇത് SonarQube പോലെയല്ല. പാറ്റേണുകളോ ശൈലികളോ ഞങ്ങൾ പരിശോധിക്കുന്നില്ല. വിശകലനത്തിൽ നിരവധി സമീപനങ്ങൾ ഉപയോഗിക്കുന്നു: ദുർബലത ട്രീ അനുസരിച്ച്, അനുസരിച്ച് ഡാറ്റഫ്ലോ, കോൺഫിഗറേഷൻ ഫയലുകൾ വിശകലനം ചെയ്തുകൊണ്ട്. കോഡിനെ സംബന്ധിച്ചിടത്തോളം ഇതാണ്.

സമീപനത്തിന്റെ പ്രോസ്: വികസനത്തിന്റെ പ്രാരംഭ ഘട്ടത്തിൽ കോഡിലെ കേടുപാടുകൾ തിരിച്ചറിയുന്നുഇതുവരെ സ്റ്റാൻഡുകളോ റെഡിമെയ്ഡ് ഉപകരണങ്ങളോ ഇല്ലാത്തപ്പോൾ, കൂടാതെ വർദ്ധിച്ചുവരുന്ന സ്കാനിംഗ് ശേഷി: മാറിയ കോഡിന്റെ ഒരു വിഭാഗം സ്കാൻ ചെയ്യുന്നു, സ്കാനിംഗ് സമയം കുറയ്ക്കുന്ന ഞങ്ങൾ നിലവിൽ ചെയ്യുന്ന ഫീച്ചർ മാത്രം.

Минусы - ഇത് ആവശ്യമായ ഭാഷകൾക്കുള്ള പിന്തുണയുടെ അഭാവമാണ്.

ആവശ്യമായ സംയോജനങ്ങൾ, എന്റെ ആത്മനിഷ്ഠമായ അഭിപ്രായത്തിൽ, ഉപകരണങ്ങളിൽ ഉണ്ടായിരിക്കണം:

• ഇന്റഗ്രേഷൻ ടൂൾ: ജെങ്കിൻസ്, ടീംസിറ്റി, ഗിറ്റ്ലാബ് സിഐ.
• വികസന പരിസ്ഥിതി: ഇന്റലിജ് ഐഡിയ, വിഷ്വൽ സ്റ്റുഡിയോ. ഒരു ഡവലപ്പർക്ക് ഇപ്പോഴും ഓർമ്മിക്കേണ്ട, മനസ്സിലാക്കാൻ കഴിയാത്ത ഒരു ഇന്റർഫേസ് നാവിഗേറ്റ് ചെയ്യാതെ, ജോലിസ്ഥലത്ത് തന്റെ സ്വന്തം വികസന പരിതസ്ഥിതിയിൽ കണ്ടെത്തിയ ആവശ്യമായ എല്ലാ സംയോജനങ്ങളും കേടുപാടുകളും കാണുന്നത് കൂടുതൽ സൗകര്യപ്രദമാണ്.
• കോഡ് അവലോകനം: SonarQube, മാനുവൽ അവലോകനം.
• ഡിഫെക്റ്റ് ട്രാക്കറുകൾ: ജിറയും ബഗ്‌സില്ലയും.

സ്റ്റാറ്റിക് വിശകലനത്തിന്റെ ചില മികച്ച പ്രതിനിധികളെ ചിത്രം കാണിക്കുന്നു.

ടൂളുകളല്ല, പ്രക്രിയയാണ് പ്രധാനം, അതിനാൽ ഓപ്പൺ സോഴ്‌സ് സൊല്യൂഷനുകൾ ഉണ്ട്, അവ പ്രോസസ്സ് പരിശോധിക്കുന്നതിനും നല്ലതാണ്.

SAST ഓപ്പൺ സോഴ്‌സിന് ധാരാളം കേടുപാടുകളോ സങ്കീർണ്ണമായ ഡാറ്റാഫ്ലോകളോ കണ്ടെത്താൻ കഴിയില്ല, പക്ഷേ ഒരു പ്രോസസ്സ് നിർമ്മിക്കുമ്പോൾ അവ ഉപയോഗിക്കാനും ഉപയോഗിക്കാനും കഴിയും. പ്രക്രിയ എങ്ങനെ നിർമ്മിക്കപ്പെടും, ബഗുകളോട് ആരാണ് പ്രതികരിക്കുക, ആരാണ് റിപ്പോർട്ട് ചെയ്യുക, ആരാണ് റിപ്പോർട്ട് ചെയ്യുക എന്നിവ മനസ്സിലാക്കാൻ അവ സഹായിക്കുന്നു. നിങ്ങളുടെ കോഡിന്റെ സുരക്ഷ നിർമ്മിക്കുന്നതിനുള്ള പ്രാരംഭ ഘട്ടം നടപ്പിലാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഓപ്പൺ സോഴ്‌സ് സൊല്യൂഷനുകൾ ഉപയോഗിക്കുക.

നിങ്ങളുടെ യാത്രയുടെ തുടക്കത്തിൽ നിങ്ങൾക്ക് ഒന്നുമില്ലെങ്കിൽ ഇത് എങ്ങനെ സംയോജിപ്പിക്കാനാകും: CI ഇല്ല, ജെങ്കിൻസ് ഇല്ല, TeamCity ഇല്ല? പ്രക്രിയയിലേക്കുള്ള സംയോജനം നമുക്ക് പരിഗണിക്കാം.

CVS ലെവൽ ഇന്റഗ്രേഷൻ

നിങ്ങൾക്ക് Bitbucket അല്ലെങ്കിൽ GitLab ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് തലത്തിൽ സംയോജിപ്പിക്കാൻ കഴിയും കൺകറന്റ് വേർഷൻ സിസ്റ്റം.

ഇവന്റ് പ്രകാരം - അഭ്യർത്ഥന വലിക്കുക, പ്രതിബദ്ധത. നിങ്ങൾ കോഡ് സ്കാൻ ചെയ്യുക, സുരക്ഷാ പരിശോധന വിജയിച്ചോ പരാജയപ്പെട്ടോ എന്ന് ബിൽഡ് സ്റ്റാറ്റസ് കാണിക്കുന്നു.

ഫീഡ്ബാക്ക്. തീർച്ചയായും, ഫീഡ്ബാക്ക് എല്ലായ്പ്പോഴും ആവശ്യമാണ്. നിങ്ങൾ സൈഡ് സെക്യൂരിറ്റി ചെയ്താൽ, അത് ഒരു ബോക്സിൽ ഇടുകയും അതിനെക്കുറിച്ച് ആരോടും ഒന്നും പറയാതിരിക്കുകയും ചെയ്താൽ, മാസാവസാനം ഒരു കൂട്ടം ബഗുകൾ വലിച്ചെറിഞ്ഞു - ഇത് ശരിയല്ല, നല്ലതല്ല.

കോഡ് അവലോകന സംവിധാനവുമായുള്ള സംയോജനം

ഒരിക്കൽ, നിരവധി പ്രധാനപ്പെട്ട പ്രോജക്റ്റുകളിൽ ഞങ്ങൾ ഒരു സാങ്കേതിക AppSec ഉപയോക്താവിന്റെ ഡിഫോൾട്ട് അവലോകകനായി പ്രവർത്തിച്ചു. പുതിയ കോഡിൽ പിശകുകൾ തിരിച്ചറിഞ്ഞിട്ടുണ്ടോ അതോ പിശകുകൾ ഇല്ലയോ എന്നതിനെ ആശ്രയിച്ച്, റിവ്യൂവർ പുൾ അഭ്യർത്ഥനയിൽ "അംഗീകരിക്കുക" അല്ലെങ്കിൽ "ജോലി ആവശ്യമാണ്" എന്ന നില സജ്ജമാക്കുന്നു - ഒന്നുകിൽ എല്ലാം ശരിയാണ്, അല്ലെങ്കിൽ കൃത്യമായി മെച്ചപ്പെടുത്തേണ്ടവയുടെ ലിങ്കുകൾ മെച്ചപ്പെടുത്തേണ്ടതുണ്ട്. നിർമ്മാണത്തിലേക്ക് പോകുന്ന പതിപ്പുമായി സംയോജിപ്പിക്കുന്നതിന്, വിവര സുരക്ഷാ പരിശോധന വിജയിച്ചില്ലെങ്കിൽ ഞങ്ങൾ ലയന നിരോധനം പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ട്. ഞങ്ങൾ ഇത് മാനുവൽ കോഡ് അവലോകനത്തിൽ ഉൾപ്പെടുത്തി, ഈ പ്രക്രിയയിൽ പങ്കെടുത്ത മറ്റ് പങ്കാളികൾ ഈ പ്രത്യേക പ്രക്രിയയുടെ സുരക്ഷാ സ്റ്റാറ്റസുകൾ കണ്ടു.

സോനാർ ക്യൂബുമായുള്ള സംയോജനം

പലർക്കും ഉണ്ട് ഗുണനിലവാരമുള്ള ഗേറ്റ് കോഡ് ഗുണനിലവാരത്തിന്റെ കാര്യത്തിൽ. ഇവിടെയും സമാനമാണ് - നിങ്ങൾക്ക് SAST ഉപകരണങ്ങൾക്കായി മാത്രം ഒരേ ഗേറ്റുകൾ നിർമ്മിക്കാൻ കഴിയും. ഒരേ ഇന്റർഫേസ്, ഒരേ ഗുണനിലവാരമുള്ള ഗേറ്റ്, അത് മാത്രമേ വിളിക്കൂ സുരക്ഷാ ഗേറ്റ്. കൂടാതെ, SonarQube ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഒരു പ്രോസസ്സ് ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് അവിടെ എല്ലാം എളുപ്പത്തിൽ സമന്വയിപ്പിക്കാനാകും.

സിഐ തലത്തിൽ ഏകീകരണം

ഇവിടെയും എല്ലാം വളരെ ലളിതമാണ്:

• ഓട്ടോടെസ്റ്റുകൾക്ക് തുല്യമായി, യൂണിറ്റ് ടെസ്റ്റുകൾ.
• വികസന ഘട്ടങ്ങൾ അനുസരിച്ച് വിഭജനം: dev, test, prod. വ്യത്യസ്‌ത സെറ്റ് നിയമങ്ങളോ വിവിധ പരാജയ വ്യവസ്ഥകളോ ഉൾപ്പെടുത്തിയേക്കാം: അസംബ്ലി നിർത്തുക, അസംബ്ലി നിർത്തരുത്.
• സിൻക്രണസ്/അസിൻക്രണസ് ലോഞ്ച്. സുരക്ഷാ പരിശോധനകൾ അവസാനിക്കുമോ ഇല്ലയോ എന്ന് ഞങ്ങൾ കാത്തിരിക്കുകയാണ്. അതായത്, ഞങ്ങൾ അവയെ സമാരംഭിച്ച് മുന്നോട്ട് പോകുക, തുടർന്ന് എല്ലാം നല്ലതോ ചീത്തയോ എന്ന പദവി നമുക്ക് ലഭിക്കും.

എല്ലാം തികഞ്ഞ പിങ്ക് ലോകത്താണ്. യഥാർത്ഥ ജീവിതത്തിൽ അങ്ങനെയൊന്നുമില്ല, പക്ഷേ ഞങ്ങൾ പരിശ്രമിക്കുന്നു. സുരക്ഷാ പരിശോധനകൾ നടത്തുന്നതിന്റെ ഫലം യൂണിറ്റ് ടെസ്റ്റുകളുടെ ഫലത്തിന് സമാനമായിരിക്കണം.

ഉദാഹരണത്തിന്, ഞങ്ങൾ ഒരു വലിയ പ്രോജക്റ്റ് എടുത്തു, ഇപ്പോൾ ഞങ്ങൾ അത് SAST ഉപയോഗിച്ച് സ്കാൻ ചെയ്യുമെന്ന് തീരുമാനിച്ചു - ശരി. ഞങ്ങൾ ഈ പ്രോജക്റ്റിനെ SAST-ലേക്ക് തള്ളിവിട്ടു, അത് ഞങ്ങൾക്ക് 20 അപകടസാധ്യതകൾ നൽകി, ശക്തമായ ഇച്ഛാശക്തിയുള്ള തീരുമാനത്തിലൂടെ എല്ലാം ശരിയാണെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു. 000 കേടുപാടുകൾ ഞങ്ങളുടെ സാങ്കേതിക കടമാണ്. ഞങ്ങൾ കടം ഒരു ബോക്സിൽ ഇടും, ഞങ്ങൾ അത് സാവധാനം മായ്‌ക്കുകയും വൈകല്യമുള്ള ട്രാക്കറുകളിലേക്ക് ബഗുകൾ ചേർക്കുകയും ചെയ്യും. നമുക്ക് ഒരു കമ്പനിയെ വാടകയ്‌ക്കെടുക്കാം, എല്ലാം സ്വയം ചെയ്യാം, അല്ലെങ്കിൽ സുരക്ഷാ ചാമ്പ്യന്മാർ ഞങ്ങളെ സഹായിക്കട്ടെ - സാങ്കേതിക കടം കുറയും.

പുതിയ കോഡിലെ പുതുതായി ഉയർന്നുവരുന്ന എല്ലാ കേടുപാടുകളും ഒരു യൂണിറ്റിലെയോ ഓട്ടോടെസ്റ്റുകളിലെയോ പിശകുകൾ പോലെ തന്നെ ഇല്ലാതാക്കണം. ആപേക്ഷികമായി പറഞ്ഞാൽ, അസംബ്ലി ആരംഭിച്ചു, ഞങ്ങൾ അത് നടത്തി, രണ്ട് ടെസ്റ്റുകളും രണ്ട് സുരക്ഷാ പരിശോധനകളും പരാജയപ്പെട്ടു. ശരി - ഞങ്ങൾ പോയി, എന്താണ് സംഭവിച്ചതെന്ന് നോക്കി, ഒന്ന് ശരിയാക്കി, മറ്റൊന്ന് ശരിയാക്കി, അടുത്ത തവണ പ്രവർത്തിപ്പിച്ചു - എല്ലാം ശരിയാണ്, പുതിയ കേടുപാടുകൾ ഒന്നും പ്രത്യക്ഷപ്പെട്ടില്ല, പരിശോധനകളൊന്നും പരാജയപ്പെട്ടില്ല. ഈ ടാസ്‌ക് കൂടുതൽ ആഴത്തിലുള്ളതാണെങ്കിൽ നിങ്ങൾ അത് നന്നായി മനസ്സിലാക്കേണ്ടതുണ്ട്, അല്ലെങ്കിൽ കേടുപാടുകൾ പരിഹരിക്കുന്നത് ഹൂഡിന് കീഴിലുള്ള വലിയ പാളികളെ ബാധിക്കുകയാണെങ്കിൽ: വൈകല്യമുള്ള ട്രാക്കറിലേക്ക് ഒരു ബഗ് ചേർത്തു, അത് മുൻഗണന നൽകുകയും ശരിയാക്കുകയും ചെയ്യുന്നു. നിർഭാഗ്യവശാൽ, ലോകം പൂർണമല്ല, പരീക്ഷണങ്ങൾ ചിലപ്പോൾ പരാജയപ്പെടുന്നു.

കോഡിലെ കേടുപാടുകളുടെ സാന്നിധ്യവും എണ്ണവും കണക്കിലെടുത്ത് ഗുണനിലവാരമുള്ള ഗേറ്റിന്റെ അനലോഗ് ആണ് സുരക്ഷാ ഗേറ്റിന്റെ ഉദാഹരണം.

ഞങ്ങൾ SonarQube-മായി സംയോജിപ്പിക്കുന്നു - പ്ലഗിൻ ഇൻസ്റ്റാൾ ചെയ്തു, എല്ലാം വളരെ സൗകര്യപ്രദവും രസകരവുമാണ്.

വികസന പരിസ്ഥിതിയുമായി സംയോജനം

സംയോജന ഓപ്ഷനുകൾ:

• കമ്മിറ്റിന് മുമ്പ് വികസന പരിതസ്ഥിതിയിൽ നിന്ന് ഒരു സ്കാൻ പ്രവർത്തിപ്പിക്കുക.
• ഫലങ്ങൾ കാണുക.
• ഫലങ്ങളുടെ വിശകലനം.
• സെർവറുമായുള്ള സമന്വയം.

സെർവറിൽ നിന്ന് ഫലങ്ങൾ സ്വീകരിക്കുന്നത് ഇങ്ങനെയാണ്.

നമ്മുടെ വികസന അന്തരീക്ഷത്തിൽ ഇന്റലിജ് IDEA സ്കാൻ ചെയ്യുമ്പോൾ അത്തരം കേടുപാടുകൾ കണ്ടെത്തിയതായി നിങ്ങളെ അറിയിക്കുന്ന ഒരു അധിക ഇനം ദൃശ്യമാകുന്നു. നിങ്ങൾക്ക് ഉടനടി കോഡ് എഡിറ്റുചെയ്യാനും ശുപാർശകൾ നോക്കാനും കഴിയും ഫ്ലോ ഗ്രാഫ്. ഇതെല്ലാം ഡവലപ്പറുടെ ജോലിസ്ഥലത്താണ് സ്ഥിതിചെയ്യുന്നത്, ഇത് വളരെ സൗകര്യപ്രദമാണ് - മറ്റ് ലിങ്കുകൾ പിന്തുടരുകയും അധികമായി എന്തെങ്കിലും നോക്കുകയും ചെയ്യേണ്ടതില്ല.

ഓപ്പൺ സോഴ്സ്

ഇത് എന്റെ പ്രിയപ്പെട്ട വിഷയമാണ്. എല്ലാവരും ഓപ്പൺ സോഴ്സ് ലൈബ്രറികൾ ഉപയോഗിക്കുന്നു - എല്ലാം ഇതിനകം നടപ്പിലാക്കിയ ഒരു റെഡിമെയ്ഡ് ലൈബ്രറി എടുക്കാൻ കഴിയുമ്പോൾ ഒരു കൂട്ടം ക്രച്ചുകളും സൈക്കിളുകളും എഴുതുന്നത് എന്തുകൊണ്ട്?

തീർച്ചയായും, ഇത് ശരിയാണ്, പക്ഷേ ലൈബ്രറികളും ആളുകൾ എഴുതിയതാണ്, അവയിൽ ചില അപകടസാധ്യതകളും ഉൾപ്പെടുന്നു, കൂടാതെ ആനുകാലികമായി അല്ലെങ്കിൽ നിരന്തരം റിപ്പോർട്ട് ചെയ്യപ്പെടുന്ന കേടുപാടുകളും ഉണ്ട്. അതിനാൽ, ആപ്ലിക്കേഷൻ സെക്യൂരിറ്റിയിൽ അടുത്ത ഘട്ടമുണ്ട് - ഇതാണ് ഓപ്പൺ സോഴ്സ് ഘടകങ്ങളുടെ വിശകലനം.

ഓപ്പൺ സോഴ്സ് അനാലിസിസ് - ഒഎസ്എ

ഉപകരണം മൂന്ന് വലിയ ഘട്ടങ്ങൾ ഉൾക്കൊള്ളുന്നു.

ലൈബ്രറികളിലെ കേടുപാടുകൾക്കായി തിരയുന്നു. ഉദാഹരണത്തിന്, ഞങ്ങൾ ചില ലൈബ്രറികൾ ഉപയോഗിക്കുന്നുണ്ടെന്ന് ടൂളിന് അറിയാം സിവിഇ അല്ലെങ്കിൽ ലൈബ്രറിയുടെ ഈ പതിപ്പുമായി ബന്ധപ്പെട്ട ബഗ് ട്രാക്കറുകളിൽ ചില കേടുപാടുകൾ ഉണ്ട്. നിങ്ങൾ ഇത് ഉപയോഗിക്കാൻ ശ്രമിക്കുമ്പോൾ, ലൈബ്രറി അപകടസാധ്യതയുള്ളതാണെന്ന് ഉപകരണം മുന്നറിയിപ്പ് നൽകും കൂടാതെ കേടുപാടുകൾ ഇല്ലാത്ത മറ്റൊരു പതിപ്പ് ഉപയോഗിക്കാൻ നിങ്ങളെ ഉപദേശിക്കുകയും ചെയ്യും.

ലൈസൻസ് പരിശുദ്ധിയുടെ വിശകലനം. ഇത് ഇതുവരെ ഇവിടെ പ്രത്യേകിച്ച് ജനപ്രിയമല്ല, എന്നാൽ നിങ്ങൾ വിദേശത്ത് ജോലി ചെയ്യുകയാണെങ്കിൽ, ഉപയോഗിക്കാനോ പരിഷ്‌ക്കരിക്കാനോ കഴിയാത്ത ഒരു ഓപ്പൺ സോഴ്‌സ് ഘടകം ഉപയോഗിക്കുന്നതിന് കാലാകാലങ്ങളിൽ നിങ്ങൾക്ക് അവിടെ നികുതി ലഭിക്കും. ലൈസൻസുള്ള ലൈബ്രറിയുടെ നയമനുസരിച്ച്, ഞങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയില്ല. അല്ലെങ്കിൽ, ഞങ്ങൾ അത് പരിഷ്കരിച്ച് അത് ഉപയോഗിക്കുകയാണെങ്കിൽ, ഞങ്ങൾ ഞങ്ങളുടെ കോഡ് പോസ്റ്റ് ചെയ്യണം. തീർച്ചയായും, ആരും അവരുടെ ഉൽപ്പന്നങ്ങളുടെ കോഡ് പ്രസിദ്ധീകരിക്കാൻ ആഗ്രഹിക്കുന്നില്ല, എന്നാൽ നിങ്ങൾക്ക് ഇതിൽ നിന്ന് സ്വയം പരിരക്ഷിക്കാനും കഴിയും.

ഒരു വ്യാവസായിക അന്തരീക്ഷത്തിൽ ഉപയോഗിക്കുന്ന ഘടകങ്ങളുടെ വിശകലനം. ഞങ്ങൾ അവസാനം വികസനം പൂർത്തിയാക്കി ഞങ്ങളുടെ മൈക്രോ സർവീസിന്റെ ഏറ്റവും പുതിയ റിലീസ് പുറത്തിറക്കിയ ഒരു സാങ്കൽപ്പിക സാഹചര്യം സങ്കൽപ്പിക്കുക. അവൻ അവിടെ അത്ഭുതകരമായി ജീവിക്കുന്നു - ഒരാഴ്ച, ഒരു മാസം, ഒരു വർഷം. ഞങ്ങൾ അത് ശേഖരിക്കുന്നില്ല, സുരക്ഷാ പരിശോധനകൾ നടത്തുന്നില്ല, എല്ലാം ശരിയാണെന്ന് തോന്നുന്നു. എന്നാൽ പെട്ടെന്ന്, റിലീസ് ചെയ്ത് രണ്ടാഴ്ച കഴിഞ്ഞ്, വ്യാവസായിക പരിതസ്ഥിതിയിൽ ഈ പ്രത്യേക ബിൽഡിൽ ഞങ്ങൾ ഉപയോഗിക്കുന്ന ഓപ്പൺ സോഴ്സ് ഘടകത്തിൽ ഒരു ഗുരുതരമായ കേടുപാടുകൾ പ്രത്യക്ഷപ്പെടുന്നു. ഞങ്ങൾ എന്ത്, എവിടെയാണ് ഉപയോഗിക്കുന്നതെന്ന് രേഖപ്പെടുത്തുന്നില്ലെങ്കിൽ, ഈ അപകടസാധ്യത ഞങ്ങൾ കാണില്ല. നിലവിൽ വ്യവസായത്തിൽ ഉപയോഗിക്കുന്ന ലൈബ്രറികളിലെ കേടുപാടുകൾ നിരീക്ഷിക്കാൻ ചില ഉപകരണങ്ങൾക്ക് കഴിവുണ്ട്. ഇത് വളരെ ഉപയോഗപ്രദമാണ്.

അവസരങ്ങൾ:

• വികസനത്തിന്റെ വിവിധ ഘട്ടങ്ങൾക്ക് വ്യത്യസ്ത നയങ്ങൾ.
• ഒരു വ്യാവസായിക അന്തരീക്ഷത്തിൽ ഘടകങ്ങൾ നിരീക്ഷിക്കുന്നു.
• സ്ഥാപനത്തിനുള്ളിലെ ലൈബ്രറികളുടെ നിയന്ത്രണം.
• വിവിധ ബിൽഡ് സിസ്റ്റങ്ങൾക്കും ഭാഷകൾക്കുമുള്ള പിന്തുണ.
• ഡോക്കർ ചിത്രങ്ങളുടെ വിശകലനം.

ഓപ്പൺ സോഴ്സ് വിശകലനത്തിൽ ഏർപ്പെട്ടിരിക്കുന്ന വ്യവസായ പ്രമുഖരുടെ ഏതാനും ഉദാഹരണങ്ങൾ.

ഇത് മാത്രമാണ് സൗജന്യം ആശ്രിതത്വം-പരിശോധന OWASP ൽ നിന്ന്. ആദ്യ ഘട്ടങ്ങളിൽ നിങ്ങൾക്ക് ഇത് ഓണാക്കാം, ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു, എന്താണ് പിന്തുണയ്ക്കുന്നതെന്ന് കാണുക. അടിസ്ഥാനപരമായി, ഇവയെല്ലാം ക്ലൗഡ് ഉൽപ്പന്നങ്ങളാണ്, അല്ലെങ്കിൽ ഓൺ-പ്രെമൈസ് ആണ്, എന്നാൽ അവയുടെ അടിത്തറയ്ക്ക് പിന്നിൽ അവ ഇപ്പോഴും ഇന്റർനെറ്റിലേക്ക് അയയ്ക്കപ്പെടുന്നു. അവർ നിങ്ങളുടെ ലൈബ്രറികളല്ല, മറിച്ച് ഹാഷുകൾ അല്ലെങ്കിൽ അവരുടെ സ്വന്തം മൂല്യങ്ങൾ, അവർ കണക്കുകൂട്ടുന്ന, കൂടാതെ കേടുപാടുകളുടെ സാന്നിധ്യത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ ലഭിക്കുന്നതിന് അവരുടെ സെർവറിലേക്ക് വിരലടയാളങ്ങൾ അയയ്ക്കുന്നു.

പ്രക്രിയ സംയോജനം

ലൈബ്രറികളുടെ ചുറ്റളവ് നിയന്ത്രണം, ബാഹ്യ ഉറവിടങ്ങളിൽ നിന്ന് ഡൗൺലോഡ് ചെയ്തവ. ഞങ്ങൾക്ക് ബാഹ്യവും ആന്തരികവുമായ ശേഖരങ്ങളുണ്ട്. ഉദാഹരണത്തിന്, ഇവന്റ് സെൻട്രൽ Nexus പ്രവർത്തിപ്പിക്കുന്നു, കൂടാതെ "നിർണ്ണായക" അല്ലെങ്കിൽ "ഉയർന്ന" പദവിയുള്ള ഞങ്ങളുടെ ശേഖരത്തിൽ കേടുപാടുകൾ ഇല്ലെന്ന് ഉറപ്പാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. Nexus Firewall Lifecycle ടൂൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് പ്രോക്സിയിംഗ് കോൺഫിഗർ ചെയ്യാൻ കഴിയും, അതുവഴി അത്തരം കേടുപാടുകൾ ഇല്ലാതാക്കുകയും ആന്തരിക ശേഖരത്തിൽ അവസാനിക്കാതിരിക്കുകയും ചെയ്യും.

സിഐയിലേക്കുള്ള സംയോജനം. ഓട്ടോടെസ്റ്റുകൾ, യൂണിറ്റ് ടെസ്റ്റുകൾ, വികസന ഘട്ടങ്ങളായി വിഭജനം എന്നിവയ്ക്കൊപ്പം ഒരേ തലത്തിൽ: dev, test, prod. ഓരോ ഘട്ടത്തിലും, നിങ്ങൾക്ക് ഏത് ലൈബ്രറിയും ഡൌൺലോഡ് ചെയ്യാം, എന്തും ഉപയോഗിക്കാം, എന്നാൽ "നിർണ്ണായക" പദവിയിൽ ബുദ്ധിമുട്ടുള്ള എന്തെങ്കിലും ഉണ്ടെങ്കിൽ, നിർമ്മാണത്തിലേക്ക് റിലീസ് ചെയ്യുന്ന ഘട്ടത്തിൽ ഡവലപ്പർമാരുടെ ശ്രദ്ധ ഇതിലേക്ക് ആകർഷിക്കുന്നത് മൂല്യവത്താണ്.

പുരാവസ്തുക്കളുമായുള്ള സംയോജനം: Nexus ആൻഡ് JFrog.

വികസന പരിതസ്ഥിതിയിലേക്കുള്ള സംയോജനം. നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന ഉപകരണങ്ങൾക്ക് വികസന പരിതസ്ഥിതികളുമായി സംയോജനം ഉണ്ടായിരിക്കണം. ഡെവലപ്പർക്ക് തന്റെ ജോലിസ്ഥലത്ത് നിന്നുള്ള സ്കാനിംഗ് ഫലങ്ങളിലേക്ക് ആക്സസ് ഉണ്ടായിരിക്കണം, അല്ലെങ്കിൽ CVS-ൽ ഏർപ്പെടുന്നതിന് മുമ്പ് കേടുപാടുകൾക്കായി കോഡ് സ്വയം സ്കാൻ ചെയ്യാനും പരിശോധിക്കാനുമുള്ള കഴിവ് ഉണ്ടായിരിക്കണം.

സിഡി സംയോജനം. ഇത് ഞാൻ ശരിക്കും ഇഷ്ടപ്പെടുന്നതും ഞാൻ ഇതിനകം സംസാരിച്ചതുമായ ഒരു രസകരമായ സവിശേഷതയാണ് - ഒരു വ്യാവസായിക അന്തരീക്ഷത്തിൽ പുതിയ കേടുപാടുകൾ ഉണ്ടാകുന്നത് നിരീക്ഷിക്കൽ. ഇത് ഇതുപോലെ പ്രവർത്തിക്കുന്നു.

നമുക്ക് ഉണ്ട് പൊതു ഘടക ശേഖരങ്ങൾ — പുറത്ത് ചില ഉപകരണങ്ങൾ, ഞങ്ങളുടെ ആന്തരിക ശേഖരം. അതിൽ വിശ്വസനീയമായ ഘടകങ്ങൾ മാത്രം അടങ്ങിയിരിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഒരു അഭ്യർത്ഥന പ്രോക്സി ചെയ്യുമ്പോൾ, ഡൗൺലോഡ് ചെയ്ത ലൈബ്രറിക്ക് കേടുപാടുകൾ ഇല്ലെന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു. ഞങ്ങൾ സജ്ജീകരിക്കുകയും വികസനവുമായി ഏകോപിപ്പിക്കുകയും ചെയ്യുന്ന ചില നയങ്ങൾക്ക് കീഴിലാണെങ്കിൽ, ഞങ്ങൾ അത് അപ്‌ലോഡ് ചെയ്യില്ല, മറ്റൊരു പതിപ്പ് ഉപയോഗിക്കാൻ ആവശ്യപ്പെടും. അതനുസരിച്ച്, ലൈബ്രറിയിൽ ശരിക്കും നിർണായകവും മോശവുമായ എന്തെങ്കിലും ഉണ്ടെങ്കിൽ, ഇൻസ്റ്റാളേഷൻ ഘട്ടത്തിൽ ഡവലപ്പർക്ക് ലൈബ്രറി ലഭിക്കില്ല - ഉയർന്നതോ താഴ്ന്നതോ ആയ ഒരു പതിപ്പ് ഉപയോഗിക്കട്ടെ.

• നിർമ്മിക്കുമ്പോൾ, ആരും മോശമായി ഒന്നും തെറിപ്പിച്ചിട്ടില്ലെന്നും എല്ലാ ഘടകങ്ങളും സുരക്ഷിതമാണെന്നും ആരും ഫ്ലാഷ് ഡ്രൈവിൽ അപകടകരമായ ഒന്നും കൊണ്ടുവന്നിട്ടില്ലെന്നും ഞങ്ങൾ പരിശോധിക്കുന്നു.
• റിപ്പോസിറ്ററിയിൽ ഞങ്ങൾക്ക് വിശ്വസനീയമായ ഘടകങ്ങൾ മാത്രമേ ഉള്ളൂ.
• വിന്യസിക്കുമ്പോൾ, ഞങ്ങൾ പാക്കേജ് തന്നെ വീണ്ടും പരിശോധിക്കുന്നു: യുദ്ധം, ജാർ, ഡിഎൽ അല്ലെങ്കിൽ ഡോക്കർ ചിത്രം നയം പാലിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ.
• വ്യവസായത്തിൽ പ്രവേശിക്കുമ്പോൾ, വ്യാവസായിക പരിതസ്ഥിതിയിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് ഞങ്ങൾ നിരീക്ഷിക്കുന്നു: ഗുരുതരമായ കേടുപാടുകൾ പ്രത്യക്ഷപ്പെടുന്നു അല്ലെങ്കിൽ ദൃശ്യമാകില്ല.

ഡൈനാമിക് അനാലിസിസ് - DAST

ഡൈനാമിക് വിശകലന ഉപകരണങ്ങൾ മുമ്പ് പറഞ്ഞതിൽ നിന്ന് അടിസ്ഥാനപരമായി വ്യത്യസ്തമാണ്. ആപ്ലിക്കേഷനുമൊത്തുള്ള ഉപയോക്താവിന്റെ പ്രവർത്തനത്തിന്റെ ഒരുതരം അനുകരണമാണിത്. ഇതൊരു വെബ് ആപ്ലിക്കേഷനാണെങ്കിൽ, ഞങ്ങൾ അഭ്യർത്ഥനകൾ അയയ്‌ക്കുന്നു, ക്ലയന്റിന്റെ ജോലി അനുകരിക്കുന്നു, മുൻവശത്തുള്ള ബട്ടണുകളിൽ ക്ലിക്കുചെയ്യുക, ഫോമിൽ നിന്ന് കൃത്രിമ ഡാറ്റ അയയ്ക്കുക: ഉദ്ധരണികൾ, ബ്രാക്കറ്റുകൾ, വ്യത്യസ്ത എൻകോഡിംഗുകളിലെ പ്രതീകങ്ങൾ, ആപ്ലിക്കേഷൻ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും പ്രോസസ്സ് ചെയ്യുന്നുവെന്നും കാണുന്നതിന്. ബാഹ്യ ഡാറ്റ.

ഓപ്പൺ സോഴ്‌സിലെ ടെംപ്ലേറ്റ് കേടുപാടുകൾ പരിശോധിക്കാൻ ഇതേ സിസ്റ്റം നിങ്ങളെ അനുവദിക്കുന്നു. ഞങ്ങൾ ഏത് ഓപ്പൺ സോഴ്‌സാണ് ഉപയോഗിക്കുന്നതെന്ന് DAST-ന് അറിയാത്തതിനാൽ, അത് "ക്ഷുദ്രകരമായ" പാറ്റേണുകൾ എറിയുകയും സെർവറിന്റെ പ്രതികരണങ്ങൾ വിശകലനം ചെയ്യുകയും ചെയ്യുന്നു:

- അതെ, ഇവിടെ ഒരു ഡിസീരിയലൈസേഷൻ പ്രശ്നമുണ്ട്, പക്ഷേ ഇവിടെ ഇല്ല.

ഇതിൽ വലിയ അപകടസാധ്യതകളുണ്ട്, കാരണം ടെസ്റ്റർമാർ പ്രവർത്തിക്കുന്ന അതേ ബെഞ്ചിൽ നിങ്ങൾ ഈ സുരക്ഷാ പരിശോധന നടത്തിയാൽ, അസുഖകരമായ കാര്യങ്ങൾ സംഭവിക്കാം.

• ആപ്ലിക്കേഷൻ സെർവർ നെറ്റ്‌വർക്കിൽ ഉയർന്ന ലോഡ്.
• സംയോജനങ്ങളൊന്നുമില്ല.
• വിശകലനം ചെയ്ത ആപ്ലിക്കേഷന്റെ ക്രമീകരണങ്ങൾ മാറ്റാനുള്ള കഴിവ്.
• ആവശ്യമായ സാങ്കേതിക വിദ്യകൾക്ക് പിന്തുണയില്ല.
• സജ്ജീകരിക്കാനുള്ള ബുദ്ധിമുട്ട്.

ഞങ്ങൾ ഒടുവിൽ AppScan സമാരംഭിച്ചപ്പോൾ ഞങ്ങൾക്ക് ഒരു സാഹചര്യമുണ്ടായിരുന്നു: ആപ്ലിക്കേഷനിലേക്ക് ആക്‌സസ് ലഭിക്കാൻ ഞങ്ങൾ വളരെക്കാലം ശ്രമിച്ചു, 3 അക്കൗണ്ടുകൾ ലഭിച്ചു, സന്തോഷിച്ചു - ഞങ്ങൾ ഒടുവിൽ എല്ലാം പരിശോധിക്കും! ഞങ്ങൾ ഒരു സ്കാൻ ആരംഭിച്ചു, ആപ്പ്‌സ്കാൻ ആദ്യം ചെയ്തത് അഡ്മിൻ പാനലിലേക്ക് പോയി എല്ലാ ബട്ടണുകളും തുളച്ച് ഡാറ്റയുടെ പകുതി മാറ്റുകയും സെർവറിനെ പൂർണ്ണമായും നശിപ്പിക്കുകയും ചെയ്യുക എന്നതാണ്. മെയിൽഫോം-അഭ്യർത്ഥനകൾ. പരിശോധനയ്‌ക്കൊപ്പം വികസനം പറഞ്ഞു:

- സുഹൃത്തുക്കളേ, നിങ്ങൾ എന്നെ കളിയാക്കുകയാണോ?! ഞങ്ങൾ നിങ്ങൾക്ക് അക്കൗണ്ടുകൾ നൽകി, നിങ്ങൾ ഒരു നിലപാട് സജ്ജമാക്കി!

സാധ്യമായ അപകടസാധ്യതകൾ പരിഗണിക്കുക. മികച്ച രീതിയിൽ, വിവര സുരക്ഷ പരിശോധിക്കുന്നതിനായി ഒരു പ്രത്യേക സ്റ്റാൻഡ് തയ്യാറാക്കുക, അത് പരിസ്ഥിതിയുടെ ബാക്കി ഭാഗങ്ങളിൽ നിന്ന് എങ്ങനെയെങ്കിലും ഒറ്റപ്പെടുത്തും, കൂടാതെ സോപാധികമായി അഡ്മിൻ പാനൽ പരിശോധിക്കുക, വെയിലത്ത് മാനുവൽ മോഡിൽ. ഇതൊരു പെന്റസ്റ്റ് ആണ് - ഞങ്ങൾ ഇപ്പോൾ പരിഗണിക്കാത്ത പരിശ്രമത്തിന്റെ ശേഷിക്കുന്ന ശതമാനം.

ലോഡ് ടെസ്റ്റിംഗിന്റെ അനലോഗ് ആയി നിങ്ങൾക്ക് ഇത് ഉപയോഗിക്കാൻ കഴിയുമെന്നത് പരിഗണിക്കേണ്ടതാണ്. ആദ്യ ഘട്ടത്തിൽ, നിങ്ങൾക്ക് 10-15 ത്രെഡുകളുള്ള ഒരു ഡൈനാമിക് സ്കാനർ ഓണാക്കാനും എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണാനും കഴിയും, എന്നാൽ സാധാരണയായി, പ്രാക്ടീസ് കാണിക്കുന്നതുപോലെ, ഒന്നും നല്ലതല്ല.

ഞങ്ങൾ സാധാരണയായി ഉപയോഗിക്കുന്ന കുറച്ച് വിഭവങ്ങൾ.

എടുത്തുപറയേണ്ടതാണ് ബർപ്പ് സ്യൂട്ട് ഏതൊരു സുരക്ഷാ പ്രൊഫഷണലിനും ഒരു "സ്വിസ് കത്തി" ആണ്. എല്ലാവരും ഇത് ഉപയോഗിക്കുന്നു, ഇത് വളരെ സൗകര്യപ്രദമാണ്. എന്റർപ്രൈസ് പതിപ്പിന്റെ ഒരു പുതിയ ഡെമോ പതിപ്പ് ഇപ്പോൾ പുറത്തിറങ്ങി. നേരത്തെ ഇത് പ്ലഗിനുകളുള്ള ഒരു സ്റ്റാൻഡ് എലോൺ യൂട്ടിലിറ്റി ആയിരുന്നെങ്കിൽ, ഇപ്പോൾ ഡവലപ്പർമാർ ഒടുവിൽ ഒരു വലിയ സെർവർ നിർമ്മിക്കുന്നു, അതിൽ നിന്ന് നിരവധി ഏജന്റുമാരെ നിയന്ത്രിക്കാൻ കഴിയും. ഇത് രസകരമാണ്, ഇത് പരീക്ഷിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു.

പ്രക്രിയ സംയോജനം

സംയോജനം വളരെ നല്ലതും ലളിതമായും സംഭവിക്കുന്നു: വിജയകരമായ ഇൻസ്റ്റാളേഷന് ശേഷം സ്കാനിംഗ് ആരംഭിക്കുക സ്റ്റാൻഡിനായുള്ള അപേക്ഷകളും വിജയകരമായ സംയോജന പരിശോധനയ്ക്ക് ശേഷം സ്കാൻ ചെയ്യുന്നു.

സംയോജനങ്ങൾ പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ അല്ലെങ്കിൽ സ്റ്റബുകളും മോക്ക് ഫംഗ്‌ഷനുകളും ഉണ്ടെങ്കിൽ, അത് അർത്ഥശൂന്യവും ഉപയോഗശൂന്യവുമാണ് - ഞങ്ങൾ ഏത് പാറ്റേൺ അയച്ചാലും സെർവർ അതേ രീതിയിൽ തന്നെ പ്രതികരിക്കും.

• എബൌട്ട്, ഒരു പ്രത്യേക ടെസ്റ്റിംഗ് സ്റ്റാൻഡ്.
• പരിശോധിക്കുന്നതിന് മുമ്പ്, ലോഗിൻ സീക്വൻസ് എഴുതുക.
• അഡ്മിനിസ്ട്രേഷൻ സിസ്റ്റത്തിന്റെ പരിശോധന മാനുവൽ മാത്രമാണ്.

പ്രക്രിയ

പൊതുവായി പ്രക്രിയയെക്കുറിച്ചും ഓരോ ഉപകരണത്തിന്റെയും പ്രവർത്തനത്തെക്കുറിച്ചും അൽപ്പം സാമാന്യവൽക്കരിച്ചു. എല്ലാ ആപ്ലിക്കേഷനുകളും വ്യത്യസ്തമാണ് - ഒന്ന് ഡൈനാമിക് വിശകലനം, മറ്റൊന്ന് സ്റ്റാറ്റിക് വിശകലനം, മൂന്നാമത്തേത് ഓപ്പൺസോഴ്സ് വിശകലനം, പെന്റസ്റ്റുകൾ അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും, ഉദാഹരണത്തിന്, ഇവന്റുകൾ വഫ്.

എല്ലാ പ്രക്രിയകൾക്കും നിയന്ത്രണം ആവശ്യമാണ്.

ഒരു പ്രോസസ്സ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും അത് എവിടെ മെച്ചപ്പെടുത്താമെന്നും മനസിലാക്കാൻ, പ്രൊഡക്ഷൻ മെട്രിക്‌സ്, ടൂളുകളിൽ നിന്നുള്ള മെട്രിക്‌സ്, ഡിഫെക്റ്റ് ട്രാക്കറുകൾ എന്നിവയുൾപ്പെടെ നിങ്ങൾക്ക് ലഭിക്കുന്ന എല്ലാത്തിൽ നിന്നും മെട്രിക്‌സ് ശേഖരിക്കേണ്ടതുണ്ട്.

ഏത് വിവരവും സഹായകരമാണ്. ഈ അല്ലെങ്കിൽ ആ ഉപകരണം എവിടെയാണ് മികച്ച രീതിയിൽ ഉപയോഗിക്കുന്നതെന്ന് വ്യത്യസ്ത കോണുകളിൽ നിന്ന് നോക്കേണ്ടത് ആവശ്യമാണ്, അവിടെ പ്രക്രിയ പ്രത്യേകമായി കുറയുന്നു. സമയത്തെ അടിസ്ഥാനമാക്കിയുള്ള പ്രക്രിയ എവിടെ മെച്ചപ്പെടുത്തണമെന്ന് കാണാൻ വികസന പ്രതികരണ സമയം നോക്കുന്നത് മൂല്യവത്താണ്. കൂടുതൽ ഡാറ്റ, ഓരോ പ്രക്രിയയുടെയും വിശദാംശങ്ങളിലേക്ക് ഉയർന്ന തലത്തിൽ നിന്ന് കൂടുതൽ വിഭാഗങ്ങൾ നിർമ്മിക്കാൻ കഴിയും.

എല്ലാ സ്റ്റാറ്റിക്, ഡൈനാമിക് അനലൈസറുകൾക്കും അവരുടേതായ API-കൾ ഉള്ളതിനാൽ, അവരുടേതായ ലോഞ്ച് രീതികൾ, തത്വങ്ങൾ, ചിലർക്ക് ഷെഡ്യൂളറുകൾ ഉണ്ട്, മറ്റുള്ളവർക്ക് ഇല്ല - ഞങ്ങൾ ഒരു ടൂൾ എഴുതുകയാണ്. AppSec ഓർക്കസ്ട്രേറ്റർ, ഇത് ഉൽപ്പന്നത്തിൽ നിന്ന് മുഴുവൻ പ്രക്രിയയിലേക്കും ഒരൊറ്റ എൻട്രി പോയിന്റ് സൃഷ്ടിക്കാനും ഒരു പോയിന്റിൽ നിന്ന് അത് നിയന്ത്രിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു.

മാനേജർമാർക്കും ഡെവലപ്പർമാർക്കും സെക്യൂരിറ്റി എഞ്ചിനീയർമാർക്കും ഒരു എൻട്രി പോയിന്റ് ഉണ്ട്, അതിൽ നിന്ന് അവർക്ക് എന്താണ് പ്രവർത്തിക്കുന്നതെന്ന് കാണാനും കോൺഫിഗർ ചെയ്യാനും സ്കാൻ പ്രവർത്തിപ്പിക്കാനും സ്കാൻ ഫലങ്ങൾ സ്വീകരിക്കാനും ആവശ്യകതകൾ സമർപ്പിക്കാനും കഴിയും. ഞങ്ങൾ പേപ്പർവർക്കിൽ നിന്ന് മാറി, എല്ലാം മനുഷ്യരൂപത്തിലേക്ക് വിവർത്തനം ചെയ്യാൻ ശ്രമിക്കുന്നു, അത് വികസനം ഉപയോഗിക്കുന്നു - സ്റ്റാറ്റസും മെട്രിക്സും ഉള്ള കോൺഫ്ലൂയൻസ് പേജുകൾ, ജിറയിലോ വിവിധ ഡിഫെക്റ്റ് ട്രാക്കറുകളിലോ ഉള്ള വൈകല്യങ്ങൾ, അല്ലെങ്കിൽ സിഐയിലെ ഒരു സിൻക്രണസ്/അസിൻക്രണസ് പ്രക്രിയയിലേക്കുള്ള സംയോജനം. /സിഡി.

കീ ടേക്ക്അവേസ്

ഉപകരണങ്ങൾ പ്രധാന കാര്യമല്ല. ആദ്യം പ്രക്രിയയിലൂടെ ചിന്തിക്കുക - തുടർന്ന് ഉപകരണങ്ങൾ നടപ്പിലാക്കുക. ഉപകരണങ്ങൾ നല്ലതും എന്നാൽ ചെലവേറിയതുമാണ്, അതിനാൽ നിങ്ങൾക്ക് പ്രക്രിയയിൽ നിന്ന് ആരംഭിച്ച് വികസനവും സുരക്ഷയും തമ്മിൽ ആശയവിനിമയവും ധാരണയും ഉണ്ടാക്കാം. സുരക്ഷാ കാഴ്ചപ്പാടിൽ, എല്ലാം "നിർത്തേണ്ട" ആവശ്യമില്ല, വികസനത്തിന്റെ കാഴ്ചപ്പാടിൽ, ഉയർന്ന മെഗാ സൂപ്പർ ക്രിട്ടിക്കൽ എന്തെങ്കിലും ഉണ്ടെങ്കിൽ, അത് ഇല്ലാതാക്കേണ്ടതുണ്ട്, പ്രശ്നത്തിന് നേരെ കണ്ണടയ്ക്കരുത്.

ഉൽപ്പന്ന നിലവാരം - പൊതു ലക്ഷ്യം സുരക്ഷയും വികസനവും. ഞങ്ങൾ ഒരു കാര്യം ചെയ്യുന്നു, എല്ലാം ശരിയായി പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു, പ്രശസ്തി അപകടസാധ്യതകളോ സാമ്പത്തിക നഷ്ടങ്ങളോ ഇല്ല. അതുകൊണ്ടാണ് ആശയവിനിമയം മെച്ചപ്പെടുത്തുന്നതിനും ഉൽപ്പന്നത്തിന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുത്തുന്നതിനുമായി ഞങ്ങൾ DevSecOps, SecDevOps സമീപനം പ്രോത്സാഹിപ്പിക്കുന്നത്.

നിങ്ങൾക്ക് ഇതിനകം ഉള്ളതിൽ നിന്ന് ആരംഭിക്കുക: ആവശ്യകതകൾ, വാസ്തുവിദ്യ, ഭാഗിക പരിശോധനകൾ, പരിശീലനങ്ങൾ, മാർഗ്ഗനിർദ്ദേശങ്ങൾ. എല്ലാ പ്രോജക്റ്റുകൾക്കും എല്ലാ സമ്പ്രദായങ്ങളും ഉടനടി പ്രയോഗിക്കേണ്ട ആവശ്യമില്ല - ആവർത്തിച്ച് നീങ്ങുക. ഒരൊറ്റ മാനദണ്ഡമില്ല - പരീക്ഷണം കൂടാതെ വ്യത്യസ്ത സമീപനങ്ങളും പരിഹാരങ്ങളും പരീക്ഷിക്കുക.

വിവര സുരക്ഷാ വൈകല്യങ്ങളും പ്രവർത്തന വൈകല്യങ്ങളും തമ്മിൽ തുല്യമായ അടയാളമുണ്ട്.

എല്ലാം ഓട്ടോമേറ്റ് ചെയ്യുകഅത് നീങ്ങുന്നു. ചലിക്കാത്തതെന്തും, അത് നീക്കി യാന്ത്രികമാക്കുക. കൈകൊണ്ട് എന്തെങ്കിലും ചെയ്താൽ, അത് പ്രക്രിയയുടെ നല്ല ഭാഗമല്ല. ഒരുപക്ഷേ ഇത് അവലോകനം ചെയ്യുകയും യാന്ത്രികമാക്കുകയും ചെയ്യുന്നത് മൂല്യവത്താണ്.

ഐഎസ് ടീമിന്റെ വലിപ്പം ചെറുതാണെങ്കിൽ - സുരക്ഷാ ചാമ്പ്യൻമാരെ ഉപയോഗിക്കുക.

ഒരുപക്ഷേ ഞാൻ സംസാരിച്ചത് നിങ്ങൾക്ക് അനുയോജ്യമാകില്ല, നിങ്ങൾ നിങ്ങളുടേതായ എന്തെങ്കിലും കൊണ്ടുവരും - അത് നല്ലതാണ്. പക്ഷേ നിങ്ങളുടെ പ്രക്രിയയുടെ ആവശ്യകതകളെ അടിസ്ഥാനമാക്കി ടൂളുകൾ തിരഞ്ഞെടുക്കുക. ഈ ഉപകരണം മോശമാണ്, ഇതാണ് നല്ലത് എന്ന് സമൂഹം പറയുന്നത് നോക്കരുത്. ഒരുപക്ഷേ നിങ്ങളുടെ ഉൽപ്പന്നത്തിന് വിപരീതമായിരിക്കാം.

ഉപകരണങ്ങൾക്കുള്ള ആവശ്യകതകൾ.

• ലോ ലെവൽ ഫാൾസ് പോസിറ്റീവ്.
• മതിയായ വിശകലന സമയം.
• ഉപകാരപ്രദമായ ഉപയോഗത്തിന്.
• സംയോജനങ്ങളുടെ ലഭ്യത.
• ഉൽപ്പന്ന വികസന റോഡ്മാപ്പ് മനസ്സിലാക്കുന്നു.
• ഉപകരണങ്ങൾ ഇഷ്ടാനുസൃതമാക്കാനുള്ള സാധ്യത.

DevOpsConf 2018-ൽ യൂറിയുടെ റിപ്പോർട്ട് ഏറ്റവും മികച്ച ഒന്നായി തിരഞ്ഞെടുത്തു. കൂടുതൽ രസകരമായ ആശയങ്ങളും പ്രായോഗിക കേസുകളും പരിചയപ്പെടാൻ, മെയ് 27, 28 തീയതികളിൽ Skolkovo-ലേക്ക് വരൂ DevOpsConf ഉള്ളിൽ ഉത്സവം RIT++. ഇതിലും നല്ലത്, നിങ്ങളുടെ അനുഭവം പങ്കിടാൻ നിങ്ങൾ തയ്യാറാണെങ്കിൽ പ്രയോഗിക്കുക ഏപ്രിൽ 21 വരെ റിപ്പോർട്ട് സമർപ്പിക്കണം.

അവലംബം: www.habr.com