विकास में एक स्थैतिक विश्लेषक को कैसे लागू किया जाए ताकि हर कोई खुश हो?

इस प्रक्रिया में, हमें अक्सर यह सवाल पूछा जाता है: विकास में एक स्थिर विश्लेषक को कैसे लागू किया जाए ताकि सब कुछ ठीक हो जाए। हमने पहले से ही इस बारे में बात की थी कि सुरक्षित विकास के लिए एक स्थिर विश्लेषक की आवश्यकता क्यों है। यह लेख उपयोगी होगा यदि आप एक स्थिर विश्लेषक चुन रहे हैं या पहले से ही इसे लागू करने की योजना बना रहे हैं। प्रक्रिया कैसे स्थापित करें ताकि कोड में खोजी गई कमजोरियां आखिरकार तय हों? इस लेख में हम आपको इस मुद्दे से निपटने में मदद करने की कोशिश करेंगे।

क्या आना है?

विश्लेषक को इस तरह से लागू करना कि कमजोरियों को निश्चित रूप से तय किया जाए, यह कोई त्वरित मामला नहीं है। अनुभव से, हम कह सकते हैं कि कुछ हफ़्ते से लेकर कई महीनों तक का समय लगता है। यदि आप एक बड़ी कंपनी में विश्लेषक को लागू कर रहे हैं, तो अनुमोदन की एक श्रृंखला के लिए तैयार हो जाओ। आखिरकार, ये सैकड़ों कोड आधार हैं जिनका विश्लेषण करने की आवश्यकता है, और दर्जनों टीम अपने स्वयं के विकास के आदेश के साथ।

विकास के एक नए चरण - स्थैतिक विश्लेषण को जोड़ने के लिए, आपको यह अध्ययन करना होगा कि प्रत्येक टीम की प्रक्रिया कैसे काम करती है और एक ऐसे समाधान का प्रस्ताव करती है जो सभी के लिए सुविधाजनक हो। छोटी कंपनियों में, स्थापित विकास क्रम बिल्कुल भी मौजूद नहीं हो सकता है। विश्लेषक का कार्यान्वयन एक प्रक्रिया के निर्माण के लिए एक बहाना हो सकता है। एकीकरण के लिए नरम होने के लिए, हम आपको यह पता लगाने की सलाह देते हैं कि किस विश्लेषक के पास इसके लिए क्षमताएं हैं।

एकीकरण विकल्प क्या हैं?

आमतौर पर, विश्लेषक किसी भी प्रक्रिया में एकीकरण के लिए एक गैर-ग्राफिकल इंटरफ़ेस (CLI, REST) ​​मानता है। तैयार किए गए एकीकरण के साथ विश्लेषक हैं: बिल्ड टूल और विकास वातावरण के साथ, संस्करण नियंत्रण प्रणाली (Git, SVN), CI / CD सर्वर (जेनकिंस, टीमसिटी, TFS), परियोजना प्रबंधन प्रणाली (Jira) और उपयोगकर्ता प्रबंधन (सक्रिय निर्देशिका) के साथ। आपकी कंपनी के लिए जितना उपयोगी होगा, सब कुछ सेट करना उतना ही आसान होगा।

आप एक प्रक्रिया कैसे बना सकते हैं?

मानक स्थिति पर विचार करें: इसमें शामिल विभाग सूचना सुरक्षा, रिहाई प्रबंधन और विकास हैं। एक नियम के रूप में, विश्लेषक कार्यान्वयन का ग्राहक सूचना सुरक्षा (आईएस) है। कार्य इस बात पर सहमत है कि कौन, कब और क्या करेगा। हम निम्नलिखित चरणों को भेद करते हैं: विश्लेषण शुरू करते हैं, विश्लेषण के परिणामों की प्रक्रिया करते हैं, भेद्यता को ठीक करने के लिए अनुरोध बनाते हैं, भेद्यता को ठीक करते हैं, सुधार की जांच करते हैं । प्रत्येक चरण पर अधिक विस्तार से विचार करें।

चरण 1. विश्लेषण चलाएँ

आप मैन्युअल रूप से या स्वचालित रूप से विश्लेषण चला सकते हैं। दृष्टिकोण के अपने पक्ष और विपक्ष हैं।

मैन्युअल रूप से

उन्होंने खुद विश्लेषक को याद किया, उन्होंने खुद कोड डाउनलोड किया, उन्होंने जाकर परिणामों को देखा।



