DevSecOps ची भीती आणि तिरस्कार

आमच्याकडे 2 कोड विश्लेषक, 4 डायनॅमिक चाचणी साधने, आमची स्वतःची हस्तकला आणि 250 स्क्रिप्ट्स होत्या. सध्याच्या प्रक्रियेत हे सर्व आवश्यक आहे असे नाही, परंतु एकदा तुम्ही DevSecOps लागू करणे सुरू केले की तुम्हाला शेवटपर्यंत जावे लागेल.

स्त्रोत. पात्र निर्माते: जस्टिन रोयलँड आणि डॅन हार्मन.

SecDevOps म्हणजे काय? DevSecOps बद्दल काय? फरक काय आहेत? ऍप्लिकेशन सुरक्षा - ते कशाबद्दल आहे? क्लासिक दृष्टीकोन आता का काम करत नाही? या सर्व प्रश्नांची उत्तरे माहीत आहेत युरी शाबालिन पासून स्वॉर्डफिश सुरक्षा. युरी प्रत्येक गोष्टीची तपशीलवार उत्तरे देईल आणि शास्त्रीय ऍप्लिकेशन सिक्युरिटी मॉडेलपासून DevSecOps प्रक्रियेत संक्रमणाच्या समस्यांचे विश्लेषण करेल: DevOps प्रक्रियेमध्ये सुरक्षित विकास प्रक्रियेच्या एकत्रीकरणाकडे योग्य प्रकारे कसे जायचे आणि काहीही खंडित करू नये, मुख्य टप्प्यातून कसे जायचे सुरक्षा चाचणी, कोणती साधने वापरली जाऊ शकतात आणि ते काय वेगळे आहेत आणि अडचणी टाळण्यासाठी त्यांना योग्यरित्या कसे कॉन्फिगर करावे.

स्पीकर बद्दल: युरी शाबालिन - कंपनीत मुख्य सुरक्षा आर्किटेक्ट स्वॉर्डफिश सुरक्षा. एसएसडीएलच्या अंमलबजावणीसाठी, ऍप्लिकेशन विश्लेषण साधनांच्या एकत्रित विकास आणि चाचणी परिसंस्थेमध्ये एकत्रित करण्यासाठी जबाबदार. माहिती सुरक्षेचा 7 वर्षांचा अनुभव. अल्फा-बँक, Sberbank आणि पॉझिटिव्ह टेक्नॉलॉजीज येथे काम केले, जे सॉफ्टवेअर विकसित करते आणि सेवा प्रदान करते. ZerONights, PHDays, RISSPA, OWASP या आंतरराष्ट्रीय परिषदांमध्ये स्पीकर.

ऍप्लिकेशन सुरक्षा: ते कशाबद्दल आहे?

अनुप्रयोग सुरक्षा - हा सुरक्षा विभाग आहे जो अनुप्रयोग सुरक्षिततेसाठी जबाबदार आहे. हे इन्फ्रास्ट्रक्चर किंवा नेटवर्क सुरक्षेला लागू होत नाही, तर आम्ही काय लिहितो आणि विकासक कशावर काम करतो यावर लागू होत नाही - या अनुप्रयोगाच्याच कमतरता आणि भेद्यता आहेत.

दिशानिर्देश SDL किंवा SDLC - सुरक्षा विकास जीवनचक्र - मायक्रोसॉफ्टने विकसित केले आहे. आकृती कॅनोनिकल SDLC मॉडेल दर्शवते, ज्याचे मुख्य कार्य विकासाच्या प्रत्येक टप्प्यावर, आवश्यकतांपासून प्रकाशन आणि उत्पादनापर्यंत सुरक्षिततेचा सहभाग आहे. मायक्रोसॉफ्टला लक्षात आले की उद्योगात बरेच बग आहेत, त्यापैकी बरेच आहेत आणि त्याबद्दल काहीतरी केले पाहिजे आणि त्यांनी हा दृष्टिकोन प्रस्तावित केला, जो प्रामाणिक झाला आहे.

ऍप्लिकेशन सिक्युरिटी आणि SSDL चे उद्दिष्ट असुरक्षितता शोधणे नाही, जसे सामान्यतः मानले जाते, परंतु त्यांच्या घटना रोखणे. कालांतराने, मायक्रोसॉफ्टचा कॅनॉनिकल दृष्टीकोन सुधारला गेला आहे, विकसित केला गेला आहे आणि सखोल, अधिक तपशीलवार गोतावळ्यात आणला गेला आहे.

कॅनोनिकल SDLC विविध पद्धतींमध्ये अत्यंत तपशीलवार आहे - OpenSAMM, BSIMM, OWASP. पद्धती भिन्न आहेत, परंतु सामान्यतः समान आहेत.

परिपक्वता मॉडेलमध्ये सुरक्षा निर्माण करणे

मला ते सर्वात जास्त आवडते BSIMM - परिपक्वता मॉडेलमध्ये सुरक्षा निर्माण करणे. कार्यपद्धतीचा आधार म्हणजे ऍप्लिकेशन सिक्युरिटी प्रक्रियेचे 4 डोमेनमध्ये विभाजन करणे: गव्हर्नन्स, इंटेलिजन्स, SSDL टचपॉइंट्स आणि डिप्लॉयमेंट. प्रत्येक डोमेनमध्ये 12 पद्धती आहेत, ज्या 112 क्रियाकलाप म्हणून दर्शविल्या जातात.

प्रत्येकी 112 उपक्रम आहेत परिपक्वतेचे 3 स्तर: नवशिक्या, मध्यवर्ती आणि प्रगत. तुम्ही विभागानुसार सर्व 12 सराव विभागांचा अभ्यास करू शकता, तुमच्यासाठी महत्त्वाच्या असलेल्या गोष्टी निवडू शकता, त्यांची अंमलबजावणी कशी करायची ते समजून घ्या आणि हळूहळू घटक जोडू शकता, उदाहरणार्थ, स्थिर आणि डायनॅमिक कोड विश्लेषण किंवा कोड पुनरावलोकन. निवडलेल्या क्रियाकलापांच्या अंमलबजावणीचा एक भाग म्हणून आपण एक योजना लिहा आणि शांतपणे त्यानुसार कार्य करा.

DevSecOps का

DevOps ही एक सामान्य, मोठी प्रक्रिया आहे ज्यामध्ये सुरक्षा विचारात घेणे आवश्यक आहे.

मूलतः DevOps सुरक्षा तपासण्यांचा समावेश आहे. सराव मध्ये, सुरक्षा संघांची संख्या आतापेक्षा खूपच कमी होती आणि त्यांनी प्रक्रियेत सहभागी म्हणून नाही तर नियंत्रण आणि पर्यवेक्षी संस्था म्हणून काम केले जे त्यावर आवश्यकता लादते आणि प्रकाशनाच्या शेवटी उत्पादनाची गुणवत्ता तपासते. हा एक उत्कृष्ट दृष्टीकोन आहे ज्यामध्ये सुरक्षा संघ विकासापासून भिंतीच्या मागे होते आणि प्रक्रियेत सहभागी झाले नाहीत.

