DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

எங்களிடம் 2 குறியீடு பகுப்பாய்விகள், 4 டைனமிக் சோதனைக் கருவிகள், எங்கள் சொந்த கைவினைப்பொருட்கள் மற்றும் 250 ஸ்கிரிப்ட்கள் இருந்தன. தற்போதைய செயல்பாட்டில் இவை அனைத்தும் தேவை என்று இல்லை, ஆனால் நீங்கள் DevSecOps ஐ செயல்படுத்த ஆரம்பித்தவுடன், நீங்கள் முடிவுக்கு செல்ல வேண்டும்.

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

மூல. பாத்திரத்தை உருவாக்கியவர்கள்: ஜஸ்டின் ரோய்லண்ட் மற்றும் டான் ஹார்மன்.

SecDevOps என்றால் என்ன? DevSecOps பற்றி என்ன? வேறுபாடுகள் என்ன? பயன்பாட்டு பாதுகாப்பு - அது எதைப் பற்றியது? உன்னதமான அணுகுமுறை ஏன் இனி வேலை செய்யாது? இந்தக் கேள்விகளுக்கெல்லாம் பதில் தெரியும் யூரி ஷபாலின் из வாள்மீன் பாதுகாப்பு. யூரி எல்லாவற்றிற்கும் விரிவாகப் பதிலளிப்பார் மற்றும் கிளாசிக்கல் அப்ளிகேஷன் செக்யூரிட்டி மாடலில் இருந்து DevSecOps செயல்முறைக்கு மாறுவதில் உள்ள சிக்கல்களை பகுப்பாய்வு செய்வார்: DevOps செயல்முறையில் பாதுகாப்பான மேம்பாட்டு செயல்முறையின் ஒருங்கிணைப்பை எவ்வாறு சரியாக அணுகுவது மற்றும் எதையும் உடைக்காமல், முக்கிய நிலைகளை எவ்வாறு கடப்பது பாதுகாப்பு சோதனை, என்ன கருவிகள் பயன்படுத்தப்படலாம் மற்றும் அவை என்ன வேறுபடுகின்றன மற்றும் ஆபத்துகளைத் தவிர்க்க அவற்றை எவ்வாறு சரியாகக் கட்டமைப்பது.


பேச்சாளர் பற்றி: யூரி ஷபாலின் - நிறுவனத்தில் தலைமை பாதுகாப்பு கட்டிடக் கலைஞர் வாள்மீன் பாதுகாப்பு. SSDL ஐ செயல்படுத்துவதற்கு பொறுப்பு, பயன்பாட்டு பகுப்பாய்வு கருவிகளை ஒரு ஒருங்கிணைந்த மேம்பாடு மற்றும் சோதனை சுற்றுச்சூழலுடன் ஒட்டுமொத்தமாக ஒருங்கிணைப்பதற்கு. தகவல் பாதுகாப்பில் 7 வருட அனுபவம். மென்பொருளை உருவாக்கி சேவைகளை வழங்கும் Alfa-Bank, Sberbank மற்றும் Positive Technologies ஆகிய நிறுவனங்களில் பணிபுரிந்தார். ZerONights, PHDays, RISSPA, OWASP ஆகிய சர்வதேச மாநாடுகளில் பேச்சாளர்.

பயன்பாட்டு பாதுகாப்பு: இது எதைப் பற்றியது?

பயன்பாட்டு பாதுகாப்பு - இது பயன்பாட்டுப் பாதுகாப்பிற்குப் பொறுப்பான பாதுகாப்புப் பிரிவு. இது உள்கட்டமைப்பு அல்லது நெட்வொர்க் பாதுகாப்பிற்குப் பொருந்தாது, மாறாக நாம் எழுதுவது மற்றும் டெவலப்பர்கள் என்ன வேலை செய்கிறார்கள் - இவை பயன்பாட்டின் குறைபாடுகள் மற்றும் பாதிப்புகள் ஆகும்.

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

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

