AI सिक्योरिटी स्कैनर हमारा टेक्निकल डेट वसूल रहे हैं

2024 में PHP प्रोजेक्ट के ट्रैकर पर एक बग रिपोर्ट आई थी। उसमें आउट-ऑफ-मेमोरी की समस्या बताई गई थी, यानी वह तरह की चीज़ जिससे प्रोसेस क्रैश हो जाता है। परेशान करने वाली बात है, पर बग्स की अनौपचारिक पदानुक्रम में इसकी कोई खास अहमियत नहीं मानी जाती। रिपोर्ट पड़ी रही। फिर OpenAI द्वारा स्पॉन्सर्ड PHP के एक स्वतंत्र ऑडिट के दौरान, सिक्योरिटी फर्म Calif के एक रिसर्चर ने AI सिक्योरिटी स्कैनर और अपनी गहरी विशेषज्ञता के साथ लगभग दो हफ़्ते लगाकर उस मामूली क्रैश को रिमोट कोड एक्जीक्यूशन में बदल दिया। कोई भी सर्वर जो वल्नरेबल PHP बिल्ड पर चल रहा था, उसे हमलावर का कोड चलाने या संवेदनशील डेटा उगलने के लिए मजबूर किया जा सकता था। इस खतरे के दायरे में NASA, Wikipedia और White House जैसी साइटें भी आती थीं, क्योंकि WordPress और Drupal PHP पर चलते हैं, और PHP वेब के एक चौंका देने वाले हिस्से को चलाता है।

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

गलती नंबर एक: क्रैश बग्स को ‘परेशान करने वाला पर हानिरहित’ मान लेना

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

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

void handle_request(const char *input, size_t len) {
char *buf = malloc(64);
memcpy(buf, input, len);   /* len never validated */
/* len = 65:            heap metadata trashed -> likely abort, filed as 'crash' */
/* len = attacker-tuned: adjacent object's function pointer overwritten */
process(buf);             /* calls through the corrupted pointer -> their code runs */
free(buf);
}

इन दोनों नतीजों के बीच की रेखा बग में नहीं, इनपुट में है। यह तय करना कि किन बिट्स को किस क्रम में ओवरराइट करना है ताकि एक्जीक्यूशन किसी चुने हुए एड्रेस पर पहुँचे, मेहनत का काम है, लेकिन ‘मेहनत वाला पर मैकेनिकल’ ही वह चीज़ है जिसमें भाषा मॉडल सबसे अच्छी सहायता कर सकते हैं। इस गलती का इलाज तकनीकी से पहले वैचारिक है: मेमोरी-अनसेफ़ कोड के लिए ‘यह सिर्फ़ क्रैश करता है’ को गंभीरता का संकेत मानना बंद करें। C या C++ में (या PHP जैसे इंटरप्रेटर के C कोर में) क्रैश वह एक्सप्लॉइट है जो अभी विकसित नहीं हुआ। नया ट्राइज सवाल यह नहीं है कि ‘क्या यह क्रैश करता है?’ बल्कि यह है कि ‘क्या भ्रष्टाचार पर हमलावर का प्रभाव है?’ अगर अविश्वसनीय इनपुट गलत राइट के आकार, ऑफसेट या सामग्री को नियंत्रित करता है, तो एक्सप्लॉइटेबिलिटी मान लें और उसी हिसाब से प्राथमिकता तय करें, भले ही किसी ने काम करने वाला एक्सप्लॉइट न दिखाया हो। खासकर तब, क्योंकि अब प्रदर्शित एक्सप्लॉइट में सालों नहीं, हफ़्ते लगते हैं।

गलती नंबर दो: स्कैनर के आउटपुट को बैकलॉग की तरह ट्रीट करना

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

इस स्थिति में प्रभावी ट्राइज सेवेरिटी-स्कोर वाले सवाल नहीं, बल्कि एक्सप्लॉइट-पाथ वाले सवाल पूछता है:

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

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

गलती नंबर तीन: मान लेना कि पैचिंग फाइंडिंग की रफ़्तार से चल सकती है

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

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

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

गलती नंबर चार: सिर्फ़ इसलिए फिक्स पर भरोसा करना क्योंकि उसे LLM ने लिखा है

इस सब के खिलाफ़ आशावादी तर्क यह है: ठीक है, आज AI हमारे ठीक करने की रफ़्तार से तेज़ बग खोज रहा है, लेकिन AI उन्हें ठीक भी करेगा। Anthropic ने अक्टूबर में इसी दिशा में टूलिंग जारी की: एक LLM पैच बनाता है, फिर एक दूसरा मॉडल एक मशीन-जांच योग्य प्रूफ़ बनाता है कि पैच इच्छित व्यवहार को बनाए रखता है, और एक छोटा, सरल, भरोसेमंद प्रूफ़ चेकर उस प्रूफ़ को वैलिडेट करता है। सिर्फ़ चेकर को सही होना ज़रूरी है, और वह सही हो सकता है क्योंकि वह लगभग कुछ करता ही नहीं। जाना इस दिशा को लेकर सच में उत्साहित हैं, और मैं समझता हूँ क्यों: यह फिक्सिंग को लगभग खोज जितना ऑटोमेटेड बनाने का पहला विश्वसनीय रास्ता है।

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

