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 - परिपक्वता मोडेलमा सुरक्षा निर्माण। पद्धतिको आधार भनेको एप्लिकेसन सुरक्षा प्रक्रियालाई ४ डोमेनमा विभाजन गर्नु हो: गभर्नेन्स, इन्टेलिजेन्स, SSDL टचपोइन्ट र डिप्लोइमेन्ट। प्रत्येक डोमेनमा 4 अभ्यासहरू छन्, जुन 12 गतिविधिहरूको रूपमा प्रतिनिधित्व गरिन्छ।

प्रत्येक 112 गतिविधिहरू छन् परिपक्वता को 3 स्तर: शुरुवात, मध्यवर्ती र उन्नत। सबै 12 अभ्यासहरू खण्डहरूमा अध्ययन गर्न सकिन्छ, तपाईका लागि महत्त्वपूर्ण कुराहरू चयन गर्दै, तिनीहरूलाई कसरी लागू गर्ने भनेर पत्ता लगाउँदै र बिस्तारै तत्वहरू थप्दै, उदाहरणका लागि, स्थिर र गतिशील कोड विश्लेषण वा कोड समीक्षा। तपाईंले योजना लेख्नुहोस् र चयन गरिएका गतिविधिहरू कार्यान्वयन गर्ने ढाँचाभित्र शान्तपूर्वक त्यस अनुसार काम गर्नुहोस्।

किन DevSecOps

DevOps एक समग्र ठूलो प्रक्रिया हो जसमा सुरक्षाको ख्याल गर्न आवश्यक छ।

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

मुख्य समस्या भनेको सूचना सुरक्षा विकास भन्दा फरक छ। सामान्यतया यो कुनै प्रकारको सूचना सुरक्षा सर्किट हो र यसमा २-३ ठूला र महँगो उपकरणहरू छन्। प्रत्येक छ महिनामा एक पटक, स्रोत कोड वा अनुप्रयोग जाँच गर्न आइपुग्छ, र वर्षमा एक पटक उत्पादन गरिन्छ पेन्टेस्टहरू। यी सबैले यस तथ्यलाई निम्त्याउँछ कि उद्योगको लागि रिलीज मिति स्थगित गरिएको छ, र विकासकर्ता स्वचालित उपकरणहरूबाट ठूलो संख्यामा कमजोरीहरूको सामना गर्दछ। यी सबैलाई छुट्याउन र मर्मत गर्न असम्भव छ, किनभने तिनीहरूले अघिल्लो छ महिनाको परिणामहरू क्रमबद्ध गरेका छैनन्, तर यहाँ नयाँ ब्याच छ।

हाम्रो कम्पनीको कामको प्रक्रियामा, हामी देख्छौं कि सबै क्षेत्र र उद्योगहरूमा सुरक्षाले बुझ्छ कि यो एक पाङ्ग्रामा विकासको साथ समात्ने र स्पिन गर्ने समय हो। चुस्त। DevSecOps प्रतिमान प्रत्येक रिलीज र पुनरावृत्तिमा चुस्त विकास पद्धति, कार्यान्वयन, समर्थन र सहभागितासँग पूर्ण रूपमा फिट हुन्छ।

DevSecOps मा संक्रमण

सुरक्षा विकास जीवनचक्रमा सबैभन्दा महत्त्वपूर्ण शब्द हो "प्रक्रिया"। तपाईंले औजारहरू खरिद गर्ने बारे सोच्नु अघि तपाईंले यो बुझ्नुपर्छ।

DevOps प्रक्रियामा उपकरणहरू मात्र समावेश गर्नु पर्याप्त छैन — प्रक्रियाका सहभागीहरू बीचको सञ्चार र समझ महत्त्वपूर्ण छ।

मान्छे धेरै महत्त्वपूर्ण छन्, उपकरण होइन।

अक्सर, सुरक्षित विकास प्रक्रियाको लागि योजना उपकरणको चयन र खरिदबाट सुरु हुन्छ, र हालको प्रक्रियामा उपकरणलाई एकीकृत गर्ने प्रयासमा समाप्त हुन्छ, जुन प्रयासहरू रहन्छ। यसले दुखद परिणामहरू निम्त्याउँछ, किनकि सबै उपकरणहरूको आफ्नै विशेषताहरू र सीमाहरू छन्।

एउटा सामान्य मामला भनेको सुरक्षा विभागले फराकिलो क्षमता भएको राम्रो, महँगो उपकरण छनोट गर्यो र यसलाई प्रक्रियामा एकीकृत गर्न विकासकर्ताहरूकहाँ आयो। तर यसले काम गर्दैन - प्रक्रिया यसरी बनाइएको छ कि पहिले नै खरिद गरिएको उपकरणको सीमाहरू हालको प्रतिमानमा फिट हुँदैन।

पहिले, तपाइँ कुन नतिजा चाहनुहुन्छ र प्रक्रिया कस्तो देखिनेछ भनेर वर्णन गर्नुहोस्। यसले तपाईंलाई प्रक्रियामा उपकरण र सुरक्षाको भूमिकाहरू बुझ्न मद्दत गर्नेछ।

पहिले नै प्रयोगमा छ संग सुरु गर्नुहोस्।

महँगो उपकरणहरू खरिद गर्नु अघि, तपाईंसँग पहिले नै के छ हेर्नुहोस्। प्रत्येक कम्पनीको विकासको लागि सुरक्षा आवश्यकताहरू छन्, त्यहाँ जाँचहरू छन्, पेन्टेस्टहरू छन् - किन यी सबैलाई सबैका लागि बुझ्न योग्य र सुविधाजनक फारममा रूपान्तरण नगर्ने?

