ભય અને ધિક્કાર 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. પદ્ધતિઓ અલગ છે, પરંતુ સામાન્ય રીતે સમાન છે.

પરિપક્વતા મોડેલમાં સુરક્ષાનું નિર્માણ

મને તે સૌથી વધુ ગમે છે BSIMM - પરિપક્વતા મોડેલમાં સુરક્ષાનું નિર્માણ. પદ્ધતિનો આધાર એપ્લીકેશન સિક્યોરિટી પ્રક્રિયાનું 4 ડોમેન્સમાં વિભાજન છે: ગવર્નન્સ, ઇન્ટેલિજન્સ, SSDL ટચપોઇન્ટ્સ અને ડિપ્લોયમેન્ટ. દરેક ડોમેનમાં 12 પ્રેક્ટિસ હોય છે, જે 112 પ્રવૃત્તિઓ તરીકે રજૂ થાય છે.

દરેક 112 પ્રવૃત્તિઓ ધરાવે છે 3 પરિપક્વતા સ્તર: શિખાઉ માણસ, મધ્યવર્તી અને અદ્યતન. તમે વિભાગોમાં તમામ 12 પ્રેક્ટિસનો અભ્યાસ કરી શકો છો, તમારા માટે મહત્વપૂર્ણ હોય તેવી વસ્તુઓ પસંદ કરી શકો છો, તેનો અમલ કેવી રીતે કરવો તે શોધી શકો છો અને ધીમે ધીમે ઘટકો ઉમેરી શકો છો, ઉદાહરણ તરીકે, સ્ટેટિક અને ડાયનેમિક કોડ વિશ્લેષણ અથવા કોડ સમીક્ષા. તમે એક યોજના બનાવો અને પસંદ કરેલી પ્રવૃત્તિઓના અમલીકરણના ભાગરૂપે શાંતિથી તેના અનુસાર કાર્ય કરો.

શા માટે DevSecOps

DevOps એ એકંદરે મોટી પ્રક્રિયા છે જેમાં સુરક્ષાનું ધ્યાન રાખવાની જરૂર છે.

શરૂઆતમાં DevOps સામેલ સુરક્ષા તપાસ. વ્યવહારમાં, સુરક્ષા ટીમોની સંખ્યા હવે કરતાં ઘણી ઓછી હતી, અને તેઓએ પ્રક્રિયામાં સહભાગીઓ તરીકે નહીં, પરંતુ નિયંત્રણ અને દેખરેખ સંસ્થા તરીકે કામ કર્યું હતું જે તેના પર માંગ કરે છે અને પ્રકાશનના અંતે ઉત્પાદનની ગુણવત્તા તપાસે છે. આ એક ઉત્તમ અભિગમ છે જેમાં સુરક્ષા ટીમો વિકાસથી દિવાલની પાછળ હતી અને પ્રક્રિયામાં ભાગ લીધો ન હતો.

મુખ્ય સમસ્યા એ છે કે માહિતી સુરક્ષા વિકાસથી અલગ છે. સામાન્ય રીતે આ અમુક પ્રકારની IB સર્કિટ હોય છે અને તેમાં 2-3 મોટા અને મોંઘા સાધનો હોય છે. દર છ મહિનામાં એકવાર, સ્ત્રોત કોડ અથવા એપ્લિકેશન પરીક્ષણ માટે આવે છે, અને વર્ષમાં એકવાર પેન્ટેસ્ટ. આ બધું એ હકીકત તરફ દોરી જાય છે કે ઉદ્યોગ માટેની પ્રકાશન તારીખો મુલતવી રાખવામાં આવી છે, અને સ્વચાલિત સાધનોમાંથી મોટી સંખ્યામાં નબળાઈઓ વિકાસકર્તા પર પડે છે. આ બધું ડિસએસેમ્બલ અને રિપેર કરવું અશક્ય છે, કારણ કે અગાઉના છ મહિનામાં પણ પરિણામોને તોડી પાડવામાં આવ્યા ન હતા, અને અહીં એક નવી બેચ છે.

અમારી કંપનીના કાર્યની પ્રક્રિયામાં, અમે જોઈએ છીએ કે તમામ ક્ષેત્રો અને ઉદ્યોગોમાં સુરક્ષા સમજે છે કે તે એક ચક્રમાં વિકાસને પકડવાનો અને સ્પિન કરવાનો સમય છે - માં ચપળ. DevSecOps પેરાડાઈમ ચપળ વિકાસ પદ્ધતિ, અમલીકરણ, સમર્થન અને દરેક પ્રકાશન અને પુનરાવર્તનમાં સહભાગિતામાં સંપૂર્ણ રીતે બંધબેસે છે.

DevSecOps પર સંક્રમણ

સુરક્ષા વિકાસ જીવનચક્રમાં સૌથી મહત્વપૂર્ણ શબ્દ છે "પ્રક્રિયા". સાધનો ખરીદવા વિશે વિચારતા પહેલા તમારે આ સમજવાની જરૂર છે.

DevOps પ્રક્રિયામાં માત્ર સાધનોનો સમાવેશ કરવો પૂરતો નથી - પ્રક્રિયાના સહભાગીઓ વચ્ચે વાતચીત અને સમજણ મહત્વપૂર્ણ છે.

લોકો સાધનો કરતાં વધુ મહત્વપૂર્ણ છે

ઘણીવાર સુરક્ષિત વિકાસ પ્રક્રિયાનું આયોજન ટૂલ પસંદ કરવા અને ખરીદવાથી શરૂ થાય છે, અને વર્તમાન પ્રક્રિયામાં સાધનને એકીકૃત કરવાના પ્રયાસો સાથે સમાપ્ત થાય છે, જે પ્રયાસો રહે છે. આ દુઃખદ પરિણામો તરફ દોરી જાય છે, કારણ કે તમામ સાધનોની પોતાની લાક્ષણિકતાઓ અને મર્યાદાઓ હોય છે.

એક સામાન્ય કિસ્સો એ છે કે જ્યારે સુરક્ષા વિભાગે સુવિધાઓની વિશાળ શ્રેણી સાથે એક સારું, ખર્ચાળ સાધન પસંદ કર્યું અને તેને પ્રક્રિયામાં બનાવવા માટે વિકાસકર્તાઓ પાસે આવ્યા. પરંતુ તે કામ કરતું નથી - પ્રક્રિયા એવી રીતે ડિઝાઇન કરવામાં આવી છે કે પહેલેથી ખરીદેલ સાધનની મર્યાદાઓ વર્તમાન નમૂનામાં બંધબેસતી નથી.

પ્રથમ, તમે શું પરિણામ ઇચ્છો છો અને પ્રક્રિયા કેવી દેખાશે તેનું વર્ણન કરો. આ પ્રક્રિયામાં સાધન અને સુરક્ષાની ભૂમિકાઓને સમજવામાં મદદ કરશે.

જે પહેલેથી ઉપયોગમાં છે તેની સાથે પ્રારંભ કરો

ખર્ચાળ સાધનો ખરીદતા પહેલા, તમારી પાસે પહેલેથી જ શું છે તે જુઓ. દરેક કંપનીની સુરક્ષા આવશ્યકતાઓ હોય છે જે વિકાસને લાગુ પડે છે, ત્યાં તપાસો, પેન્ટેસ્ટ છે - આ બધું દરેક માટે સમજી શકાય તેવા અને અનુકૂળ સ્વરૂપમાં કેમ રૂપાંતરિત થતું નથી?

સામાન્ય રીતે આવશ્યકતાઓ કાગળની તાલમડ છે જે શેલ્ફ પર રહે છે. એક એવો કિસ્સો હતો જ્યારે અમે કંપની પાસે પ્રક્રિયાઓ જોવા અને તેમને સોફ્ટવેર માટેની સુરક્ષા જરૂરિયાતો બતાવવા માટે કહીએ છીએ. નિષ્ણાત જેણે આ કર્યું તે લાંબા સમયથી શોધી રહ્યો હતો:

- હવે, નોંધોમાં ક્યાંક એક રસ્તો હતો જ્યાં આ દસ્તાવેજ આવેલો છે.

પરિણામે, અમને એક અઠવાડિયા પછી દસ્તાવેજ મળ્યો.

જરૂરિયાતો, તપાસો અને વધુ માટે, એક પૃષ્ઠ બનાવો, ઉદાહરણ તરીકે પર સંગમ - તે દરેક માટે અનુકૂળ છે.

જે પહેલાથી જ છે તેને ફરીથી ફોર્મેટ કરવું અને તેનો ઉપયોગ શરૂ કરવા માટે સરળ છે.

સુરક્ષા ચેમ્પિયન્સનો ઉપયોગ કરો

સામાન્ય રીતે, 100-200 વિકાસકર્તાઓ માટેની સરેરાશ કંપનીમાં, એક સુરક્ષા અધિકારી હોય છે જે ઘણા કાર્યો કરે છે અને તેની પાસે શારીરિક રીતે બધું તપાસવાનો સમય નથી. જો તે પોતાનો શ્રેષ્ઠ પ્રયાસ કરે તો પણ, તે એકલા વિકાસ દ્વારા જનરેટ થતા તમામ કોડને તપાસશે નહીં. આવા કિસ્સાઓ માટે, એક ખ્યાલ વિકસાવવામાં આવ્યો છે - સુરક્ષા ચેમ્પિયન્સ.

સિક્યુરિટી ચેમ્પિયન્સ એ ડેવલપમેન્ટ ટીમની અંદરની વ્યક્તિ છે જે તમારા ઉત્પાદનની સુરક્ષામાં રસ ધરાવે છે.

સિક્યુરિટી ચેમ્પિયન એ ડેવલપમેન્ટ ટીમ માટે એન્ટ્રી પોઈન્ટ છે અને એક સુરક્ષા પ્રચારક બધા એકમાં ફેરવાઈ જાય છે.

સામાન્ય રીતે, જ્યારે કોઈ સુરક્ષા અધિકારી વિકાસ ટીમ પાસે આવે છે અને કોડમાં ભૂલ દર્શાવે છે, ત્યારે તેને આશ્ચર્યજનક જવાબ મળે છે:

- અને તમે કોણ છો? હું તમને પ્રથમ વખત જોઉં છું. મારી સાથે બધું સારું છે - મારા વરિષ્ઠ મિત્રએ કોડ સમીક્ષા પર "લાગુ કરો" મૂક્યું, અમે આગળ વધીએ છીએ!

આ એક સામાન્ય પરિસ્થિતિ છે, કારણ કે ત્યાં વરિષ્ઠ અથવા ફક્ત ટીમના સાથીઓ પર વધુ વિશ્વાસ છે કે જેમની સાથે વિકાસકર્તા કામ પર અને કોડ સમીક્ષામાં સતત સંપર્ક કરે છે. જો, સિક્યોરિટી ગાર્ડને બદલે, સિક્યુરિટી ચેમ્પિયન ભૂલ અને તેના પરિણામો દર્શાવે છે, તો તેના શબ્દમાં વધુ વજન હશે.

ઉપરાંત, વિકાસકર્તાઓ તેમના કોડને કોઈપણ સુરક્ષા વ્યક્તિ કરતાં વધુ સારી રીતે જાણે છે. જે વ્યક્તિ પાસે સ્ટેટિક એનાલિસિસ ટૂલમાં ઓછામાં ઓછા 5 પ્રોજેક્ટ્સ છે, તે સામાન્ય રીતે તમામ ઘોંઘાટને યાદ રાખવું મુશ્કેલ છે. સુરક્ષા ચેમ્પિયન્સ તેમના ઉત્પાદનને જાણે છે: પ્રથમ સ્થાને શું અને શું જોવું તેની સાથે શું ક્રિયાપ્રતિક્રિયા કરે છે - તેઓ વધુ કાર્યક્ષમ છે.

તેથી સિક્યોરિટી ચેમ્પિયન્સ અમલમાં મૂકવા અને સુરક્ષા ટીમના પ્રભાવને વિસ્તૃત કરવાનું વિચારો. ચેમ્પિયન માટે, આ પણ ઉપયોગી છે: નવા ક્ષેત્રમાં વ્યાવસાયિક વિકાસ, તકનીકી ક્ષિતિજને વિસ્તરણ, તકનીકી, સંચાલકીય અને નેતૃત્વ કુશળતાને પમ્પિંગ કરવું, બજાર મૂલ્ય વધારવું. આ સામાજિક ઇજનેરીનું અમુક તત્વ છે, વિકાસ ટીમમાં તમારી "આંખો".

પરીક્ષણ તબક્કાઓ

પેરાડાઈમ 20 બાય 80 કહે છે કે 20% પ્રયત્નો 80% પરિણામો આપે છે. આ 20% એપ્લિકેશન વિશ્લેષણ પ્રેક્ટિસ છે જે સ્વચાલિત થઈ શકે છે અને હોવી જોઈએ. આવી પ્રવૃત્તિઓના ઉદાહરણો સ્થિર વિશ્લેષણ છે - સેસ્ટ, ગતિશીલ વિશ્લેષણ - ડાસ્ટ, и ઓપન સોર્સ નિયંત્રણ. હું તમને પ્રવૃત્તિઓ વિશે તેમજ ટૂલ્સ વિશે વધુ કહીશ, જ્યારે પ્રક્રિયામાં દાખલ કરવામાં આવે ત્યારે આપણે સામાન્ય રીતે કઈ સુવિધાઓનો સામનો કરીએ છીએ અને તેને યોગ્ય રીતે કેવી રીતે કરવું.

મુખ્ય સાધન સમસ્યાઓ

હું ધ્યાનની જરૂર હોય તેવા તમામ સાધનો માટે સંબંધિત સમસ્યાઓને પ્રકાશિત કરીશ. હું તેનું વધુ વિગતવાર વિશ્લેષણ કરીશ જેથી વધુ પુનરાવર્તન ન થાય.

લાંબા વિશ્લેષણ સમય. જો તે તમામ પરીક્ષણો અને એસેમ્બલી માટે કમિટથી લઈને પ્રોડક્શન માટે રિલીઝ થવા માટે 30 મિનિટ લે છે, તો માહિતી સુરક્ષા તપાસમાં એક દિવસ લાગશે. તેથી કોઈ પણ પ્રક્રિયાને ધીમું કરશે નહીં. આ લક્ષણને ધ્યાનમાં લો અને તારણો દોરો.

ઉચ્ચ ખોટા નકારાત્મક અથવા ખોટા હકારાત્મક. બધા ઉત્પાદનો અલગ છે, બધા વિવિધ ફ્રેમવર્ક અને તેમની પોતાની કોડિંગ શૈલીનો ઉપયોગ કરે છે. વિવિધ કોડ બેઝ અને ટેક્નોલોજીઓ પર, ટૂલ્સ ખોટા નેગેટિવ અને ફોલ્સ પોઝિટિવના વિવિધ સ્તરો બતાવી શકે છે. તો જુઓ શું છે તમારા કંપનીઓ અને માટે તમારા એપ્લિકેશનો સારા અને વિશ્વસનીય પરિણામ બતાવશે.

હાલના સાધનો સાથે કોઈ એકીકરણ નથી. તમે પહેલાથી જે ઉપયોગ કરો છો તેની સાથે એકીકરણની દ્રષ્ટિએ ટૂલ્સ જુઓ. ઉદાહરણ તરીકે, જો તમારી પાસે Jenkins અથવા TeamCity છે, તો આ સૉફ્ટવેર સાથે સાધનોનું એકીકરણ તપાસો, અને GitLab CI સાથે નહીં, જેનો તમે ઉપયોગ કરતા નથી.