मुख्य समस्या ही आहे की माहिती सुरक्षा ही विकासापासून वेगळी आहे. सहसा हे काही प्रकारचे माहिती सुरक्षा सर्किट असते आणि त्यात 2-3 मोठी आणि महाग साधने असतात. दर सहा महिन्यांनी एकदा, तपासणे आवश्यक असलेला स्त्रोत कोड किंवा अनुप्रयोग येतो आणि वर्षातून एकदा ते तयार केले जातात पेंटेस्ट. हे सर्व या वस्तुस्थितीकडे नेत आहे की उद्योगासाठी रिलीजची तारीख उशीर झाली आहे आणि विकसकाला स्वयंचलित साधनांमधून मोठ्या संख्येने भेद्यतेचा सामना करावा लागतो. हे सर्व वेगळे करणे आणि दुरुस्त करणे अशक्य आहे, कारण मागील सहा महिन्यांचे निकाल लावले गेले नाहीत, परंतु येथे एक नवीन बॅच आहे.

आमच्या कंपनीच्या कार्यादरम्यान, आम्ही पाहतो की सर्व क्षेत्रे आणि उद्योगांमधील सुरक्षिततेला हे समजते की एकाच चाकावर विकासाला पकडण्याची आणि फिरण्याची वेळ आली आहे - मध्ये चपळ. DevSecOps प्रतिमान चपळ विकास कार्यपद्धती, अंमलबजावणी, समर्थन आणि प्रत्येक प्रकाशन आणि पुनरावृत्तीमध्ये सहभागासह पूर्णपणे फिट आहे.

DevSecOps मध्ये संक्रमण

सिक्युरिटी डेव्हलपमेंट लाईफसायकलमधील सर्वात महत्त्वाचा शब्द आहे "प्रक्रिया". आपण साधने खरेदी करण्याचा विचार करण्यापूर्वी आपण हे समजून घेणे आवश्यक आहे.

DevOps प्रक्रियेत साधने समाविष्ट करणे पुरेसे नाही—प्रक्रियेतील सहभागींमधील संवाद आणि समजून घेणे महत्त्वाचे आहे.

लोक जास्त महत्वाचे आहेत, साधने नाहीत.

बर्‍याचदा, सुरक्षित विकास प्रक्रियेसाठी नियोजन हे साधन निवडण्यापासून आणि खरेदीपासून सुरू होते आणि सध्याच्या प्रक्रियेमध्ये साधन समाकलित करण्याच्या प्रयत्नांसह समाप्त होते, जे प्रयत्न राहतील. यामुळे दुर्दैवी परिणाम होतात, कारण सर्व साधनांची स्वतःची वैशिष्ट्ये आणि मर्यादा असतात.

जेव्हा सुरक्षा विभागाने विस्तृत क्षमता असलेले एक चांगले, महाग साधन निवडले आणि ते प्रक्रियेमध्ये समाकलित करण्यासाठी विकसकांकडे आले तेव्हा एक सामान्य प्रकरण आहे. परंतु ते कार्य करत नाही - प्रक्रियेची रचना अशा प्रकारे केली जाते की आधीच खरेदी केलेल्या साधनाच्या मर्यादा सध्याच्या प्रतिमानात बसत नाहीत.

प्रथम, तुम्हाला कोणता परिणाम हवा आहे आणि प्रक्रिया कशी दिसेल याचे वर्णन करा. हे प्रक्रियेतील साधन आणि सुरक्षिततेच्या भूमिका समजून घेण्यास मदत करेल.

आधीपासून वापरात असलेल्यापासून सुरुवात करा

महाग साधने खरेदी करण्यापूर्वी, आपल्याकडे आधीपासूनच काय आहे ते पहा. प्रत्येक कंपनीला विकासासाठी सुरक्षा आवश्यकता असतात, तपासण्या आहेत, पेंटेस्ट आहेत - हे सर्व प्रत्येकासाठी समजण्यायोग्य आणि सोयीस्कर स्वरूपात का बदलत नाही?

सामान्यत: आवश्यकता कागदी ताल्मुड असते जी शेल्फवर असते. आम्ही प्रक्रिया पाहण्यासाठी एका कंपनीकडे आलो आणि सॉफ्टवेअरसाठी सुरक्षा आवश्यकता पाहण्यास सांगितले तेव्हा एक प्रकरण होते. ज्या तज्ञाने हे हाताळले त्यांनी शोधण्यात बराच वेळ घालवला:

- आता, नोट्समध्ये कुठेतरी एक मार्ग होता जिथे हा दस्तऐवज आहे.

परिणामी, आम्हाला एका आठवड्यानंतर दस्तऐवज प्राप्त झाले.

आवश्यकता, तपासण्या आणि इतर गोष्टींसाठी, वर एक पृष्ठ तयार करा उदा. संगम - हे प्रत्येकासाठी सोयीचे आहे.

तुमच्याकडे आधीपासून जे आहे ते रीफॉर्मेट करणे आणि ते सुरू करण्यासाठी वापरणे सोपे आहे.

सुरक्षा चॅम्पियन्स वापरा

सामान्यतः, 100-200 विकसकांसह सरासरी कंपनीमध्ये, एक सुरक्षा तज्ञ असतो जो अनेक कार्ये करतो आणि शारीरिकरित्या सर्वकाही तपासण्यासाठी वेळ नसतो. जरी त्याने सर्वतोपरी प्रयत्न केले तरी, तो एकटाच विकास निर्माण करणारे सर्व कोड तपासणार नाही. अशा प्रकरणांसाठी, एक संकल्पना विकसित केली गेली आहे - सुरक्षा चॅम्पियन्स.

सिक्युरिटी चॅम्पियन्स हे डेव्हलपमेंट टीममधील लोक आहेत ज्यांना तुमच्या उत्पादनाच्या सुरक्षिततेमध्ये स्वारस्य आहे.

सिक्युरिटी चॅम्पियन हा डेव्हलपमेंट टीममधला एक प्रवेश बिंदू आहे आणि एक सुरक्षा सुवार्तिक एकामध्ये आणला जातो.

सहसा, जेव्हा एखादा सुरक्षा तज्ञ विकास कार्यसंघाकडे येतो आणि कोडमधील त्रुटी दर्शवतो तेव्हा त्याला आश्चर्यकारक उत्तर मिळते:

- आणि तू कोण आहेस? मी तुला पहिल्यांदाच पाहत आहे. माझ्याबरोबर सर्व काही ठीक आहे - माझ्या वरिष्ठ मित्राने मला कोड पुनरावलोकनावर "अर्ज" दिले, आम्ही पुढे जाऊ!

ही एक सामान्य परिस्थिती आहे, कारण ज्यांच्याशी डेव्हलपर कामावर आणि कोड रिव्ह्यूमध्ये सतत संवाद साधतो अशा वरिष्ठांवर किंवा फक्त टीममेट्सवर जास्त विश्वास असतो. जर, सुरक्षा अधिकाऱ्याऐवजी, सुरक्षा चॅम्पियनने चूक आणि परिणाम निदर्शनास आणले, तर त्याच्या शब्दाला अधिक वजन असेल.

तसेच, विकासकांना त्यांचा कोड कोणत्याही सुरक्षा तज्ञापेक्षा चांगला माहित असतो. ज्या व्यक्तीकडे स्टॅटिक अॅनालिसिस टूलमध्ये किमान 5 प्रोजेक्ट्स आहेत, त्यांच्यासाठी सर्व बारकावे लक्षात ठेवणे कठीण असते. सुरक्षा चॅम्पियन्सना त्यांचे उत्पादन माहित आहे: काय संवाद साधते आणि प्रथम काय पहावे - ते अधिक प्रभावी आहेत.