सामान्यतया आवश्यकताहरू कागज ताल्मुड हो जुन शेल्फमा बस्छ। त्यहाँ एउटा मामला थियो जब हामी प्रक्रियाहरू हेर्नको लागि कम्पनीमा आएका थियौं र सफ्टवेयरको लागि सुरक्षा आवश्यकताहरू हेर्न सोध्यौं। विशेषज्ञ जसले यससँग व्यवहार गरे लामो समय बिताए:

- अब, नोटहरूमा कतै बाटो थियो जहाँ यो कागजात छ।

नतिजाको रूपमा, हामीले कागजात एक हप्ता पछि प्राप्त गर्यौं।

आवश्यकताहरू, जाँचहरू, इत्यादिको लागि, उदाहरणमा एउटा पृष्ठ सिर्जना गर्नुहोस्। संगोष्ठी - यो सबैको लागि सुविधाजनक छ।

तपाईंसँग पहिले नै भएको कुरालाई पुन: फर्म्याट गर्न र सुरु गर्न प्रयोग गर्न सजिलो छ।

सुरक्षा च्याम्पियनहरू प्रयोग गर्नुहोस्

सामान्यतया, एक औसत कम्पनीमा, 100-200 विकासकर्ताहरूको लागि, त्यहाँ एक सुरक्षा विशेषज्ञ हो जसले धेरै प्रकार्यहरू प्रदर्शन गर्दछ र शारीरिक रूपमा सबै कुरा जाँच गर्न समय छैन। उसले सक्दो प्रयास गरे पनि विकासले उत्पन्न गर्ने सबै कोडलाई एक्लै जाँच्न सक्दैन। त्यस्ता केसहरूको लागि एक अवधारणा विकसित गरिएको छ। सुरक्षा च्याम्पियन्स.

सुरक्षा च्याम्पियनहरू विकास टोली भित्रका मानिसहरू हुन् जो तपाईंको उत्पादनको सुरक्षामा रुचि राख्छन्।

सुरक्षा च्याम्पियन विकास टोलीमा प्रवेश बिन्दु हो र एक सुरक्षा प्रचारक एकमा रोल गरिएको छ।

सामान्यतया, जब सुरक्षा विशेषज्ञ विकास टोलीमा आउँछन् र कोडमा त्रुटि औंल्याउछन्, उसले अचम्मको जवाफ प्राप्त गर्दछ:

- अनि तिमी को हौ? म तिमीलाई पहिलो पटक देख्दै छु। मसँग सबै ठीक छ - मेरो वरिष्ठ साथीले मलाई कोड समीक्षामा "आवेदन" दिनुभयो, हामी अगाडि बढ्छौं!

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

साथै, विकासकर्ताहरूलाई उनीहरूको कोड कुनै पनि सुरक्षा विशेषज्ञ भन्दा राम्रोसँग थाहा छ। एक व्यक्ति को लागि जो एक स्थिर विश्लेषण उपकरण मा कम्तिमा 5 परियोजनाहरु छ, यो सामान्यतया सबै सूक्ष्मताहरु सम्झना गाह्रो छ। सुरक्षा च्याम्पियनहरूलाई उनीहरूको उत्पादन थाहा छ: कुन कुरासँग अन्तर्क्रिया गर्छ र पहिले के हेर्ने - तिनीहरू बढी प्रभावकारी छन्।

त्यसैले सुरक्षा च्याम्पियनहरू लागू गर्ने र आफ्नो सुरक्षा टोलीको प्रभाव विस्तार गर्ने बारे विचार गर्नुहोस्। यो च्याम्पियन आफैंको लागि पनि उपयोगी छ: नयाँ क्षेत्रमा व्यावसायिक विकास, आफ्नो प्राविधिक क्षितिज विस्तार, प्राविधिक, व्यवस्थापकीय र नेतृत्व कौशल स्तरवृद्धि, बजार मूल्य वृद्धि। यो सामाजिक ईन्जिनियरिङ् को केहि तत्व हो, विकास टोली मा तपाइँको "आँखा"।

परीक्षण चरणहरू

20 देखि 80 प्रतिमान २०% प्रयासले ८०% नतिजा दिन्छ भनी बताउँछ। यो 20% अनुप्रयोग विश्लेषण अभ्यासहरू हुन् जुन स्वचालित हुन सक्छ र हुनुपर्छ। त्यस्ता गतिविधिहरूको उदाहरणहरू स्थिर विश्लेषण हुन्। SAST, गतिशील विश्लेषण - DAST и खुला स्रोत नियन्त्रण। म तपाईंलाई गतिविधिहरू बारे थप जानकारी दिनेछु, साथै उपकरणहरूको बारेमा, प्रक्रियामा परिचय गराउँदा हामीले प्राय: कस्ता सुविधाहरू सामना गर्छौं, र यसलाई कसरी सही रूपमा गर्ने।

उपकरणको मुख्य समस्याहरू

म समस्याहरू हाइलाइट गर्नेछु जुन सबै उपकरणहरूको लागि सान्दर्भिक छ र ध्यान आवश्यक छ। म तिनीहरूलाई थप विस्तारमा विश्लेषण गर्नेछु ताकि आफैलाई थप दोहोर्याउन नपरोस्।