કસ્ટમાઇઝેશનનો અભાવ અથવા અતિશય જટિલતા. જો સાધનમાં API નથી, તો પછી તેની શા માટે જરૂર છે? ઈન્ટરફેસમાં જે કરી શકાય તે બધું API દ્વારા ઉપલબ્ધ હોવું જોઈએ. આદર્શ રીતે, ટૂલમાં ચેકને કસ્ટમાઇઝ કરવાની ક્ષમતા હોવી જોઈએ.

કોઈ પ્રોડક્ટ ડેવલપમેન્ટ રોડમેપ નથી. વિકાસ સ્થિર નથી, અમે હંમેશા નવા ફ્રેમવર્ક અને કાર્યોનો ઉપયોગ કરીએ છીએ, જૂના કોડને નવી ભાષાઓમાં ફરીથી લખીએ છીએ. અમે ખાતરી કરવા માંગીએ છીએ કે અમે જે ટૂલ ખરીદીએ છીએ તે નવા ફ્રેમવર્ક અને ટેક્નોલોજીને સપોર્ટ કરશે. તેથી, તે જાણવું અગત્યનું છે કે ઉત્પાદનમાં વાસ્તવિક અને સાચું છે roadmap વિકાસ

પ્રક્રિયા સુવિધાઓ

સાધનોની વિશેષતાઓ ઉપરાંત, વિકાસ પ્રક્રિયાની વિશેષતાઓને ધ્યાનમાં લો. ઉદાહરણ તરીકે, વિકાસમાં દખલ કરવી એ એક સામાન્ય ભૂલ છે. ચાલો જોઈએ કે અન્ય કઈ સુવિધાઓ ધ્યાનમાં લેવી જોઈએ અને સુરક્ષા ટીમે શું ધ્યાન આપવું જોઈએ.

વિકાસને વિક્ષેપિત ન કરવા અને સમયમર્યાદા પ્રકાશિત કરવા માટે, બનાવો વિવિધ નિયમો અને અલગ સ્ટોપર્સ બતાવો - નબળાઈઓની હાજરીમાં બિલ્ડ પ્રક્રિયાને રોકવા માટેના માપદંડ - વિવિધ વાતાવરણ માટે. ઉદાહરણ તરીકે, અમે સમજીએ છીએ કે વર્તમાન શાખા ડેવલપમેન્ટ સ્ટેન્ડ અથવા UAT પર જઈ રહી છે, તેથી અમે રોકાતાં નથી અને કહેતા નથી:

- તમારી પાસે અહીં નબળાઈઓ છે, તમે આગળ ક્યાંય જશો નહીં!

આ બિંદુએ, વિકાસકર્તાઓને જણાવવું મહત્વપૂર્ણ છે કે ત્યાં સુરક્ષા સમસ્યાઓ છે જેના પર ધ્યાન આપવું જરૂરી છે.

નબળાઈઓની હાજરી વધુ પરીક્ષણ માટે અવરોધ નથી: મેન્યુઅલ, એકીકરણ અથવા મેન્યુઅલ. બીજી બાજુ, અમારે ઉત્પાદનની સુરક્ષામાં કોઈક રીતે સુધારો કરવાની જરૂર છે, અને જેથી વિકાસકર્તાઓ સુરક્ષાને જે શોધે છે તેના પર સ્કોર ન કરે. તેથી, કેટલીકવાર અમે આ કરીએ છીએ: સ્ટેન્ડ પર, જ્યારે તે વિકાસના વાતાવરણમાં રોલઆઉટ થાય છે, ત્યારે અમે ફક્ત વિકાસને સૂચિત કરીએ છીએ:

- ગાય્સ, તમને સમસ્યાઓ છે, કૃપા કરીને તેના પર ધ્યાન આપો.

UAT સ્ટેજ પર, અમે ફરીથી નબળાઈઓ વિશે ચેતવણીઓ બતાવીએ છીએ, અને પ્રમોશનમાં બહાર નીકળવાના તબક્કે અમે કહીએ છીએ:

"ગાય્સ, અમે તમને ઘણી વખત ચેતવણી આપી છે, તમે કંઈ કર્યું નથી - અમે તમને આ સાથે બહાર જવા દઈશું નહીં.

જો આપણે કોડ અને ગતિશીલતા વિશે વાત કરીએ, તો તમારે ફક્ત તે લક્ષણો અને કોડની નબળાઈઓ બતાવવાની અને ચેતવણી આપવી જરૂરી છે જે હમણાં જ આ સુવિધામાં લખવામાં આવી હતી. જો વિકાસકર્તાએ બટનને 3 પિક્સેલ્સ દ્વારા ખસેડ્યું અને અમે તેને કહીએ કે તેની પાસે ત્યાં એક SQL ઈન્જેક્શન છે અને તેથી તેને તાત્કાલિક ઠીક કરવાની જરૂર છે, તો આ ખોટું છે. ફક્ત હવે શું લખાયેલ છે તે જુઓ, અને એપ્લિકેશનમાં જે ફેરફાર આવે છે તે જુઓ.

ચાલો કહીએ કે અમારી પાસે કેટલીક કાર્યાત્મક ખામી છે - જે રીતે એપ્લિકેશન કામ ન કરવી જોઈએ: પૈસા ટ્રાન્સફર થતા નથી, જ્યારે તમે બટન પર ક્લિક કરો છો, ત્યારે આગલા પૃષ્ઠ પર કોઈ સંક્રમણ નથી, અથવા ઉત્પાદન લોડ થતું નથી. સુરક્ષા ખામીઓ - આ સમાન ખામીઓ છે, પરંતુ એપ્લિકેશનના સંદર્ભમાં નહીં, પરંતુ સુરક્ષા.

તમામ સોફ્ટવેર ગુણવત્તા સમસ્યાઓ સુરક્ષા સમસ્યાઓ નથી. પરંતુ તમામ સુરક્ષા સમસ્યાઓ સોફ્ટવેરની ગુણવત્તા સાથે સંબંધિત છે. શરીફ મન્સૂર, એક્સપેડિયા.

તમામ નબળાઈઓ સમાન ખામીઓ હોવાથી, તે તમામ વિકાસ ખામીઓ જેવી જ જગ્યાએ સ્થિત હોવી જોઈએ. તેથી અહેવાલો અને ડરામણી પીડીએફ વિશે ભૂલી જાઓ જે કોઈ વાંચતું નથી.

જ્યારે હું ડેવલપમેન્ટ કંપની માટે કામ કરતો હતો, ત્યારે મને સ્ટેટિક એનાલિસિસ ટૂલ્સ તરફથી રિપોર્ટ મળ્યો. મેં તેને ખોલ્યું, ગભરાઈ ગયો, કોફી બનાવી, 350 પાનામાં લીફ કરી, તેને બંધ કરી અને કામ પર ગયો. મોટા અહેવાલો મૃત અહેવાલો છે. સામાન્ય રીતે તેઓ ક્યાંય જતા નથી, ઇમેઇલ્સ કાઢી નાખવામાં આવે છે, ભૂલી જાય છે, ખોવાઈ જાય છે અથવા વ્યવસાય કહે છે કે તે જોખમો લઈ રહ્યો છે.

શુ કરવુ? અમે ફક્ત પુષ્ટિ કરેલી ખામીઓને વિકાસ માટે અનુકૂળ સ્વરૂપમાં રૂપાંતરિત કરીએ છીએ, ઉદાહરણ તરીકે, તેને જીરામાં બેકલોગમાં મૂકો. કાર્યાત્મક ખામીઓ અને પરીક્ષણ ખામીઓ સાથે અગ્રતાના ક્રમમાં ખામીઓને પ્રાથમિકતા આપવામાં આવે છે અને દૂર કરવામાં આવે છે.