यदि कंपनी में लगभग एक दर्जन परियोजनाएं हैं और एक सुरक्षा अधिकारी को निगरानी सुरक्षा सौंपी जाती है, तो ऐसा परिदृश्य संभव है। यदि लगभग सौ परियोजनाएं हैं, तो आपको स्वचालन को कॉन्फ़िगर करने की आवश्यकता है।

स्वचालित

यह निर्धारित करें कि आपको कितनी बार और किस बिंदु पर कोड का विश्लेषण करने की आवश्यकता है। उदाहरण के लिए, किसी दिए गए शेड्यूल (सप्ताह में एक बार) या प्रत्येक परिवर्तन के बाद, उत्पादक वातावरण में प्रवेश करने से पहले।

यदि एप्लिकेशन शायद ही कभी अपडेट किया जाता है, लेकिन आपको इसकी सुरक्षा की निगरानी करने की भी आवश्यकता है, यदि कोई परिवर्तन हो तो विश्लेषण को कॉन्फ़िगर करें।

यदि बहुत से लोग कोड पर काम करते हैं, तो कई शाखाएं बनाई जाती हैं, अक्सर परिवर्तन होते हैं - अक्सर विश्लेषण करना बेहतर होता है, लेकिन विकास में हस्तक्षेप नहीं करते हैं। उदाहरण के लिए, मुख्य शाखा के साथ मर्ज अनुरोध बनाने के समय या जब इस शाखा पर कार्य की स्थिति बदलती है। एक संस्करण नियंत्रण प्रणाली के साथ या एक परियोजना प्रबंधन प्रणाली के साथ एकीकरण आपको इसमें मदद करेगा। CI / CD के साथ एकीकरण बिल्ड चरणों में से एक का विश्लेषण करेगा।

शेड्यूल सेट करें ताकि आपके पास परिणामों को संसाधित करने का समय हो।

चरण 2. विश्लेषण के परिणामों की प्रक्रिया करें

डेवलपर्स को मिली सभी कमजोरियों को तुरंत ठीक करने का निर्देश न दें। सुरक्षा अधिकारी पहले उन्हें सत्यापित करने दें। पहले विश्लेषण के परिणाम विवादास्पद लग सकते हैं: दर्जनों महत्वपूर्ण, सैकड़ों कम महत्वपूर्ण कमजोरियां और हजारों झूठी सकारात्मक। यहाँ क्या करना है? हम धीरे-धीरे कमजोरियों को ठीक करने की सलाह देते हैं। अंतिम लक्ष्य पुराने कोड और नए दोनों में कमजोरियों की अनुपस्थिति को प्राप्त करना है। प्रारंभिक चरण में, महत्वपूर्ण को सत्यापित करें (अभी भी उनके साथ असुरक्षित) और नई कमजोरियों (नए कोड को ठीक करना आसान है)।

फ़िल्टर का उपयोग करें। भाषा, फ़ाइल और निर्देशिका द्वारा गंभीरता से कमजोरियों को क्रमबद्ध करें। अधिक उन्नत उपकरण आपको केवल नए कोड में कमजोरियां दिखाएंगे, तीसरे पक्ष के पुस्तकालयों में कमजोरियों को छिपाएंगे। फिल्टर लगाए गए हैं, लेकिन क्या अभी भी कई कमजोरियां हैं?

सबसे संभावित कमजोरियों को देखें। ऐसे विश्लेषक हैं जो एक झूठे सकारात्मक की संभावना का मूल्यांकन करते हैं। यदि कई कमजोरियां हैं, और सभी के लिए महत्वपूर्ण स्तर लगभग समान है, तो इस मीट्रिक का उपयोग करके परिणामों को फ़िल्टर करें। तो आप जल्दी से सबसे अधिक संभावित कमजोरियों को संसाधित करते हैं (नीचे स्क्रीनशॉट देखें)।



सत्यापन की स्थिति का उपयोग करें। सत्यापन परिणामों पर कब्जा करने के लिए, आमतौर पर विश्लेषणकर्ता भेद्यता के लिए स्थितियों के साथ काम करने की पेशकश करते हैं: एक झूठी सकारात्मक के रूप में पुष्टि करें या अस्वीकार करें। एक नियम के रूप में, किए गए कार्य को rescan के दौरान संरक्षित किया जाना चाहिए।

चरण 3. एक भेद्यता फिक्स अनुरोध बनाएँ

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

यदि सुरक्षा अधिकारी परिणामों की समीक्षा और पुष्टि करता है, तो पुष्टि की गई कमजोरियों के और सुधार के लिए आमतौर पर एक कार्य निर्धारित करने की आवश्यकता होती है। हमने बार-बार इस तथ्य का सामना किया है कि यह इस कदम पर था कि कठिनाइयां पैदा हुईं।

