कंप्यूटर सुरक्षा कठिन क्यों है

⚠️ इस लेख के कुछ अंश अधिक गहराई वाले तकनीकी विवरण बताते हैं। ⚠️ चिह्न वाले अनुच्छेद या पूरे खंड वैकल्पिक हैं। यदि आप केवल मुख्य विचार समझना चाहते हैं, तो इन्हें छोड़ सकते हैं; इससे लेख का मुख्य तर्क समझने में बाधा नहीं आएगी।

परिचय

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

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

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

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

एक खतरे का मॉडल यह पहचान करता है कि किस चीज़ को सुरक्षा की आवश्यकता है, हमलावर क्या बदल सकता है, विशेषाधिकार प्राप्त निर्णय कहाँ होते हैं और कौन सी धारणाएँ विफल हो सकती हैं। यह हर हमले की भविष्यवाणी करने का दावा किए बिना नुकसान के संभावित मार्गों को उजागर करने में मदद करता है। [2]

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

जहां सुरक्षा सबसे पहले विफल होती है

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

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

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

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

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

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

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

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

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

पहचान, अनुमति और प्रत्यायोजित अधिकार

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

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

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

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

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

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

जब सही जाँच अब लागू नहीं होती

अनुमति जाँच करते समय सही हो सकती है, लेकिन फिर भी बाद की कार्रवाई को सुरक्षित करने में विफल हो सकती है। किसी फ़ाइल को स्वीकृत किया जा सकता है और फिर प्रोग्राम द्वारा खोले जाने से पहले उसे बदला जा सकता है। दो कर्मचारी पर्याप्त स्टॉक देख सकते हैं और फिर दोनों उसका उपभोग कर सकते हैं। ये जाँच और उपयोग के बीच स्थिति बदलने की समस्या (TOCTOU) समस्याएँ हैं: निरीक्षण की गई स्थिति अब वह स्थिति नहीं है जिस पर परिणामी क्रिया होती है। ये सुरक्षा कमजोरियाँ तब बन जाती हैं जब कोई अन्य पक्ष आवश्यक नियम का उल्लंघन करने के लिए इस अंतर का फायदा उठा सकता है। कुछ समवर्ती क्रियाओं से उत्पन्न होती हैं; अन्य उन संसाधनों से संबंधित हैं जिनकी पहचान या अनुमतियाँ काम के दौरान बदल जाती हैं। [13]

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

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

जब सूचना को कार्य को निर्देशित करने की अनुमति दी जाती है

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

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

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

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

मेमोरी सुरक्षा और प्रोग्रामिंग भाषाओं की गारंटी

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

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

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

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

मेमोरी-सेफ भाषा सुविधाएँ कुछ भार भाषा या उसके रनटाइम द्वारा लागू किए गए नियमों में स्थानांतरित कर देती हैं। सुरक्षित Rust कोड प्रोग्राम चलने से पहले कई अमान्य संदर्भों को अस्वीकार कर देता है और आवश्यकतानुसार अनुक्रमित एक्सेस की जाँच करता है। Swift की सामान्य सुरक्षित सुविधाएँ सीमाओं और प्रबंधित जीवनकाल बाधाओं को लागू करती हैं। Python एप्लिकेशन कोड आमतौर पर रॉ पॉइंटर अंकगणित करने के बजाय प्रबंधित ऑब्जेक्ट पर काम करता है। ये भाषाएँ सही सुरक्षा निर्णयों की आवश्यकता को समाप्त नहीं करती हैं, और उनकी सुरक्षा आवश्यक रूप से हर नेटिव कंपोनेंट तक विस्तारित नहीं होती है। Rust में स्पष्ट रूप से असुरक्षित क्षेत्र हैं; Swift, C लाइब्रेरी को कॉल कर सकता है या असुरक्षित पॉइंटर का उपयोग कर सकता है; Python नेटिव एक्सटेंशन लोड कर सकता है। एक मेमोरी-सेफ एप्लिकेशन जो मेमोरी-असुरक्षित कोड को डेटा पास करता है, उसे उस सीमा और उसके आगे के कोड की जाँच करने की आवश्यकता विरासत में मिलती है। भाषा का चुनाव जोखिम के महत्वपूर्ण वर्गों को बदलता है, लेकिन किसी उत्पाद का मूल्यांकन उसके द्वारा वास्तव में किए जाने वाले कार्यों के आधार पर किया जाना चाहिए। [17] [18] [19]

स्ज़ेकेरेस, पेयर, वेई और सोंग के 2013 के SoK शोध में यह जांच की गई कि मेमोरी-करप्शन एक्सप्लॉइट कैसे विकसित होते हैं और विभिन्न सुरक्षा उपाय उन्हें कैसे बाधित करने का प्रयास करते हैं। उनके विश्लेषण में अमान्य मेमोरी ऑपरेशनों को रोकना, करप्शन का पता लगाना और दोष होने के बाद शोषण को कठिन बनाना शामिल है। ये भौतिक रूप से भिन्न गारंटी हैं। यह शोधपत्र नए कंपाइलर और हार्डवेयर शमन से पहले का है, लेकिन इसका वर्गीकरण बताता है कि किसी एक्सप्लॉइट तकनीक को रोकना यह साबित नहीं करता कि अंतर्निहित मेमोरी दोष दूर हो गया है। [20]

