4.4 स्थैतिक विश्लेषण और कोड स्मेल मेट्रिक्स

अवलोकन और प्रेरणा

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

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

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

प्रमुख सिद्धांत

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

सिफ़ारिशें

कच्ची गिनती नहीं, गंभीरता-भारित खोजों को ट्रैक करें

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

संपूर्ण ऐतिहासिक बैकलॉग पर नहीं, नई पेश की गई खोजों पर गेट लगाएँ

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

झूठी-सकारात्मक दर को सक्रिय रूप से प्रबंधित करें

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

स्थैतिक विश्लेषण खोजों का उपयोग समीक्षा के लिए एक प्रॉम्प्ट के रूप में करें, एक स्वचालित फ़ैसले के रूप में नहीं

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

इस भाग के अन्य कोड-गुणवत्ता मेट्रिक्स के साथ स्थैतिक विश्लेषण को जोड़ें

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

समझौते: लाभ और हानि

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

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

अपनी टीम के साथ चर्चा करने के प्रश्न

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

क्षेत्र दृष्टिकोण

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

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

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

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

उदाहरण

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

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

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

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

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

विरोधी-पैटर्न और नुक़सान

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

परिपक्वता मॉडल

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

चर्चा के लिए विचार

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

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

Static Program Analysis, by Anders Møller and Michael I. Schwartzbach (स्थैतिक विश्लेषण तकनीकों के सैद्धांतिक और व्यावहारिक आधार)।
OWASP का स्थैतिक अनुप्रयोग सुरक्षा परीक्षण (SAST) पर मार्गदर्शन, सुरक्षित सॉफ़्टवेयर विकास प्रथाओं पर व्यापक OWASP फ़ाउंडेशन संसाधनों का हिस्सा।
Refactoring: Improving the Design of Existing Code, by Martin Fowler (कोड स्मेल कैटलॉग जिस पर अधिकांश स्थैतिक विश्लेषण टूलिंग निर्भर करती है)।
Working Effectively with Legacy Code, by Michael Feathers (एक स्थापित कोडबेस में गुणवत्ता मुद्दों के एक विरासत बैकलॉग का प्रबंधन)।