अनुरोध फॉर्म

ऐसी कंपनियां हैं जिनमें परियोजना प्रबंधन प्रणाली (उदाहरण के लिए, जीरा) में चरण के लिए बड़े कार्य निर्धारित किए गए हैं। और उप-मुखौटे और बग के लिए, उदाहरण के लिए, गिटलैब इश्यू का उपयोग किया जाता है, जिसके लिए केवल टीम लीडर और उसकी टीम की पहुंच होती है। यह भी होता है कि परियोजना प्रबंधन प्रणाली में एक अलग कार्य बनाए बिना विधानसभा असंभव है। विश्लेषक में एकीकरण हो सकते हैं जिसके साथ आप इंटरफ़ेस में तुरंत आवश्यक प्रश्न बना सकते हैं।

अक्सर कई विकास समूहों के साथ एक ही कंपनी के भीतर, उनमें से प्रत्येक के पास कार्य कार्यों को लागू करने की अपनी प्रक्रिया है। और आपको सभी के लिए अनुकूल होने की आवश्यकता है। प्रश्न उठते हैं:

• क्या यह कमजोरियों को ठीक करने के लिए एक अलग परियोजना को आवंटित करने या मौजूदा वाले कार्यों को बनाने के लिए इसके लायक है?
• भेद्यता एक परिचित बग या एक नई इकाई है?
• प्रत्येक भेद्यता या समान समूह के लिए एक अलग कार्य बनाएं?
• मुझे समस्या के विवरण के रूप में क्या देना चाहिए: विश्लेषक इंटरफ़ेस या कोड में एक जगह पर एक भेद्यता का लिंक और समस्या का संक्षेप में वर्णन करें?
• और क्या डेवलपर को परिणामों तक पहुंच की आवश्यकता है - बस एक पीडीएफ रिपोर्ट पाठ के साथ भेजें "देखें पृष्ठ 257 ”और यह पर्याप्त है?

बेशक, यह इस बात पर निर्भर करता है कि टीम में प्रक्रिया को कैसे समायोजित किया जाता है, किस ट्रैकिंग सिस्टम का उपयोग किया जाता है।

यदि कोड उन ठेकेदारों द्वारा लिखा गया है जिनके लिए आंतरिक प्रणालियों तक पहुंच न्यूनतम है, तो पीडीएफ रिपोर्ट वाली योजना उपयुक्त है। आमतौर पर, एक रिपोर्ट के लिए, आप उन कमजोरियों का चयन कर सकते हैं जो आपके लिए रुचि रखते हैं और तुरंत उन्हें विश्लेषक इंटरफ़ेस से वांछित पते पर भेज दें।

यदि कोई कंपनी एक निश्चित प्रकार के संसाधनों के साथ एक निश्चित प्रकार के कार्यों के लिए एक परियोजना बनाए बिना एक भी कदम नहीं उठा सकती है, तो आपको अपने सिस्टम के लिए एकीकरण के साथ एक उपकरण की तलाश करनी चाहिए। सबसे लचीला एकीकरण आपके लिए कार्य का विवरण उत्पन्न करेगा (वे संस्करण नियंत्रण प्रणाली में स्रोत कोड के लिंक के बारे में भी नहीं भूलेंगे) और आपको सभी आवश्यक फ़ील्ड भरने की अनुमति देगा। कार्य का प्रकार चुनें, माता-पिता, कलाकारों और यहां तक ​​कि रिलीज़ संस्करण भी निर्दिष्ट करें।

श्रम लागत और शर्तें

यदि टीम ने प्रत्येक कार्य के लिए श्रम लागत का आकलन करने का निर्णय लिया है, तो भेद्यता को ठीक करने का कार्य समान होना चाहिए। साथ ही, डेवलपर्स कमजोरियों को सत्यापित करते हैं। कभी-कभी इस कदम पर यह पता चलता है कि भेद्यता झूठी है या शोषण करना असंभव है।

लेकिन एक नियम के रूप में, संसाधन अभी भी सभी कमजोरियों को तुरंत ठीक करने के लिए पर्याप्त नहीं हैं। इसलिए, उनकी प्राथमिकताओं का समन्वय करना भी आवश्यक है।

कार्य श्रम लागत और प्राथमिकताओं द्वारा निर्धारित किए गए थे - फिर रिलीज की तारीखों के लिए जिम्मेदार (यह परियोजना प्रबंधक या एक ही टीम लीड हो सकता है) तय करते हैं कि क्या तय करना है और कब। सबसे पहले, विश्लेषक का उपयोग करते हुए, हम आपको सलाह देते हैं कि रिलीज को स्थगित न करें, अगर सभी कमजोरियां तय नहीं हुई हैं।

