Android की सुरक्षा टीम, Android प्लैटफ़ॉर्म और Android डिवाइसों के साथ बंडल किए गए कई मुख्य Android ऐप्लिकेशन में मिली सुरक्षा से जुड़ी जोखिम की आशंकाओं को मैनेज करने के लिए ज़िम्मेदार है.
Android की सुरक्षा टीम, अंदरूनी रिसर्च के ज़रिए सुरक्षा से जुड़े जोखिमों का पता लगाती है. साथ ही, तीसरे पक्षों की ओर से बताई गई गड़बड़ियों के बारे में भी जवाब देती है. बाहरी गड़बड़ियों के सोर्स में ये शामिल हैं: कमज़ोरी की जानकारी देने वाला फ़ॉर्म के ज़रिए रिपोर्ट की गई समस्याएं, पब्लिश की गई और पब्लिश होने से पहले की गई शैक्षणिक रिसर्च, अपस्ट्रीम ओपन सोर्स प्रोजेक्ट के रखरखाव करने वाले लोग, डिवाइस बनाने वाली कंपनियों के पार्टनर से मिली सूचनाएं, और ब्लॉग या सोशल मीडिया पर सार्वजनिक तौर पर बताई गई समस्याएं.
सुरक्षा से जुड़ी समस्याओं की शिकायत करना
कोई भी डेवलपर, Android का इस्तेमाल करने वाला व्यक्ति या सुरक्षा रिसर्चर, Android की सुरक्षा टीम को सुरक्षा से जुड़ी संभावित समस्याओं के बारे में सूचना दे सकता है. इसके लिए, जोखिम की जानकारी देने वाला फ़ॉर्म भरें.
सुरक्षा से जुड़ी समस्याओं के तौर पर मार्क किए गए बग, बाहरी तौर पर नहीं दिखते. हालांकि, समस्या का आकलन या समाधान होने के बाद, उन्हें आखिर में दिखाया जा सकता है. अगर आपको सुरक्षा से जुड़ी किसी समस्या को हल करने के लिए, पैच या Compatibility Test Suite (CTS) टेस्ट सबमिट करना है, तो कृपया इसे गड़बड़ी की रिपोर्ट में अटैच करें. साथ ही, AOSP पर कोड अपलोड करने से पहले जवाब का इंतज़ार करें.
गड़बड़ियों को प्राथमिकता के हिसाब से व्यवस्थित करना
सुरक्षा से जुड़ी जोखिम की आशंका को ठीक करने के लिए, सबसे पहले यह पता लगाना ज़रूरी है कि बग कितना गंभीर है और Android का कौन-सा कॉम्पोनेंट इससे प्रभावित हुआ है. गंभीरता के आधार पर यह तय किया जाता है कि समस्या को कितनी प्राथमिकता दी जाएगी. वहीं, कॉम्पोनेंट के आधार पर यह तय किया जाता है कि गड़बड़ी को कौन ठीक करेगा, किसे इसकी सूचना दी जाएगी, और गड़बड़ी को ठीक करने के बाद उपयोगकर्ताओं के लिए इसे कैसे डिप्लॉय किया जाएगा.
कॉन्टेक्स्ट टाइप
इस टेबल में, हार्डवेयर और सॉफ़्टवेयर की सुरक्षा से जुड़े कॉन्टेक्स्ट की परिभाषाएं दी गई हैं. कॉन्टेक्स्ट को इस तरह से तय किया जा सकता है कि यह आम तौर पर किस तरह के संवेदनशील डेटा को प्रोसेस करता है या यह किस क्षेत्र में काम करता है. सभी सिस्टम पर सभी सुरक्षा कॉन्टेक्स्ट लागू नहीं होते. इस टेबल को सबसे कम से लेकर सबसे ज़्यादा प्राथमिकता के हिसाब से क्रम में लगाया गया है.
| कॉन्टेक्स्ट टाइप | टाइप की परिभाषा |
|---|---|
| सीमित कॉन्टेक्स्ट |
यह एक प्रतिबंधित एक्ज़ीक्यूशन एनवायरमेंट है, जहां सिर्फ़ बुनियादी अनुमतियां दी जाती हैं. उदाहरण के लिए, सैंडबॉक्स वाले एनवायरमेंट में गैर-भरोसेमंद डेटा को प्रोसेस करने वाले भरोसेमंद ऐप्लिकेशन. |
| अनप्रिविलेज्ड कॉन्टेक्स्ट |
यह एक सामान्य एक्ज़ीक्यूशन एनवायरमेंट है, जिसे बिना किसी खास अधिकार वाले कोड के लिए इस्तेमाल किया जाता है. उदाहरण के लिए, ऐसा Android ऐप्लिकेशन जो untrusted_app_all एट्रिब्यूट के साथ SELinux डोमेन में चलता है.
|
| Privileged context |
यह एक खास एक्ज़ीक्यूशन एनवायरमेंट होता है. इसके पास ज़्यादा अनुमतियों का ऐक्सेस हो सकता है. यह कई उपयोगकर्ताओं की निजी पहचान से जुड़ी जानकारी (पीआईआई) को मैनेज करता है और/या सिस्टम की इंटिग्रिटी बनाए रखता है. उदाहरण के लिए, ऐसा Android ऐप्लिकेशन जिसमें ऐसी सुविधाएं हों जिन पर SELinux untrusted_app डोमेन से पाबंदी लगी हो या जिसे privileged|signature अनुमतियां ऐक्सेस करने की अनुमति हो.
|
| ओएस कर्नेल |
ऐसी सुविधाएं जो:
|
| भरोसेमंद हार्डवेयर बेस (टीएचबी) | अलग-अलग हार्डवेयर कॉम्पोनेंट, जो आम तौर पर SoC पर होते हैं. ये डिवाइस के मुख्य इस्तेमाल के मामलों के लिए ज़रूरी फ़ंक्शन उपलब्ध कराते हैं. जैसे, सेल्युलर बेसबैंड, डीएसपी, जीपीयू, और एमएल प्रोसेसर. |
| बूटलोडर चेन | यह एक ऐसा कॉम्पोनेंट है जो बूट होने पर डिवाइस को कॉन्फ़िगर करता है. इसके बाद, कंट्रोल को Android OS को पास कर देता है. |
| ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) | यह एक ऐसा कॉम्पोनेंट है जिसे किसी भी तरह के ओएस कर्नल से सुरक्षित रखने के लिए डिज़ाइन किया गया है. उदाहरण के लिए, TrustZone और हाइपरवाइज़र, जैसे कि pKVM, जो वर्चुअल मशीनों को ओएस कर्नल से सुरक्षित रखते हैं. |
| Secure Enclave / Secure Element (SE) |
यह एक वैकल्पिक हार्डवेयर कॉम्पोनेंट है. इसे डिवाइस के अन्य सभी कॉम्पोनेंट और फ़िज़िकल अटैक से सुरक्षित रखने के लिए डिज़ाइन किया गया है. इसके बारे में सुरक्षित एलिमेंट के बारे में जानकारी लेख में बताया गया है. इसमें कुछ Android डिवाइसों में मौजूद Titan-M चिप शामिल है. |
गंभीरता
किसी बग की गंभीरता से आम तौर पर यह पता चलता है कि अगर किसी बग का फ़ायदा उठाया जाता है, तो कितना नुकसान हो सकता है. समस्या की गंभीरता का पता लगाने के लिए, इन शर्तों का इस्तेमाल करें.
| रेटिंग | सफल शोषण के नतीजे |
|---|---|
| सबसे अहम सिद्धांत |
|
| ज़्यादा |
|
| ठीक-ठाक |
|
| कम |
|
| सुरक्षा पर न के बराबर असर (एनएसआई) |
|
गंभीरता के मॉडिफ़ायर
सुरक्षा से जुड़ी कमियों की गंभीरता का पता लगाना अक्सर आसान होता है. हालांकि, स्थितियों के आधार पर रेटिंग में बदलाव हो सकता है.
| वजह | प्रभाव |
|---|---|
| हमले को अंजाम देने के लिए, इसे खास अधिकार वाले कॉन्टेक्स्ट के तौर पर चलाना ज़रूरी है. यह टीईई, एसई, और pKVM जैसे हाइपरवाइज़र पर लागू नहीं होता | -1 गंभीरता |
| कमज़ोरी से जुड़ी जानकारी देने से, समस्या का असर कम हो जाता है | -1 गंभीरता |
| बायोमेट्रिक ऑथेंटिकेशन को बायपास करने की सुविधा. इसके लिए, डिवाइस के मालिक से सीधे तौर पर बायोमेट्रिक जानकारी की ज़रूरत होती है | -1 गंभीरता |
| कंपाइलर या प्लैटफ़ॉर्म कॉन्फ़िगरेशन, सोर्स कोड में मौजूद किसी जोखिम को कम करते हैं | अगर बुनियादी कमज़ोरी मध्यम या उससे ज़्यादा है, तो मध्यम गंभीरता |
| इसके लिए, डिवाइस के इंटरनल कॉम्पोनेंट को ऐक्सेस करना ज़रूरी होता है. डिवाइस बंद होने या चालू होने के बाद से अनलॉक न होने पर भी ऐसा किया जा सकता है | -1 गंभीरता |
| डिवाइस चालू होने और पहले अनलॉक किए जाने के दौरान, डिवाइस के इंटरनल को फ़िज़िकल ऐक्सेस करने की ज़रूरत होती है | -2 गंभीरता |
| लोकल अटैक, जिसके लिए बूटलोडर चेन को अनलॉक करना ज़रूरी है | कम से ज़्यादा नहीं |
| ऐसा लोकल अटैक जिसमें डिवाइस पर डेवलपर मोड या डेवलपर मोड की कोई सेटिंग चालू होनी चाहिए. साथ ही, यह डेवलपर मोड की कोई गड़बड़ी नहीं होनी चाहिए. | कम से ज़्यादा नहीं |
| अगर Google की ओर से उपलब्ध कराई गई SEPolicy के तहत, कोई भी SELinux डोमेन कार्रवाई नहीं कर सकता | सुरक्षा पर बहुत कम असर पड़ा है |
लोकल बनाम प्रॉक्सिमल बनाम रिमोट
रिमोट अटैक वेक्टर से पता चलता है कि ऐप्लिकेशन इंस्टॉल किए बिना या डिवाइस का फ़िज़िकल ऐक्सेस पाए बिना, बग का फ़ायदा उठाया जा सकता है. इसमें ऐसे बग शामिल हैं जो किसी वेब पेज को ब्राउज़ करने, ईमेल पढ़ने, एसएमएस मैसेज पाने या किसी नुकसान पहुंचाने वाले नेटवर्क से कनेक्ट करने पर ट्रिगर हो सकते हैं.
प्रॉक्सिमल अटैक वेक्टर को रिमोट माना जाता है. इनमें ऐसे बग शामिल हैं जिनका फ़ायदा सिर्फ़ ऐसा हमलावर उठा सकता है जो टारगेट डिवाइस के आस-पास मौजूद हो. उदाहरण के लिए, ऐसा बग जिसके लिए खराब फ़ॉर्मैट वाले वाई-फ़ाई या ब्लूटूथ पैकेट भेजने की ज़रूरत होती है. हम अल्ट्रा-वाइडबैंड (यूडब्ल्यूबी) और एनएफ़सी पर आधारित हमलों को प्रॉक्सिमल मानते हैं. इसलिए, इन्हें रिमोट माना जाता है.
लोकल अटैक के लिए, हमलावर के पास पीड़ित के डिवाइस का ऐक्सेस पहले से होना चाहिए. सिर्फ़ सॉफ़्टवेयर का इस्तेमाल करके किए गए एक काल्पनिक उदाहरण में, ऐसा किसी ऐसे नुकसान पहुंचाने वाले ऐप्लिकेशन के ज़रिए किया जा सकता है जिसे पीड़ित ने इंस्टॉल किया है. इसके अलावा, ऐसा किसी ऐसे झटपट ऐप्लिकेशन के ज़रिए भी किया जा सकता है जिसे चलाने की अनुमति पीड़ित ने दी है.
जो डिवाइस सफलतापूर्वक कनेक्ट हो जाते हैं (जैसे कि ब्लूटूथ वाले साथी डिवाइस), उन्हें लोकल डिवाइस माना जाता है. हम जोड़े गए डिवाइस और पेयरिंग की प्रोसेस में शामिल डिवाइस के बीच अंतर करते हैं.
- ऐसे बग जो उपयोगकर्ता को यह पता लगाने में मुश्किल पैदा करते हैं कि कौनसे डिवाइस को पेयर किया जा रहा है (जैसे कि पुष्टि करना), उन्हें प्रॉक्सिमल माना जाता है. इसलिए, उन्हें रिमोट माना जाता है.
- पेयरिंग के दौरान, उपयोगकर्ता की सहमति (यानी कि अनुमति) मिलने से पहले होने वाली गड़बड़ियों को प्रॉक्सिमल माना जाता है. इसलिए, इन्हें रिमोट गड़बड़ियां माना जाता है.
- उपयोगकर्ता की सहमति मिलने के बाद होने वाली गड़बड़ियों को स्थानीय गड़बड़ियां माना जाता है. भले ही, पेयरिंग आखिर में काम न करे.
फ़िज़िकल अटैक वेक्टर को स्थानीय माना जाता है. इनमें ऐसे बग शामिल हैं जिनका फ़ायदा सिर्फ़ ऐसा हमलावर उठा सकता है जिसके पास डिवाइस का फ़िज़िकल ऐक्सेस हो. उदाहरण के लिए, लॉक स्क्रीन में मौजूद कोई बग या ऐसा बग जिसके लिए यूएसबी केबल को प्लग इन करना ज़रूरी हो. यूएसबी से कनेक्ट होने पर, डिवाइसों के अनलॉक होने की संभावना ज़्यादा होती है. इसलिए, यूएसबी कनेक्शन की ज़रूरत वाले हमलों की गंभीरता एक जैसी होती है. इससे कोई फ़र्क़ नहीं पड़ता कि डिवाइस को अनलॉक करना ज़रूरी है या नहीं.
नेटवर्क सिक्योरिटी
Android यह मानता है कि सभी नेटवर्क खतरनाक हैं और वे हमलों को इंजेक्ट कर सकते हैं या ट्रैफ़िक की जासूसी कर सकते हैं. लिंक-लेयर सिक्योरिटी (उदाहरण के लिए, वाई-फ़ाई एन्क्रिप्शन) किसी डिवाइस और उससे कनेक्ट किए गए ऐक्सेस पॉइंट के बीच होने वाले कम्यूनिकेशन को सुरक्षित करती है. हालांकि, यह डिवाइस और उन सर्वर के बीच की चेन में मौजूद बाकी लिंक को सुरक्षित नहीं करती जिनसे डिवाइस कम्यूनिकेट कर रहा है.
इसके उलट, एचटीटीपीएस आम तौर पर पूरे कम्यूनिकेशन को एंड-टू-एंड सुरक्षित रखता है. यह डेटा को उसके सोर्स पर एन्क्रिप्ट (सुरक्षित) करता है. इसके बाद, जब डेटा अपने फ़ाइनल डेस्टिनेशन पर पहुंच जाता है, तब उसे डिक्रिप्ट (सुरक्षित तरीके से बदलना) और पुष्टि की जाती है. इस वजह से, लिंक-लेयर नेटवर्क की सुरक्षा को खतरे में डालने वाली कमियों को एचटीटीपीएस/टीएलएस में मौजूद कमियों की तुलना में कम गंभीर माना जाता है: इंटरनेट पर ज़्यादातर कम्यूनिकेशन के लिए, सिर्फ़ वाई-फ़ाई एन्क्रिप्शन काफ़ी नहीं होता.
बायोमेट्रिक ऑथेंटिकेशन
बायोमेट्रिक पुष्टि करना एक मुश्किल काम है. यहां तक कि सबसे अच्छे सिस्टम को भी, मिलते-जुलते डेटा से गुमराह किया जा सकता है. ज़्यादा जानकारी के लिए, Android Developers Blog: Lockscreen and authentication improvements in Android 11 लेख पढ़ें. गंभीरता के आधार पर दी गई इन रेटिंग से, दो तरह के हमलों के बीच अंतर किया जाता है. साथ ही, इनका मकसद यह है कि इनसे अंतिम उपयोगकर्ता को होने वाले जोखिम का पता चल सके.
पहले तरह के हमलों में, बायोमेट्रिक ऑथेंटिकेशन को सामान्य तरीके से बायपास किया जा सकता है. इसके लिए, मालिक के बायोमेट्रिक डेटा की अच्छी क्वालिटी की ज़रूरत नहीं होती. उदाहरण के लिए, अगर कोई हमलावर फ़िंगरप्रिंट सेंसर पर गम का एक टुकड़ा रख देता है और सेंसर पर बचे हुए अवशेष के आधार पर डिवाइस को ऐक्सेस करने की अनुमति मिल जाती है, तो यह एक सामान्य हमला है. इसे किसी भी ऐसे डिवाइस पर किया जा सकता है जिसमें फ़िंगरप्रिंट सेंसर की सुविधा हो. इसके लिए, डिवाइस के मालिक की जानकारी की ज़रूरत नहीं होती. यह हमला सामान्य है और इससे ज़्यादा उपयोगकर्ताओं पर असर पड़ सकता है. इसलिए, इस हमले को गंभीरता के हिसाब से पूरी रेटिंग मिलती है. उदाहरण के लिए, लॉकस्क्रीन को बायपास करने के लिए, 'ज़्यादा' रेटिंग मिलती है.
हमले की दूसरी क्लास में आम तौर पर, डिवाइस के मालिक के आधार पर प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (स्पूफ़) शामिल होता है. कभी-कभी, इस बायोमेट्रिक जानकारी को पाना काफ़ी आसान होता है. उदाहरण के लिए, अगर सोशल मीडिया पर किसी व्यक्ति की प्रोफ़ाइल फ़ोटो, बायोमेट्रिक पुष्टि को धोखा देने के लिए काफ़ी है, तो बायोमेट्रिक बाईपास को पूरी गंभीरता वाली रेटिंग मिलेगी. हालांकि, अगर हमलावर को डिवाइस के मालिक से सीधे तौर पर बायोमेट्रिक डेटा हासिल करना पड़ता है (उदाहरण के लिए, उसके चेहरे का इन्फ़्रारेड स्कैन), तो यह एक बड़ी बाधा है. इससे हमले से प्रभावित होने वाले लोगों की संख्या सीमित हो जाती है. इसलिए, यहां -1 मॉडिफ़ायर का इस्तेमाल किया गया है.
SYSTEM_ALERT_WINDOW और टैपजैकिंग
SYSTEM_ALERT_WINDOW और टैपजैकिंग से जुड़ी हमारी नीतियों के बारे में जानकारी पाने के लिए, BugHunter University के
सुरक्षा पर असर न डालने वाली गड़बड़ियां
पेज पर, "सुरक्षा के लिहाज़ से ज़रूरी न होने वाली स्क्रीन पर टैपजैकिंग/ओवरले SYSTEM_ALERT_WINDOW की कमज़ोरी" सेक्शन देखें.
Android Automotive OS में एक से ज़्यादा उपयोगकर्ताओं के लिए सुरक्षा
Android Automotive OS में, एक से ज़्यादा उपयोगकर्ताओं के लिए सुरक्षा मॉडल का इस्तेमाल किया जाता है. यह मॉडल, अन्य डिवाइसों के नाप या आकार के लिए इस्तेमाल किए जाने वाले मॉडल से अलग होता है. हर Android उपयोगकर्ता को किसी अलग व्यक्ति के लिए बनाया जाता है. उदाहरण के लिए, मेहमान के तौर पर कुछ समय के लिए खाता इस्तेमाल करने की सुविधा, उस दोस्त को दी जा सकती है जिसने कार के मालिक से कार उधार ली है. इस तरह के इस्तेमाल के मामलों को ध्यान में रखते हुए, उपयोगकर्ताओं के पास डिफ़ॉल्ट रूप से उन ज़रूरी कॉम्पोनेंट का ऐक्सेस होता है जिनकी मदद से वे गाड़ी का इस्तेमाल कर सकते हैं. जैसे, वाई-फ़ाई और मोबाइल नेटवर्क की सेटिंग.
जिस कॉम्पोनेंट पर असर पड़ा है
गड़बड़ी को ठीक करने की ज़िम्मेदारी, डेवलपमेंट टीम की होती है. यह इस बात पर निर्भर करता है कि गड़बड़ी किस कॉम्पोनेंट में है. यह Android प्लैटफ़ॉर्म का मुख्य कॉम्पोनेंट, ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर (ओईएम) की ओर से उपलब्ध कराया गया कर्नल ड्राइवर या Pixel डिवाइसों पर पहले से लोड किए गए ऐप्लिकेशन में से कोई एक हो सकता है.
Android इंजीनियरिंग टीम, हमारी इंटरनल रिपॉज़िटरी में AOSP कोड में मौजूद गड़बड़ियों को ठीक करती है.
इस कॉम्पोनेंट से यह भी तय होता है कि उपयोगकर्ताओं को अपडेट कैसे मिलेंगे. फ़्रेमवर्क या कर्नल में मौजूद गड़बड़ी के लिए, ओवर-द-एयर (OTA) फ़र्मवेयर अपडेट की ज़रूरत होती है. इसे हर OEM को पुश करना होता है. Google Play पर पब्लिश किए गए किसी ऐप्लिकेशन या लाइब्रेरी (उदाहरण के लिए, Gmail, Google Play Services या WebView) में मौजूद बग को, Google Play से अपडेट के तौर पर Android उपयोगकर्ताओं को भेजा जा सकता है.
पार्टनर को सूचना देना
जब Android सुरक्षा बुलेटिन में AOSP की सुरक्षा से जुड़ी जोखिम की आशंका को ठीक किया जाता है, तो हम Android पार्टनर को समस्या की जानकारी देते हैं और पैच उपलब्ध कराते हैं. Android के हर नए वर्शन के साथ, बैकपोर्ट किए जा सकने वाले वर्शन की सूची बदल जाती है. जिन डिवाइसों पर इसका इस्तेमाल किया जा सकता है उनकी सूची पाने के लिए, डिवाइस बनाने वाली कंपनी से संपर्क करें.
कोड को AOSP में रिलीज़ करना
अगर सुरक्षा से जुड़ी गड़बड़ी AOSP कॉम्पोनेंट में है, तो ओटीए को उपयोगकर्ताओं के लिए रिलीज़ करने के बाद, गड़बड़ी को ठीक करने वाला अपडेट AOSP को भेज दिया जाता है.
Android के अपडेट पाना
Android सिस्टम के अपडेट आम तौर पर, डिवाइसों को ओटीए अपडेट पैकेज के ज़रिए डिलीवर किए जाते हैं. ये अपडेट, डिवाइस बनाने वाली कंपनी या मोबाइल और इंटरनेट सेवा देने वाली कंपनी से मिल सकते हैं. Google Pixel डिवाइस के अपडेट, Google Pixel टीम से मिलते हैं. ये अपडेट, कैरियर के टेक्निकल एक्सेप्टेंस (टीए) की टेस्टिंग प्रक्रिया पूरी होने के बाद मिलते हैं. Google, Pixel की फ़ैक्ट्री इमेज भी पब्लिश करता है. इन्हें डिवाइसों पर साइड-लोड किया जा सकता है.
Google की सेवाएं अपडेट करना
Android की सुरक्षा टीम, सुरक्षा से जुड़ी गड़बड़ियों के लिए पैच उपलब्ध कराने के साथ-साथ, सुरक्षा से जुड़ी गड़बड़ियों की समीक्षा भी करती है. इससे यह पता चलता है कि उपयोगकर्ताओं को सुरक्षित रखने के अन्य तरीके हैं या नहीं. उदाहरण के लिए, Google Play सभी ऐप्लिकेशन को स्कैन करता है. साथ ही, सुरक्षा से जुड़ी किसी गड़बड़ी का गलत फ़ायदा उठाने की कोशिश करने वाले ऐप्लिकेशन को हटा देता है. Google Play से बाहर के सोर्स से इंस्टॉल किए गए ऐप्लिकेशन के लिए, Google Play services वाले डिवाइस भी ऐप्लिकेशन की पुष्टि करें सुविधा का इस्तेमाल कर सकते हैं. इससे, उपयोगकर्ताओं को ऐसे ऐप्लिकेशन के बारे में चेतावनी दी जा सकती है जो नुकसान पहुंचा सकते हैं.
अन्य संसाधन
Android ऐप्लिकेशन डेवलपर के लिए जानकारी: https://developer.android.com
सुरक्षा से जुड़ी जानकारी, Android Open Source और Developer साइटों पर मौजूद है. शुरू करने के लिए इन जगहों पर जाएं:
रिपोर्ट
Android की सुरक्षा टीम कभी-कभी रिपोर्ट या व्हाइटपेपर पब्लिश करती है. ज़्यादा जानकारी के लिए, सुरक्षा रिपोर्ट देखें.