பயன்பாட்டு பாதுகாப்பு மற்றும் SSDL ஆகியவை பொதுவாக நம்பப்படும் பாதிப்புகளைக் கண்டறிவதை நோக்கமாகக் கொண்டிருக்கவில்லை, ஆனால் அவை ஏற்படுவதைத் தடுக்கின்றன. காலப்போக்கில், மைக்ரோசாப்டின் நியமன அணுகுமுறை மேம்படுத்தப்பட்டு, மேம்படுத்தப்பட்டு, ஆழமான, விரிவான முழுக்குக்கு அறிமுகப்படுத்தப்பட்டது.

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

ஓபன்எஸ்ஏஎம்எம், பிஎஸ்ஐஎம்எம், ஓஒஏஎஸ்பி போன்ற பல்வேறு முறைகளில் நியதி SDLC மிகவும் விரிவாக உள்ளது. முறைகள் வேறுபட்டவை, ஆனால் பொதுவாக ஒரே மாதிரியானவை.

முதிர்வு மாதிரியில் பாதுகாப்பை உருவாக்குதல்

எனக்கு மிகவும் பிடிக்கும் BSIMM - முதிர்வு மாதிரியில் பாதுகாப்பை உருவாக்குதல். முறையின் அடிப்படையானது பயன்பாட்டு பாதுகாப்பு செயல்முறையை 4 களங்களாகப் பிரிப்பதாகும்: ஆளுமை, உளவுத்துறை, SSDL தொடுப்புள்ளிகள் மற்றும் வரிசைப்படுத்தல். ஒவ்வொரு டொமைனுக்கும் 12 நடைமுறைகள் உள்ளன, அவை 112 செயல்பாடுகளாக குறிப்பிடப்படுகின்றன.

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

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

ஏன் DevSecOps

DevOps என்பது ஒரு பொதுவான, பெரிய செயல்முறையாகும், இதில் பாதுகாப்பு கணக்கில் எடுத்துக்கொள்ளப்பட வேண்டும்.

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

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

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

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

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

DevSecOps க்கு மாறுதல்

பாதுகாப்பு மேம்பாட்டு வாழ்க்கைச் சுழற்சியில் மிக முக்கியமான சொல் "செயல்முறை". கருவிகளை வாங்குவது பற்றி சிந்திக்கும் முன் இதை நீங்கள் புரிந்து கொள்ள வேண்டும்.

DevOps செயல்பாட்டில் கருவிகளை இணைத்துக்கொள்வது மட்டும் போதாது - செயல்முறை பங்கேற்பாளர்களிடையே தொடர்பு மற்றும் புரிதல் முக்கியம்.

மக்கள் மிகவும் முக்கியம், கருவிகள் அல்ல.

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

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

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

ஏற்கனவே பயன்பாட்டில் உள்ளவற்றிலிருந்து தொடங்கவும்

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

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

- இப்போது, ​​குறிப்புகளில் எங்கோ இந்த ஆவணம் இருக்கும் பாதை இருந்தது.

இதன் விளைவாக, ஒரு வாரம் கழித்து எங்களுக்கு ஆவணம் கிடைத்தது.

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

உங்களிடம் ஏற்கனவே உள்ளதை மறுவடிவமைத்து, தொடங்குவதற்கு அதைப் பயன்படுத்துவது எளிது.

பாதுகாப்பு சாம்பியன்களைப் பயன்படுத்தவும்

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

உங்கள் தயாரிப்பின் பாதுகாப்பில் ஆர்வமுள்ள மேம்பாட்டுக் குழுவில் உள்ளவர்கள் பாதுகாப்பு சாம்பியன்கள்.

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

செக்யூரிட்டி சாம்பியன் என்பது டெவலப்மென்ட் டீமில் ஒரு நுழைவு புள்ளி மற்றும் ஒரு பாதுகாப்பு சுவிசேஷகர் ஒருவராக உருட்டப்பட்டார்.

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