चरण 4. कमजोरियों को ठीक करें

संसाधनों को सही तरीके से कैसे आवंटित किया जाए: नए लोगों को जोड़ना या उन लोगों को सौंपना जो पहले से ही विकास में लगे हुए हैं, एक बजट मुद्दा है। एक बात सही है: यदि कंपनी विश्लेषक की स्थापना के लिए संसाधन आवंटित करती है, तो आपको कमजोरियों को ठीक करने की लागतों के लिए तैयार करने की आवश्यकता है। एक संभावित तरीका तकनीकी ऋण के साथ नौकरी के रूप में कमजोरियों को ठीक करने के लिए समय का प्रतिशत रखना है।

दो परिदृश्य हैं: विकास प्रक्रिया में या एक सुरक्षा अधिकारी के अनुरोध पर तुरंत सही। विकास के दौरान कमजोरियों को ठीक करना एक आदर्श परिदृश्य है। तुरंत मिल गया - तुरंत ठीक किया गया। मुख्य शाखा के साथ विलय का अनुरोध करने से पहले डेवलपर अपनी सुविधा शाखा को स्कैन करता है। यह एकीकरण के माध्यम से भी स्वचालित किया जा सकता है: विकास के माहौल के साथ, निर्माण उपकरण, संस्करण नियंत्रण प्रणाली, या सीआई / सीडी के साथ।

एक अन्य परिदृश्य सभी परिवर्तनों के बाद मुख्य विकास शाखा का विश्लेषण करना है। एक सुरक्षा अधिकारी या टीम लीडर परिणामों की समीक्षा करता है और कमजोरियों को ठीक करने के लिए कार्य करता है। यह परिदृश्य अधिक समय लेने वाला है। डेवलपर के इनपुट में स्रोत कोड, सुधार कार्य और विश्लेषण परिणाम होते हैं। एक डेवलपर के लिए, एक भेद्यता को ठीक करने का कार्य बग को ठीक करने से बहुत अलग नहीं है।

चरण 5. फिक्स को सत्यापित करें

आपको यह सुनिश्चित करने की ज़रूरत है कि भेद्यता वास्तव में तय हो गई है और इसकी जगह एक नया दिखाई नहीं दिया है। सही कोड के विश्लेषण के परिणाम हैं। क्या देखना है? भेद्यता की फाइल और लाइन नंबर? या भेद्यता नाम से खोज? यह संभव है और ऐसा है। लेकिन अगर कोड को बदल दिया गया था, तो भेद्यता के साथ लाइन शिफ्ट हो सकती है, और एक भेद्यता की कई घटनाएं हो सकती हैं। कुछ विश्लेषक "निश्चित" भेद्यता दिखा सकते हैं। सहमत हैं, इसलिए आप भेद्यता की जांच को तेजी से जांच सकते हैं (स्क्रीनशॉट देखें)।

उदाहरण

यहाँ दो संभावित परिदृश्य हैं।

परिदृश्य 1

टीम परियोजना नियंत्रण और कार्य प्रबंधन के लिए संस्करण नियंत्रण, जीरा के लिए गिट का उपयोग करती है। जेनकिंस बिल्ड शेड्यूल को कॉन्फ़िगर करता है। उदाहरण के लिए, दिन में एक बार यदि शाखा में परिवर्तन होते हैं। एक अतिरिक्त कदम के रूप में, विश्लेषक की शुरुआत का संकेत दिया जाता है।

सुरक्षा अधिकारी मुख्य शाखा (मास्टर या विकास) के विश्लेषण के परिणामों की समीक्षा करता है, और डेवलपर्स अपनी सुविधा शाखाओं की समीक्षा करते हैं।

यदि आवश्यक हो तो डेवलपर्स कमजोरियों को ठीक करते हैं। यदि विश्लेषक मांग पर कमजोरियों को फ़िल्टर कर सकता है: केवल नई कमजोरियों को दिखाएं या तीसरे पक्ष के पुस्तकालयों में कमजोरियों को न दिखाएं, किसी विशिष्ट निर्देशिका या फ़ाइल में कमजोरियों को दिखाएं - डेवलपर जल्दी से परिणाम उसके लिए दिलचस्प देख पाएंगे। इसलिए, सुधार की संभावना अधिक है।

