🦀 ⏱️ 👩🏽 (एस) एसडीएलसी, या कैसे विकास को सुरक्षित बनाने के लिए। भाग 1 📤 🧒🏿 👩🏻

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

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

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

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

SAST

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

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

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

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

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

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

चलो शुरू करते हैं

यदि आपके पास पहले से ही मुक्त स्थिर विश्लेषक हैं तो SAST क्यों?

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

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

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

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

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

कौन सा SAST टूल चुनना है?

मैं एक उपकरण चुनने के चरण में थोड़ा ध्यान केन्द्रित करूंगा। SAST उपकरण बहुत सारे हैं, आमतौर पर कई टुकड़े बाजार (3-4) पर प्रस्तुत किए जाते हैं। सवाल उठता है, सही उपकरण कैसे चुनना है, क्या देखना है? यहां मैं आश्चर्य नहीं करूंगा, मैं तीन बिंदुओं पर ध्यान केंद्रित करूंगा: कार्यात्मक तुलना, गुणवत्ता तुलना और लाइसेंसिंग। अपने स्थानीय सर्किट में परीक्षण उपकरण (पायलट) लेना और अपने बुनियादी ढांचे में अपने कोड की जांच करना महत्वपूर्ण है।

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

स्कैनिंग का सबसे स्वचालित लॉन्च (आदर्श रूप से, दो बटन में अनावश्यक सेटिंग्स के बिना, आप एक स्कैन चला सकते हैं);
— , , ;
;
;
;
(, );
;
, “”;
“ , ”;
;
.

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

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

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

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

आप किस बिंदु पर स्कैनिंग शुरू करते हैं?

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

इस दृष्टिकोण के साथ, हमें एक बोनस भी मिलता है: डेवलपर्स, जब वे एसएएसटी परिणाम "हर दिन" देखते हैं, तो सुरक्षित प्रोग्रामिंग के ज्ञान में अग्रिम होता है, इस प्रकार, सामान्य रूप से, सुरक्षित विकास की संस्कृति को बढ़ाया जाता है और कोड बेहतर हो जाता है।

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

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

तकनीकी दिक्कतें

और फिर मैं आपको तुरंत 4 प्रश्न दूंगा।

SAST को सोनारक्यूब के रूप में कनेक्ट करें, कठिनाई क्या है?
SAST लंबे समय तक काम करता है, DevSecOps को कैसे कॉन्फ़िगर करें?
SAST झूठी सकारात्मकता देता है, गुणवत्ता गेट को कैसे कॉन्फ़िगर करें?
और रिपोर्ट में झूठी सकारात्मकता के बिना, कई हजार कमजोरियां, उनके साथ क्या करना है?

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

एल्गोरिदम की घातीय प्रकृति के कारण, एसएएसटी लंबे समय तक चल सकता है और बहुत सारे संसाधनों का उपभोग कर सकता है - एक लिंटर या सोनारक्यूब से बहुत अधिक।
उसी कारण से, एसएएसटी बहुत सी झूठी सकारात्मक चीजें दे सकता है - यह संभावना नहीं है कि डेवलपर्स अगले स्कैन के बाद हर दिन गिर के एक गुच्छा को पार्स करना चाहेंगे।
आमतौर पर SAST को पहली बार कोड बेस पर लॉन्च किया जाता है, और पहला रन बहुत सारे ऑपरेशन दिखा सकता है, खासकर अगर कोड बहुत है और डेटाबेस बहुत नया नहीं है।

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

संगठनात्मक मामले

मैं संगठनात्मक मुद्दों के बारे में नहीं भूलूंगा। बड़ी कंपनियों में, उनमें से बहुत कुछ उत्पन्न होता है, कार्यान्वयन प्रक्रिया से, संसाधनों के आवंटन से लेकर नियमों के निर्माण और प्रक्रियाओं की प्रतिकृति तक।

संगठनात्मक मुद्दे उन्हीं तकनीकी विशेषताओं से उत्पन्न होते हैं जिनकी हमने पिछले पैराग्राफ में चर्चा की थी। खैर, इसके अलावा, ऐतिहासिक रूप से स्थापित विभाजन और विकास और सुरक्षा के बीच टकराव अभी तक दूर नहीं हुआ है। मैं हमारे पिछले लेख का भी उल्लेख करता हूं ।

जारी रहती है

सस्ट लागू करें - यह आवश्यक है, यह आमतौर पर उचित है। लेकिन, लागू करना शुरू करना, आपके रास्ते में आने वाले सभी नुकसानों से परिचित होना अच्छा होगा। इस लेख में, हमने उन्हें अलग करना शुरू किया, हम निम्नलिखित में तकनीकी पहलुओं के साथ जारी रखेंगे।

(एस) एसडीएलसी, या कैसे विकास को सुरक्षित बनाने के लिए। भाग 1