- மேலும் நீங்கள் யார்? நான் உன்னை முதல் முறை பார்க்கிறேன். என்னுடன் எல்லாம் நன்றாக இருக்கிறது - எனது மூத்த நண்பர் குறியீடு மதிப்பாய்வில் எனக்கு “விண்ணப்பிக்கவும்” கொடுத்தார், நாங்கள் தொடர்கிறோம்!

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

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

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

சோதனை நிலைகள்

முன்னுதாரணம் 20 முதல் 80 வரை 20% முயற்சி 80% முடிவுகளைத் தருகிறது என்று கூறுகிறார். இந்த 20% என்பது பயன்பாட்டு பகுப்பாய்வு நடைமுறைகள் ஆகும், இது தானியங்கு மற்றும் இருக்க வேண்டும். அத்தகைய நடவடிக்கைகளின் எடுத்துக்காட்டுகள் நிலையான பகுப்பாய்வு - SAST, மாறும் பகுப்பாய்வு - DAST и திறந்த மூலக் கட்டுப்பாடு. செயல்பாடுகள் மற்றும் கருவிகள், செயல்பாட்டில் அவற்றை அறிமுகப்படுத்தும்போது நாம் வழக்கமாக என்ன அம்சங்களை எதிர்கொள்கிறோம், அதை எவ்வாறு சரியாகச் செய்வது என்பது பற்றி மேலும் விரிவாக நான் உங்களுக்குச் சொல்கிறேன்.

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

கருவிகளின் முக்கிய சிக்கல்கள்

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

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

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

ஏற்கனவே உள்ள கருவிகளுடன் ஒருங்கிணைப்பு இல்லை. நீங்கள் ஏற்கனவே பயன்படுத்தியவற்றுடன் ஒருங்கிணைப்புகளின் அடிப்படையில் கருவிகளைப் பாருங்கள். எடுத்துக்காட்டாக, உங்களிடம் Jenkins அல்லது TeamCity இருந்தால், இந்த மென்பொருளுடன் கருவிகளின் ஒருங்கிணைப்பைச் சரிபார்க்கவும், நீங்கள் பயன்படுத்தாத GitLab CI உடன் அல்ல.

தனிப்பயனாக்கலின் பற்றாக்குறை அல்லது அதிகப்படியான சிக்கலானது. ஒரு கருவியில் API இல்லை என்றால், அது ஏன் தேவைப்படுகிறது? இடைமுகத்தில் செய்யக்கூடிய அனைத்தும் API மூலம் கிடைக்க வேண்டும். வெறுமனே, கருவியானது காசோலைகளைத் தனிப்பயனாக்கும் திறனைக் கொண்டிருக்க வேண்டும்.

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

செயல்முறை அம்சங்கள்

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

வளர்ச்சியைத் தவறவிடாமல் மற்றும் காலக்கெடுவை வெளியிட, உருவாக்கவும் வெவ்வேறு விதிகள் மற்றும் வேறுபட்டது ஷோ ஸ்டாப்பர்கள் - பாதிப்புகளின் முன்னிலையில் கட்டுமான செயல்முறையை நிறுத்துவதற்கான அளவுகோல்கள் - வெவ்வேறு சூழல்களுக்கு. எடுத்துக்காட்டாக, தற்போதைய கிளை டெவலப்மென்ட் ஸ்டாண்ட் அல்லது UAT க்கு செல்கிறது என்பதை நாங்கள் புரிந்துகொள்கிறோம், அதாவது நாங்கள் நிறுத்த வேண்டாம்:

"உங்களுக்கு இங்கே பாதிப்புகள் உள்ளன, நீங்கள் மேலும் எங்கும் செல்ல மாட்டீர்கள்!"

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

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

- நண்பர்களே, உங்களுக்கு பிரச்சினைகள் உள்ளன, தயவுசெய்து அவற்றில் கவனம் செலுத்துங்கள்.