सुरक्षा अधिकारी मुख्य शाखा के विश्लेषण के परिणामों की समीक्षा करता है। जीरा के साथ एकीकरण का उपयोग करते हुए, सुरक्षा अधिकारी विश्लेषक इंटरफ़ेस से भेद्यता प्रबंधन कार्य करता है। अगला समय सीमा और प्राथमिकताओं का समन्वय है।

जब भेद्यता तय हो जाती है और नया कोड सभी आंतरिक विकास चरणों (टीम लीड, उपयोगकर्ता और प्रतिगमन परीक्षण की समीक्षा) से गुजरता है, तो सुरक्षा अधिकारी को यह सुनिश्चित करना होगा कि भेद्यता अब नहीं है। लेखक पूर्ण कार्य को बंद कर देता है।

दृश्य २

कंपनी का कोड ठेकेदारों के एक समूह द्वारा लिखा गया है। Timlid ईमेल के माध्यम से डेवलपर्स के साथ बातचीत करता है और संस्करण नियंत्रण के लिए GitLab का उपयोग करता है। ठेकेदारों के पास आंतरिक परियोजना प्रबंधन प्रणाली (जीरा) तक पहुंच नहीं है।

सुरक्षा अधिकारी या टीम लीडर स्वयं मुख्य विकास शाखा के विश्लेषण के परिणामों की समीक्षा करता है। ठेकेदार के पास विश्लेषक तक पहुंच नहीं है। यदि ऐसी कमजोरियाँ हैं जिन्हें ठीक करने की आवश्यकता है, तो सुरक्षा अधिकारी टीम के नेता को या डेवलपर को तुरंत विश्लेषण के परिणामों के साथ एक पीडीएफ रिपोर्ट भेजता है।

रिपोर्ट से, डेवलपर को पता चलता है कि भेद्यता कहाँ पाई जाती है, इसमें क्या होता है और इसे कैसे तय किया जा सकता है। यह मूल्यवान है अगर असुरक्षित डेटा के प्रवाह (उदाहरण के लिए, SQL इंजेक्शन) से संबंधित कमजोरियों के लिए, वितरण योजना को रिपोर्ट में अनलोड किया जाएगा: डेटा स्रोत से फ़ंक्शन / विधि कॉल में उनके उपयोग के लिए (स्क्रीनशॉट देखें)।



भेद्यता को ठीक करने के बाद, टीम लीडर सुरक्षा अधिकारी को सूचित करता है कि यह रि-स्कैन के परिणामों की जांच करने का समय है।

और क्या जरूरी है?

सूचना सुरक्षा और विकास के बीच संपर्क स्थापित करना। यह महत्वपूर्ण है कि दोनों पक्ष कमजोरियों को ठीक करने में रुचि रखते हैं। खैर, अगर यह केवल अनुरोध नहीं होगा, बल्कि लाइव संचार भी होगा।

उपयोगकर्ता भूमिकाओं की उपेक्षा न करें। एक अच्छे विश्लेषक के पास अधिकारों में अंतर करने की क्षमता होनी चाहिए। यह संभावना नहीं है कि एक ठेकेदार को व्यवस्थापक अधिकारों या आंतरिक प्रणालियों के विश्लेषण के परिणामों की आवश्यकता होगी। परिणामों को संपादित करने के लिए - महत्वपूर्णता और स्थिति को बदलने के लिए - यह सुरक्षा अधिकारी और टीम को लीड करने की अनुमति देने के लिए पर्याप्त है। न्यूनतम विशेषाधिकार के सिद्धांत को रद्द नहीं किया गया है।

यदि कंपनी बड़ी है और उपयोगकर्ता प्रबंधन प्रणाली (उदाहरण के लिए, सक्रिय निर्देशिका) का उपयोग करती है, तो तैयार एकीकरण वाले उपकरणों पर विचार करें। आप कंपनी में स्वीकृत भूमिकाओं और समूहों का पुन: उपयोग कर पाएंगे और उन्हें आवश्यक अधिकार दे पाएंगे।

निष्कर्ष

एक विश्लेषक चुनने के बाद, इस तथ्य के लिए तैयार करें कि इसे अभी भी सही तरीके से लागू करने की आवश्यकता है। प्रतिभागियों के साथ बैठकों और समन्वय से डरो मत: प्रक्रिया में आप जितना बेहतर समझेंगे, परिणाम उतना ही उपयोगी होगा। यह महत्वपूर्ण है कि कार्य परिदृश्य को न केवल अनुमोदित किया जाता है, बल्कि पालन करना भी शुरू कर दिया जाता है।

एलिसैवेट्टा खारलामोवा, लीड एनालिस्ट, सोलर ऐपसेंसर द्वारा पोस्ट किया गया