त्यामुळे सिक्युरिटी चॅम्पियन्सची अंमलबजावणी करण्याचा आणि तुमच्या सुरक्षा टीमचा प्रभाव वाढवण्याचा विचार करा. हे स्वतः चॅम्पियनसाठी देखील उपयुक्त आहे: नवीन क्षेत्रात व्यावसायिक विकास, त्याची तांत्रिक क्षितिजे विस्तृत करणे, तांत्रिक, व्यवस्थापकीय आणि नेतृत्व कौशल्ये सुधारणे, बाजार मूल्य वाढवणे. हे सामाजिक अभियांत्रिकीचे काही घटक आहे, विकास कार्यसंघातील तुमचे "डोळे".

चाचणीचे टप्पे

नमुना 20 ते 80 म्हणतात की 20% प्रयत्न 80% परिणाम देतात. हे 20% अनुप्रयोग विश्लेषण पद्धती आहेत जे स्वयंचलित असू शकतात आणि पाहिजेत. अशा क्रियाकलापांची उदाहरणे स्थिर विश्लेषण आहेत - सेस्ट, डायनॅमिक विश्लेषण - DAST и ओपन सोर्स कंट्रोल. मी तुम्हाला अ‍ॅक्टिव्हिटींबद्दल, तसेच टूल्सबद्दल, प्रक्रियेमध्ये त्यांचा परिचय करून देताना कोणत्या वैशिष्ट्यांचा सामना करतो आणि ते योग्यरित्या कसे करावे याबद्दल अधिक सांगेन.

साधनांची मुख्य समस्या

मी सर्व उपकरणांसाठी संबंधित आणि लक्ष देण्याची आवश्यकता असलेल्या समस्या हायलाइट करेन. त्यांची पुनरावृत्ती होऊ नये म्हणून मी त्यांचे अधिक तपशीलवार विश्लेषण करेन.

दीर्घ विश्लेषण वेळ. जर वचनबद्धतेपासून रिलीज होण्यास सर्व चाचण्या आणि असेंब्लीसाठी 30 मिनिटे लागतात, तर माहिती सुरक्षा तपासणीस एक दिवस लागेल. त्यामुळे कोणीही प्रक्रियेची गती कमी करणार नाही. हे वैशिष्ट्य विचारात घ्या आणि निष्कर्ष काढा.

उच्च पातळी खोटे नकारात्मक किंवा चुकीचे सकारात्मक. सर्व उत्पादने भिन्न आहेत, सर्व भिन्न फ्रेमवर्क आणि त्यांची स्वतःची कोडिंग शैली वापरतात. भिन्न कोडबेस आणि तंत्रज्ञानावर, साधने चुकीचे नकारात्मक आणि चुकीचे सकारात्मक स्तर दर्शवू शकतात. त्यामुळे नक्की काय आहे ते पहा आपल्या पैकी कंपन्या आणि साठी आपले अनुप्रयोग चांगले आणि विश्वासार्ह परिणाम दर्शवतील.

विद्यमान साधनांसह कोणतेही एकत्रीकरण नाही. तुम्ही आधीपासून वापरत असलेल्या साधनांसह एकत्रीकरणाच्या दृष्टीने साधने पहा. उदाहरणार्थ, तुमच्याकडे Jenkins किंवा TeamCity असल्यास, तुम्ही वापरत नसलेल्या GitLab CI सह नव्हे तर या सॉफ्टवेअरसह टूल्सचे एकत्रीकरण तपासा.

सानुकूलनाची कमतरता किंवा अत्यधिक जटिलता. जर टूलमध्ये एपीआय नसेल, तर त्याची गरज का आहे? इंटरफेसमध्ये करता येणारी प्रत्येक गोष्ट API द्वारे उपलब्ध असावी. तद्वतच, टूलमध्ये चेक सानुकूलित करण्याची क्षमता असावी.

उत्पादन विकास रोडमॅप नाही. विकास स्थिर राहत नाही, आम्ही नेहमी नवीन फ्रेमवर्क आणि फंक्शन्स वापरत असतो, जुना कोड नवीन भाषांमध्ये पुन्हा लिहित असतो. आम्ही खरेदी करत असलेले साधन नवीन फ्रेमवर्क आणि तंत्रज्ञानास समर्थन देईल याची आम्हाला खात्री हवी आहे. म्हणून, हे जाणून घेणे महत्वाचे आहे की उत्पादनामध्ये वास्तविक आणि योग्य आहे आराखडा विकास

प्रक्रिया वैशिष्ट्ये

साधनांच्या वैशिष्ट्यांव्यतिरिक्त, विकास प्रक्रियेची वैशिष्ट्ये विचारात घ्या. उदाहरणार्थ, विकासात अडथळा आणणे ही एक सामान्य चूक आहे. इतर कोणती वैशिष्ट्ये विचारात घ्यावीत आणि सुरक्षा पथकाने कोणत्या गोष्टींकडे लक्ष दिले पाहिजे ते पाहूया.

विकास चुकवू नये आणि अंतिम मुदत सोडू नये म्हणून, तयार करा भिन्न नियम आणि भिन्न स्टॉपर्स दाखवा - असुरक्षिततेच्या उपस्थितीत बिल्ड प्रक्रिया थांबविण्याचे निकष - वेगवेगळ्या वातावरणासाठी. उदाहरणार्थ, आम्ही समजतो की सध्याची शाखा डेव्हलपमेंट स्टँड किंवा UAT वर जाते, याचा अर्थ आम्ही थांबत नाही आणि म्हणत नाही:

"तुमच्याकडे येथे असुरक्षा आहेत, तुम्ही पुढे कुठेही जाणार नाही!"

या टप्प्यावर, विकासकांना सांगणे महत्त्वाचे आहे की सुरक्षा समस्या आहेत ज्याकडे लक्ष देणे आवश्यक आहे.

असुरक्षिततेची उपस्थिती पुढील चाचणीसाठी अडथळा नाही: मॅन्युअल, इंटिग्रेशन किंवा मॅन्युअल. दुसरीकडे, आम्हाला उत्पादनाची सुरक्षितता कशीतरी वाढवण्याची गरज आहे आणि जेणेकरुन विकसकांना जे सुरक्षित वाटते त्याकडे दुर्लक्ष करू नये. म्हणून, काहीवेळा आम्ही असे करतो: स्टँडवर, जेव्हा ते विकासाच्या वातावरणात आणले जाते, तेव्हा आम्ही फक्त विकासास सूचित करतो:

- मित्रांनो, तुम्हाला समस्या आहेत, कृपया त्यांच्याकडे लक्ष द्या.

यूएटी स्टेजवर आम्ही पुन्हा असुरक्षिततेबद्दल चेतावणी दर्शवतो आणि रिलीझ स्टेजवर आम्ही म्हणतो:

- मित्रांनो, आम्ही तुम्हाला अनेक वेळा चेतावणी दिली, तुम्ही काहीही केले नाही - आम्ही तुम्हाला यासह बाहेर पडू देणार नाही.

