स्थैतिक विश्लेषण का सही उपयोग कैसे करें

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

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

स्थैतिक विश्लेषण के बारे में

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

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

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

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

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

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


डेवलपर परीक्षण के लिए स्रोत कोड सौंपता है

बिल्डिंग कोड के लिए आवश्यकताओं पर विशेष ध्यान दिया जाता है। अधिकांश भाषाओं के विश्लेषण के लिए कोड की आवश्यकता होती है जो विश्लेषण के दौरान एकत्र किए जाएं (JVM भाषाएँ - Java, Scala, Kotlin और like, C / C ++, Objective-C, C #)। आप समझते हैं कि यह कितना दर्दनाक है: एक नई मशीन पर विधानसभा के लिए एक बड़ी परियोजना के वातावरण को पुन: पेश करना। दूसरी ओर, ये आवश्यकताएँ उचित हैं; वे विश्लेषण तकनीक और इन भाषाओं की बारीकियों का पालन करते हैं।

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

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

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

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

विश्लेषण की प्रक्रिया

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


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

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

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

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

विश्लेषण के परिणाम

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


सुरक्षा गार्ड डेवलपर को भेद्यता रिपोर्ट भेज रहा है

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

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

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

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

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

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

विश्लेषक की जांच करें

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


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

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

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

क्षमता

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

विकास प्रक्रिया में एकीकरण

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

टूल में पूर्ण गैर-ग्राफ़िकल इंटरफ़ेस (उदाहरण के लिए, CLI या REST API) होना चाहिए, जिसके साथ आप अपनी किसी भी प्रक्रिया में विश्लेषक को एकीकृत कर सकते हैं। यह अच्छा है अगर विश्लेषक के पास विभिन्न घटकों के साथ तैयार-निर्मित एकीकरण हैं: आईडीई या बिल्ड सिस्टम के लिए प्लग-इन, संस्करण नियंत्रण प्रणालियों के साथ एकीकरण, सीआई / सीडी सर्वर के लिए प्लग-इन (जेनकिंस, टीमसिटी), प्रोजेक्ट सिस्टम के साथ एकीकरण (JIRA) या उपयोगकर्ताओं के साथ काम करना ( सक्रिय निर्देशिका)।

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

सारांश

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