कैसे पता करें कि किसी कंपैनियन ऐप में प्रभावी भेद्यता रिपोर्टिंग चैनल है या नहीं

पुष्टि करें कि प्रवेश बिंदु प्रदाता का ही है

आधिकारिक ऐप-स्टोर लिस्टिंग से जुड़े डेवलपर वेबसाइट से शुरुआत करें, फिर सुरक्षा (Security), विश्वास (Trust), भेद्यता प्रकटीकरण (Vulnerability Disclosure), बग बाउंटी (Bug Bounty), या जिम्मेदार प्रकटीकरण (Responsible Disclosure) पृष्ठ देखें। उसी आधिकारिक डोमेन पर मानक /.well-known/security.txt स्थान की जांच करें। RFC 9116 सुरक्षा संपर्कों को खोजना आसान बनाने के लिए उस फ़ाइल को परिभाषित करता है और इसे नीति, एन्क्रिप्शन, पावती, भाषा और समाप्ति (एक्सपायरी) जानकारी को इंगित करने की अनुमति देता है। सोशल-मीडिया डायरेक्ट मैसेज, कम्युनिटी मॉडरेटर, या किसी पुराने फ़ोरम पोस्ट से कॉपी किए गए पते को तब तक असत्यापित मानें जब तक कि आधिकारिक डोमेन इसकी पुष्टि न कर दे। पृष्ठ का URL और उसकी दृश्यमान अपडेट या समाप्ति तिथि रिकॉर्ड करें। एक security.txt फ़ाइल जो वर्षों पहले समाप्त हो चुकी है, किसी असंबंधित मूल कंपनी पर पुनर्निर्देशित (रीडायरेक्ट) करती है, या किसी निष्क्रिय मेलबॉक्स का नाम देती है, वह पुष्टि प्राप्त करने की चेतावनी है—अन्यत्र विवरण प्रकाशित करने की अनुमति नहीं।

चैनल का मूल्यांकन करने से पहले दायरा और सुरक्षित-आचरण की सीमाएं पढ़ें

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

जांचें कि एक उपयोगी रिपोर्ट और सुरक्षित सबमिशन कैसा दिखता है

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

पावती, स्थिति और क्लोजर देखें—त्वरित समाधान नहीं

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

समन्वित प्रकटीकरण और रिपोर्टर गोपनीयता शर्तों को सत्यापित करें

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

समस्या को सही ढंग से रूट करें और सात-साक्ष्य परिणाम रिकॉर्ड करें

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

इस विषय को आगे पढ़ें