लामो विश्लेषण समय। यदि सबै परीक्षणहरू र एसेम्बलीका लागि रिलीज गर्न कमिटबाट 30 मिनेट लाग्छ भने, सूचना सुरक्षा जाँचहरूले एक दिन लिनेछ। यसरी प्रक्रियालाई कसैले ढिलो गर्दैन। यो सुविधालाई ध्यानमा राख्नुहोस् र आफ्नो निष्कर्ष निकाल्नुहोस्।

उच्च स्तरको गलत नकारात्मक वा गलत सकारात्मक। सबै उत्पादनहरू फरक छन्, सबै फरक फ्रेमवर्कहरू प्रयोग गर्छन् र तिनीहरूको आफ्नै कोडिङ शैली छ। विभिन्न कोडबेस र प्रविधिहरूमा, उपकरणहरूले गलत नकारात्मक र गलत सकारात्मक को विभिन्न स्तरहरू देखाउन सक्छन्। त्यसोभए वास्तवमा के छ हेर्नुहोस् तिम्रो कम्पनीहरु र को लागी तिम्रो अनुप्रयोगहरूले राम्रो र भरपर्दो परिणामहरू देखाउनेछन्।

अवस्थित उपकरणहरूसँग कुनै एकीकरण छैन। तपाईंले पहिले नै प्रयोग गरिरहनुभएको कुरासँग एकीकरणको दृष्टिकोणबाट उपकरणहरू हेर्नुहोस्। उदाहरणका लागि, यदि तपाईंसँग Jenkins वा TeamCity छ भने, यो सफ्टवेयरसँग उपकरणहरूको एकीकरण जाँच गर्नुहोस्, र GitLab CI सँग होइन, जुन तपाईंले प्रयोग गर्नुहुन्न।

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

कुनै उत्पादन विकास रोडम्याप छैन। विकास स्थिर रहँदैन, हामी सधैं नयाँ फ्रेमवर्क र प्रकार्यहरू प्रयोग गर्दैछौं, पुरानो कोडलाई नयाँ भाषाहरूमा पुन: लेख्दै। हामी यो सुनिश्चित गर्न चाहन्छौं कि हामीले खरिद गर्ने उपकरणले नयाँ फ्रेमवर्क र प्रविधिहरूलाई समर्थन गर्नेछ। त्यसकारण, यो जान्न महत्त्वपूर्ण छ कि उत्पादनमा वास्तविक र सही छ Roadmap विकास।

प्रकृया सुविधाहरू

उपकरणका सुविधाहरूको अतिरिक्त, विकास प्रक्रियाका सुविधाहरूलाई ध्यानमा राख्नुहोस्। उदाहरणका लागि, विकासको बाटोमा लाग्नु सामान्य गल्ती हो। हेरौं कुन अन्य सुविधाहरूलाई ध्यानमा राख्नुपर्छ र सुरक्षा टोलीले केमा ध्यान दिनुपर्छ।

विकास र रिलीज डेडलाइन नछुटाउनको लागि, सिर्जना गर्नुहोस् विभिन्न नियमहरू र विभिन्न रोक्नेहरू देखाउनुहोस् - यदि कमजोरीहरू छन् भने निर्माण प्रक्रिया रोक्नको लागि मापदण्ड - विभिन्न वातावरण को लागी। उदाहरणका लागि, हामी बुझ्छौं कि हालको शाखा विकास स्ट्यान्ड वा UAT मा जान्छ, जसको मतलब हामी रोक्दैनौं र यसो भन्छौं:

- तपाईंसँग यहाँ कमजोरीहरू छन्, तपाईं कतै जानुहुने छैन!

यस चरणमा, विकासकर्ताहरूलाई बताउन महत्त्वपूर्ण छ कि त्यहाँ सुरक्षा समस्याहरू छन् जुन ध्यान दिन लायक छन्।

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

- साथीहरू, तपाईलाई समस्या छ, कृपया तिनीहरूलाई ध्यान दिनुहोस्।

UAT चरणमा हामी फेरि कमजोरीहरूको बारेमा चेतावनीहरू देखाउँछौं, र रिलीज चरणमा हामी भन्छौं:

- साथीहरू, हामीले तपाईंलाई धेरै पटक चेतावनी दियौं, तपाईंले केही गर्नुभएन - हामी तपाईंलाई यसबाट बाहिर जान दिने छैनौं।

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

मानौं हामीसँग एक निश्चित कार्यात्मक दोष छ - जसरी अनुप्रयोगले काम गर्नु हुँदैन: पैसा हस्तान्तरण हुँदैन, जब तपाइँ बटनमा क्लिक गर्नुहुन्छ त्यहाँ अर्को पृष्ठमा कुनै संक्रमण हुँदैन, वा उत्पादन लोड हुँदैन। सुरक्षा त्रुटिहरू - यी समान दोषहरू हुन्, तर अनुप्रयोग सञ्चालनको सर्तमा होइन, तर सुरक्षामा।

सबै सफ्टवेयर गुणस्तर समस्याहरू सुरक्षा समस्याहरू होइनन्। तर सबै सुरक्षा समस्याहरू सफ्टवेयर गुणस्तरसँग सम्बन्धित छन्। शेरिफ मन्सुर, एक्सपेडिया।

सबै कमजोरीहरू त्रुटिहरू भएकाले, तिनीहरू सबै विकास त्रुटिहरू जस्तै ठाउँमा अवस्थित हुनुपर्छ। त्यसैले कसैले नपढ्ने रिपोर्टहरू र डरलाग्दो पीडीएफहरू बिर्सनुहोस्।