जर आपण कोड आणि डायनॅमिक्सबद्दल बोललो तर, फक्त या वैशिष्ट्यामध्ये लिहिलेल्या वैशिष्ट्यांबद्दल आणि कोडच्या असुरक्षा दर्शविल्या पाहिजेत आणि चेतावणी द्यावी लागेल. जर एखाद्या विकसकाने एक बटण 3 पिक्सेलने हलवले आणि आम्ही त्याला सांगितले की त्याच्याकडे एक SQL इंजेक्शन आहे आणि त्यामुळे ते तातडीने दुरुस्त करणे आवश्यक आहे, हे चुकीचे आहे. फक्त आता काय लिहिले आहे आणि अनुप्रयोगात येणारा बदल पहा.

समजा आमच्याकडे एक विशिष्ट कार्यात्मक दोष आहे - अनुप्रयोग ज्या प्रकारे कार्य करू नये: पैसे हस्तांतरित केले जात नाहीत, जेव्हा तुम्ही बटणावर क्लिक करता तेव्हा पुढील पृष्ठावर कोणतेही संक्रमण होत नाही किंवा उत्पादन लोड होत नाही. सुरक्षा दोष - हे समान दोष आहेत, परंतु ऍप्लिकेशन ऑपरेशनच्या दृष्टीने नव्हे तर सुरक्षिततेच्या बाबतीत.

सर्व सॉफ्टवेअर गुणवत्ता समस्या सुरक्षा समस्या नाहीत. परंतु सर्व सुरक्षा समस्या सॉफ्टवेअर गुणवत्तेशी संबंधित आहेत. शेरीफ मन्सूर, एक्सपीडिया.

सर्व असुरक्षा समान दोष असल्याने, ते सर्व विकास दोषांप्रमाणेच त्याच ठिकाणी असले पाहिजेत. म्हणून कोणीही वाचत नाही असे अहवाल आणि धडकी भरवणारा PDF विसरून जा.

जेव्हा मी एका विकास कंपनीत काम करत होतो, तेव्हा मला स्थिर विश्लेषण साधनांकडून अहवाल प्राप्त झाला. मी ते उघडले, घाबरलो, कॉफी बनवली, 350 पानांची पाने टाकली, बंद केली आणि कामाला लागलो. मोठे अहवाल मृत अहवाल आहेत. सहसा ते कुठेही जात नाहीत, अक्षरे हटविली जातात, विसरली जातात, हरवली जातात किंवा व्यवसाय म्हणतो की तो जोखीम स्वीकारतो.

काय करायचं? आम्‍हाला आढळलेल्‍या पुष्‍टी दोषांचे विकासासाठी सोयीस्कर फॉर्ममध्‍ये रूपांतर करतो, उदाहरणार्थ, आम्‍ही ते जिरामध्‍ये अनुशेषात ठेवतो. आम्ही दोषांना प्राधान्य देतो आणि कार्यात्मक दोष आणि चाचणी दोषांसह त्यांना प्राधान्यक्रमाने दूर करतो.

स्थिर विश्लेषण - SAST

हे भेद्यतेसाठी कोड विश्लेषण आहे., पण ते SonarQube सारखे नाही. आम्ही फक्त नमुने किंवा शैली तपासत नाही. विश्लेषणामध्ये अनेक पद्धती वापरल्या जातात: असुरक्षिततेच्या झाडानुसार, त्यानुसार माहितीचा प्रवाह, कॉन्फिगरेशन फाइल्सचे विश्लेषण करून. हे सर्व आहे जे संहितेशी संबंधित आहे.

दृष्टिकोनाचे साधक: विकासाच्या सुरुवातीच्या टप्प्यावर कोडमधील भेद्यता ओळखणेजेव्हा अद्याप कोणतेही स्टँड किंवा तयार साधने नाहीत, आणि वाढीव स्कॅनिंग क्षमता: कोडचा एक विभाग स्कॅन करणे जो बदलला आहे आणि फक्त आम्ही सध्या करत असलेले वैशिष्ट्य, ज्यामुळे स्कॅनिंगचा वेळ कमी होतो.

मिनिन्स - ही आवश्यक भाषांसाठी समर्थनाची कमतरता आहे.

आवश्यक एकत्रीकरण, जे माझ्या व्यक्तिनिष्ठ मतानुसार साधनांमध्ये असावे:

• एकत्रीकरण साधन: जेनकिन्स, टीमसिटी आणि गिटलॅब सीआय.
• विकास वातावरण: इंटेलिज IDEA, व्हिज्युअल स्टुडिओ. विकासकाला लक्षात न येण्याजोग्या इंटरफेसवर नॅव्हिगेट न करणे अधिक सोयीचे आहे, ज्याला अद्याप लक्षात ठेवणे आवश्यक आहे, परंतु त्याच्या स्वतःच्या विकासाच्या वातावरणात कामाच्या ठिकाणी त्याला आढळलेल्या सर्व आवश्यक एकत्रीकरण आणि असुरक्षा पाहणे अधिक सोयीचे आहे.
• कोड पुनरावलोकन: सोनारक्यूब आणि मॅन्युअल पुनरावलोकन.
• दोष ट्रॅकर्स: जिरा आणि बगझिला.

चित्र स्थिर विश्लेषणाचे काही उत्कृष्ट प्रतिनिधी दर्शविते.

ही साधने महत्त्वाची नसून प्रक्रिया आहे, म्हणून तेथे मुक्त स्रोत उपाय आहेत जे प्रक्रियेची चाचणी घेण्यासाठी देखील चांगले आहेत.

SAST ओपन सोर्सला मोठ्या प्रमाणात भेद्यता किंवा जटिल डेटाफ्लो आढळणार नाहीत, परंतु प्रक्रिया तयार करताना त्यांचा वापर केला जाऊ शकतो आणि केला पाहिजे. प्रक्रिया कशी तयार केली जाईल, दोषांना कोण प्रतिसाद देईल, कोण अहवाल देईल आणि कोण अहवाल देईल हे समजून घेण्यात ते मदत करतात. तुम्‍हाला तुमच्‍या कोडची सुरक्षा तयार करण्‍याचा प्रारंभिक टप्पा पार पाडायचा असेल, तर ओपन सोर्स सोल्यूशन्स वापरा.

जर तुम्ही तुमच्या प्रवासाच्या सुरुवातीला असाल आणि तुमच्याकडे काहीही नसेल तर हे कसे एकत्रित केले जाऊ शकते: CI नाही, जेनकिन्स नाही, TeamCity नाही? चला प्रक्रियेमध्ये एकत्रीकरणाचा विचार करूया.

CVS स्तर एकत्रीकरण

तुमच्याकडे Bitbucket किंवा GitLab असल्यास, तुम्ही स्तरावर समाकलित करू शकता समवर्ती आवृत्त्या प्रणाली.

प्रसंगानुसार - पुल विनंती, वचनबद्ध. तुम्ही कोड स्कॅन करता आणि बिल्ड स्थिती दर्शवते की सुरक्षा तपासणी पास झाली की अयशस्वी.

अभिप्राय. अर्थात, अभिप्राय नेहमीच आवश्यक असतो. जर तुम्ही फक्त बाजूला सुरक्षा केली असेल, तर ते एका बॉक्समध्ये ठेवले आणि कोणालाही त्याबद्दल काहीही सांगितले नाही आणि नंतर महिन्याच्या शेवटी बग्सचा एक समूह टाकला - हे योग्य नाही आणि चांगले नाही.