સ્ટેટિક એનાલિસિસ - SAST

આ નબળાઈઓ માટે કોડ વિશ્લેષણ છે., પરંતુ તે SonarQube જેવું નથી. અમે ફક્ત પેટર્ન અથવા શૈલી માટે જ તપાસ કરતા નથી. વિશ્લેષણ સંખ્યાબંધ અભિગમોનો ઉપયોગ કરે છે: નબળાઈ વૃક્ષ દ્વારા, દ્વારા માહિતી પ્રવાહ, રૂપરેખાંકન ફાઇલોનું વિશ્લેષણ કરીને. તે બધા કોડ માટે જ છે.

અભિગમના ગુણ: વિકાસના પ્રારંભિક તબક્કે કોડમાં નબળાઈઓને ઓળખવીજ્યારે ત્યાં કોઈ સ્ટેન્ડ અને તૈયાર સાધનો ન હોય, અને વધારાની સ્કેન ક્ષમતા: કોડના એક વિભાગને સ્કેન કરે છે જે બદલાઈ ગયો છે, અને માત્ર તે જ સુવિધા જે અમે હાલમાં કરી રહ્યા છીએ, જે સ્કેનનો સમય ઘટાડે છે.

મિનિસી જરૂરી ભાષાઓ માટે સમર્થનનો અભાવ છે.

જરૂરી એકીકરણ, જે મારા વ્યક્તિલક્ષી અભિપ્રાયમાં સાધનોમાં હોવું જોઈએ:

• એકીકરણ સાધન: જેનકિન્સ, ટીમસિટી અને ગિટલેબ સીઆઈ.
• ડેવલપમેન્ટ એન્વાયરમેન્ટ: ઈન્ટેલિજ આઈડીઈએ, વિઝ્યુઅલ સ્ટુડિયો. વિકાસકર્તા માટે તે અગમ્ય ઇન્ટરફેસમાં ન ચઢવું વધુ અનુકૂળ છે જેને હજુ પણ યાદ રાખવાની જરૂર છે, પરંતુ તેના પોતાના વિકાસના વાતાવરણમાં કાર્યસ્થળ પર તેને મળી આવેલ તમામ જરૂરી સંકલન અને નબળાઈઓ જોવા માટે.
• કોડ સમીક્ષા: SonarQube અને મેન્યુઅલ સમીક્ષા.
• ખામી ટ્રેકર્સ: જીરા અને બગઝિલા.

ચિત્ર સ્થિર વિશ્લેષણના કેટલાક શ્રેષ્ઠ પ્રતિનિધિઓ દર્શાવે છે.

તે સાધનો મહત્વપૂર્ણ નથી, પરંતુ પ્રક્રિયા છે, તેથી ત્યાં ઓપન સોર્સ સોલ્યુશન્સ છે જે પ્રક્રિયા ચલાવવા માટે પણ સારા છે.

SAST ઓપન સોર્સ મોટી સંખ્યામાં નબળાઈઓ અથવા જટિલ ડેટાફ્લો શોધી શકશે નહીં, પરંતુ પ્રક્રિયા બનાવતી વખતે તેનો ઉપયોગ કરી શકાય છે અને થવો જોઈએ. તેઓ સમજવામાં મદદ કરે છે કે પ્રક્રિયા કેવી રીતે બનાવવામાં આવશે, કોણ બગ્સને પ્રતિસાદ આપશે, કોણ જાણ કરશે, કોણ જાણ કરશે. જો તમે તમારા કોડની સુરક્ષા બનાવવાના પ્રારંભિક તબક્કાને પૂર્ણ કરવા માંગતા હો, તો ઓપન સોર્સ સોલ્યુશન્સનો ઉપયોગ કરો.

આ કેવી રીતે સંકલિત થઈ શકે જો તમે પ્રવાસની શરૂઆતમાં છો, તમારી પાસે કંઈ નથી: ન તો CI, ન જેનકિન્સ, ન તો TeamCity? પ્રક્રિયાના એકીકરણને ધ્યાનમાં લો.

CVS સ્તરે એકીકરણ

જો તમારી પાસે Bitbucket અથવા GitLab હોય, તો તમે સ્તર પર એકીકરણ કરી શકો છો સમવર્તી આવૃત્તિઓ સિસ્ટમ.

ઘટના દ્વારા વિનંતી ખેંચો, પ્રતિબદ્ધ કરો. તમે કોડ સ્કેન કરો અને બિલ્ડ સ્ટેટસમાં બતાવો કે સુરક્ષા તપાસ પાસ થઈ કે નિષ્ફળ.

પ્રતિસાદ. અલબત્ત, પ્રતિસાદ હંમેશા જરૂરી છે. જો તમે તે માત્ર સુરક્ષાની બાજુએ કર્યું હોય, તો તેને એક બૉક્સમાં મૂકો અને તેના વિશે કોઈને કંઈપણ કહ્યું નહીં, અને પછી મહિનાના અંતે ભૂલોનો સમૂહ ફેંકી દો, આ યોગ્ય નથી અને સારું નથી.

કોડ સમીક્ષા સિસ્ટમ સાથે એકીકરણ

એકવાર, અમે AppSec તકનીકી વપરાશકર્તાને સંખ્યાબંધ મહત્વપૂર્ણ પ્રોજેક્ટ્સમાં ડિફોલ્ટ સમીક્ષક તરીકે સેટ કરીએ છીએ. નવા કોડમાં ભૂલો જોવા મળી હતી કે કોઈ ભૂલો નથી તેના આધારે, સમીક્ષક પુલ વિનંતી પર "સ્વીકારવા" અથવા "કામની જરૂર છે" માટે સ્થિતિ મૂકે છે - કાં તો બધું બરાબર છે, અથવા તમારે ફાઇનલ કરવાની જરૂર છે અને બરાબર શું છે તેની લિંક કરવાની જરૂર છે. અંતિમ સ્વરૂપ આપવા માટે. જે સંસ્કરણ રિલીઝ થઈ રહ્યું છે તેની સાથે એકીકરણ માટે, જો IS પરીક્ષણ પાસ ન થયું હોય તો અમે મર્જને અક્ષમ કર્યું છે. અમે મેન્યુઅલ કોડ સમીક્ષામાં આનો સમાવેશ કર્યો છે, અને બાકીની પ્રક્રિયાના સહભાગીઓએ આ ચોક્કસ પ્રક્રિયા માટે સુરક્ષા સ્થિતિઓ જોઈ છે.

SonarQube સાથે એકીકરણ

ઘણા પાસે છે ગુણવત્તા દ્વાર કોડ ગુણવત્તાના સંદર્ભમાં. તે અહીં સમાન છે - તમે ફક્ત SAST સાધનો માટે સમાન દરવાજા બનાવી શકો છો. ત્યાં સમાન ઇન્ટરફેસ હશે, સમાન ગુણવત્તાનો દરવાજો, ફક્ત તે જ કહેવામાં આવશે સુરક્ષા દ્વાર. અને એ પણ, જો તમે SonarQube નો ઉપયોગ કરીને કોઈ પ્રક્રિયા સેટ કરી હોય, તો તમે ત્યાં બધું સરળતાથી એકીકૃત કરી શકો છો.

CI સ્તરે એકીકરણ

અહીં પણ, બધું એકદમ સરળ છે:

• ઑટોટેસ્ટ સાથે સમકક્ષ, એકમ પરીક્ષણો.
• વિકાસના તબક્કાઓ દ્વારા વિભાજન: dev, test, prod. નિયમોના વિવિધ સેટનો સમાવેશ થઈ શકે છે, અથવા અલગ-અલગ નિષ્ફળ શરતો હોઈ શકે છે: અમે એસેમ્બલી બંધ કરીએ છીએ, અમે એસેમ્બલી બંધ કરતા નથી.
• સિંક્રનસ / અસુમેળ શરૂઆત. અમે સુરક્ષા પરીક્ષણોના અંતની રાહ જોઈ રહ્યા છીએ અથવા અમે રાહ જોઈ રહ્યા નથી. એટલે કે, અમે હમણાં જ તેમને લૉન્ચ કરીને આગળ વધીએ છીએ, અને પછી અમને એક સ્ટેટસ મળે છે કે બધું સારું છે કે ખરાબ.