सुरक्षित भाषाएँ सहायक होती हैं, लेकिन मौजूदा प्रणालियों को रातोंरात बदला नहीं जा सकता। C और C++ ऑपरेटिंग सिस्टम, फ़र्मवेयर और विशिष्ट लाइब्रेरी में गहराई से समाहित हैं, जिनमें से कई प्रदर्शन, हार्डवेयर या संगतता संबंधी बाधाओं का सामना करती हैं। उन्हें फिर से लिखने से स्वयं दोष उत्पन्न हो सकते हैं, और टीमों को प्रतिस्थापनों को मान्य करने के लिए कौशल और उपकरणों की आवश्यकता होती है। यह अनिश्चित काल तक असुरक्षित मेमोरी हैंडलिंग को स्वीकार करने का औचित्य नहीं देता है। व्यावहारिक मूल्यांकन यह है कि अविश्वसनीय डेटा अनियंत्रित संचालन तक कहाँ पहुँचता है, कौन सी मूल निर्भरताएँ बनी रहती हैं, उन घटकों के क्या विशेषाधिकार हैं और परीक्षण, निवारण और रखरखाव जोखिम को कैसे संबोधित करते हैं। केवल एक भाषा लेबल इन सवालों का जवाब नहीं दे सकता। [2]

जब डिज़ाइन ही असुरक्षित हो

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

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

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

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

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

गुप्त जानकारी ऐसे व्यवहार से भी लीक हो सकती है जिसका उद्देश्य कभी उत्तर देना नहीं था। अलग-अलग त्रुटि संदेशों से पता चल सकता है कि कोई खाता मौजूद है या नहीं। एक जाँच जिसमें गुप्त जानकारी के आधार पर अलग-अलग समय लगता है, यदि उस अंतर को विश्वसनीय रूप से देखा जा सकता है, तो समय-आधारित साइड चैनल से जानकारी लीक हो सकती है। ये खुलासे गुप्त जानकारी के लिए सीधे अनुरोध या किसी टूटे हुए एन्क्रिप्शन एल्गोरिदम के बिना भी हो सकते हैं। हर मापने योग्य अंतर का फायदा नहीं उठाया जा सकता; संकेत, परिस्थितियाँ और जो अनुमान लगाया जा सकता है, सब मायने रखते हैं। [26]

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

किसी प्रोटोकॉल में डिज़ाइन संबंधी खामी अंतर्निहित हो सकती है: कार्यान्वयन उसके नियमों का पूरी निष्ठा से पालन कर सकता है, भले ही उन नियमों में किसी वैध संदेश को पुनः प्रसारित करने, पुनर्निर्देशित करने या उसका दुरुपयोग करने का कोई रास्ता हो। रॉस एंडरसन और रोजर नीडहम ने प्रोग्रामिंग सैटन्स कंप्यूटर में इस प्रतिकूल परिप्रेक्ष्य का अध्ययन किया है। [27] यहां तक ​​कि सही ढंग से निर्दिष्ट और कार्यान्वित सॉफ़्टवेयर भी हार्डवेयर द्वारा अपेक्षित सीमाओं को संरक्षित करने पर निर्भर करता है।

जब हार्डवेयर ही असुरक्षित हो

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

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

⚠️ हार्डवेयर की अन्य कमजोरियाँ जानकारी को बदले बिना ही उसे उजागर कर सकती हैं। आधुनिक प्रोसेसर कभी-कभी समय बचाने के लिए पहले से ही काम करते हैं, यह अनुमान लगाते हुए कि किन निर्देशों की आवश्यकता होगी। इसे अनुमानात्मक निष्पादन (speculative execution) कहा जाता है। यदि अनुमान गलत साबित होता है, तो अस्थायी परिणाम को हटा दिया जाता है, लेकिन उस काम के निशान कैश में रह सकते हैं, जो एक छोटा भंडार है जो प्रोसेसर को हाल ही में उपयोग की गई जानकारी को जल्दी से पुनः प्राप्त करने में मदद करता है। उन निशानों को मापने से कभी-कभी ऐसे रहस्य उजागर हो सकते हैं जिन्हें प्रोग्राम को पढ़ने की अनुमति नहीं थी। स्पेक्ट्रे ने इस तरह के खुलासे को प्रेरित करने के लिए हेरफेर किए गए अनुमानों का फायदा उठाया; मेल्टडाउन ने एक्सेस उल्लंघन के प्रभावी होने से पहले कुछ प्रोसेसर द्वारा संरक्षित डेटा को संभालने के तरीके में एक अलग कमजोरी का फायदा उठाया। ये प्रोसेसर साइड चैनल हैं, जो पहले वर्णित टाइमिंग लीक से संबंधित हैं। ये इस बात से संबंधित हैं कि एक प्रोसेसर आंतरिक रूप से निर्देशों को कैसे निष्पादित करता है, न कि केवल प्रकाशित निर्देश सेट जो यह बताता है कि सॉफ़्टवेयर किन कार्यों का अनुरोध कर सकता है। प्रभावित प्रोसेसर, स्थितियाँ और प्रतिउपाय भिन्न होते हैं। [30] [31] [32]

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