कोड पुनरावलोकन प्रणालीसह एकत्रीकरण

एकदा, आम्ही अनेक महत्त्वाच्या प्रकल्पांमध्ये तांत्रिक AppSec वापरकर्त्यासाठी डीफॉल्ट पुनरावलोकनकर्ता म्हणून काम केले. नवीन कोडमध्ये त्रुटी ओळखल्या गेल्या आहेत किंवा कोणत्याही त्रुटी नाहीत यावर अवलंबून, पुनरावलोकनकर्ता पुल विनंतीवर "स्वीकारण्यासाठी" किंवा "कामाची आवश्यकता आहे" अशी स्थिती सेट करतो - एकतर सर्व काही ठीक आहे, किंवा नेमके काय सुधारणे आवश्यक आहे याचे दुवे. सुधारणे आवश्यक आहे. उत्पादनात जात असलेल्या आवृत्तीसह एकत्रीकरणासाठी, आम्ही माहिती सुरक्षा चाचणी उत्तीर्ण न झाल्यास विलीनीकरण प्रतिबंध सक्षम केला आहे. आम्ही मॅन्युअल कोड पुनरावलोकनामध्ये याचा समावेश केला आणि प्रक्रियेतील इतर सहभागींनी या विशिष्ट प्रक्रियेसाठी सुरक्षा स्थिती पाहिल्या.

SonarQube सह एकत्रीकरण

अनेकांकडे आहे दर्जेदार गेट कोड गुणवत्तेच्या बाबतीत. येथेही तेच आहे - तुम्ही फक्त SAST साधनांसाठी समान गेट्स बनवू शकता. समान इंटरफेस असेल, समान दर्जाचे गेट असेल, फक्त त्याला कॉल केले जाईल सुरक्षा गेट. आणि तसेच, जर तुमच्याकडे सोनारक्यूब वापरण्याची प्रक्रिया असेल, तर तुम्ही तिथे सर्वकाही सहजपणे समाकलित करू शकता.

CI स्तरावर एकत्रीकरण

येथे सर्व काही अगदी सोपे आहे:

• ऑटोटेस्टच्या बरोबरीने, युनिट चाचण्या.
• विकासाच्या टप्प्यांनुसार विभागणी: देव, चाचणी, उत्पादन. नियमांचे वेगवेगळे संच किंवा भिन्न अयशस्वी अटी समाविष्ट केल्या जाऊ शकतात: असेंब्ली थांबवा, असेंब्ली थांबवू नका.
• सिंक्रोनस/असिंक्रोनस लॉन्च. आम्ही सुरक्षा चाचण्या संपण्याची वाट पाहत आहोत की नाही. म्हणजेच, आम्ही फक्त त्यांना लॉन्च केले आणि पुढे जाऊ, आणि मग आम्हाला स्थिती मिळते की सर्वकाही चांगले किंवा वाईट आहे.

हे सर्व परिपूर्ण गुलाबी जगात आहे. खऱ्या आयुष्यात असं काही नसतं, पण आम्ही धडपडतो. चालू सुरक्षा तपासणीचा परिणाम युनिट चाचण्यांच्या निकालांसारखाच असावा.

उदाहरणार्थ, आम्ही एक मोठा प्रकल्प घेतला आणि ठरवले की आता आम्ही ते SAST - OK सह स्कॅन करू. आम्ही हा प्रकल्प SAST मध्ये ढकलला, त्याने आम्हाला 20 असुरक्षा दिल्या आणि दृढ इच्छाशक्तीच्या निर्णयाने आम्ही ठरवले की सर्व काही ठीक आहे. 000 असुरक्षा हे आमचे तांत्रिक कर्ज आहे. आम्ही कर्ज एका बॉक्समध्ये ठेवू, आम्ही ते हळूहळू साफ करू आणि दोष ट्रॅकरमध्ये दोष जोडू. चला एक कंपनी भाड्याने घेऊ, सर्वकाही स्वतः करू, किंवा सुरक्षा चॅम्पियन्सची आम्हाला मदत करा - आणि तांत्रिक कर्ज कमी होईल.

आणि नवीन कोडमधील सर्व नवीन उदयोन्मुख भेद्यता युनिट किंवा ऑटोटेस्टमधील त्रुटींप्रमाणेच काढून टाकल्या पाहिजेत. तुलनेने बोलायचे झाल्यास, असेंब्ली सुरू झाली, आम्ही ती चालवली, दोन चाचण्या आणि दोन सुरक्षा चाचण्या अयशस्वी झाल्या. ठीक आहे - आम्ही गेलो, काय झाले ते पाहिले, एक गोष्ट निश्चित केली, दुसरी निश्चित केली, पुढच्या वेळी ती चालविली - सर्व काही ठीक होते, कोणतीही नवीन भेद्यता दिसून आली नाही, कोणत्याही चाचण्या अयशस्वी झाल्या नाहीत. जर हे कार्य अधिक सखोल असेल आणि तुम्हाला ते नीट समजून घेणे आवश्यक आहे, किंवा असुरक्षा निश्चित केल्याने हुडच्या खाली असलेल्या मोठ्या स्तरांवर परिणाम होतो: दोष ट्रॅकरमध्ये एक बग जोडला गेला होता, तो प्राधान्याने आणि दुरुस्त केला जातो. दुर्दैवाने, जग परिपूर्ण नाही आणि चाचण्या कधीकधी अयशस्वी होतात.

सिक्युरिटी गेटचे उदाहरण म्हणजे कोडमधील भेद्यतेची उपस्थिती आणि संख्या यानुसार दर्जेदार गेटचे अॅनालॉग.

आम्ही SonarQube सह समाकलित करतो - प्लगइन स्थापित केले आहे, सर्वकाही अतिशय सोयीस्कर आणि छान आहे.

विकास वातावरणाशी एकीकरण

एकत्रीकरण पर्याय:

• कमिट करण्यापूर्वी डेव्हलपमेंट एन्व्हायर्नमेंटमधून स्कॅन चालवणे.
• परिणाम पहा.
• परिणामांचे विश्लेषण.
• सर्व्हरसह सिंक्रोनाइझेशन.

सर्व्हरकडून परिणाम प्राप्त करताना असे दिसते.

आमच्या विकासाच्या वातावरणात इंटेलिज आयडीईए स्कॅन दरम्यान अशा असुरक्षा आढळून आल्याची माहिती देणारा एक अतिरिक्त आयटम फक्त दिसतो. तुम्ही कोड त्वरित संपादित करू शकता, शिफारसी पाहू शकता आणि प्रवाह आलेख. हे सर्व डेव्हलपरच्या कामाच्या ठिकाणी स्थित आहे, जे खूप सोयीचे आहे - इतर लिंक्सचे अनुसरण करण्याची आणि काहीतरी अतिरिक्त पाहण्याची आवश्यकता नाही.

मुक्त स्रोत

हा माझा आवडता विषय आहे. प्रत्येकजण ओपन सोर्स लायब्ररी वापरतो - जेव्हा तुम्ही तयार लायब्ररी घेऊ शकता तेव्हा क्रॅच आणि सायकली का लिहा ज्यामध्ये सर्वकाही आधीच लागू आहे?