તે બધું એક સંપૂર્ણ ગુલાબી વિશ્વમાં છે. વાસ્તવિક જીવનમાં, આ કેસ નથી, પરંતુ અમે પ્રયત્ન કરીએ છીએ. સુરક્ષા તપાસનું પરિણામ એકમ પરીક્ષણોના પરિણામો જેવું જ હોવું જોઈએ.

ઉદાહરણ તરીકે, અમે એક મોટો પ્રોજેક્ટ લીધો અને નક્કી કર્યું કે હવે અમે તેને SAST - OK સાથે સ્કેન કરીશું. અમે આ પ્રોજેક્ટને SAST માં ખસેડ્યો, તેણે અમને 20 નબળાઈઓ આપી, અને અમે મજબૂત-ઇચ્છાથી નિર્ણય લીધો કે બધું બરાબર છે. 000 નબળાઈઓ એ અમારું તકનીકી દેવું છે. અમે દેવું એક બૉક્સમાં મૂકીશું, અમે તેને ધીમે ધીમે વધારીશું અને ખામી ટ્રેકર્સમાં ભૂલો શરૂ કરીશું. એક કંપની ભાડે રાખો, બધું જાતે કરો અથવા સુરક્ષા ચેમ્પિયન અમને મદદ કરો અને તકનીકી દેવું ઘટશે.

અને નવા કોડમાં નવી દેખાતી તમામ નબળાઈઓને એકમમાં અથવા ઑટોટેસ્ટમાં ભૂલોની જેમ જ દૂર કરવી જોઈએ. સાપેક્ષ રીતે કહીએ તો, એસેમ્બલી શરૂ થઈ, દૂર લઈ ગઈ, બે પરીક્ષણો અને બે સુરક્ષા પરીક્ષણો નીચે પડ્યા. ઠીક છે - અમે ગયા, શું થયું તે જોયું, એક સુધાર્યું, બીજું સુધાર્યું, આગલી વખતે વાહન ચલાવ્યું - બધું સારું છે, કોઈ નવી નબળાઈઓ દેખાઈ નથી, પરીક્ષણો નિષ્ફળ થયા નથી. જો આ કાર્ય વધુ ઊંડું છે અને તમારે તેને સારી રીતે સમજવાની જરૂર છે, અથવા નબળાઈઓને ઠીક કરવાથી હૂડની નીચે શું છે તેના મોટા સ્તરોને અસર કરે છે: ખામી ટ્રૅકરમાં બગ લાવવામાં આવે છે, તેને પ્રાથમિકતા આપવામાં આવે છે અને તેને ઠીક કરવામાં આવે છે. કમનસીબે, વિશ્વ સંપૂર્ણ નથી અને પરીક્ષણો ક્યારેક નિષ્ફળ જાય છે.

કોડમાં નબળાઈઓની હાજરી અને સંખ્યાના સંદર્ભમાં સુરક્ષા દ્વારનું ઉદાહરણ ગુણવત્તાવાળા દ્વારનું એનાલોગ છે.

અમે SonarQube સાથે સંકલિત કરીએ છીએ - પ્લગઇન ઇન્સ્ટોલ કરેલું છે, બધું ખૂબ અનુકૂળ અને સરસ છે.

વિકાસ પર્યાવરણ સંકલન

એકીકરણ વિકલ્પો:

• પ્રતિબદ્ધતા પહેલા જ વિકાસ વાતાવરણમાંથી સ્કેન શરૂ કરી રહ્યું છે.
• પરિણામો જુઓ.
• પરિણામોનું વિશ્લેષણ.
• સર્વર સાથે સિંક્રનાઇઝેશન.

સર્વરમાંથી પરિણામો મેળવવાનું આ રીતે દેખાય છે.

આપણા વિકાસના વાતાવરણમાં ઇન્ટેલલીજ આઈડીઇએ તે માત્ર એક વધારાની આઇટમ દેખાય છે જે કહે છે કે સ્કેન દરમિયાન આવી નબળાઈઓ મળી આવી હતી. તમે તરત જ કોડ સંપાદિત કરી શકો છો, ભલામણો જોઈ શકો છો અને પ્રવાહ ગ્રાફ. આ બધું વિકાસકર્તાના કાર્યસ્થળ પર સ્થિત છે, જે ખૂબ અનુકૂળ છે - તમારે બાકીની લિંક્સને અનુસરવાની અને કંઈક વધારાની જોવાની જરૂર નથી.

ઓપન સોર્સ

આ મારો પ્રિય વિષય છે. દરેક વ્યક્તિ ઓપન સોર્સ લાઇબ્રેરીનો ઉપયોગ કરે છે - જ્યારે તમે તૈયાર પુસ્તકાલય લઈ શકો છો જેમાં બધું પહેલેથી જ અમલમાં છે ત્યારે ક્રૉચ અને સાયકલનો સમૂહ શા માટે લખો?

અલબત્ત, આ સાચું છે, પરંતુ પુસ્તકાલયો પણ લોકો દ્વારા લખવામાં આવે છે, તેમાં ચોક્કસ જોખમો પણ શામેલ હોય છે, અને એવી નબળાઈઓ પણ હોય છે જે સમયાંતરે અથવા સતત જાણ કરવામાં આવે છે. તેથી, એપ્લિકેશન સુરક્ષામાં આગળનું પગલું છે - આ ઓપન સોર્સ ઘટકોનું વિશ્લેષણ છે.

ઓપન સોર્સ એનાલિસિસ - OSA

આ સાધનમાં ત્રણ મુખ્ય પગલાં શામેલ છે.

પુસ્તકાલયોમાં નબળાઈઓ શોધવી. ઉદાહરણ તરીકે, સાધન જાણે છે કે અમે અમુક પ્રકારની લાઇબ્રેરીનો ઉપયોગ કરી રહ્યા છીએ, અને તે અંદર સીવી અથવા બગ ટ્રેકર્સમાં કેટલીક નબળાઈઓ છે જે લાઈબ્રેરીના આ સંસ્કરણ સાથે સંબંધિત છે. જો તમે તેનો ઉપયોગ કરવાનો પ્રયાસ કરો છો, તો ટૂલ તમને ચેતવણી આપશે કે લાઇબ્રેરી સંવેદનશીલ છે, અને તમને અન્ય સંસ્કરણનો ઉપયોગ કરવાની સલાહ આપશે જ્યાં કોઈ નબળાઈઓ નથી.

લાઇસન્સ શુદ્ધતાનું વિશ્લેષણ. આ હજી સુધી અમારી સાથે ખૂબ લોકપ્રિય નથી, પરંતુ જો તમે કોઈ વિદેશી દેશ સાથે કામ કરો છો, તો ત્યાં તમને સમયાંતરે ઓપન સોર્સ કમ્પોનન્ટનો ઉપયોગ કરવા બદલ હુમલો થઈ શકે છે જેનો ઉપયોગ અથવા ફેરફાર કરી શકાતો નથી. લાઇસન્સ પ્રાપ્ત પુસ્તકાલયની નીતિ અનુસાર, અમે આ કરી શકતા નથી. અથવા, જો આપણે તેમાં ફેરફાર કરીને તેનો ઉપયોગ કર્યો હોય, તો અમારે અમારો કોડ પોસ્ટ કરવો જોઈએ. અલબત્ત, કોઈ પણ તેમના ઉત્પાદનોનો કોડ પોસ્ટ કરવા માંગતો નથી, પરંતુ તમે આનાથી તમારી જાતને સુરક્ષિત પણ કરી શકો છો.