जब म एक विकास कम्पनीमा काम गरिरहेको थिएँ, मैले स्थिर विश्लेषण उपकरणहरूबाट रिपोर्ट प्राप्त गरें। मैले यसलाई खोलें, डराए, कफी बनाए, 350 पृष्ठहरू पल्टाए, यसलाई बन्द गरे र काममा लागें। ठूला रिपोर्टहरू मृत रिपोर्टहरू हुन्। सामान्यतया तिनीहरू कतै जाँदैनन्, इमेलहरू मेटाइएका छन्, बिर्सिएका छन्, हराइएका छन्, वा व्यवसायले जोखिम लिइरहेको छ भन्दछ।

के गर्ने? हामीले फेला परेका पुष्टि भएका दोषहरूलाई विकासका लागि सुविधाजनक फारममा रूपान्तरण गर्छौं, उदाहरणका लागि, हामीले तिनीहरूलाई जिरामा ब्याकलगमा राख्छौं। हामी दोषहरूलाई प्राथमिकता दिन्छौं र कार्यात्मक दोषहरू र परीक्षण त्रुटिहरू जस्तै प्राथमिकताको क्रममा तिनीहरूलाई हटाउँछौं।

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

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

दृष्टिकोण को लाभ: विकासको प्रारम्भिक चरणमा कोडमा कमजोरीहरू पहिचान गर्दैजब त्यहाँ कुनै स्ट्यान्ड वा तयार उपकरणहरू छैनन्, र वृद्धिशील स्क्यानिङ क्षमता: परिवर्तन भएको कोडको खण्ड स्क्यान गर्दै र हामीले हाल गरिरहनुभएको सुविधा मात्र स्क्यान गर्ने समय घटाउँछ।

Минусы - यो आवश्यक भाषाहरूको लागि समर्थनको अभाव हो।

आवश्यक एकीकरण, जुन उपकरणहरूमा हुनुपर्छ, मेरो व्यक्तिपरक विचारमा:

• एकीकरण उपकरण: Jenkins, TeamCity र Gitlab CI।
• विकास वातावरण: Intellij IDEA, भिजुअल स्टुडियो। यो एक विकासकर्ताको लागि अझै पनि याद गर्न आवश्यक एक बुझ्न नसकिने इन्टरफेस नेभिगेट गर्न को लागी अधिक सुविधाजनक छ, तर सबै आवश्यक एकीकरण र कमजोरीहरु को लागी उसले आफ्नो विकास वातावरण मा आफ्नो कार्यस्थल मा फेला पारेको छ।
• कोड समीक्षा: SonarQube र म्यानुअल समीक्षा।
• दोष ट्र्याकरहरू: जिरा र बगजिला।

तस्वीरले स्थिर विश्लेषणका केही उत्कृष्ट प्रतिनिधिहरू देखाउँछ।

यो महत्त्वपूर्ण उपकरणहरू होइन, तर प्रक्रिया हो, त्यसैले त्यहाँ खुला स्रोत समाधानहरू छन् जुन प्रक्रिया परीक्षणको लागि पनि राम्रो छन्।

SAST खुला स्रोतले ठूलो संख्यामा भेद्यता वा जटिल डेटाफ्लोहरू फेला पार्दैन, तर तिनीहरू प्रक्रिया निर्माण गर्दा प्रयोग गर्न सकिन्छ। तिनीहरूले तपाइँलाई प्रक्रिया कसरी बनाइनेछ भनेर बुझ्न मद्दत गर्दछ, कसले बगहरूमा प्रतिक्रिया दिनेछ, कसले रिपोर्ट गर्नेछ, कसले रिपोर्ट गर्नेछ। यदि तपाइँ आफ्नो कोडको सुरक्षा निर्माणको प्रारम्भिक चरण पूरा गर्न चाहनुहुन्छ भने, खुला स्रोत समाधानहरू प्रयोग गर्नुहोस्।

यदि तपाईं आफ्नो यात्राको सुरुमा हुनुहुन्छ र केहि पनि छैन भने यसलाई कसरी एकीकृत गर्न सकिन्छ: न त CI, न Jenkins, न TeamCity? प्रक्रियामा एकीकरणलाई हेरौं।

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

यदि तपाइँसँग Bitbucket वा GitLab छ भने, तपाइँ मा एकीकृत गर्न सक्नुहुन्छ समवर्ती संस्करण प्रणाली.

घटना द्वारा - पुल अनुरोध, प्रतिबद्ध। तपाईंले कोड स्क्यान गर्नुभयो र सुरक्षा जाँच पास भयो वा असफल भयो भनी निर्माण स्थितिमा देखाउनुहोस्।

प्रतिक्रिया। निस्सन्देह, प्रतिक्रिया सधैं आवश्यक छ। यदि तपाईंले भर्खरै सुरक्षा पक्षमा सुरक्षा गर्नुभयो भने, यसलाई एउटा बाकसमा राख्नुभयो र कसैलाई यसबारे केही नभन्नुभयो, र त्यसपछि महिनाको अन्त्यमा बगहरूको गुच्छा फ्याँकिनुभयो, यो सही छैन र राम्रो छैन।

कोड समीक्षा प्रणाली संग एकीकरण

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

SonarQube संग एकीकरण

धेरैसँग छ गुणस्तर गेट कोड गुणस्तर द्वारा। यहाँ पनि उस्तै छ - तपाईंले SAST उपकरणहरूको लागि मात्र उही गेटहरू गर्न सक्नुहुन्छ। त्यहाँ एउटै इन्टरफेस हुनेछ, एउटै गुणस्तर गेट, मात्र यो भनिन्छ सुरक्षा गेट। र त्यसैगरी, यदि तपाईंसँग SonarQube प्रयोग गर्ने प्रक्रिया छ भने, तपाईं सजिलैसँग त्यहाँ सबै कुरा एकीकृत गर्न सक्नुहुन्छ।

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