अर्थात, हे खरे आहे, परंतु लायब्ररी देखील लोकांद्वारे लिहिली जातात, त्यात काही जोखीम देखील असतात आणि काही असुरक्षा देखील असतात ज्या वेळोवेळी किंवा सतत नोंदवल्या जातात. म्हणून, ऍप्लिकेशन सिक्युरिटीमध्ये पुढील पायरी आहे - हे ओपन सोर्स घटकांचे विश्लेषण आहे.

मुक्त स्रोत विश्लेषण - OSA

साधनामध्ये तीन मोठे टप्पे समाविष्ट आहेत.

लायब्ररीतील भेद्यता शोधत आहे. उदाहरणार्थ, टूलला माहित आहे की आम्ही काही लायब्ररी वापरत आहोत आणि ते मध्ये सीव्ही किंवा बग ट्रॅकर्समध्ये काही असुरक्षा आहेत ज्या लायब्ररीच्या या आवृत्तीशी संबंधित आहेत. तुम्ही ते वापरण्याचा प्रयत्न करता तेव्हा, टूल लायब्ररी असुरक्षित असल्याची चेतावणी देईल आणि तुम्हाला भेद्यता नसलेली दुसरी आवृत्ती वापरण्याचा सल्ला देईल.

परवाना शुद्धतेचे विश्लेषण. हे अद्याप येथे विशेषतः लोकप्रिय नाही, परंतु जर तुम्ही परदेशात काम करत असाल, तर तुम्हाला वेळोवेळी तेथे एखादा ओपन सोर्स घटक वापरल्याबद्दल कर मिळू शकतो जो वापरला जाऊ शकत नाही किंवा बदलू शकत नाही. परवानाधारक लायब्ररीच्या धोरणानुसार, आम्ही हे करू शकत नाही. किंवा, आम्ही त्यात बदल करून वापरल्यास, आम्ही आमचा कोड पोस्ट केला पाहिजे. अर्थात, कोणीही त्यांच्या उत्पादनांचा कोड प्रकाशित करू इच्छित नाही, परंतु आपण यापासून स्वतःचे संरक्षण देखील करू शकता.

औद्योगिक वातावरणात वापरल्या जाणार्‍या घटकांचे विश्लेषण. चला एका काल्पनिक परिस्थितीची कल्पना करूया की आम्ही शेवटी विकास पूर्ण केला आहे आणि आमच्या मायक्रोसर्व्हिसचे नवीनतम प्रकाशन जारी केले आहे. तो तेथे आश्चर्यकारकपणे राहतो - एक आठवडा, एक महिना, एक वर्ष. आम्ही ते गोळा करत नाही, आम्ही सुरक्षा तपासणी करत नाही, सर्वकाही ठीक आहे असे दिसते. पण अचानक, रिलीझच्या दोन आठवड्यांनंतर, ओपन सोर्स घटकामध्ये एक गंभीर भेद्यता दिसून येते, जी आम्ही औद्योगिक वातावरणात या विशिष्ट बिल्डमध्ये वापरतो. आम्ही काय आणि कुठे वापरतो याची नोंद न केल्यास, आम्हाला ही भेद्यता दिसणार नाही. काही साधनांमध्ये सध्या उद्योगात वापरल्या जाणार्‍या लायब्ररींमधील भेद्यतेचे निरीक्षण करण्याची क्षमता आहे. ते खूप उपयुक्त आहे.

वैशिष्ट्ये:

• विकासाच्या वेगवेगळ्या टप्प्यांसाठी वेगवेगळी धोरणे.
• औद्योगिक वातावरणात घटकांचे निरीक्षण करणे.
• संस्थेतील ग्रंथालयांचे नियंत्रण.
• विविध बिल्ड सिस्टम आणि भाषांसाठी समर्थन.
• डॉकर प्रतिमांचे विश्लेषण.

मुक्त स्रोत विश्लेषणामध्ये गुंतलेल्या उद्योगातील नेत्यांची काही उदाहरणे.

फक्त एक मुक्त आहे अवलंबित्व - तपासा OWASP कडून. तुम्ही पहिल्या टप्प्यात ते चालू करू शकता, ते कसे कार्य करते आणि ते कशाचे समर्थन करते ते पहा. मूलभूतपणे, ही सर्व क्लाउड उत्पादने किंवा ऑन-प्रिमाइस आहेत, परंतु त्यांच्या बेसच्या मागे ते अद्याप इंटरनेटवर पाठवले जातात. ते तुमची लायब्ररी नाही तर हॅश किंवा त्यांची स्वतःची मूल्ये पाठवतात, ज्याची ते गणना करतात आणि असुरक्षिततेच्या उपस्थितीबद्दल माहिती प्राप्त करण्यासाठी त्यांच्या सर्व्हरवर बोटांचे ठसे पाठवतात.

प्रक्रिया एकत्रीकरण

ग्रंथालयांचे परिमिती नियंत्रण, जे बाह्य स्त्रोतांकडून डाउनलोड केले जातात. आमच्याकडे बाह्य आणि अंतर्गत भांडार आहेत. उदाहरणार्थ, इव्हेंट सेंट्रल नेक्सस चालवतो आणि आम्हाला खात्री करायची आहे की आमच्या भांडारात "गंभीर" किंवा "उच्च" स्थितीसह कोणतीही भेद्यता नाही. तुम्ही Nexus Firewall Lifecycle टूल वापरून प्रॉक्सी कॉन्फिगर करू शकता जेणेकरून अशा भेद्यता कापल्या जातील आणि अंतर्गत भांडारात संपुष्टात येणार नाहीत.

CI मध्ये एकत्रीकरण. ऑटोटेस्ट, युनिट चाचण्या आणि विकासाच्या टप्प्यांमध्ये विभागणीसह समान स्तरावर: dev, test, prod. प्रत्येक टप्प्यावर, आपण कोणतीही लायब्ररी डाउनलोड करू शकता, काहीही वापरू शकता, परंतु "गंभीर" स्थितीसह काहीतरी कठीण असल्यास, उत्पादनात रिलीज होण्याच्या टप्प्यावर कदाचित विकसकांचे लक्ष वेधून घेणे योग्य आहे.

कलाकृतींसह एकत्रीकरण: Nexus आणि JFrog.

विकास वातावरणात एकत्रीकरण. तुम्ही निवडलेल्या साधनांचा विकास वातावरणाशी एकीकरण असावा. डेव्हलपरला त्याच्या कामाच्या ठिकाणाहून स्कॅनिंग परिणामांमध्ये प्रवेश असणे आवश्यक आहे किंवा CVS ला कमिट करण्यापूर्वी असुरक्षिततेसाठी स्वतः कोड स्कॅन करण्याची आणि तपासण्याची क्षमता असणे आवश्यक आहे.

सीडी एकत्रीकरण. हे एक छान वैशिष्ट्य आहे जे मला खरोखर आवडते आणि ज्याबद्दल मी आधीच बोललो आहे - औद्योगिक वातावरणात नवीन असुरक्षिततेच्या उदयाचे निरीक्षण करणे. हे असे काहीतरी कार्य करते.