ઔદ્યોગિક વાતાવરણમાં ઉપયોગમાં લેવાતા ઘટકોનું વિશ્લેષણ. કાલ્પનિક પરિસ્થિતિની કલ્પના કરો કે અમે આખરે વિકાસ પૂર્ણ કર્યો છે અને ઉદ્યોગ માટે અમારી માઇક્રોસર્વિસનું નવીનતમ પ્રકાશન બહાર પાડ્યું છે. તે ત્યાં અદ્ભુત રીતે રહે છે - એક અઠવાડિયું, એક મહિનો, એક વર્ષ. અમે તેને એકત્રિત કરતા નથી, અમે સુરક્ષા તપાસ કરતા નથી, બધું સારું લાગે છે. પરંતુ અચાનક, પ્રકાશનના બે અઠવાડિયા પછી, ઓપન સોર્સ ઘટકમાં એક નિર્ણાયક નબળાઈ બહાર આવે છે, જેનો ઉપયોગ આપણે આ ચોક્કસ એસેમ્બલીમાં, ઔદ્યોગિક વાતાવરણમાં કરીએ છીએ. જો આપણે શું અને ક્યાં ઉપયોગ કરીએ છીએ તે રેકોર્ડ ન કરીએ, તો આ નબળાઈ ફક્ત જોવામાં આવશે નહીં. કેટલાક ટૂલ્સ પાસે લાઇબ્રેરીઓમાં નબળાઈઓને મોનિટર કરવાની ક્ષમતા હોય છે જેનો ઉપયોગ હાલમાં પ્રમોશનમાં થાય છે. તે ખૂબ જ ઉપયોગી છે.

તકો

• વિકાસના વિવિધ તબક્કાઓ માટે વિવિધ નીતિઓ.
• ઔદ્યોગિક વાતાવરણમાં ઘટકોનું નિરીક્ષણ કરો.
• સંસ્થાના સમોચ્ચમાં પુસ્તકાલયોનું નિયંત્રણ.
• વિવિધ બિલ્ડ સિસ્ટમ્સ અને ભાષાઓ માટે સપોર્ટ.
• ડોકર છબીઓનું વિશ્લેષણ.

ક્ષેત્રના નેતાઓના થોડા ઉદાહરણો જેઓ ઓપન સોર્સના વિશ્લેષણમાં રોકાયેલા છે.

એકમાત્ર મફત છે નિર્ભરતા તપાસ OWASP તરફથી. તમે તેને પ્રથમ તબક્કામાં ચાલુ કરી શકો છો, તે કેવી રીતે કાર્ય કરે છે અને તે શું સપોર્ટ કરે છે તે જુઓ. મૂળભૂત રીતે, આ તમામ ક્લાઉડ પ્રોડક્ટ્સ છે, અથવા ઓન-પ્રિમાઈસ, પરંતુ તેમના આધાર પાછળ તેઓ હજી પણ ઇન્ટરનેટ પર જાય છે. તેઓ તમારી લાઇબ્રેરીઓ મોકલતા નથી, પરંતુ હેશ અથવા તેમના મૂલ્યો કે જેની તેઓ ગણતરી કરે છે, અને નબળાઈઓની હાજરીના સમાચાર પ્રાપ્ત કરવા માટે તેમના સર્વર પર ફિંગરપ્રિન્ટ મોકલે છે.

પ્રક્રિયા એકીકરણ

પરિમિતિ પુસ્તકાલય નિયંત્રણજે બાહ્ય સ્ત્રોતોમાંથી ડાઉનલોડ કરેલ છે. અમારી પાસે બાહ્ય અને આંતરિક ભંડાર છે. ઉદાહરણ તરીકે, અમારી પાસે ઇવેન્ટ સેન્ટ્રલની અંદર નેક્સસ છે, અને અમે ખાતરી કરવા માંગીએ છીએ કે અમારા ભંડારની અંદર "જટિલ" અથવા "ઉચ્ચ" સ્થિતિ સાથે કોઈ નબળાઈઓ નથી. તમે નેક્સસ ફાયરવોલ લાઇફસાઇકલ ટૂલનો ઉપયોગ કરીને પ્રોક્સીંગ સેટ કરી શકો છો જેથી આવી નબળાઈઓ કાપી નાખવામાં આવે અને આંતરિક ભંડારમાં શામેલ ન થાય.

CI એકીકરણ. ઓટોટેસ્ટ, યુનિટ ટેસ્ટ અને વિકાસના તબક્કામાં વિભાજન સાથે સમાન સ્તર પર: dev, test, prod. દરેક તબક્કે, તમે કોઈપણ પુસ્તકાલયો ડાઉનલોડ કરી શકો છો, કોઈપણ વસ્તુનો ઉપયોગ કરી શકો છો, પરંતુ જો ત્યાં "જટિલ" સ્થિતિ સાથે કંઈક મુશ્કેલ હોય, તો તમારે પ્રોમમાં પ્રવેશવાના તબક્કે વિકાસકર્તાઓનું ધ્યાન આ તરફ દોરવું જોઈએ.

આર્ટિફેક્ટ એકીકરણ: Nexus અને JFrog.

વિકાસ વાતાવરણમાં એકીકરણ. તમે જે સાધનો પસંદ કરો છો તેમાં વિકાસ વાતાવરણ સાથે સંકલન હોવું જોઈએ. વિકાસકર્તા પાસે તેના કાર્યસ્થળમાંથી સ્કેન પરિણામોની ઍક્સેસ હોવી જોઈએ, અથવા તેને CVS માં મોકલતા પહેલા નબળાઈઓ માટે કોડને સ્કેન કરવાની અને તપાસવાની ક્ષમતા હોવી જોઈએ.

સીડી એકીકરણ. આ એક સરસ સુવિધા છે જે મને ખરેખર ગમે છે અને જેના વિશે મેં પહેલેથી જ વાત કરી છે - ઔદ્યોગિક વાતાવરણમાં નવી નબળાઈઓના ઉદભવનું નિરીક્ષણ કરવું. તે આ રીતે કામ કરે છે.

અમારી પાસે જાહેર ઘટક ભંડાર - બહારના કેટલાક સાધનો અને અમારી આંતરિક ભંડાર. અમે ઇચ્છીએ છીએ કે તેમાં માત્ર વિશ્વસનીય ઘટકો હોય. વિનંતીને પ્રોક્સી કરતી વખતે, અમે તપાસીએ છીએ કે ડાઉનલોડ કરેલ લાઇબ્રેરીમાં કોઈ નબળાઈઓ નથી. જો તે અમુક નીતિઓ હેઠળ આવે છે જે અમે સેટ કરીએ છીએ અને વિકાસ સાથે જરૂરી સંકલન કરીએ છીએ, તો અમે તેને અપલોડ કરતા નથી અને અલગ સંસ્કરણનો ઉપયોગ કરવા માટે ઠપકો આવે છે. તદનુસાર, જો લાઇબ્રેરીમાં ખરેખર કંઈક જટિલ અને ખરાબ છે, તો વિકાસકર્તાને ઇન્સ્ટોલેશનના તબક્કે પણ લાઇબ્રેરી પ્રાપ્ત થશે નહીં - તેને ઉચ્ચ અથવા નીચલા સંસ્કરણનો ઉપયોગ કરવા દો.