⚠️ 2018 में सामने आई Fusée Gelée नामक Tegra X1 रिकवरी-मोड भेद्यता एक ऐसी खामी को दर्शाती है जो भौतिक USB एक्सेस के माध्यम से पहुँच योग्य है, न कि रिमोट नेटवर्क सेवा के माध्यम से। सॉफ़्टवेयर में बदलाव और परिचालन प्रतिबंध जोखिम को कम कर सकते हैं, लेकिन वे वास्तव में अपरिवर्तनीय बूट ROM को दोबारा नहीं लिख सकते। सुरक्षित बूट अपने मूल विश्वास की गारंटी और इसके द्वारा कवर की जाने वाली हमले की स्थितियों के दायरे में मूल्यवान बना रहता है। [33] [34] [35]

⚠️ ग्लोसनर और माचिरी के 2026 के SoK ने हार्डवेयर-आधारित हैंडऑफ़ के बाद सॉफ़्टवेयर बूट श्रृंखला में 43 बूटलोडर की जाँच की। इसके BOOTBENCH डेटासेट में 3,658 रिपोर्ट की गई कमजोरियाँ और संबंधित परिवर्तन शामिल हैं, और लेखकों ने मौजूदा पहचान और सुदृढ़ीकरण तकनीकों में सीमाओं की पहचान की। ये आंकड़े यह साबित नहीं करते कि हर बूटलोडर का शोषण किया जा सकता है या कोई विशेष डिवाइस असुरक्षित है। वे यह दर्शाते हैं कि बूट सॉफ़्टवेयर के अधिकृत स्रोत से आने की पुष्टि करना, यह स्थापित करने से अलग है कि अधिकृत कार्यान्वयन में कोई शोषण योग्य दोष नहीं है। [36]

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

विफलता को फैलने से पहले ही नियंत्रित करना

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

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

व्यवहार में ये सीमाएँ कैसे सफल या असफल होती हैं, इस पर पर्याप्त शोध हुआ है। लेफ्यूवर और उनके सहयोगियों के 2025 के SoK ने 211 शोध प्रयासों और 61 मुख्यधारा के खंडित प्रणालियों का विश्लेषण किया। इसने प्रयोग करने योग्य अलगाव नीतियों को परिभाषित करने, शोध को उत्पादन में बदलने और भ्रमित प्रतिनिधियों और हार्डवेयर बाधाओं से जुड़े खतरों का मूल्यांकन करने में लगातार कठिनाइयों की पहचान की। यदि किसी प्रक्रिया की अनुमतियाँ अत्यधिक हैं या कोई विशेषाधिकार प्राप्त होस्ट उससे अप्रतिबंधित अनुरोधों पर कार्य करता है, तो वह प्रभावी नियंत्रण का प्रमाण नहीं है। प्रासंगिक इंजीनियरिंग कार्य इंटरफ़ेस के दोनों पक्षों पर उपलब्ध अधिकार को परिभाषित करना और यह प्रदर्शित करना है कि लागू की गई सीमाएँ उस डिज़ाइन से मेल खाती हैं। [37]

नियंत्रण एक सामान्य सिद्धांत को दर्शाता है: रोकथाम और क्षति सीमित करने के अलग-अलग कार्य होते हैं। इनपुट जाँच का उद्देश्य किसी हानिकारक क्रिया को शुरू होने से पहले ही अस्वीकार करना है। मेमोरी सुरक्षा नियम कुछ अमान्य पहुँच को रोकते हैं। सैंडबॉक्सिंग उन संसाधनों को सीमित करती है जहाँ तक दोषपूर्ण कोड पहुँच सकता है। निगरानी और पुनर्प्राप्ति किसी सेवा को संभावित विफलताओं को पहचानने और उनका जवाब देने में मदद करती है। कई सुरक्षा उपाय एक गलती के परिणामों को कम कर सकते हैं, लेकिन उनकी स्वतंत्रता को मान लेने के बजाय स्थापित किया जाना चाहिए। इसलिए, सफलतापूर्वक उपयोग किया गया दोष एक सीमित घटक तक ही सीमित रह सकता है; यह स्वचालित रूप से सिस्टम के हर हिस्से तक पहुँच प्रदान नहीं करता है। एक ईमानदार सुरक्षा दावा निषिद्ध प्रभाव और प्रासंगिक सीमाओं को लागू करने वाले तंत्रों की पहचान करता है, न कि तकनीकों की गिनती करने या सुरक्षित शब्द का विज्ञापन करने की। [38]