UAT கட்டத்தில் நாங்கள் மீண்டும் பாதிப்புகள் பற்றிய எச்சரிக்கைகளைக் காட்டுகிறோம், வெளியீட்டு கட்டத்தில் நாங்கள் சொல்கிறோம்:

- நண்பர்களே, நாங்கள் உங்களை பலமுறை எச்சரித்தோம், நீங்கள் எதுவும் செய்யவில்லை - இதை நாங்கள் உங்களை வெளியேற்ற மாட்டோம்.

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

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

அனைத்து மென்பொருள் தர பிரச்சனைகளும் பாதுகாப்பு பிரச்சனைகள் அல்ல. ஆனால் அனைத்து பாதுகாப்பு சிக்கல்களும் மென்பொருள் தரத்துடன் தொடர்புடையவை. ஷெரிப் மன்சூர், எக்ஸ்பீடியா.

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

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

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

என்ன செய்ய? நாங்கள் கண்டறிந்த உறுதிப்படுத்தப்பட்ட குறைபாடுகளை வளர்ச்சிக்கு வசதியான வடிவமாக மாற்றுகிறோம், எடுத்துக்காட்டாக, அவற்றை ஜிராவில் பின்னிணைப்பில் வைக்கிறோம். செயல்பாட்டுக் குறைபாடுகள் மற்றும் சோதனைக் குறைபாடுகளுடன், குறைபாடுகளுக்கு முன்னுரிமை அளித்து, முன்னுரிமையின் வரிசையில் அவற்றை நீக்குகிறோம்.

நிலையான பகுப்பாய்வு - SAST

இது பாதிப்புகளுக்கான குறியீடு பகுப்பாய்வு ஆகும்., ஆனால் இது SonarQube போன்றது அல்ல. நாங்கள் வடிவங்கள் அல்லது பாணியை மட்டும் சரிபார்க்கவில்லை. பகுப்பாய்வில் பல அணுகுமுறைகள் பயன்படுத்தப்படுகின்றன: பாதிப்பு மரத்தின் படி, படி தரவுப்பாய்வு, கட்டமைப்பு கோப்புகளை பகுப்பாய்வு செய்வதன் மூலம். இது குறியீட்டைப் பற்றியது.

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

Минусы - இது தேவையான மொழிகளுக்கான ஆதரவு இல்லாதது.

தேவையான ஒருங்கிணைப்புகள், எனது அகநிலை கருத்தில் கருவிகளில் எது இருக்க வேண்டும்:

  • ஒருங்கிணைப்பு கருவி: ஜென்கின்ஸ், டீம்சிட்டி மற்றும் கிட்லாப் சிஐ.
  • வளர்ச்சி சூழல்: Intellij IDEA, விஷுவல் ஸ்டுடியோ. ஒரு டெவலப்பருக்கு இன்னும் மனப்பாடம் செய்ய வேண்டிய புரிந்துகொள்ள முடியாத இடைமுகத்தை வழிநடத்தாமல் இருப்பது மிகவும் வசதியானது, ஆனால் அவர் தனது சொந்த வளர்ச்சி சூழலில் பணியிடத்தில் கண்டறிந்த அனைத்து தேவையான ஒருங்கிணைப்புகள் மற்றும் பாதிப்புகளைப் பார்ப்பது மிகவும் வசதியானது.
  • குறியீடு மதிப்பாய்வு: SonarQube மற்றும் கைமுறை மதிப்பாய்வு.
  • குறைபாடு கண்காணிப்பாளர்கள்: ஜிரா மற்றும் பக்ஜில்லா.

நிலையான பகுப்பாய்வின் சில சிறந்த பிரதிநிதிகளை படம் காட்டுகிறது.

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

இது முக்கியமான கருவிகள் அல்ல, ஆனால் செயல்முறை, எனவே செயல்முறையை சோதிப்பதற்கு நல்ல திறந்த மூல தீர்வுகள் உள்ளன.

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

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