यहाँ सबै कुरा पनि एकदम सरल छ:

• अटोटेस्टको रूपमा समान स्तरमा, एकाइ परीक्षण।
• विकास चरणहरू द्वारा विभाजन: देव, परीक्षण, उत्पादन। नियमहरूको विभिन्न सेटहरू वा विभिन्न असफल अवस्थाहरू समावेश गर्न सकिन्छ: असेंबली रोक्नुहोस्, सम्मेलन रोक्न नगर्नुहोस्।
• सिंक्रोनस/एसिन्क्रोनस प्रक्षेपण। हामी सुरक्षा परीक्षणको अन्त्यको लागि पर्खिरहेका छौं कि छैन। त्यो हो, हामीले भर्खरै तिनीहरूलाई सुरु गर्यौं र अगाडि बढ्छौं, र त्यसपछि हामी सबै कुरा राम्रो वा नराम्रो छ भन्ने स्थिति पाउँछौं।

यो सबै एक उत्तम गुलाबी संसारमा छ। वास्तविक जीवनमा त्यस्तो केही छैन, तर हामी यसको लागि प्रयास गर्छौं। चलिरहेको सुरक्षा जाँचको नतिजा एकाइ परीक्षणको नतिजा जस्तै हुनुपर्छ।

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

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

सुरक्षा गेटको एक उदाहरण कोडमा कमजोरीहरूको उपस्थिति र संख्याको सन्दर्भमा गुणस्तर गेटको एनालग हो।

हामी SonarQube सँग एकीकृत गर्छौं - प्लगइन स्थापित छ, सबै कुरा धेरै सुविधाजनक र राम्रो छ।

विकास वातावरण संग एकीकरण

एकीकरण विकल्प:

• प्रतिबद्ध गर्नु अघि विकास वातावरणबाट स्क्यान सुरु गर्दै।
• नतिजाहरू हेर्नुहोस्।
• परिणामहरूको विश्लेषण।
• सर्भरसँग सिंक्रोनाइजेसन।

यो सर्भरबाट परिणामहरू प्राप्त गर्न जस्तो देखिन्छ।

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

खुला स्रोत

यो मेरो मनपर्ने विषय हो। सबैजनाले खुला स्रोत पुस्तकालयहरू प्रयोग गर्छन् - सबै कुरा पहिले नै कार्यान्वयन भएको रेडिमेड लाइब्रेरी लिन सक्नुहुँदा बैसाखी र साइकलको गुच्छा किन लेख्ने?

निस्सन्देह, यो सत्य हो, तर पुस्तकालयहरू पनि मानिसहरूद्वारा लेखिएका हुन्छन्, निश्चित जोखिमहरू पनि समावेश हुन्छन्, र समय-समयमा वा निरन्तर रूपमा रिपोर्ट गरिएका जोखिमहरू पनि समावेश हुन्छन्। त्यसकारण, त्यहाँ अनुप्रयोग सुरक्षामा अर्को चरण छ - यो खुला स्रोत घटकहरूको विश्लेषण हो।

खुला स्रोत विश्लेषण - OSA

उपकरणले तीन ठूला चरणहरू समावेश गर्दछ।

पुस्तकालयहरूमा कमजोरीहरू खोज्दै। उदाहरणका लागि, उपकरणलाई थाहा छ कि हामीले केही पुस्तकालय प्रयोग गरिरहेका छौं, र त्यो CVE वा त्यहाँ बग ट्र्याकरहरूमा केही कमजोरीहरू छन् जुन पुस्तकालयको यस संस्करणसँग सम्बन्धित छन्। जब तपाइँ यसलाई प्रयोग गर्ने प्रयास गर्नुहुन्छ, उपकरणले पुस्तकालय कमजोर छ भनेर चेतावनी जारी गर्नेछ र तपाइँलाई कमजोरी नभएको अर्को संस्करण प्रयोग गर्न सल्लाह दिन्छ।

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

औद्योगिक वातावरणमा प्रयोग हुने अवयवहरूको विश्लेषण। काल्पनिक अवस्थाको कल्पना गरौं: हामीले अन्ततः विकास पूरा गरेका छौं र हाम्रो माइक्रोसर्भिसको पछिल्लो रिलीज जारी गरेका छौं। उहाँ त्यहाँ अचम्मको रूपमा बस्नुहुन्छ - एक हप्ता, एक महिना, एक वर्ष। हामी यसलाई सङ्कलन गर्दैनौं, हामी सुरक्षा जाँचहरू सञ्चालन गर्दैनौं, सबै ठीक छ जस्तो देखिन्छ। तर अचानक, रिलिज भएको दुई हप्ता पछि, ओपन सोर्स कम्पोनेन्टमा एक महत्वपूर्ण कमजोरी देखा पर्दछ, जुन हामीले यो विशेष निर्माणमा औद्योगिक वातावरणमा प्रयोग गर्छौं। यदि हामीले यसलाई के र कहाँ प्रयोग गर्छौं भनेर रेकर्ड गर्दैनौं भने, हामीले यो कमजोरी देख्ने छैनौं। केही उपकरणहरूसँग पुस्तकालयहरूमा कमजोरीहरू निगरानी गर्ने क्षमता छ जुन हाल उद्योगमा प्रयोग गरिन्छ। यो धेरै उपयोगी छ।

विशेषताहरू:

• विकासका विभिन्न चरणहरूका लागि विभिन्न नीतिहरू।
• औद्योगिक वातावरणमा अनुगमन घटकहरू।
• संगठन भित्र पुस्तकालयहरूको नियन्त्रण।
• विभिन्न निर्माण प्रणाली र भाषाहरूको लागि समर्थन।
• डकर छविहरूको विश्लेषण।

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

एक मात्र मुक्त छ निर्भरता - जाँच OWASP बाट। तपाइँ यसलाई पहिलो चरणहरूमा खोल्न सक्नुहुन्छ, यसले कसरी काम गर्दछ र यसले के समर्थन गर्दछ हेर्नुहोस्। मूलतया, यी सबै क्लाउड उत्पादनहरू हुन्, वा आधारमा, तर तिनीहरूको आधार पछाडि तिनीहरू अझै इन्टरनेटमा पठाइन्छ। तिनीहरूले तपाईंको पुस्तकालयहरू होइन, तर ह्यासहरू वा तिनीहरूको आफ्नै मानहरू पठाउँछन्, जुन तिनीहरूले गणना गर्छन्, र तिनीहरूको सर्भरमा फिंगरप्रिन्टहरू भेद्यताहरूको उपस्थितिको बारेमा जानकारी प्राप्त गर्नका लागि।

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

परिधिमा पुस्तकालयहरूको नियन्त्रण, जुन बाह्य स्रोतहरूबाट डाउनलोड गरिन्छ। हामीसँग बाह्य र आन्तरिक भण्डारहरू छन्। उदाहरणका लागि, घटना केन्द्रले Nexus चलाउँछ, र हामी हाम्रो रिपोजिटरीमा "महत्वपूर्ण" वा "उच्च" स्थितिको साथ कुनै कमजोरीहरू नहोस् भन्ने चाहन्छौं। तपाईंले Nexus Firewall Lifecycle उपकरण प्रयोग गरेर प्रोक्सी कन्फिगर गर्न सक्नुहुन्छ ताकि त्यस्ता कमजोरीहरू काटियोस् र आन्तरिक भण्डारमा समाप्त नहोस्।

CI मा एकीकरण। अटोटेस्ट, एकाइ परीक्षण र विकास चरणहरूमा विभाजनको साथ समान स्तरमा: dev, test, prod। प्रत्येक चरणमा, तपाइँ कुनै पनि पुस्तकालयहरू डाउनलोड गर्न सक्नुहुन्छ, कुनै पनि प्रयोग गर्न सक्नुहुन्छ, तर यदि "महत्वपूर्ण" स्थितिको साथ केहि कठिन छ भने, यो उद्योगमा रिलीजको चरणमा विकासकर्ताहरूको ध्यानमा ल्याउन लायक हुन सक्छ।

कलाकृतिहरु संग एकीकरण: Nexus र JFrog।

विकास वातावरणमा एकीकरण। तपाईंले रोज्नुहुने उपकरणहरू विकास वातावरणसँग एकीकरण हुनुपर्छ। विकासकर्तासँग आफ्नो कार्यस्थलबाट स्क्यानिङ परिणामहरूमा पहुँच हुनुपर्दछ, वा CVS मा कमिट गर्नु अघि कमजोरीहरूको लागि कोड स्क्यान गर्ने र जाँच गर्ने क्षमता हुनुपर्छ।

सीडी मा एकीकरण। यो एक राम्रो सुविधा हो जुन मलाई साँच्चै मनपर्छ र जसको बारेमा मैले पहिले नै कुरा गरिसकेको छु - औद्योगिक वातावरणमा नयाँ कमजोरीहरूको उदयको निगरानी। यो केहि यस्तो काम गर्दछ।

हामी संग छ सार्वजनिक कम्पोनेन्ट रिपोजिटरीहरू — बाहिर केही उपकरणहरू, र हाम्रो आन्तरिक भण्डार। हामी यसमा विश्वसनीय घटकहरू मात्र समावेश गर्न चाहन्छौं। अनुरोध प्रोक्सी गर्दा, हामी जाँच गर्छौं कि डाउनलोड गरिएको पुस्तकालयमा कमजोरीहरू छैनन्। यदि यो निश्चित नीतिहरू अन्तर्गत पर्दछ जुन हामीले स्थापना गर्छौं र आवश्यक रूपमा विकाससँग समन्वय गर्छौं, तब हामी यसलाई अपलोड गर्दैनौं र अर्को संस्करण प्रयोग गर्न बाध्य छौं। तदनुसार, यदि पुस्तकालयमा साँच्चै आलोचनात्मक र खराब केहि छ भने, विकासकर्ताले स्थापना चरणमा पुस्तकालय प्राप्त गर्दैन - उसलाई उच्च वा तल्लो संस्करण प्रयोग गर्न दिनुहोस्।

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

गतिशील विश्लेषण - DAST

गतिशील विश्लेषण उपकरणहरू अहिलेसम्म भनिएको कुनै पनि कुराबाट मौलिक रूपमा फरक छन्। यो अनुप्रयोगसँग प्रयोगकर्ताको कामको एक प्रकारको नक्कल हो। यदि यो वेब अनुप्रयोग हो भने, हामी अनुरोधहरू पठाउँछौं, क्लाइन्टको कामको अनुकरण गर्दै, अगाडिको बटनहरूमा क्लिक गर्नुहोस्, फारमबाट कृत्रिम डेटा पठाउनुहोस्: उद्धरणहरू, कोष्ठकहरू, विभिन्न सङ्केतनहरूमा क्यारेक्टरहरू, अनुप्रयोगले कसरी काम गर्छ र हेर्नको लागि। बाह्य डाटा प्रशोधन गर्दछ।