आमच्याकडे आहे सार्वजनिक घटक भांडार — बाहेरील काही साधने आणि आमचे अंतर्गत भांडार. त्यात फक्त विश्वसनीय घटक असावेत अशी आमची इच्छा आहे. विनंती प्रॉक्सी करताना, आम्ही तपासतो की डाउनलोड केलेल्या लायब्ररीमध्ये भेद्यता नाही. जर ते आम्ही सेट केलेल्या विशिष्ट धोरणांच्या अंतर्गत येत असेल आणि विकासाशी समन्वय साधणे आवश्यक असेल, तर आम्ही ते अपलोड करत नाही आणि दुसरी आवृत्ती वापरण्यास सांगितले जाते. त्यानुसार, लायब्ररीमध्ये खरोखर गंभीर आणि वाईट काहीतरी असल्यास, विकासकाला इंस्टॉलेशन टप्प्यावर लायब्ररी मिळणार नाही - त्याला उच्च किंवा कमी आवृत्ती वापरू द्या.

• इमारत बांधताना, आम्ही तपासतो की कोणीही काहीही खराब केले नाही, सर्व घटक सुरक्षित आहेत आणि फ्लॅश ड्राइव्हवर कोणीही धोकादायक काहीही आणले नाही.
• आमच्याकडे रिपॉजिटरीमध्ये फक्त विश्वसनीय घटक आहेत.
• तैनात करताना, आम्ही पुन्हा एकदा पॅकेज स्वतः तपासतो: वॉर, जार, डीएल किंवा डॉकर इमेज हे धोरणाचे पालन करत असल्याची खात्री करण्यासाठी.
• उद्योगात प्रवेश करताना, आम्ही औद्योगिक वातावरणात काय घडत आहे याचे निरीक्षण करतो: गंभीर असुरक्षा दिसून येतात किंवा दिसत नाहीत.

डायनॅमिक विश्लेषण - DAST

डायनॅमिक विश्लेषण साधने आधी सांगितलेल्या प्रत्येक गोष्टीपेक्षा मूलभूतपणे भिन्न आहेत. अनुप्रयोगासह वापरकर्त्याच्या कार्याचे हे एक प्रकारचे अनुकरण आहे. जर हे वेब अॅप्लिकेशन असेल, तर आम्ही क्लायंटच्या कामाचे अनुकरण करून विनंत्या पाठवतो, समोरच्या बटणावर क्लिक करतो, फॉर्ममधून कृत्रिम डेटा पाठवतो: कोट्स, ब्रॅकेट, वेगवेगळ्या एन्कोडिंगमधील वर्ण, अॅप्लिकेशन कसे कार्य करते आणि प्रक्रिया कशी करते हे पाहण्यासाठी बाह्य डेटा.

समान प्रणाली तुम्हाला मुक्त स्त्रोतामध्ये टेम्पलेट भेद्यता तपासण्याची परवानगी देते. आम्ही कोणता मुक्त स्रोत वापरत आहोत हे DAST ला माहीत नसल्यामुळे, ते फक्त "दुर्भावनापूर्ण" पॅटर्न टाकते आणि सर्व्हरच्या प्रतिसादांचे विश्लेषण करते:

- होय, येथे डीसीरियलायझेशन समस्या आहे, परंतु येथे नाही.

यामध्ये मोठे धोके आहेत, कारण जर तुम्ही ही सुरक्षा चाचणी त्याच बेंचवर घेतली ज्यावर परीक्षक काम करतात, तर अप्रिय गोष्टी घडू शकतात.

• अनुप्रयोग सर्व्हर नेटवर्कवर उच्च भार.
• कोणतेही एकत्रीकरण नाही.
• विश्लेषण केलेल्या अनुप्रयोगाची सेटिंग्ज बदलण्याची क्षमता.
• आवश्यक तंत्रज्ञानासाठी कोणतेही समर्थन नाही.
• सेटअप करण्यात अडचण.

आम्ही शेवटी AppScan लाँच केले तेव्हा आमच्याकडे परिस्थिती होती: आम्ही अनुप्रयोगात प्रवेश मिळविण्यासाठी बराच वेळ घालवला, 3 खाती मिळाली आणि आम्हाला आनंद झाला - आम्ही शेवटी सर्वकाही तपासू! आम्ही एक स्कॅन लाँच केले, आणि AppScan ने सर्वप्रथम अॅडमिन पॅनेलमध्ये जाणे, सर्व बटणे टोचणे, अर्धा डेटा बदलणे आणि नंतर सर्व्हर पूर्णपणे नष्ट करणे. मेलफॉर्म- विनंत्या. चाचणीसह विकास म्हणाला:

- मित्रांनो, तुम्ही माझी मस्करी करत आहात?! आम्ही तुम्हाला खाती दिली आणि तुम्ही एक भूमिका मांडली!

संभाव्य धोके विचारात घ्या. तद्वतच, माहितीच्या सुरक्षिततेच्या चाचणीसाठी एक स्वतंत्र स्टँड तयार करा, जे किमान कसे तरी इतर वातावरणापासून वेगळे केले जाईल आणि सशर्तपणे प्रशासक पॅनेल तपासा, शक्यतो मॅन्युअल मोडमध्ये. हा एक पेन्टेस्ट आहे - प्रयत्नांची ती उर्वरित टक्केवारी ज्यांचा आपण आता विचार करत नाही.

हे लक्षात घेण्यासारखे आहे की आपण हे लोड चाचणीचे अॅनालॉग म्हणून वापरू शकता. पहिल्या टप्प्यावर, आपण 10-15 थ्रेडसह डायनॅमिक स्कॅनर चालू करू शकता आणि काय होते ते पाहू शकता, परंतु सामान्यतः, सराव शो म्हणून, काहीही चांगले नाही.

काही संसाधने जी आपण सहसा वापरतो.

हायलाइट करण्यासारखे आहे बर्प सूट कोणत्याही सुरक्षा व्यावसायिकांसाठी "स्विस चाकू" आहे. प्रत्येकजण ते वापरतो आणि ते खूप सोयीस्कर आहे. एंटरप्राइझ आवृत्तीची नवीन डेमो आवृत्ती आता प्रसिद्ध झाली आहे. जर पूर्वी प्लगइनसह केवळ एक स्वतंत्र युटिलिटी होती, तर आता विकासक शेवटी एक मोठा सर्व्हर बनवत आहेत ज्यातून अनेक एजंट व्यवस्थापित करणे शक्य होईल. हे छान आहे, मी तुम्हाला प्रयत्न करण्याची शिफारस करतो.

प्रक्रिया एकत्रीकरण

एकत्रीकरण अगदी चांगले आणि सोपे होते: यशस्वी स्थापनेनंतर स्कॅनिंग सुरू करा स्टँडसाठी अर्ज आणि यशस्वी एकीकरण चाचणीनंतर स्कॅनिंग.

जर एकत्रीकरण कार्य करत नसेल किंवा स्टब आणि मॉक फंक्शन्स असतील तर ते निरर्थक आणि निरुपयोगी आहे - आम्ही कोणताही नमुना पाठवला तरीही सर्व्हर त्याच प्रकारे प्रतिसाद देईल.

• आदर्शपणे, एक स्वतंत्र चाचणी स्टँड.
• चाचणी करण्यापूर्वी, लॉगिन क्रम लिहा.
• प्रशासन यंत्रणेची चाचणी केवळ मॅन्युअल आहे.