உங்கள் பயணத்தின் தொடக்கத்தில் இருந்தால், எதுவும் இல்லை என்றால் இதை எப்படி ஒருங்கிணைக்க முடியும்: சிஐ இல்லை, ஜென்கின்ஸ் இல்லை, டீம்சிட்டி இல்லை? செயல்பாட்டில் ஒருங்கிணைப்பதைக் கருத்தில் கொள்வோம்.

CVS நிலை ஒருங்கிணைப்பு

உங்களிடம் Bitbucket அல்லது GitLab இருந்தால், நீங்கள் மட்டத்தில் ஒருங்கிணைக்கலாம் ஒரே நேரத்தில் பதிப்புகள் அமைப்பு.

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

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

குறியீடு மதிப்பாய்வு அமைப்புடன் ஒருங்கிணைப்பு

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

SonarQube உடன் ஒருங்கிணைப்பு

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

CI மட்டத்தில் ஒருங்கிணைப்பு

இங்கே எல்லாம் மிகவும் எளிமையானது:

  • தன்னியக்க சோதனைகளுக்கு இணையாக, அலகு சோதனைகள்.
  • வளர்ச்சி நிலைகள் மூலம் பிரிவு: dev, test, prod. வெவ்வேறு விதிகள் அல்லது வெவ்வேறு தோல்வி நிலைமைகள் சேர்க்கப்படலாம்: சட்டசபையை நிறுத்துங்கள், சட்டசபையை நிறுத்த வேண்டாம்.
  • ஒத்திசைவு/ஒத்திசைவற்ற வெளியீடு. பாதுகாப்பு சோதனைகள் முடிவடைகிறதா இல்லையா என்று நாங்கள் காத்திருக்கிறோம். அதாவது, நாங்கள் அவற்றைத் தொடங்கினோம், பின்னர் எல்லாம் நல்லது அல்லது கெட்டது என்ற நிலையைப் பெறுகிறோம்.

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

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

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

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

DevSecOps பற்றிய பயம் மற்றும் வெறுப்புநாங்கள் SonarQube உடன் ஒருங்கிணைக்கிறோம் - சொருகி நிறுவப்பட்டுள்ளது, எல்லாம் மிகவும் வசதியானது மற்றும் குளிர்ச்சியானது.

வளர்ச்சி சூழலுடன் ஒருங்கிணைப்பு

ஒருங்கிணைப்பு விருப்பங்கள்:

  • உறுதி செய்வதற்கு முன் வளர்ச்சி சூழலில் இருந்து ஸ்கேன் இயக்குதல்.
  • முடிவுகளைக் காண்க.
  • முடிவுகளின் பகுப்பாய்வு.
  • சேவையகத்துடன் ஒத்திசைவு.

இது சர்வரில் இருந்து முடிவுகளைப் பெறுவது போல் தெரிகிறது.

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

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

திறந்த மூல

இது எனக்கு மிகவும் பிடித்த தலைப்பு. எல்லோரும் ஓப்பன் சோர்ஸ் நூலகங்களைப் பயன்படுத்துகிறார்கள் - எல்லாவற்றையும் ஏற்கனவே செயல்படுத்திய ஒரு ஆயத்த நூலகத்தை நீங்கள் எடுக்கும்போது ஊன்றுகோல் மற்றும் சைக்கிள்களை ஏன் எழுத வேண்டும்?

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

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

திறந்த மூல பகுப்பாய்வு - OSA

கருவி மூன்று பெரிய நிலைகளை உள்ளடக்கியது.

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

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

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

அம்சங்கள்:

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