⚠️ नियंत्रण और हार्डवेयर सुरक्षा की सीमाएँ

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

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

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

Secure Enclave (सिक्योर एन्क्लेव) एक अलग प्रवर्तन सीमा का उदाहरण है। समर्थित Apple उपकरणों पर, यह अपने स्वयं के सुरक्षित स्टार्टअप, संरक्षित मेमोरी और माइक्रोकर्नेल के साथ एक सुरक्षा प्रोसेसर है। इसे मुख्य ऑपरेटिंग सिस्टम कर्नेल के असुरक्षित होने पर भी चुनिंदा रहस्यों की सुरक्षा के लिए डिज़ाइन किया गया है। एक एप्लिकेशन सिक्योर एन्क्लेव द्वारा नियंत्रित कार्यों के लिए एक निजी कुंजी उत्पन्न कर सकता है और कुंजी प्राप्त किए बिना ही अनुमत क्रिप्टोग्राफिक कार्य का अनुरोध कर सकता है। क्या संरक्षित रहता है यह कुंजी की पहुँच नीति और एन्क्लेव द्वारा लागू किए जाने वाले कार्यों पर निर्भर करता है, न कि केवल चिप की उपस्थिति पर। [41] [42]

अन्य प्रणालियाँ हार्डवेयर द्वारा लागू की गई विभिन्न सीमाओं का उपयोग करती हैं। एक विश्वसनीय प्लेटफ़ॉर्म मॉड्यूल (टीपीएम), जिसे एक अलग डिवाइस के रूप में या प्रोसेसर के भीतर कार्यान्वित किया जाता है, चयनित क्रिप्टोग्राफ़िक कुंजियों की सुरक्षा करता है और सिस्टम की शुरुआत के मापों से उनके उपयोग को जोड़ सकता है; यह एप्लिकेशन कोड चलाने के लिए एक सामान्य-उद्देश्यीय वातावरण नहीं है। Arm TrustZone समर्थित प्रोसेसर पर सुरक्षित और सामान्य निष्पादन स्थितियों को अलग करता है, इसलिए जब सिस्टम सही ढंग से डिज़ाइन किया जाता है, तो निर्दिष्ट सॉफ़्टवेयर और संसाधन सामान्य ऑपरेटिंग सिस्टम के लिए दुर्गम रह सकते हैं। Intel Software Guard Extensions (SGX), समर्थित प्रोसेसर पर, चयनित एप्लिकेशन कोड और डेटा को विशेषाधिकार प्राप्त सॉफ़्टवेयर से एन्क्लेव में अलग करता है, जिसमें ऑपरेटिंग सिस्टम कर्नेल भी शामिल है। एप्पल के सिक्योर एन्क्लेव के विपरीत, ट्रस्टज़ोन और एसजीएक्स को एक अलग सुरक्षा प्रोसेसर की आवश्यकता नहीं होती है। वे विभिन्न संसाधनों की भी सुरक्षा करते हैं और उन्हें विनिमेय नहीं माना जा सकता है। [43] [44] [45]

मुख्य कर्नेल से स्वतंत्र कुछ सुरक्षा प्राधिकरण को बनाए रखना कर्नेल के उल्लंघन के बाद प्लेटफ़ॉर्म के भरोसे को बहाल करने में भी मदद कर सकता है। कर्नेल के नियंत्रण से परे एक विश्वसनीय स्टार्टअप या रिकवरी पथ, डिवाइस के सेवा में वापस आने से पहले अधिकृत फ़र्मवेयर और ऑपरेटिंग सिस्टम सॉफ़्टवेयर की जाँच कर सकता है। संरक्षित कुंजियाँ और बूट प्रक्रिया के मापन इन जाँचों में सहायता कर सकते हैं। NIST अनधिकृत परिवर्तनों का पता लगाने, अपडेट को स्वीकृत करने और क्षतिग्रस्त प्लेटफ़ॉर्म फ़र्मवेयर को पुनर्प्राप्त करने के लिए भरोसे के मूलों को अलग करता है। इन तत्वों को एक कार्यशील रिकवरी प्रक्रिया में संयोजित किया जाना चाहिए: एक TPM, सिक्योर एन्क्लेव, ट्रस्टज़ोन वातावरण या SGX एन्क्लेव, अपने आप में, एक उल्लंघन किए गए ऑपरेटिंग सिस्टम को पुनर्स्थापित नहीं करता है। [35] [38]

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