1. एक रिग्रेशन सूट जिसमें एक्सप्लॉइट इनपुट शामिल हो। जिस प्रूफ़-ऑफ़-कॉन्सेप्ट ने फाइंडिंग को ट्रिगर किया, वह एक स्थायी टेस्ट बन जाता है। अगर स्कैनर ने आपको क्रैश करने वाला इनपुट दिया, तो वही आपका पहला नया टेस्ट केस है, बिल्कुल मुफ़्त।
2. वेरिएंट हंट। मर्ज से पहले कोई (या कोई टूल) पूछता है: यही पैटर्न और कहाँ मौजूद है? किसी सिस्टमेटिक पैटर्न के एक उदाहरण को ठीक करना ही वह तरीका है जिससे CVE के सीक्वल आते हैं।
3. डिफ़ के बजाय इनवेरिएंट की स्वतंत्र पुष्टि। बताएं कि अब क्या सच होना चाहिए, जैसे ‘रिक्वेस्ट हैंडलिंग से अवैलिडेटेड लंबाई वाले memcpy तक कोई पाथ नहीं’, और उसी को टेस्ट, स्टैटिक एनालिसिस या फॉर्मल टूलिंग से जांचें। सिर्फ़ डिफ़ रिव्यू करना मॉडल का होमवर्क दोबारा पढ़ना है।

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

गलती नंबर पाँच: मान लेना कि किसी और ने कोड का ऑडिट कर दिया है

यहाँ के हर तकनीकी सबक के नीचे एक आर्थिक सबक है। PHP एक सार्वजनिक उपयोगिता जितने बड़े पैमाने का इन्फ्रास्ट्रक्चर है। यह WordPress, Drupal और वेब के उस लंबे हिस्से को चलाता है जिसमें अंतरिक्ष एजेंसियाँ और सरकारी मुख्यालयों की वेबसाइटें भी शामिल हैं, और इसकी सिक्योरिटी PHP Foundation जैसी एक छोटी, फंडेड संस्था और स्वयंसेवकों पर टिकी है। ओपन सोर्स का आरामदायक मिथक हमेशा यह रहा है कि ‘काफ़ी आँखें हों तो सारे बग सतही हो जाते हैं’। असल में तीस सालों तक हुआ यह कि सब मानते रहे कि वे आँखें किसी और की हैं। अब AI बिना भेदभाव के वे आँखें हमलावरों और डिफेंडरों, दोनों को दे रहा है, यानी यह मिथक आखिरकार सच हो रहा है, बस प्रतिकूल तरीके से और डेडलाइन पर।

PHP2Shell का खुलासा एक असामान्य व्यवस्था की वजह से काम कर पाया: OpenAI ने एक बाहरी ऑडिट स्पॉन्सर किया, एक अच्छी तरह संसाधन-सम्पन्न फर्म ने काम किया, और Wiz ने निष्कर्षों की पुष्टि और विस्तार में मदद की। यह दान है, कोई सिस्टम नहीं, और यह आपकी डिपेंडेंसी ट्री में मौजूद सैकड़ों महत्वपूर्ण लेकिन बिना फंड वाले प्रोजेक्ट्स तक नहीं पहुँच सकता। अगर आपके संगठन का प्रोडक्शन किसी ओपन-सोर्स इंटरप्रेटर, फ्रेमवर्क या लाइब्रेरी पर निर्भर है, और है ही, तो जो फिक्स मायने रखते हैं वे उबाऊ हैं: फाउंडेशन को फंड करें, ऑडिट स्पॉन्सर करें, इंजीनियर के घंटे योगदान में दें, और जब आप अपने स्कैनर चलाएं और किसी डिपेंडेंसी में कुछ मिले, तो अपने फोर्क को पैच करके आगे बढ़ने के बजाय उसे अपस्ट्रीम रिपोर्ट करें। विकल्प वह दुनिया है जिसकी भविष्यवाणी Johns Hopkins के Matthew Green करते हैं: जब तक कोई इतनी बड़ी घटना न हो जो आम लोगों को परेशान कर दे, तब तक कुछ भी संरचनात्मक नहीं बदलेगा। इस बीच उनकी सलाह बिल्कुल सीधी और सही है: जब अपडेट का प्रॉम्प्ट आए, तो उसे अभी इंस्टॉल करें, अगले हफ़्ते नहीं। यही सबक हमने पिछले बड़े PHP खुलासे चक्र में कठिन तरीके से सीखा था, जब उन टीमों के लिए सब कुछ बंद कर देना चतुर फिक्स से बेहतर साबित हुआ जो तेज़ी से पैच नहीं कर पा रही थीं।

आँखें आ गई हैं। बस वे इस बात की परवाह नहीं करतीं कि वे किस तरफ़ हैं।

AI द्वारा सामने लाई गई कमज़ोरियों के लिए सोमवार-सुबह प्लेबुक

ऊपर की सारी बातें एक छोटी सूची में सिमटती हैं, उन चीज़ों की जो मैं इस तिमाही में करूँगा अगर मैं किसी ऐसे इंजीनियरिंग संगठन को चला रहा होता जिसमें प्रोडक्शन में कोई भी लीगेसी कोड हो, और अगर आप यह पढ़ रहे हैं, तो आपके प्रोडक्शन में लीगेसी कोड है:

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

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