जानें कि vulnerability disclosure program क्या है, Katie Moussouris जैसे नेताओं ने बिजनेस केस कैसे समझाया, और छोटी टीमें स्कोप, ट्रायएज और समयसीमाएँ कैसे सेट कर सकती हैं।
ज़्यादातर टीम्स के पास पहले से ही सुरक्षा फ़ीडबैक आता है। बस उसके उतरने के लिए एक सुरक्षित जगह नहीं होती।
एक vulnerability disclosure program रिसर्चर्स और कस्टमर्स को एक स्पष्ट, कानूनी और सम्मानजनक तरीका देता है कि वे मुद्दों की रिपोर्ट कर सकें इससे पहले कि वे हेडलाइन बनें। नीति न होने पर रिपोर्ट सबसे खराब समय पर, गलत चैनल से और अस्पष्ट अपेक्षाओं के साथ आती हैं। एक अच्छे इरादे वाला रिसरчер निजी पते पर ईमेल कर सकता है, ध्यान पाने के लिए सार्वजनिक रूप से पोस्ट कर सकता है, या तब तक टोक सकता है जब तक किसी का जवाब न आए। एक प्रोग्राम के साथ, हर कोई जानता है कहाँ रिपोर्ट भेजनी है, कौन सा परीक्षण allowed है, और आपकी टीम अगला क्या करेगी।
मुद्दों को जल्दी पकड़ना मायने रखता है क्योंकि एक बग के शोषित होने पर लागत जल्दी बढ़ती है। एक छोटा authentication गलती जो एक शांत हफ्ते में पकड़ी जाती है, एक दिन में ठीक हो सकती है। वही गलती जब दुरुपयोग के बाद मिलती है तो आपातकालीन पैच, incident response, कस्टमर सपोर्ट लोड और दीर्घकालिक भरोसे की क्षति हो सकती है।
VDP और बग बाउंटी के बीच व्यावहारिक सोच:
Katie Moussouris ने एक साधारण बिजनेस फ्रेमिंग लोकप्रिय बनाई जिससे कंपनियों के लिए बग बाउंटी स्वीकार करना आसान हुआ: सिक्योरिटी रिसर्चर्स “दुश्मन” नहीं हैं। वे क्वालिटी के लिए एक मैनेज्ड, पॉज़िटिव-सम इनपुट हो सकते हैं। यही तर्क VDPs पर भी लागू होता है। आप परेशानी बुला रहे नहीं होते, आप उन समस्याओं के लिए नियंत्रित इनटेक बना रहे होते हैं जो पहले से मौजूद हैं।
एक छोटी टीम जो तेजी से शिप करती है (मान लीजिए, एक वेब ऐप जिसमें React फ्रंट-एंड और एक API है) के लिए फ़ायदा अक्सर तुरन्त होता है: कम अनपेक्षित eskalations, स्पष्ट फिक्स प्राथमिकताएँ, और सुरक्षा रिपोर्ट्स को गंभीरता से लेने की प्रतिष्ठा।
एक vulnerability disclosure program (VDP) लोगों के लिए एक सार्वजनिक, predictable तरीका है जिससे वे आपको सुरक्षा मुद्दे रिपोर्ट कर सकें, और आपकी टीम सुरक्षित रूप से जवाब दे सके। यह पुरस्कार देने जैसा नहीं है। लक्ष्य है समस्याओं को उपयोगकर्ताओं को नुकसान पहुँचाने से पहले ठीक करना।
आम तौर पर तीन समूह हिस्सा लेते हैं: सिक्योरिटी रिसर्चर्स जो सक्रिय रूप से मुद्दे ढूंढते हैं, ग्राहक जो संदिग्ध व्यवहार देखते हैं, और कर्मचारी या ठेकेदार जो सामान्य काम के दौरान समस्याएँ पाते हैं। इन सभी को एक ही सरल रिपोर्टिंग रास्ते की ज़रूरत होती है।
रिपोर्ट आमतौर पर एक समर्पित ईमेल पते, एक वेब फॉर्म, या टिकटिंग इनटेक के माध्यम से आती हैं। एक छोटी टीम के लिए सबसे ज़रूरी बात यही है कि इनबॉक्स का मालिक हो, मॉनिटर किया जाए, और सामान्य सपोर्ट से अलग हो।
एक मजबूत रिपोर्ट आपको इतनी जानकारी देती है कि आप जल्दी reproduce कर सकें: क्या मिला, क्यों यह महत्वपूर्ण है, reproduce करने के कदम, कौन सा सिस्टम या endpoint प्रभावित है, और प्रभाव का प्रमाण। सुझाए गए फिक्स अच्छे होते हैं पर वैकल्पिक हैं।
रिपोर्ट आने पर आप लिखित में कुछ प्रतिबद्धताएँ करते हैं, आमतौर पर एक responsible disclosure policy में। छोटा शुरू करें और केवल वही वादा करें जो आप निभा सकते हैं। कम से कम: आप रिपोर्ट की प्राप्ति स्वीकार करेंगे, बुनियादी ट्रायएज करेंगे, और रिपोर्टर को अपडेट रखते रहेंगे।
पीछे की प्रक्रिया सीधी है: प्राप्ति की पुष्टि करें, समस्या की पुष्टि करें, गंभीरता का आकलन करें, एक मालिक असाइन करें, फिक्स करें, और समाधान होने तक स्थिति संवाद करते रहें। भले ही आप तुरंत फिक्स न कर सकें, नियमित अपडेट भरोसा बनाते हैं और बार-बार पूछताछ घटाते हैं।
VDP बेसलाइन है। आप एक सुरक्षित रिपोर्टिंग मार्ग प्रकाशित करते हैं, बताते हैं कौन सा परीक्षण allowed है, और प्रतिक्रिया का वादा करते हैं। किसी पैसे की ज़रूरत नहीं। “डील” दोनों तरफ स्पष्टता और अच्छी नीयत है।
बग बाउंटी पुरस्कार जोड़ता है। आप इसे सीधे चला सकते हैं (ईमेल के साथ payout तरीका) या किसी प्लेटफ़ॉर्म के माध्यम से जो रिसर्चर्स तक पहुंच, रिपोर्ट हैंडलिंग और भुगतान में मदद करता है। ट्रेडऑफ़: अधिक ध्यान, अधिक वॉल्यूम, और तेजी से काम करने का दबाव।
बाउंटी तब समझ में आती है जब आपकी टीम लोड संभाल सके। अगर आपका प्रोडक्ट रोज़ बदलता है, आपका लॉगिंग कमजोर है, या किसी के पास सुरक्षा ट्रायएज की जिम्मेदारी नहीं है, तो बाउंटी ऐसी कतार बना सकती है जिसे आप साफ़ नहीं कर पाएँगे। predictable intake चाहिए तो VDP से शुरू करें। तब बाउंटी पर विचार करें जब आपकी surface स्थिर हो, पर्याप्त एक्सपोज़र हो ताकि असली findings आएँ, आप दिनों या हफ़्तों में ट्रायएज और फिक्स कर सकें, और आपके पास स्पष्ट बजट और भुगतान तरीका हो।
रिवॉर्ड्स के लिए सरल रखें: गंभीरता के अनुसार फिक्स्ड रेंज (low से critical), और बहुत स्पष्ट, reproducible रिपोर्टों के लिए छोटे बोनस।
पेयआउट्स केवल बिजनेस केस का एक हिस्सा हैं। बड़ा फायदा जल्दी चेतावनी और कम जोखिम है: कम अनपेक्षित incidents, इंजीनियरिंग में बेहतर सुरक्षा आदतें, और एक दस्तावेजीकृत प्रक्रिया जिसे ग्राहक समीक्षा के दौरान दिखा सकते हैं।
एक अच्छा VDP एक वादा से शुरू होता है: आप उन रिपोर्टों को देखेंगे जो आप वास्तव में verify और fix कर सकते हैं। यदि स्कोप बहुत व्यापक है, रिपोर्टें जमा हो जाती हैं, रिसर्चर्स निराश होते हैं, और आप जो भरोसा कमाने की कोशिश कर रहे थे वह खो जाते हैं।
उन एसेट्स से शुरू करें जिनके आप end-to-end मालिक हैं। अधिकांश छोटी टीमों के लिए इसका मतलब है production वेब ऐप और कोई भी सार्वजनिक API जिसका उपयोग ग्राहक करते हैं। आंतरिक टूल्स, पुराने प्रोटोटाइप, और थर्ड-पार्टी सर्विसेज को तब तक बाहर रखें जब तक बेसिक्स काम नहीं कर रहे।
स्पष्ट रूप से बताएं क्या in scope है और क्या नहीं। कुछ ठोस उदाहरण बातचीत कम कर देते हैं:
फिर बताएं कौन सा परीक्षण allowed है ताकि कोई अनजाने में यूज़र्स को नुकसान न पहुँचाए। सीमाएँ सरल रखें: मास स्कैनिंग नहीं, रेट लिमिट्स का सम्मान करें, डिनायल-ऑफ-सर्विस टेस्ट न करें, और दूसरों के डेटा तक पहुंचने की अनुमति न दें। यदि आप सीमित टेस्ट अकाउंट्स की अनुमति देना चाहते हैं तो स्पष्ट रूप से कहें।
अंत में, तय करें कि आप non-production सिस्टम्स को कैसे हैंडल करेंगे। स्टेजिंग reproduction में मदद कर सकता है, पर अक्सर वह noisy और कम मॉनिटर किया जाता है। कई टीम्स पहले स्टेजिंग को exclude कर देती हैं और सिर्फ़ production findings स्वीकार करती हैं, फिर लॉगिंग स्थिर होने और सुरक्षित परीक्षण के तरीके उपलब्ध होने पर स्टेजिंग जोड़ती हैं।
उदाहरण: एक छोटी SaaS टीम जो Koder.ai apps चला रही है, वह शुरुआत कर सकती है “production app + हमारे primary domain पर public API” के साथ और customer self-hosted deployments को तब तक स्पष्ट रूप से exclude कर सकती है जब तक टीम के पास reproduce और फिक्स शिप करने का तरीका न हो।
अच्छे नियम एक ही समय में दो काम करते हैं: वे असली उपयोगकर्ताओं को सुरक्षित रखते हैं, और रिसर्चर्स को भरोसा देते हैं कि वे अच्छा विश्वास में रिपोर्ट करने पर परेशानी में नहीं फँसेंगे। भाषा सरल और विशिष्ट रखें। अगर एक टेस्ट करने वाला नहीं बता सकता कि क्या allowed है, तो या तो वह रुक जाएगा या जोखिम उठाएगा।
सुरक्षित परीक्षण सीमाओं से शुरू करें। लक्ष्य रिसर्च को रोकना नहीं है; लक्ष्य यह है कि जब मुद्दा अज्ञात हो तब नुकसान न हो। सामान्य नियमों में शामिल हैं: कोई सोशल इंजीनियरिंग नहीं (फिशिंग, कर्मचारियों को कॉल करना, नकली सपोर्ट टिकट), कोई डिनायल-ऑफ-सर्विस या स्ट्रेस टेस्टिंग नहीं, कोई फिज़िकल हमले या धमकी नहीं, स्कोप के बाहर स्कैनिंग नहीं, और असली उपयोगकर्ता डेटा छूने पर तुरंत बंद कर दें।
फिर बताएं कैसे रिपोर्ट करें और "उपयोगी" क्या दिखता है। एक सरल टेम्पलेट ट्रायएज को तेज़ करता है: कहाँ हुआ (URL/app स्क्रीन, environment, account प्रकार), reproduce करने के क्रमबद्ध कदम, प्रभाव, प्रमाण (स्क्रीनशॉट, छोटा वीडियो, request/response), और संपर्क विवरण।
प्राईवेसी के बारे में स्पष्ट रहें। रिसर्चर्स से कहें कि वे डेटा एक्सेस को कम रखें, datasets डाउनलोड न करें, और स्क्रीनशॉट में संवेदनशील जानकारी (ईमेल, टोकन, व्यक्तिगत विवरण) redact करें। यदि उन्हें एक्सेस साबित करने की ज़रूरत है, तो सबसे छोटा संभव सैंपल माँगें।
अंत में, duplicates और partial reports के लिए अपेक्षाएँ तय करें। आप कह सकते हैं कि पहले स्पष्ट रिपोर्ट को क्रेडिट (या रिवार्ड) दिया जाएगा जो प्रभाव साबित करती है, और अधूरी रिपोर्टें बंद की जा सकती हैं अगर आप उन्हें reproduce नहीं कर पाएँ। एक छोटी पंक्ति जैसे "अगर आप सुनिश्चित नहीं हैं, तो जो भी है submit करें और हम मार्गदर्शन करेंगे" दरवाज़ा खुला रखती है बिना परिणामों का वादा किए।
VDP सबसे तेज़ी से तब फेल होता है जब रिपोर्टें किसी साझा इनबॉक्स में बिना मालिक के पड़ी रहती हैं। ट्रायएज वह आदत है जो "हमें रिपोर्ट मिली" को एक स्पष्ट निर्णय में बदल देती है: क्या यह असली है, यह कितना बुरा है, कौन इसे ठीक करेगा, और हम रिपोर्टर को क्या बताएँगे।
एक छोटा सा severity rubric चुनें जिसे आपकी पूरी टीम लगातार लागू कर सके:
पहली प्रतिक्रिया एक व्यक्ति को असाइन करें (सिक्योरिटी लीड, ऑन-कॉल इंजीनियर, या फाउंडर), और वीकेंड व छुट्टियों के लिये एक बैकअप रखें। यही एक निर्णय “कोई और संभालेगा” बनने से रोकता है।
False positives और “सिक्योरिटी थिएटर” घटाने के लिए एक ठोस चीज़ माँगें: एक repeatable proof। यह स्टेप्स, छोटा वीडियो, या न्यूनतम request/response हो सकता है। अगर आप reproduce नहीं कर पा रहे, तो बताएं क्या किया, और एक निशाना सवाल पूछें। स्कैनर आउटपुट को निर्णायक न मानें—इसे एक सुराग समझें।
अगर रिपोर्ट थर्ड-पार्टी सेवाओं को छूती है (क्लाउड स्टोरेज, identity provider, analytics), तो जो आप नियंत्रित करते हैं और जो आप नहीं करते उसे अलग करें। पहले अपनी configuration की पुष्टि करें, फिर जरूरत पड़े तो विक्रेता से संपर्क करें। रिपोर्टर को यह बताते रहें कि आप क्या साझा कर सकते हैं।
हर रिपोर्ट को एक सरल आंतरिक टेम्पलेट में डोक्यूमेंट करें: सारांश, प्रभावित सतह, गंभीरता और क्यों, reproduction नोट्स, मालिक, और वर्तमान स्थिति। संगत नोट्स अगली रिपोर्ट को पहले से तेज़ बनाती हैं।
समयरेखाएँ एक ऐसे प्रोग्राम के बीच फर्क हैं जो भरोसा बनाती है और जिसे नज़रअंदाज़ किया जाता है। ऐसे लक्ष्य चुनें जिन्हें आप वर्तमान टीम के साथ सच में पूरा कर सकें, उन्हें प्रकाशित करें, और पालन करें।
कई छोटी टीमों के लिए स्वीकार्य प्रतिबद्धतियाँ:
अगर आप इन नंबरों को पूरा नहीं कर सकते, तो अभी उन्हें बड़ा रखें बजाय बाद में न पूरा करने के। 30 दिन कहें और 20 में डिलीवर करें बेहतर है बनिस्बत 7 दिन का वादा करके चुप हो जाने के।
रिपोर्ट रिसर्चर्स के लिए महत्व बरतती है। भले ही आपके पास अभी फिक्स न हो, नियमित अपडेट्स निराशा कम करते हैं और सार्वजनिक escalation रोकते हैं। एक predictable cadence रखें और शामिल करें: वर्तमान स्थिति (ट्रायजिंग, फिक्स कर रहे हैं, टेस्टिंग), अगला कदम, और अगली अपडेट की तारीख।
जब आप पुष्टि कर लें कि मुद्दा वैध है तो disclosure तारीख पर सहमत हों। यदि आपको और समय चाहिए तो जल्दी माँगें और बताएं क्यों (जटिल फिक्स, रोलआउट बाधाएँ)। यदि मुद्दा सक्रिय रूप से शोषित हो रहा है, तो उपयोगकर्ता सुरक्षा को प्राथमिकता दें और तैयार रहें कि आप जल्दी संवाद करें, भले ही पूरा फिक्स अभी रोलआउट न हुआ हो।
रिपोर्ट की पुष्टि और रैंकिंग के बाद लक्ष्य सरल है: उपयोगकर्ताओं की जल्दी सुरक्षा करना। एक सुरक्षित पैच या mitigation भेजें भले ही आपने परफेक्ट root-cause writeup पूरा न किया हो। आज एक छोटा फिक्स आमतौर पर अगले महीने के बड़े रिफैक्टर से बेहतर होता है।
जब पूरा फिक्स जोखिमपूर्ण या धीमा हो तो शॉर्ट-टर्म mitigations समय खरीदते हैं। सामान्य विकल्पों में किसी फीचर को फ्लैग के पीछे डिसेबल करना, रेट लिमिट्स कड़ा करना, खराब request पैटर्न को ब्लॉक करना, एक्सपोज़्ड सीक्रेट्स को रोटेट करना, या लॉगिंग और अलर्ट जोड़ना शामिल है। mitigation खत्म की रेखा नहीं है, पर वे वास्तविक नुकसान को घटाते हैं जब आप असली मरम्मत पर काम कर रहे हों।
रिपोर्ट क्लोज़ करने से पहले mini-release की तरह फिक्स को validate करें: समस्या पुन: उत्पन्न करें, पुष्टि करें कि फिक्स के बाद वह काम नहीं कर रहा, संभव हो तो regression टेस्ट जोड़ें, आसपास के परमिशन्स में साइड-इफेक्ट्स की जाँच करें, और अगर मिल सके तो दूसरी आँखों से देखवाएँ।
संचार पैच जितना महत्वपूर्ण है उतना ही। रिपोर्टर को बताएं कि आपने क्या पुष्टि की, आपने क्या बदला (साधारण शब्दों में), और कब यह deploy होगा। अगर और समय चाहिए तो बताएं क्यों और अगली अपडेट की तारीख दें। उपयोगकर्ताओं के लिए छोटा और ईमानदार रखें: क्या प्रभावित था, आपने क्या किया, और क्या उन्हें कोई क्रिया करनी चाहिए (पासवर्ड रिसेट, की रोटेशन, ऐप अपडेट)।
जब मुद्दा कई उपयोगकर्ताओं को प्रभावित करता है, फिर से खोजा जा सकता है, या उपयोगकर्ता क्रिया की ज़रूरत है तो एक संक्षिप्त advisory प्रकाशित करें। इसमें संक्षेप, गंभीरता, प्रभावित कंपोनेंट्स, फिक्स तारीख, और रिपोर्टर को क्रेडिट (यदि वे चाहते हैं) शामिल करें। Koder.ai जैसे प्लेटफ़ॉर्म्स पर, जहाँ ऐप्स डिप्लॉय और होस्ट किए जाते हैं, advisories उन टीमों की भी मदद करते हैं जो exports या कस्टम डोमेन्स इस्तेमाल कर रही हैं ताकि वे समझ सकें कि उन्हें फिर से deploy करने की ज़रूरत है या नहीं।
अधिकांश छोटी टीम्स की विफलता अच्छी नीयत की कमी से नहीं होती। वे इसलिए फेल होती हैं क्योंकि प्रोग्राम उनकी क्षमता से बड़ा होता है, या इतना अस्पष्ट होता है कि हर रिपोर्ट बहस बन जाती है।
एक व्यावहारिक नियम: अपना VDP उस सप्ताह के हिसाब से डिज़ाइन करें जो आप कर रहे हैं, न कि उस सप्ताह के जिस आप चाह रहे हैं।
सामान्य गलतियाँ और सबसे सरल समाधान जो आमतौर पर काम करता है:
उदाहरण: एक रिसरचर ने एक एक्सपोज़्ड स्टेजिंग endpoint रिपोर्ट किया। अगर आपकी नियमावली में स्टेजिंग का ज़िक्र नहीं है, तो आपकी टीम दिनों तक बहस कर सकती है। यदि स्टेजिंग या तो शामिल है या स्पष्ट रूप से आउट ऑफ़ स्कोप है, तो आप जल्दी जवाब दे सकते हैं, इसे सही रास्ते पर भेज सकते हैं, और बातचीत शांत रख सकते हैं।
एक न्यूनतम व्यवहार्य VDP परफेक्ट पेपरवर्क के बारे में नहीं बल्कि predictable व्यवहार के बारे में है। लोगों को पता होना चाहिए कि वे क्या टेस्ट कर सकते हैं, कैसे रिपोर्ट करें, और कब उन्हें प्रतिक्रिया मिलेगी।
चेकलिस्ट संक्षिप्त रखें:
यदि आप तेज़ी से शिप करते हैं (उदाहरण के लिए, एक प्लेटफ़ॉर्म जैसे Koder.ai जो वेब, बैकएंड, और मोबाइल ऐप्स डिप्लॉय करता है), तो यह टीमों और रिलीज़ चक्रों के बीच रिपोर्ट खोने से बचाता है।
एक तीन-व्यक्ति SaaS टीम को एक ईमेल मिला जिसका शीर्षक था: “पासवर्ड रिसेट के माध्यम से संभावित अकाउंट takeover।” रिसर्चर कहता है कि यदि उन्हें पीड़ित का ईमेल पता पता है तो वे पीड़ित का पासवर्ड रिसेट कर सकते हैं, क्योंकि रिसेट लिंक तब भी वैध है जब उपयोगकर्ता ने नया अनुरोध किया हो।
टीम जल्दी रिपोर्टर को प्राप्ति की पुष्टि भेजती है और दो चीजें माँगती है: ठीक-ठीक reproduce करने के कदम, और क्या रिसर्चर ने केवल अपने खातों पर टेस्ट किया। वे रिसर्चर को याद दिलाते हैं कि असली ग्राहक डेटा तक पहुँच न करें।
प्रोडक्शन उपयोगकर्ताओं को छुए बिना प्रभाव की पुष्टि करने के लिए टीम dummy खातों के साथ स्टेजिंग में फ्लो को recreate करती है। वे एक ही अकाउंट के लिए दो रिसेट ईमेल जनरेट करते हैं, फिर जांचते हैं क्या पुराना टोकन अभी भी काम करता है। यह काम करता है, और वे बिना किसी अतिरिक्त जांच के नया पासवर्ड सेट कर सकते हैं। वे सर्वर लॉग्स और टाइमस्टैम्प कैप्चर करते हैं पर किसी भी ईमेल सामग्री की नकल नहीं करते जो दुरुपयोग हो सके।
वे इसे High गंभीरता टैग करते हैं: यह एक वास्तविक रास्ते से अकाउंट takeover की ओर ले जाता है। अपनी नीति के अंतर्गत, वे mitigation के लिए 72 घंटे और पूर्ण फिक्स के लिए 7 दिन का समय तय करते हैं।
वे रिपोर्टर को हर चरण पर अपडेट रखते हैं:
बंद करने के बाद, वे एक स्वचालित टेस्ट जोड़कर single-use reset tokens के लिए दोहराव रोकते हैं, असामान्य रिसेट वॉल्यूम की निगरानी शुरू करते हैं, और अपने आंतरिक चेकलिस्ट को अपडेट करते हैं: “किसी भी लॉगिन या रिसेट टोकन को single-use, short-lived और नए जारी होने पर invalidated होना चाहिए।”
VDP को ऐसे शुरू करें जिसे आप सप्ताह-दर-सप्ताह चला सकें। एक साधारण इनबॉक्स, स्पष्ट स्कोप, और एक सुसंगत ट्रायएज रूटीन एक fancier नीति से बेहतर है जो अनछुई पड़ी रहती है। एक बार वर्कफ़्लो स्थिर और आपकी प्रतिक्रिया cadence विश्वसनीय हो जाने पर, उन क्षेत्रों के लिए बग बाउंटी जोड़ें जहाँ आप गहरा परीक्षण चाहते हैं।
कुछ मीट्रिक ट्रैक करें ताकि आप बिना इसे फुल-टाइम काम बनाए प्रगति देख सकें: स्वीकार करने का समय, ट्रायएज का समय, फिक्स का समय (या सुरक्षित mitigation तक का समय), reopen दर, और कितनी रिपोर्टें वास्तव में actionable हैं।
प्रत्येक महत्वपूर्ण रिपोर्ट के बाद एक हल्का retro करें: क्या धीमा किया, क्या रिपोर्टर को भ्रम हुआ, कौन सा निर्णय बहुत समय ले गया, और अगली बार आप क्या बदलेंगे।
यदि आपकी टीम तेज़ी से शिप करती है, तो “safe release” को योजना का हिस्सा बनाएं। छोटे, reversible परिवर्तन का लक्ष्य रखें। यदि आपके पास snapshots और rollback उपलब्ध हैं, तो उनका उपयोग करें ताकि एक सुरक्षा फिक्स लंबी outage में न बदल जाए।
एक व्यावहारिक मासिक ताल:
यदि आप Koder.ai (koder.ai) पर बनाते हैं, तो डिप्लॉयमेंट और होस्टिंग workflow का हिस्सा हैं, और स्रोत कोड एक्सपोर्ट उपलब्ध होता है जब आपको ज़रूरत हो। यह सुरक्षा फिक्स तेज़ी से पुश करने और किसी परिवर्तन के साइड-इफेक्ट होने पर सुरक्षित रूप से recover करने में आसान बना सकता है।
A VDP लोगों को एक स्पष्ट, कानूनी और predictable तरीका देता है जिससे वे आपको सुरक्षा मुद्दे रिपोर्ट कर सकें। यह रोकता है कि रिपोर्ट सार्वजनिक पोस्ट, रैंडम डीएम, या बार-बार जांच के रूप में अचानक सामने आएं.
मुख्य लाभ तेज़ी और नियंत्रण है: आपको समस्याओं के बारे में पहले पता चलता है, आप शांति से उन्हें ठीक कर सकते हैं, और लगातार प्रतिक्रिया देकर आप भरोसा बनाते हैं।
शुरू करें जब आप विश्वसनीय रूप से ये तीन काम कर सकें:
यदि आप अभी ये नहीं कर सकते, तो स्कोप को टैट कर लें और समयसीमाएँ लंबी रखें न कि VDP को पूरी तरह छोड़ दें।
एक सरल VDP नीति में ये शामिल होना चाहिए:
डिफ़ॉल्ट: सबसे पहले वे एसेट्स चुनें जिन पर आप end-to-end मालिकाना रखते हैं, आमतौर पर आपका production वेब ऐप और सार्वजनिक API.
किसी भी चीज़ को बाहर रखें जिसे आप तुरंत verify या fix नहीं कर सकते (पुराने प्रोटोटाइप, आंतरिक टूल्स, थर्ड-पार्टी सर्विसेज)। एक बार आपकी workflow स्थिर हो जाए तो आप स्कोप बढ़ा सकते हैं।
सामान्य बेसलाइन नियम:
साफ़ सीमाएँ यूज़र्स की सुरक्षा करती हैं और अच्छे इरादे वाले रिसर्चर्स को भी सुरक्षा देती हैं।
ऐसी रिपोर्ट माँगें जो आसानी से reproduce की जा सके:
सुझाए गए फिक्स मददगार होते हैं पर अनिवार्य नहीं; reproducibility सबसे ज़्यादा मायने रखती है।
एक मालिक चुनें (और एक बैकअप) और एक सरल फ्लो अपनाएँ:
जब रिपोर्ट साझा इनबॉक्स में बिना मालिक के पड़ी रहती हैं तो VDP टूट जाता है।
एक छोटा रबरिक जो प्रभाव पर टिका हो इस्तेमाल करें:
संशय होने पर ट्रायएज में ऊपर से शुरू करें, फिर वास्तविक दुनिया के असर की पुष्टि के बाद समायोजित करें।
एक छोटे टीम के लिए व्यावहारिक डिफ़ॉल्ट:
यदि आप इन पर खरे नहीं उतर सकते, तो अभी इन्हें बड़ा रखें और फिर अपने लक्ष्य से बेहतर करें।
जब आप अधिक वॉल्यूम संभाल सकें और आपके पास ये हो:
VDP बेसलाइन है; बाउंटी ज्यादा ध्यान और दबाव लाती है, इसलिए तभी जोड़ें जब आप साथ रख सकें।
इसे छोटा रखें और केवल वही वादा करें जो आप लगातार निभा सकें।