ज़िंकस, जोइस और ग्रीन के 2022 के SoK ने शक्तिशाली डेटा एक्सट्रैक्शन विरोधियों के खिलाफ मोबाइल उपकरणों पर डेटा गोपनीयता की जांच की, जिनमें भौतिक डिवाइस एक्सेस या संबंधित क्लाउड सेवाओं तक पहुंच रखने वाले भी शामिल हैं। इसका दायरा कुंजी की सुरक्षा से कहीं अधिक व्यापक है: जानकारी सुरक्षित होने से पहले, डिक्रिप्शन के बाद या आश्रित सेवाओं के माध्यम से भी उजागर हो सकती है। यह ऐतिहासिक विश्लेषण वर्तमान SPTM या सिक्योर एन्क्लेव व्यवहार को मान्य नहीं करता है। यह इस बात पर जोर देता है कि यह बताना आवश्यक है कि कौन सी जानकारी सुरक्षित रहती है, किन क्षमताओं के खिलाफ और यह कब एक विश्वसनीय सीमा से बाहर निकल जाती है। [46]

कर्नेल-निर्भर सुरक्षा की सीमाएँ

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

एक iPhone MIE और PAC को सपोर्ट कर सकता है, लेकिन इसका मतलब यह नहीं है कि उस पर चलने वाला हर ऐप इन दोनों सुरक्षा उपायों का इस्तेमाल करता है। Apple कर्नेल सहित चुनिंदा सिस्टम अटैक सरफेस पर MIE को स्वचालित रूप से लागू करता है। यह कवरेज स्वचालित रूप से हर थर्ड-पार्टी ऐप, एक्सटेंशन, हेल्पर प्रोसेस या लाइब्रेरी तक नहीं फैलता है। इसलिए, एक ही सपोर्टेड iPhone पर दो ऐप्स में अलग-अलग सुरक्षा उपाय हो सकते हैं। MIE में Apple द्वारा डिज़ाइन किया गया हार्डवेयर, सुरक्षित मेमोरी एलोकेटर और ऑपरेटिंग सिस्टम कंट्रोल शामिल हैं; यह केवल सामान्य Arm मेमोरी टैगिंग एक्सटेंशन (MTE) नहीं है।

अपने ऐप्स में हार्डवेयर मेमोरी टैगिंग का उपयोग करने के लिए, डेवलपर्स को संबंधित Xcode लक्ष्यों के लिए इसे सक्षम करना होगा और यह पुष्टि करनी होगी कि हार्डवेयर इसका समर्थन करता है। एंटाइटेलमेंट और रनटाइम सेटिंग्स भी मायने रखती हैं: नकली विफलताओं की रिपोर्ट करने वाला डायग्नोस्टिक मोड, जांच को लागू करने के समान नहीं है। PAC एक अलग निवारण है। केवल संगत हार्डवेयर का मतलब यह नहीं है कि प्रत्येक ऐप बाइनरी PAC का उपयोग करता है; संबंधित कोड को उपयुक्त arm64e आर्किटेक्चर के लिए बनाया जाना चाहिए, और बाहरी नेटिव लाइब्रेरी को संगत बिल्ड की आवश्यकता होती है। डेवलपर्स को यह सत्यापित करना चाहिए कि वास्तविक रिलीज़ में कौन सी सुरक्षाएँ सक्षम हैं, जिसमें इसके घटक और निर्भरताएँ शामिल हैं, और समर्थित भौतिक उपकरणों पर परीक्षण करना चाहिए। डिवाइस विनिर्देश किसी विशेष ऐप में सुरक्षाओं के संचालन का प्रमाण नहीं है। [47] [48] [49]

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

जब सुरक्षा उपाय विफल हो जाते हैं

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

किसी हमले का असर पहले खाते या प्रक्रिया तक ही सीमित नहीं रहता। हमलावर उस आधार का उपयोग करके उच्चतर अनुमतियाँ प्राप्त कर सकता है, जिसे विशेषाधिकार वृद्धि कहा जाता है, या अतिरिक्त प्रणालियों में प्रवेश कर सकता है, जिसे दूसरी प्रणालियों तक फैलना (lateral movement) कहा जाता है। प्रत्येक अगला कदम किसी अन्य उपयोगी कमजोरी, प्रमाण पत्र या विश्वसनीय संबंध पर निर्भर करता है; एक सेवा पर नियंत्रण स्वचालित रूप से उसके पड़ोसी सेवाओं पर नियंत्रण स्थापित नहीं करता है। यही कारण है कि प्रारंभिक आधार पर उपलब्ध अधिकार, प्रणालियों के बीच अलगाव और विशेषाधिकार प्राप्त अनुरोधों पर जाँच यह निर्धारित करती है कि हमला कितना फैल सकता है। रोकथाम पहले घटक के प्रभावित होने के बाद भी प्रगति को रोक सकती है। [51] [52]

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

जब आपूर्ति श्रृंखला सुरक्षा को कमजोर करती है

यहां तक ​​कि एक छोटा एप्लिकेशन भी दूसरों द्वारा लिखे, निर्मित और अनुरक्षित सॉफ़्टवेयर पर निर्भर करता है: ऑपरेटिंग-सिस्टम घटक, लाइब्रेरी, विकास उपकरण और बाहरी सेवाएं। रिपोर्ट की गई खामी तभी मायने रखती है जब प्रभावित संस्करण मौजूद हो और प्रासंगिक ऑपरेशन उजागर हो, लेकिन अलग-अलग शेड्यूल पर बनाए रखी गई निर्भरताओं के बीच इसे स्थापित करना मुश्किल हो सकता है। इसलिए उत्पाद का नाम उसके संचालन में वास्तव में शामिल घटकों और सेवाओं के बारे में बहुत कम बताता है। [53]

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