उही प्रणालीले तपाईंलाई खुला स्रोतमा टेम्प्लेट कमजोरीहरू जाँच गर्न अनुमति दिन्छ। DAST लाई हामीले कुन खुला स्रोत प्रयोग गर्दैछौं भन्ने थाहा नभएकोले, यसले "दुर्भावनापूर्ण" ढाँचाहरू फ्याँक्छ र सर्भरको प्रतिक्रियाहरूको विश्लेषण गर्छ:

- हो, यहाँ डिसिरियलाइजेशन समस्या छ, तर यहाँ छैन।

यसमा ठूला जोखिमहरू छन्, किनकि यदि तपाईंले यो सुरक्षा परीक्षणलाई परीक्षकहरूसँग काम गर्ने बेन्चमा सञ्चालन गर्नुभयो भने, खराब चीजहरू हुन सक्छ।

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

हामीले अन्ततः AppScan सुरु गर्दा एउटा अवस्था थियो: हामीले लामो समयदेखि एप्लिकेसनमा पहुँच प्राप्त गर्ने प्रयास गरिरहेका थियौं, 3 खाताहरू पायौं र खुसी थियौं - हामी अन्ततः सबै कुरा जाँच गर्नेछौं! हामीले स्क्यान गर्न थाल्यौं, र एपस्क्यानले गरेको पहिलो कुरा प्रशासक प्यानलमा जानु, सबै बटनहरू छेड्ने, डाटाको आधा परिवर्तन गर्ने, र त्यसपछि पूर्ण रूपमा सर्भरलाई आफ्नै साथ मार्ने थियो। मेल फारम- अनुरोधहरू। परीक्षण संग विकास भन्नुभयो:

- केटाहरू, के तपाईं मसँग मजाक गर्दै हुनुहुन्छ ?! हामीले तपाईंलाई खाताहरू दियौं, र तपाईंले स्ट्यान्ड सेट गर्नुभयो!

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

यो तपाईं लोड परीक्षण को एक एनालग रूपमा प्रयोग गर्न सक्नुहुन्छ कि विचार गर्न लायक छ। पहिलो चरणमा, तपाइँ 10-15 थ्रेडहरूमा गतिशील स्क्यानर खोल्न सक्नुहुन्छ र के हुन्छ हेर्नुहोस्, तर सामान्यतया, अभ्यास शो अनुसार, केहि राम्रो छैन।

हामीले सामान्यतया प्रयोग गर्ने केही स्रोतहरू।

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

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

एकीकरण एकदम राम्रो हुन्छ र सरल छ: सफल स्थापना पछि स्क्यान सुरु गर्नुहोस् स्ट्यान्डका लागि आवेदनहरू र सफल एकीकरण परीक्षण पछि स्क्यानिङ.

यदि एकीकरणले काम गर्दैन वा त्यहाँ स्टबहरू र नक्कली प्रकार्यहरू छन् भने, यो व्यर्थ र बेकार छ - हामीले जुन ढाँचा पठाए पनि, सर्भरले अझै पनि उस्तै प्रतिक्रिया दिनेछ।

• आदर्श रूपमा, एक अलग परीक्षण स्ट्यान्ड।
• परीक्षण गर्नु अघि, लगइन अनुक्रम लेख्नुहोस्।
• प्रशासन प्रणालीको परीक्षण म्यानुअल मात्र हो।

प्रक्रिया

सामान्य रूपमा प्रक्रिया र विशेष रूपमा प्रत्येक उपकरणको कामको बारेमा थोरै सामान्यीकरण। सबै अनुप्रयोगहरू फरक छन् - केहि गतिशील विश्लेषण संग राम्रो काम गर्दछ, केहि स्थिर विश्लेषण संग, अन्य OpenSource विश्लेषण संग, पेन्टेस्ट, वा केहि अन्य संग, उदाहरण को लागी, घटनाहरु संग Waf.

प्रत्येक प्रक्रिया नियन्त्रण आवश्यक छ।

प्रक्रियाले कसरी काम गर्छ र यसलाई कहाँ सुधार गर्न सकिन्छ भन्ने कुरा बुझ्नको लागि, तपाईंले उत्पादन मेट्रिक्स, उपकरणहरूबाट मेट्रिक्स, र दोष ट्र्याकरहरू सहित आफ्नो हातमा प्राप्त गर्न सक्ने सबै चीजहरूबाट मेट्रिकहरू सङ्कलन गर्न आवश्यक छ।

कुनै पनि जानकारी उपयोगी छ। तपाईले विभिन्न दृष्टिकोणबाट हेर्नु पर्छ जहाँ एक वा अर्को उपकरण राम्रोसँग प्रयोग गरिन्छ, जहाँ प्रक्रिया विशेष रूपमा ढिलो हुन्छ। समयको आधारमा प्रक्रिया कहाँ सुधार गर्ने भनेर बुझ्नको लागि विकास प्रतिक्रिया समय हेर्न लायक हुन सक्छ। जति धेरै डेटा, उति धेरै खण्डहरू शीर्ष-स्तरबाट प्रत्येक प्रक्रियाको विवरणहरूमा निर्माण गर्न सकिन्छ।