प्रक्रिया

सर्वसाधारणपणे प्रक्रियेबद्दल आणि विशेषतः प्रत्येक साधनाच्या कार्याबद्दल थोडेसे सामान्यीकृत. सर्व ऍप्लिकेशन्स भिन्न आहेत - एक डायनॅमिक विश्लेषणासह, दुसरा स्थिर विश्लेषणासह, तिसरा ओपनसोर्स विश्लेषणासह, पेंटेस्ट्स किंवा इतर काहीतरी, उदाहरणार्थ, इव्हेंटसह चांगले कार्य करते वाफ.

प्रत्येक प्रक्रियेवर नियंत्रण आवश्यक आहे.

प्रक्रिया कशी कार्य करते आणि ती कुठे सुधारली जाऊ शकते हे समजून घेण्यासाठी, तुम्हाला उत्पादन मेट्रिक्स, टूल्समधील मेट्रिक्स आणि दोष ट्रॅकर्ससह तुमच्या हातांनी मिळू शकणार्‍या प्रत्येक गोष्टीतून मेट्रिक्स गोळा करणे आवश्यक आहे.

कोणतीही माहिती उपयुक्त आहे. हे किंवा ते साधन कोठे अधिक चांगले वापरले जाते, जेथे प्रक्रिया विशेषतः कमी होते ते वेगवेगळ्या कोनातून पाहणे आवश्यक आहे. वेळेवर आधारित प्रक्रिया कुठे सुधारायची हे पाहण्यासाठी विकास प्रतिसाद वेळा पाहण्यासारखे असू शकते. जितका अधिक डेटा, तितके अधिक विभाग उच्च-स्तरीय ते प्रत्येक प्रक्रियेच्या तपशीलापर्यंत तयार केले जाऊ शकतात.

सर्व स्टॅटिक आणि डायनॅमिक विश्लेषकांचे स्वतःचे API आहेत, त्यांच्या स्वतःच्या लाँच पद्धती, तत्त्वे आहेत, काहींना शेड्यूलर आहेत, इतरांकडे नाही - आम्ही एक साधन लिहित आहोत AppSec ऑर्केस्ट्रेटर, जे तुम्हाला उत्पादनाच्या संपूर्ण प्रक्रियेमध्ये एकल एंट्री पॉइंट तयार करण्यास आणि एका बिंदूपासून व्यवस्थापित करण्यास अनुमती देते.

व्यवस्थापक, विकासक आणि सुरक्षा अभियंत्यांकडे एक एंट्री पॉइंट असतो ज्यावरून ते काय चालू आहे ते पाहू शकतात, स्कॅन कॉन्फिगर करू शकतात आणि चालवू शकतात, स्कॅन परिणाम प्राप्त करू शकतात आणि आवश्यकता सबमिट करू शकतात. आम्ही कागदोपत्री कामापासून दूर जाण्याचा, विकासाद्वारे वापरल्या जाणार्‍या प्रत्येक गोष्टीचे मानवी रुपात भाषांतर करण्याचा प्रयत्न करत आहोत - स्थिती आणि मेट्रिक्ससह संगमावरील पृष्ठे, जिरामधील दोष किंवा विविध दोष ट्रॅकर्समध्ये किंवा CI मधील समकालिक/असिंक्रोनस प्रक्रियेमध्ये एकत्रीकरण /सीडी.

महत्वाचे मुद्दे

साधने ही मुख्य गोष्ट नाही. प्रथम प्रक्रियेचा विचार करा - नंतर साधने अंमलात आणा. साधने चांगली पण महाग आहेत, त्यामुळे तुम्ही प्रक्रियेपासून सुरुवात करू शकता आणि विकास आणि सुरक्षितता यांच्यात संवाद आणि समज निर्माण करू शकता. सुरक्षेच्या दृष्टिकोनातून, सर्वकाही "थांबवण्याची" गरज नाही. विकासाच्या दृष्टिकोनातून, जर काही उच्च मेगा सुपर क्रिटिकल असेल, तर ते काढून टाकणे आवश्यक आहे, आणि समस्येकडे डोळेझाक करू नका.

उत्पादन गुणवत्ता - सामान्य ध्येय सुरक्षा आणि विकास दोन्ही. आम्ही एक गोष्ट करतो, आम्ही हे सुनिश्चित करण्याचा प्रयत्न करतो की सर्वकाही योग्यरित्या चालते आणि कोणतीही प्रतिष्ठा जोखीम किंवा आर्थिक नुकसान होणार नाही. म्हणूनच आम्ही संवाद सुधारण्यासाठी आणि उत्पादनाची गुणवत्ता सुधारण्यासाठी DevSecOps, SecDevOps दृष्टिकोनाचा प्रचार करतो.

तुमच्याकडे आधीपासून जे आहे त्यापासून सुरुवात करा: आवश्यकता, आर्किटेक्चर, आंशिक तपासणी, प्रशिक्षण, मार्गदर्शक तत्त्वे. सर्व प्रकल्पांना सर्व पद्धती त्वरित लागू करण्याची आवश्यकता नाही - पुनरावृत्तीने हलवा. कोणतेही एक मानक नाही - प्रयोग आणि भिन्न दृष्टिकोन आणि उपाय वापरून पहा.

माहिती सुरक्षा दोष आणि कार्यात्मक दोष यांच्यात समान चिन्ह आहे.

सर्वकाही स्वयंचलित कराते हलते. जे हलत नाही ते हलवा आणि स्वयंचलित करा. जर एखादी गोष्ट हाताने केली असेल तर ती प्रक्रियेचा एक चांगला भाग नाही. कदाचित त्याचे पुनरावलोकन करणे आणि ते स्वयंचलित करणे देखील योग्य आहे.

आयएस संघाचा आकार लहान असल्यास - सुरक्षा चॅम्पियन्स वापरा.

कदाचित मी ज्याबद्दल बोललो ते तुम्हाला शोभणार नाही आणि तुम्ही तुमचे स्वतःचे काहीतरी घेऊन याल - आणि ते चांगले आहे. परंतु तुमच्या प्रक्रियेच्या आवश्यकतांवर आधारित साधने निवडा. हे साधन वाईट आणि हे चांगलं असं समाज काय म्हणतो ते बघू नका. कदाचित आपल्या उत्पादनासाठी उलट सत्य असेल.

साधनांसाठी आवश्यकता.

• निम्न पातळी खोटे सकारात्मक.
• पुरेसा विश्लेषण वेळ.
• उपयोग सहज.
• एकत्रीकरणांची उपलब्धता.
• उत्पादन विकास रोडमॅप समजून घेणे.
• साधने सानुकूलित करण्याची शक्यता.

DevOpsConf 2018 मध्ये युरीचा अहवाल सर्वोत्कृष्ट म्हणून निवडला गेला. आणखी मनोरंजक कल्पना आणि व्यावहारिक प्रकरणांशी परिचित होण्यासाठी, 27 आणि 28 मे रोजी Skolkovo येथे या DevOpsConf आत उत्सव RIT++. अजून चांगले, तुम्ही तुमचा अनुभव शेअर करायला तयार असाल तर लागू करा 21 एप्रिलपर्यंत अहवालासाठी.

स्त्रोत: www.habr.com