• બનાવતી વખતે, અમે તપાસ કરીએ છીએ કે કોઈએ કંઈપણ ખરાબ કર્યું નથી, બધા ઘટકો સલામત છે અને કોઈ પણ ફ્લેશ ડ્રાઇવ પર જોખમી કંઈપણ લાવ્યા નથી.
• અમારી પાસે રિપોઝીટરીમાં માત્ર વિશ્વસનીય ઘટકો છે.
• જમાવટ કરતી વખતે, અમે ફરી એકવાર પેકેજ પોતે તપાસીએ છીએ: યુદ્ધ, જાર, ડીએલ અથવા ડોકર ઇમેજ એ હકીકત માટે કે તે નીતિનું પાલન કરે છે.
• ઔદ્યોગિક વાતાવરણમાં પ્રવેશ કરતી વખતે, અમે ઔદ્યોગિક વાતાવરણમાં શું થઈ રહ્યું છે તેનું નિરીક્ષણ કરીએ છીએ: નિર્ણાયક નબળાઈઓ દેખાય છે અથવા દેખાતી નથી.

ડાયનેમિક એનાલિસિસ - DAST

ગતિશીલ પૃથ્થકરણ ટૂલ્સ મૂળભૂત રીતે તે દરેક વસ્તુથી અલગ છે જે પહેલા કહેવામાં આવ્યું છે. આ એપ્લિકેશન સાથેના વપરાશકર્તાના કાર્યનું એક પ્રકારનું અનુકરણ છે. જો આ વેબ એપ્લિકેશન છે, તો અમે ક્લાયંટના કાર્યનું અનુકરણ કરતી વિનંતીઓ મોકલીએ છીએ, આગળના બટનો પર ક્લિક કરીએ છીએ, ફોર્મમાંથી કૃત્રિમ ડેટા મોકલીએ છીએ: એપ્લિકેશન કેવી રીતે કાર્ય કરે છે અને બાહ્ય પ્રક્રિયાઓ કરે છે તે જોવા માટે વિવિધ એન્કોડિંગ્સમાં અવતરણો, કૌંસ, અક્ષરો. ડેટા

આ જ સિસ્ટમ તમને ઓપન સોર્સમાં ટેમ્પલેટ નબળાઈઓ માટે તપાસવાની મંજૂરી આપે છે. DAST ને ખબર નથી કે આપણે કયા ઓપન સોર્સનો ઉપયોગ કરી રહ્યા છીએ, તે ફક્ત "દૂષિત" પેટર્ન ફેંકે છે અને સર્વરના પ્રતિસાદોનું વિશ્લેષણ કરે છે:

- હા, અહીં ડિસિરિયલાઈઝેશનની સમસ્યા છે, પણ અહીં નથી.

આમાં મોટા જોખમો છે, કારણ કે જો તમે આ સુરક્ષા પરીક્ષણ તે જ સ્ટેન્ડ પર કરો છો જેની સાથે પરીક્ષકો કામ કરે છે, તો અપ્રિય વસ્તુઓ થઈ શકે છે.

• એપ્લિકેશન સર્વર નેટવર્ક પર વધુ ભાર.
• કોઈ એકીકરણ નથી.
• વિશ્લેષણ કરેલ એપ્લિકેશનની સેટિંગ્સ બદલવાની ક્ષમતા.
• જરૂરી તકનીકો માટે કોઈ સપોર્ટ નથી.
• સેટિંગમાં મુશ્કેલી.

અમારી પાસે એવી પરિસ્થિતિ હતી જ્યારે અમે આખરે એપસ્કેન લોન્ચ કર્યું: અમે લાંબા સમય સુધી એપ્લિકેશનની ઍક્સેસને બહાર કાઢી નાખી, 3 એકાઉન્ટ્સ પ્રાપ્ત કર્યા અને આનંદ થયો - આખરે, અમે બધું તપાસીશું! અમે એક સ્કેન લૉન્ચ કર્યું, અને AppScan એ એડમિન પેનલમાં પ્રવેશવા, બધા બટનોને વીંધવા, અડધો ડેટા બદલવા અને પછી સર્વરને તેની પોતાની સાથે સંપૂર્ણપણે મારી નાખવાનું હતું. મેઇલ ફોર્મ- વિનંતીઓ. પરીક્ષણ સાથે વિકાસ કહ્યું:

"ગાય્સ, તમે મારી મજાક કરો છો ?! અમે તમને હિસાબ આપ્યા, અને તમે સ્ટેન્ડ મૂક્યો!

સંભવિત જોખમો ધ્યાનમાં લો. આદર્શરીતે, માહિતી સુરક્ષાનું પરીક્ષણ કરવા માટે એક અલગ સ્ટેન્ડ તૈયાર કરો, જે ઓછામાં ઓછા કોઈક રીતે બાકીના પર્યાવરણથી અલગ થઈ જશે, અને એડમિન પેનલને શરતી રીતે તપાસો, પ્રાધાન્ય મેન્યુઅલ મોડમાં. આ એક પેન્ટેસ્ટ છે - પ્રયત્નોની બાકીની ટકાવારી કે જેને આપણે હવે ધ્યાનમાં લઈ રહ્યા નથી.

તે ધ્યાનમાં લેવું યોગ્ય છે કે તમે આનો ઉપયોગ લોડ પરીક્ષણના એનાલોગ તરીકે કરી શકો છો. પ્રથમ તબક્કે, તમે 10-15 થ્રેડોમાં ડાયનેમિક સ્કેનર ચાલુ કરી શકો છો અને શું થાય છે તે જોઈ શકો છો, પરંતુ સામાન્ય રીતે, પ્રેક્ટિસ બતાવે છે તેમ, કંઈ સારું નથી.

થોડા સંસાધનો કે જેનો આપણે સામાન્ય રીતે ઉપયોગ કરીએ છીએ.

વર્થ હાઇલાઇટિંગ બર્પ સ્યુટ કોઈપણ સુરક્ષા વ્યાવસાયિક માટે "સ્વિસ છરી" છે. દરેક વ્યક્તિ તેનો ઉપયોગ કરે છે અને તે ખૂબ અનુકૂળ છે. એન્ટરપ્રાઇઝ એડિશનનું નવું ડેમો વર્ઝન હવે બહાર પાડવામાં આવ્યું છે. જો અગાઉ તે પ્લગઇન્સ સાથે એકલા ઉપયોગિતા હતી, તો હવે વિકાસકર્તાઓ આખરે એક મોટું સર્વર બનાવી રહ્યા છે જેમાંથી ઘણા એજન્ટોનું સંચાલન કરવું શક્ય બનશે. તે સરસ છે, હું તમને તેનો પ્રયાસ કરવાની ભલામણ કરું છું.

પ્રક્રિયા એકીકરણ

એકીકરણ ખૂબ સારું અને સરળ છે: સફળ ઇન્સ્ટોલેશન પછી સ્કેન શરૂ કરો સ્ટેન્ડ પર અરજીઓ અને સફળ એકીકરણ પરીક્ષણ પછી સ્કેનિંગ.

જો એકીકરણ કામ કરતું નથી અથવા ત્યાં સ્ટબ્સ અને મૉક ફંક્શન્સ છે, તો તે અર્થહીન અને નકામું છે - ભલે આપણે ગમે તે પેટર્ન મોકલીએ, સર્વર હજી પણ તે જ રીતે પ્રતિસાદ આપશે.

• આદર્શરીતે, એક અલગ ટેસ્ટ બેન્ચ.
• પરીક્ષણ કરતા પહેલા, લૉગિન ક્રમ લખો.
• વહીવટી તંત્રનું પરીક્ષણ માત્ર મેન્યુઅલ છે.

Процесс

સામાન્ય રીતે પ્રક્રિયા વિશે અને ખાસ કરીને દરેક ટૂલના કાર્ય વિશે થોડું સામાન્યીકરણ. બધી એપ્લિકેશનો અલગ-અલગ છે - એક ગતિશીલ વિશ્લેષણ સાથે વધુ સારી રીતે કાર્ય કરે છે, બીજું સ્થિર વિશ્લેષણ સાથે, ત્રીજું ઓપનસોર્સ વિશ્લેષણ સાથે, પેન્ટેસ્ટ્સ અથવા સામાન્ય રીતે કંઈક બીજું, ઉદાહરણ તરીકે, સાથેની ઘટનાઓ વાફ.