किनकि सबै स्थिर र गतिशील विश्लेषकहरूको आफ्नै API, तिनीहरूको आफ्नै सुरुवात विधिहरू, सिद्धान्तहरू छन्, कसैसँग समय तालिकाहरू छन्, अरूसँग छैन - हामी एउटा उपकरण लेख्दैछौं। AppSec अर्केस्ट्रेटर, जसले तपाईंलाई उत्पादनबाट सम्पूर्ण प्रक्रियामा एकल प्रविष्टि बिन्दु सिर्जना गर्न र एक बिन्दुबाट व्यवस्थापन गर्न अनुमति दिन्छ।

प्रबन्धकहरू, विकासकर्ताहरू र सुरक्षा इन्जिनियरहरूसँग एउटा प्रविष्टि बिन्दु छ जहाँबाट तिनीहरूले के चलिरहेको छ हेर्न, कन्फिगर र स्क्यान चलाउन, स्क्यान परिणामहरू प्राप्त गर्न, र आवश्यकताहरू पेश गर्न सक्छन्। हामी कागजी कार्यबाट टाढा जान प्रयास गर्छौं, सबै कुरालाई मानव भाषामा अनुवाद गर्ने प्रयास गर्छौं, जुन विकासद्वारा प्रयोग गरिन्छ - स्थिति र मेट्रिक्सको संगममा पृष्ठहरू, जिरामा वा विभिन्न दोष ट्र्याकरहरूमा, वा CI/CD मा सिंक्रोनस/एसिन्क्रोनस प्रक्रियामा एकीकरण।

कुञ्जी टेकवेहरू

उपकरणहरू सबैभन्दा महत्त्वपूर्ण कुरा होइनन्। पहिले प्रक्रिया मार्फत सोच्नुहोस् - त्यसपछि उपकरणहरू लागू गर्नुहोस्। उपकरणहरू राम्रा छन् तर महँगो छन्, त्यसैले तपाइँ प्रक्रियाको साथ सुरु गर्न सक्नुहुन्छ र विकास र सुरक्षा बीच सञ्चार र समझ निर्माण गर्न सक्नुहुन्छ। सुरक्षाको दृष्टिकोणबाट, सबै कुरा "रोक" गर्नु आवश्यक छैन। विकासको दृष्टिकोणबाट, यदि त्यहाँ केहि उच्च मेगा सुपर क्रिटिकल छ भने, त्यसलाई हटाउन आवश्यक छ, र समस्यामा आँखा नदेखाउनु पर्छ।

उत्पादन गुणस्तर - साझा लक्ष्य सुरक्षा र विकास दुवै। हामी एउटा कुरा गर्छौं, हामी यो सुनिश्चित गर्ने प्रयास गर्छौं कि सबै कुरा ठीकसँग काम गर्दछ र त्यहाँ कुनै प्रतिष्ठा जोखिम वा वित्तीय हानि छैन। त्यसैले हामीले सञ्चार सुधार गर्न र अझ राम्रो उत्पादन बनाउन DevSecOps, SecDevOps दृष्टिकोणको प्रचार गर्छौं।

तपाईसँग पहिले नै भएको कुराबाट सुरु गर्नुहोस्: आवश्यकताहरू, वास्तुकला, आंशिक जाँचहरू, प्रशिक्षणहरू, दिशानिर्देशहरू। सबै परियोजनाहरूमा सबै अभ्यासहरू तुरुन्तै लागू गर्न आवश्यक छैन। पुनरावृत्ति सार्नुहोस्। त्यहाँ कुनै एक मानक छैन - परिक्षण र विभिन्न दृष्टिकोण र समाधान प्रयास गर्नुहोस्।

सूचना सुरक्षा दोष र कार्यात्मक दोषहरू बीच समान चिन्ह छ.

सबै कुरा स्वचालित गर्नुहोस्त्यो सर्छ। सार्नुहोस् र नचल्ने सबै कुरा स्वचालित गर्नुहोस्। यदि केहि हातले गरिन्छ भने, यो प्रक्रियाको राम्रो भाग होइन। सायद यो समीक्षा गर्न र यसलाई स्वचालित गर्न लायक छ।

यदि IS टोलीको आकार सानो छ भने, सुरक्षा च्याम्पियनहरू प्रयोग गर्नुहोस्.

सायद मैले के कुरा गरेको छु त्यो तपाईलाई सुहाउँदैन र तपाईले आफ्नै केहि ल्याउनुहुनेछ - र त्यो राम्रो छ। तर तपाइँको प्रक्रिया को लागी आवश्यकताहरु मा आधारित उपकरण छनोट गर्नुहोस्। यो औजार नराम्रो छ र यो राम्रो छ भनेर समुदायले के भन्छ त्यो नहेर्नुहोस्। सायद उल्टो तपाईंको उत्पादनको लागि सत्य हुनेछ।

उपकरणहरूको लागि आवश्यकताहरू।

• निम्न स्तर गलत सकारात्मक।
• पर्याप्त विश्लेषण समय।
• प्रयोगको उपयोग
• एकीकरण को उपलब्धता।
• उत्पादन विकास रोडम्याप बुझ्दै।
• अनुकूलन उपकरण को सम्भावना।

DevOpsConf 2018 मा युरीको रिपोर्टलाई उत्कृष्ट मध्ये एकको रूपमा छनोट गरिएको थियो। अझ धेरै रोचक विचारहरू र व्यावहारिक केसहरूसँग परिचित हुन, मे २७ र २८ मा Skolkovo आउनुहोस्। DevOpsConf भित्र उत्सव RIT++। अझ राम्रो, यदि तपाईं आफ्नो अनुभव साझा गर्न तयार हुनुहुन्छ भने निवेदन गर्नु अप्रिल 21 सम्म रिपोर्ट को लागी।

स्रोत: www.habr.com