अबू इश्गैर और उनके सहयोगियों द्वारा 2026 में किए गए SoK में सॉफ्टवेयर के उत्पादन और वितरण में शामिल अभिनेताओं, चरणों, संसाधनों और कलाकृतियों की जांच करने के लिए AStRA मॉडल का उपयोग किया गया है। यह उन प्रश्नों को अलग करता है जिनका उत्तर SBOM दे सकता है और उन प्रश्नों को जिनके लिए स्रोत परिवर्तनों, बिल्ड अखंडता, रिलीज़ प्राधिकरण और वितरण के बारे में साक्ष्य की आवश्यकता होती है। एक पूर्ण सूची यह स्थापित नहीं करती कि बिल्ड भरोसेमंद था, और स्रोत यह स्थापित नहीं करता कि परिणामी प्रोग्राम दोषों से मुक्त है। साक्ष्य को मूल्यांकन किए जा रहे विशेष आपूर्ति-श्रृंखला जोखिम से मेल खाना चाहिए। [55]

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

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

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

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

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

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

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

रखरखाव और मरम्मत की होड़

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

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

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

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

हमलावर उन लोगों तक समाधान पहुंचने से पहले ही तेज़ी से काम कर सकते हैं जिन्हें उनकी ज़रूरत है। वास्तव में शोषण की गई कमजोरियों के अध्ययन में, मैंडिएंट ने 2018-2019 के लिए शोषण का औसत समय 63 दिन, 2021-2022 के लिए 32 दिन और 2023 के लिए पांच दिन बताया। इसकी 2026 की रिपोर्ट में 2025 के लिए ऋणात्मक सात दिन (−7 दिन) का अनुमान लगाया गया है, जिसका अर्थ है कि अध्ययन किए गए मामलों में औसतन पैच उपलब्ध होने से पहले ही पहली बार शोषण देखा गया। ये चुनिंदा शोषण की गई कमजोरियों के माप हैं, न कि हर खामी के लिए समयसीमा या ग्राहकों द्वारा अपडेट कितनी जल्दी इंस्टॉल किए जाते हैं, इसका माप। ज़ीरो-डे हमले औसत को प्रभावित करते हैं। यह तेज़ी आज के जनरेटिव एआई सिस्टम से पहले ही शुरू हो गई थी। [66] [67] [68]

कृत्रिम बुद्धिमत्ता (AI) द्वारा किया गया विश्लेषण इस पहले से ही कठिन प्रतिस्पर्धा को और भी जटिल बना देता है। प्रकाशित पैच या स्रोत-कोड में बदलाव से यह पता चल सकता है कि कौन सा संस्करण असुरक्षित है और कौन सा उसके प्रतिस्थापन से अलग है। स्वचालित उपकरण संस्करणों की तुलना करने, संभावित परीक्षण विकसित करने और असुरक्षित प्रणालियों की पहचान करने में मदद कर सकते हैं, जिससे ज्ञात कमजोरी का लाभ उठाने के प्रयास में लगने वाला काम कम हो सकता है। 2024 में हुए शोध से पता चला कि एलएलएम-आधारित एजेंट नियंत्रित परिस्थितियों में, जब उन्हें विवरण दिया जाता है, तो पहले से प्रकट की गई कई कमज़ोरियों का फायदा उठा सकता है। सितंबर 2026 में, Google थ्रेट इंटेलिजेंस ने पहले से प्रकट की गई उच्च जोखिम वाली कमज़ोरियों के बढ़ते शोषण की सूचना दी और AI-सहायता प्राप्त विश्लेषण को एक संभावित योगदानकर्ता के रूप में पहचाना, न कि इस बात का प्रमाण कि AI ने हर घटना को अंजाम दिया। [69] [70]

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

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

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

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

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

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

सुरक्षा चेतावनी का आकलन कैसे करें

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

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

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

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

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

निष्कर्ष

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

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

आपको ये बातें जाननी चाहिए:

संदर्भ

क्रमांकित स्रोत पाठ में उद्धृत किए गए हैं। n.d. का अर्थ है प्रकाशन तिथि का उल्लेख नहीं।