திறந்த மூல பகுப்பாய்வில் ஈடுபட்டுள்ள தொழில்துறை தலைவர்களின் சில எடுத்துக்காட்டுகள்.

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு
இது தான் இலவசம் சார்பு-சரிபார்ப்பு OWASP இலிருந்து. முதல் கட்டங்களில் நீங்கள் அதை இயக்கலாம், அது எவ்வாறு செயல்படுகிறது மற்றும் அது எதை ஆதரிக்கிறது என்பதைப் பார்க்கவும். அடிப்படையில், இவை அனைத்தும் கிளவுட் தயாரிப்புகள் அல்லது வளாகத்தில் உள்ளன, ஆனால் அவற்றின் தளத்திற்குப் பின்னால் அவை இன்னும் இணையத்திற்கு அனுப்பப்படுகின்றன. அவர்கள் உங்கள் நூலகங்களை அனுப்பவில்லை, ஆனால் ஹாஷ்கள் அல்லது அவற்றின் சொந்த மதிப்புகளை அவர்கள் கணக்கிடுகிறார்கள், மேலும் பாதிப்புகள் இருப்பதைப் பற்றிய தகவலைப் பெற தங்கள் சேவையகத்திற்கு கைரேகைகளை அனுப்புகிறார்கள்.

செயல்முறை ஒருங்கிணைப்பு

நூலகங்களின் சுற்றளவு கட்டுப்பாடு, இவை வெளிப்புற மூலங்களிலிருந்து பதிவிறக்கம் செய்யப்படுகின்றன. எங்களிடம் வெளிப்புற மற்றும் உள் களஞ்சியங்கள் உள்ளன. எடுத்துக்காட்டாக, Event Central Nexusஐ இயக்குகிறது, மேலும் எங்கள் களஞ்சியத்தில் "முக்கியமான" அல்லது "உயர்" அந்தஸ்துடன் பாதிப்புகள் எதுவும் இல்லை என்பதை உறுதிப்படுத்த விரும்புகிறோம். Nexus Firewall Lifecycle கருவியைப் பயன்படுத்தி நீங்கள் ப்ராக்ஸியை உள்ளமைக்கலாம், இதனால் இத்தகைய பாதிப்புகள் துண்டிக்கப்பட்டு உள் களஞ்சியத்தில் முடிவடையாது.

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

கலைப்பொருட்களுடன் ஒருங்கிணைப்பு: Nexus மற்றும் JFrog.

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

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

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

எங்களிடம் உள்ளது பொது கூறு களஞ்சியங்கள் - வெளியே சில கருவிகள், மற்றும் எங்கள் உள் களஞ்சியம். இது நம்பகமான கூறுகளை மட்டுமே கொண்டிருக்க வேண்டும் என்று நாங்கள் விரும்புகிறோம். ஒரு கோரிக்கையை ப்ராக்ஸி செய்யும் போது, ​​பதிவிறக்கம் செய்யப்பட்ட நூலகத்தில் பாதிப்புகள் இல்லை என்பதை நாங்கள் சரிபார்க்கிறோம். நாங்கள் அமைக்கும் சில கொள்கைகளுக்கு உட்பட்டு, மேம்பாட்டுடன் அவசியம் ஒருங்கிணைக்கப்பட்டால், நாங்கள் அதைப் பதிவேற்ற மாட்டோம், மேலும் மற்றொரு பதிப்பைப் பயன்படுத்தும்படி அறிவுறுத்தப்படுகிறோம். அதன்படி, நூலகத்தில் மிகவும் முக்கியமான மற்றும் மோசமான ஒன்று இருந்தால், டெவலப்பர் நிறுவல் கட்டத்தில் நூலகத்தைப் பெற மாட்டார் - அவர் அதிக அல்லது குறைந்த பதிப்பைப் பயன்படுத்தட்டும்.

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

டைனமிக் அனாலிசிஸ் - DAST

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

திறந்த மூலத்தில் டெம்ப்ளேட் பாதிப்புகளை சரிபார்க்க அதே அமைப்பு உங்களை அனுமதிக்கிறது. எந்த ஓப்பன் சோர்ஸைப் பயன்படுத்துகிறோம் என்பதை DAST அறியாததால், அது "தீங்கிழைக்கும்" வடிவங்களை எறிந்து, சர்வரின் பதில்களை பகுப்பாய்வு செய்கிறது:

- ஆமாம், இங்கே ஒரு சீரழிவு பிரச்சனை உள்ளது, ஆனால் இங்கே இல்லை.

இதில் பெரிய ஆபத்துகள் உள்ளன, ஏனென்றால் சோதனையாளர்கள் பணிபுரியும் அதே பெஞ்சில் நீங்கள் இந்த பாதுகாப்பு சோதனையை நடத்தினால், விரும்பத்தகாத விஷயங்கள் நடக்கலாம்.

  • பயன்பாட்டு சர்வர் நெட்வொர்க்கில் அதிக சுமை.
  • ஒருங்கிணைப்புகள் இல்லை.
  • பகுப்பாய்வு செய்யப்பட்ட பயன்பாட்டின் அமைப்புகளை மாற்றும் திறன்.
  • தேவையான தொழில்நுட்பங்களுக்கு ஆதரவு இல்லை.
  • அமைப்பதில் சிரமம்.

நாங்கள் இறுதியாக AppScan ஐ அறிமுகப்படுத்தியபோது எங்களுக்கு ஒரு சூழ்நிலை இருந்தது: பயன்பாட்டிற்கான அணுகலைப் பெற நாங்கள் நீண்ட நேரம் செலவிட்டோம், 3 கணக்குகளைப் பெற்றோம் மற்றும் மகிழ்ச்சியாக இருந்தோம் - இறுதியாக எல்லாவற்றையும் சரிபார்ப்போம்! நாங்கள் ஸ்கேன் ஒன்றைத் தொடங்கினோம், ஆப்ஸ்கான் செய்த முதல் விஷயம், நிர்வாகப் பலகத்திற்குள் சென்று, அனைத்து பொத்தான்களையும் துளைத்து, தரவின் பாதியை மாற்றி, பின்னர் அதன் சேவையகத்தை முழுவதுமாக அழிக்கவும். அஞ்சல் வடிவம்-கோரிக்கைகளை. சோதனையுடன் வளர்ச்சி கூறினார்:

- நண்பர்களே, நீங்கள் என்னை கேலி செய்கிறீர்களா?! நாங்கள் உங்களுக்கு கணக்குகளை வழங்கினோம், நீங்கள் ஒரு நிலைப்பாட்டை அமைத்தீர்கள்!

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

சுமை சோதனையின் அனலாக்ஸாக இதைப் பயன்படுத்தலாம் என்பதைக் கருத்தில் கொள்வது மதிப்பு. முதல் கட்டத்தில், நீங்கள் 10-15 இழைகள் கொண்ட டைனமிக் ஸ்கேனரை இயக்கலாம் மற்றும் என்ன நடக்கிறது என்பதைப் பார்க்கலாம், ஆனால் வழக்கமாக, நடைமுறையில் காண்பிக்கிறபடி, எதுவும் நன்றாக இல்லை.

நாம் வழக்கமாகப் பயன்படுத்தும் சில ஆதாரங்கள்.

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

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

செயல்முறை ஒருங்கிணைப்பு

ஒருங்கிணைப்பு நன்றாகவும் எளிமையாகவும் நடக்கிறது: வெற்றிகரமான நிறுவலுக்குப் பிறகு ஸ்கேன் செய்யத் தொடங்குங்கள் நிலைப்பாட்டிற்கான விண்ணப்பங்கள் மற்றும் வெற்றிகரமான ஒருங்கிணைப்பு சோதனைக்குப் பிறகு ஸ்கேன் செய்கிறது.

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

  • வெறுமனே, ஒரு தனி சோதனை நிலைப்பாடு.
  • சோதனைக்கு முன், உள்நுழைவு வரிசையை எழுதுங்கள்.
  • நிர்வாக அமைப்பின் சோதனை கைமுறையாக மட்டுமே உள்ளது.

செயல்முறை