દરેક પ્રક્રિયાને નિયંત્રિત કરવાની જરૂર છે.

પ્રક્રિયા કેવી રીતે કાર્ય કરે છે અને તેને ક્યાં સુધારી શકાય છે તે સમજવા માટે, તમારે ઉત્પાદન મેટ્રિક્સ, ટૂલ્સમાંથી મેટ્રિક્સ અને ડિફેક્ટ ટ્રેકર્સ સહિતની દરેક વસ્તુમાંથી મેટ્રિક્સ એકત્રિત કરવાની જરૂર છે.

કોઈપણ માહિતી મદદરૂપ છે. આ અથવા તે સાધનનો ઉપયોગ ક્યાં વધુ સારી રીતે થાય છે તે વિવિધ વિભાગોમાં જોવાની જરૂર છે, જ્યાં પ્રક્રિયા ખાસ કરીને ક્ષીણ થઈ જાય છે. સમયના આધારે પ્રક્રિયામાં ક્યાં સુધારો કરવો તે જોવા માટે વિકાસ પ્રતિભાવ સમય જોવો યોગ્ય હોઈ શકે છે. વધુ ડેટા, ટોચના સ્તરથી દરેક પ્રક્રિયાની વિગતોમાં વધુ કટ બનાવી શકાય છે.

બધા સ્ટેટિક અને ડાયનેમિક વિશ્લેષકોના પોતાના API, તેમની પોતાની લોન્ચ પદ્ધતિઓ, સિદ્ધાંતો હોવાથી, કેટલાક પાસે શેડ્યુલર્સ છે, અન્ય પાસે નથી - અમે એક સાધન લખી રહ્યા છીએ AppSec ઓર્કેસ્ટ્રેટર, જે તમને ઉત્પાદનમાંથી સમગ્ર પ્રક્રિયામાં એક જ એન્ટ્રી પોઈન્ટ બનાવવા અને તેને એક બિંદુથી મેનેજ કરવાની મંજૂરી આપે છે.

મેનેજર્સ, ડેવલપર્સ અને સિક્યુરિટી એન્જિનિયર્સ પાસે એક એન્ટ્રી પોઈન્ટ હોય છે જ્યાંથી તેઓ જોઈ શકે છે કે શું ચાલી રહ્યું છે, સ્કેન ગોઠવી અને ચલાવી શકે છે, સ્કેન પરિણામો મેળવી શકે છે અને જરૂરિયાતો સબમિટ કરી શકે છે. અમે કાગળના ટુકડાઓથી દૂર જવાનો પ્રયાસ કરીએ છીએ, દરેક વસ્તુને માનવમાં અનુવાદિત કરવાનો પ્રયાસ કરીએ છીએ જેનો વિકાસ ઉપયોગ કરે છે - સ્થિતિ અને મેટ્રિક્સ સાથે સંગમ પરના પૃષ્ઠો, જીરામાં ખામીઓ અથવા વિવિધ ખામી ટ્રેકર્સમાં અથવા CI/CD માં સિંક્રનસ/અસિંક્રોનસ પ્રક્રિયામાં એમ્બેડિંગ.

કી ટેકવેઝ

સાધનો વાંધો નથી. પહેલા પ્રક્રિયા વિશે વિચારો, પછી સાધનોનો અમલ કરો. સાધનો સારા છે, પરંતુ ખર્ચાળ છે, તેથી તમે પ્રક્રિયા સાથે પ્રારંભ કરી શકો છો અને વિકાસ અને સુરક્ષા વચ્ચેની ક્રિયાપ્રતિક્રિયા અને સમજણને ફાઇન-ટ્યુન કરી શકો છો. સુરક્ષાના દૃષ્ટિકોણથી, સળંગ દરેક વસ્તુને "રોકવાની" જરૂર નથી. વિકાસના દૃષ્ટિકોણથી, જો ત્યાં કંઈક ઉચ્ચ મેગા સુપર ક્રિટિકલ હોય, તો તેને દૂર કરવું જોઈએ, અને સમસ્યાને બંધ ન કરવી જોઈએ. .

ઉત્પાદન ગુણવત્તા - સામાન્ય ધ્યેય સુરક્ષા અને વિકાસ બંને. અમે એક વસ્તુ કરીએ છીએ, અમે ખાતરી કરવાનો પ્રયાસ કરીએ છીએ કે બધું યોગ્ય રીતે કાર્ય કરે છે અને કોઈ પ્રતિષ્ઠિત જોખમો અને નાણાકીય નુકસાન નથી. તેથી જ અમે સંચાર સ્થાપિત કરવા અને ઉત્પાદનને વધુ સારું બનાવવા માટે DevSecOps, SecDevOps તરફના અભિગમને પ્રોત્સાહન આપીએ છીએ.

પહેલાથી જે છે તેની સાથે પ્રારંભ કરો: જરૂરિયાતો, આર્કિટેક્ચર, આંશિક તપાસ, તાલીમ, માર્ગદર્શિકા. તમામ પ્રોજેક્ટ પર તમામ પ્રેક્ટિસ તાત્કાલિક લાગુ કરવી જરૂરી નથી - પુનરાવર્તિત રીતે ખસેડો. ત્યાં કોઈ એક ધોરણ નથી પ્રયોગ અને વિવિધ અભિગમો અને ઉકેલોનો પ્રયાસ કરો.

IS ખામી અને કાર્યાત્મક ખામી વચ્ચે સમાન ચિહ્ન.

બધું સ્વચાલિત કરોતે ખસેડી રહ્યું છે. જે કંઈપણ ખસેડતું નથી, ખસેડતું અને સ્વચાલિત થાય છે. જો કંઈક હાથ દ્વારા કરવામાં આવે છે, તો આ પ્રક્રિયાનો સારો ભાગ નથી. કદાચ તે પણ પુનર્વિચાર અને સ્વચાલિત કરવા યોગ્ય છે.

જો IB ટીમનું કદ નાનું હોય તો - સુરક્ષા ચેમ્પિયન્સનો ઉપયોગ કરો.

કદાચ મેં જે વિશે વાત કરી છે તે તમને અનુકૂળ નહીં આવે અને તમે તમારી પોતાની કંઈક સાથે આવશો - અને તે સારું છે. પણ તમારી પ્રક્રિયાની જરૂરિયાતોને આધારે સાધનો પસંદ કરો. સમુદાય શું કહે છે કે આ સાધન ખરાબ છે અને આ સારું છે તે જોશો નહીં. કદાચ તે તમારા ઉત્પાદન પર બીજી રીતે હશે.

સાધન જરૂરિયાતો.

• લો ફોલ્સ પોઝિટિવ.
• પર્યાપ્ત વિશ્લેષણ સમય.
• ઉપયોગની સગવડ.
• એકીકરણની ઉપલબ્ધતા.
• પ્રોડક્ટ ડેવલપમેન્ટ રોડમેપને સમજવું.
• સાધનો કસ્ટમાઇઝ કરવાની ક્ષમતા.

DevOpsConf 2018માં યુરીના રિપોર્ટને શ્રેષ્ઠમાંના એક તરીકે પસંદ કરવામાં આવ્યો હતો. હજુ વધુ રસપ્રદ વિચારો અને વ્યવહારુ કિસ્સાઓથી પરિચિત થવા માટે, 27 અને 28 મેના રોજ Skolkovo પર આવો DevOpsConf અંદર તહેવાર RIT++. વધુ સારું, જો તમે તમારો અનુભવ શેર કરવા તૈયાર છો, તો પછી અરજી કરો 21મી એપ્રિલ સુધીમાં તમારો રિપોર્ટ સબમિટ કરો.

સોર્સ: www.habr.com