1. National Institute of Standards and Technology (2012). Guide for Conducting Risk Assessments. NIST Special Publication 800-30 Rev. 1. DOI: 10.6028/NIST.SP.800-30r1.
2. National Institute of Standards and Technology (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication 800-218. DOI: 10.6028/NIST.SP.800-218.
3. OWASP Foundation (n.d.). Authentication Cheat Sheet. OWASP Cheat Sheet Series.
4. Cybersecurity and Infrastructure Security Agency and Federal Bureau of Investigation (2025). Product Security Bad Practices: Updated Guidance. CISA/FBI advisory, 17 January 2025.
5. OWASP Foundation (n.d.). Session Management Cheat Sheet. OWASP Cheat Sheet Series.
6. Zhuo, S., Biddle, R., Koh, Y. S., Lottridge, D. and Russello, G. (2023). SoK: Human-centered Phishing Susceptibility. ACM Transactions on Privacy and Security, 26(3), Article 24. DOI: 10.1145/3575797.
7. OWASP Foundation (n.d.). Authorization Cheat Sheet. OWASP Cheat Sheet Series.
8. Hardy, N. (1988). The Confused Deputy (or Why Capabilities Might Have Been Invented). ACM SIGOPS Operating Systems Review, 22(4), pp. 36–38. DOI: 10.1145/54289.871709.
9. OWASP Foundation (n.d.). Authorization Patterns Cheat Sheet. OWASP Cheat Sheet Series.
10. The Chromium Project (n.d.). Sandbox Design. Chromium design documentation.
11. National Institute of Standards and Technology (n.d.). Insider Threat. NIST CSRC Glossary.
12. OWASP Foundation (n.d.). Business Logic Security Cheat Sheet. OWASP Cheat Sheet Series.
13. MITRE (n.d.). CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition. Common Weakness Enumeration.
14. OWASP Foundation (n.d.). Input Validation Cheat Sheet. OWASP Cheat Sheet Series.
15. OWASP Foundation (n.d.). SQL Injection Prevention Cheat Sheet. OWASP Cheat Sheet Series.
16. OWASP Foundation (n.d.). Cross Site Scripting Prevention Cheat Sheet. OWASP Cheat Sheet Series.
17. The Rust Project (n.d.). The Rust Programming Language: References and Borrowing; Unsafe Rust. Rust language documentation.
18. The Swift Project (n.d.). Memory Safety. The Swift Programming Language, Swift.org.
19. Python Software Foundation (n.d.). Extending and Embedding the Python Interpreter. Python 3 documentation.
20. Szekeres, L., Payer, M., Wei, T. and Song, D. (2013). SoK: Eternal War in Memory. IEEE Symposium on Security and Privacy, pp. 48–62. DOI: 10.1109/SP.2013.13.
21. Anderson, R. (1993). Why Cryptosystems Fail. Proceedings of the 1st ACM Conference on Computer and Communications Security, pp. 215–227. DOI: 10.1145/168588.168615.
22. Internet Engineering Task Force (2023). Service Identity in TLS. RFC 9525.
23. Internet Engineering Task Force (2020). JSON Web Token Best Current Practices. RFC 8725.
24. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. IETF RFC 8446. DOI: 10.17487/RFC8446.
25. Clark, J. and van Oorschot, P. C. (2013). SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP.2013.41.
26. National Institute of Standards and Technology (n.d.). Side Channel. NIST CSRC Glossary.
27. Anderson, R. and Needham, R. (1995). Programming Satan's Computer. In Computer Science Today, pp. 426–440. DOI: 10.1007/BFB0015258.
28. Kim, Y., et al. (2014). Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors. Proceedings of the 41st International Symposium on Computer Architecture, pp. 361–372. DOI: 10.1109/ISCA.2014.6853210.
29. Seaborn, M. and Dullien, T. (2015). Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges. Google Project Zero research, March 2015.
30. Kocher, P., et al. (2018). Spectre Attacks: Exploiting Speculative Execution. arXiv:1801.01203, security research preprint.
31. Lipp, M., et al. (2018). Meltdown: Reading Kernel Memory from User Space. 27th USENIX Security Symposium.
32. Intel (n.d.). Analysis of Speculative Execution Side Channels. Intel Software Security Guidance.
33. NVIDIA (2018). Security Notice: NVIDIA Tegra RCM Vulnerability. NVIDIA Product Security Notice, 24 April 2018.
34. Temkin, K. and ReSwitched (2018). Fusée Gelée: Boot ROM Vulnerability Disclosure. Research disclosure.
35. National Institute of Standards and Technology (2018). Platform Firmware Resiliency Guidelines. NIST Special Publication 800-193. DOI: 10.6028/NIST.SP.800-193.
36. Glosner, C. and Machiry, A. (2026). SoK: All You Ever Wanted to Know About Bootloader Security but Were Afraid to Ask. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP63933.2026.00163.
37. Lefeuvre, H., Dautenhahn, N., Chisnall, D. and Olivier, P. (2025). SoK: Software Compartmentalization. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP61157.2025.00075.
38. Ross, R., Pillitteri, V., Graubart, R., Bodeau, D. and McQuaid, R. (2021). Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. NIST Special Publication 800-160, Vol. 2 Rev. 1. DOI: 10.6028/NIST.SP.800-160v2r1.
39. Apple (n.d.). Operating System Integrity. Apple Platform Security.
40. Apple Security Research (2025). Memory Integrity Enforcement: A Complete Vision for Memory Safety in Apple Devices. Apple Security Research technical blog.
41. Apple (n.d.). Secure Enclave. Apple Platform Security.
42. Apple Developer (n.d.). Protecting Keys with the Secure Enclave. Apple Developer Documentation, Security.
43. Microsoft (n.d.). Trusted Platform Module (TPM) fundamentals. Microsoft Learn.
44. Arm (n.d.). TrustZone for Cortex-A. Arm Technologies.
45. Intel (n.d.). Intel Software Guard Extensions SDK for Linux OS. Intel Developer Documentation.
46. Zinkus, M., Jois, T. M. and Green, M. (2022). SoK: Cryptographic Confidentiality of Data on Mobile Devices. Proceedings on Privacy Enhancing Technologies, 2022(1), pp. 586–607. DOI: 10.2478/popets-2022-0029.
47. Apple Developer (n.d.). Enabling Enhanced Security for Your App. Apple Developer Documentation, Xcode.
48. Apple Developer (n.d.). Preparing Your App to Work with Pointer Authentication. Apple Developer Documentation, Security.
49. LLVM Project (n.d.). Pointer Authentication. Clang Compiler Documentation.
50. OWASP Foundation (2025). A10: Mishandling of Exceptional Conditions. OWASP Top 10: 2025.
51. MITRE (n.d.). Privilege Escalation (TA0004). MITRE ATT&CK knowledge base.
52. MITRE (n.d.). Lateral Movement (TA0008). MITRE ATT&CK knowledge base.
53. OWASP Foundation (2025). A03: Software Supply Chain Failures. OWASP Top 10: 2025.
54. Cybersecurity and Infrastructure Security Agency and international partners (2026). 2026 Minimum Elements for a Software Bill of Materials (SBOM). Joint government guidance.
55. Abu Ishgair, E., Gomez, J., Melara, M. S., Cárdenas, A. A. and Torres-Arias, S. (2026). SoK: A Defense-Oriented Evaluation of Software Supply Chain Security. IEEE European Symposium on Security and Privacy, pp. 836–859. DOI: 10.1109/EuroSP68448.2026.00059.
56. Boyens, J., et al. (2024). Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. NIST SP 800-161 Rev. 1, Update 1.
57. Arasaratnam, O., et al. (2024). xz Backdoor CVE-2024-3094. Open Source Security Foundation, 30 March 2024.
58. Cox, R. (2024). Timeline of the xz Open Source Attack. Research note, 2024.
59. Supply-chain Levels for Software Artifacts (n.d.). Provenance. SLSA Specification, version 1.2.
60. Supply-chain Levels for Software Artifacts (n.d.). Build: Verifying Artifacts. SLSA Specification, version 1.2.
61. The Update Framework (2024). Overview. TUF Documentation, last updated October 2024.
62. Rekhi, S., Amberiadis, K., Akib, A. A., and Srivastava, A. (2025). Analyzing Collusion Threats in the Semiconductor Supply Chain. NIST Cybersecurity White Paper 46. DOI: 10.6028/NIST.CSWP.46.
63. National Institute of Standards and Technology (n.d.). Supply Chain. NIST Mobile Threat Catalogue.
64. Cybersecurity and Infrastructure Security Agency (n.d.). Known Exploited Vulnerabilities Catalog. CISA vulnerability catalogue.
65. UK National Cyber Security Centre (n.d.). Vulnerability Management: Carry Out Assessments. NCSC vulnerability management guidance.
66. Charrier, C., and Semrau, J. (2023). Analysis of Time-to-Exploit Trends: 2021–2022. Mandiant / Google Threat Intelligence, 28 September 2023.
67. Charrier, C., and Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. Mandiant / Google Threat Intelligence, 15 October 2024.
68. Mandiant (2026). M-Trends 2026: Data, Insights, and Strategies From the Frontlines. Google Threat Intelligence.
69. Fang, R., Bindu, R., Gupta, A., and Kang, D. (2024). LLM Agents Can Autonomously Exploit One-Day Vulnerabilities. arXiv preprint 2404.08144.
70. Grunewald, R., Mazumdar, S., and Vanderlee, K. (2026). Vulnerability Discovery and Exploitation Trends in the AI Era. Google Threat Intelligence Group, 1 October 2026.
71. UK AI Security Institute (2026). How Far Behind the Frontier Are Leading Open-Weight Models on Cyber? AISI Work.
72. International AI Safety Report (2026). International AI Safety Report 2026. Section 3.4, Open-weight models.
73. The PHP Foundation (2026). Today's PHP Security Release, and How We're Strengthening PHP Security. The PHP Foundation Blog, 21 October 2026.
74. CVE Program (n.d.). Common Vulnerabilities and Exposures: CVE Program Mission and Records. CVE Program.
75. FIRST (n.d.). Common Vulnerability Scoring System (CVSS) v4.0: User Guide. FIRST.org, document version 1.2.