பொதுவாக செயல்முறை மற்றும் குறிப்பாக ஒவ்வொரு கருவியின் வேலை பற்றியும் கொஞ்சம் பொதுவானது. எல்லா பயன்பாடுகளும் வேறுபட்டவை - ஒன்று டைனமிக் பகுப்பாய்வில் சிறப்பாக செயல்படுகிறது, மற்றொன்று நிலையான பகுப்பாய்வுடன், மூன்றாவது ஓபன்சோர்ஸ் பகுப்பாய்வு, பென்டெஸ்ட்கள் அல்லது வேறு ஏதாவது, எடுத்துக்காட்டாக, நிகழ்வுகளுடன் Waf.

ஒவ்வொரு செயல்முறைக்கும் கட்டுப்பாடு தேவை.

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

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

DevSecOps பற்றிய பயம் மற்றும் வெறுப்பு

அனைத்து நிலையான மற்றும் டைனமிக் பகுப்பாய்விகளும் அவற்றின் சொந்த ஏபிஐகள், அவற்றின் சொந்த வெளியீட்டு முறைகள், கொள்கைகள், சிலவற்றில் திட்டமிடுபவர்கள் உள்ளனர், மற்றவர்களுக்கு இல்லை - நாங்கள் ஒரு கருவியை எழுதுகிறோம். AppSec ஆர்கெஸ்ட்ரேட்டர், இது தயாரிப்பிலிருந்து முழு செயல்முறையிலும் ஒரு நுழைவுப் புள்ளியை உருவாக்கி அதை ஒரு புள்ளியில் இருந்து நிர்வகிக்க உங்களை அனுமதிக்கிறது.

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

முக்கிய எடுத்துக்காட்டுகள்

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

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

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

தகவல் பாதுகாப்பு குறைபாடுகள் மற்றும் செயல்பாட்டு குறைபாடுகள் இடையே சமமான அடையாளம் உள்ளது.

எல்லாவற்றையும் தானியங்குபடுத்துங்கள்என்று நகரும். எது நகரவில்லையோ, அதை நகர்த்தி தானியக்கமாக்குங்கள். கையால் ஏதாவது செய்தால், அது செயல்பாட்டின் ஒரு நல்ல பகுதியாக இருக்காது. ஒருவேளை அதை மதிப்பாய்வு செய்து அதை தானியக்கமாக்குவது மதிப்புக்குரியது.

IS குழுவின் அளவு சிறியதாக இருந்தால் - பாதுகாப்பு சாம்பியன்களைப் பயன்படுத்தவும்.

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

கருவிகளுக்கான தேவைகள்.

  • குறைந்த நிலை தவறான நேர்மறை.
  • போதுமான பகுப்பாய்வு நேரம்.
  • பயன்பாட்டின் வசதி.
  • ஒருங்கிணைப்புகளின் கிடைக்கும் தன்மை.
  • தயாரிப்பு மேம்பாட்டிற்கான வரைபடத்தைப் புரிந்துகொள்வது.
  • தனிப்பயனாக்கும் கருவிகளின் சாத்தியம்.

யூரியின் அறிக்கை DevOpsConf 2018 இல் சிறந்த ஒன்றாகத் தேர்ந்தெடுக்கப்பட்டது. இன்னும் சுவாரஸ்யமான யோசனைகள் மற்றும் நடைமுறை நிகழ்வுகளைப் பற்றி தெரிந்துகொள்ள, மே 27 மற்றும் 28 அன்று Skolkovo க்கு வாருங்கள் DevOpsConf உள்ளே திருவிழா RIT++. இன்னும் சிறப்பாக, உங்கள் அனுபவத்தைப் பகிர்ந்து கொள்ள நீங்கள் தயாராக இருந்தால், பிறகு விண்ணப்பிக்க ஏப்ரல் 21 வரை அறிக்கைக்கு.

ஆதாரம்: www.habr.com

கருத்தைச் சேர்