- Weslley Araújo
- पद्धति शोधपत्र, 2026
सार
Security-Driven Hardening (SDH) एक संरचित, AI-संचालित और केवल रक्षा के लिए बनी सुरक्षा पद्धति है, उस दौर के लिए जिसमें सॉफ़्टवेयर ज़्यादा से ज़्यादा AI एजेंट और ऐसे लोग लिख रहे हैं जो सुरक्षा विशेषज्ञ नहीं हैं। किसी सामान्य चेकलिस्ट को चलाने के बजाय, SDH पहले यह पहचानता है कि सिस्टम असल में क्या करता है (लॉगिन, फ़ाइल अपलोड, पेमेंट, डेटा का उजागर होना, वगैरह), और फिर उसी संदर्भ के हिसाब से सुरक्षा का काम आगे बढ़ाता है। यह डिफ़ॉल्ट रूप से सुरक्षित सिद्धांतों से चलता है, पूरी तरह रक्षा पर केंद्रित है, और आसान भाषा में लिखा जाता है ताकि कोई भी उपयोगकर्ता उस पर अमल कर सके।
यह दस्तावेज़ तर्क देता है कि SDH कोई एक टूल नहीं, बल्कि एक ऐसा कन्वेंशन है जिसकी अब तक कमी थी। सुरक्षा का ज्ञान पद्धति में और ज़रूरत पड़ने पर ही लोड होने वाली उसकी विशेषज्ञताओं में रहता है, जो एक ऐसा आधार है जिस पर हर उपयोगकर्ता आगे बढ़ सकता है, और इसी वजह से यह एक ही फ़्लो से नौसिखिए और विशेषज्ञ, दोनों के काम आता है। दो गुण इसे पहले के स्पेक-फ़र्स्ट तरीक़ों [1] से अलग करते हैं। SDH स्थिति से स्वतंत्र है: यह किसी खाली डायरेक्टरी, चल रहे प्रोजेक्ट, एक पुल रिक्वेस्ट या बड़े लेगेसी कोडबेस के हिसाब से ढल जाता है, किसी भी स्टैक में। और SDH बंद हो सकने वाला है: जिस जोखिम का बंद होना पुष्ट हो जाता है, उसे SDH पूरे फ़्लो से बंद कर देता है, जिससे वह निष्कर्ष स्थिर हो जाता है और सिर्फ़ कोड बदलने पर दोबारा खुलता है। SDH सुरक्षा पेशेवरों या विशेष Blue Team टूलिंग की जगह नहीं लेता। यह डेवलपर के अपने ज्ञान को आगे बढ़ाता है, और डेवलपर सुरक्षा को जितना ज़्यादा समझता है, उतना ही ज़्यादा वह इसे दिशा दे सकता है।
Lagune इसका रेफ़रेंस इम्प्लीमेंटेशन है, और यह साबित करता है कि यह पद्धति बनाई भी जा सकती है और दूसरी जगह ले जाई भी जा सकती है। SDH को एक ऐसे कन्वेंशन के रूप में पेश किया गया है जिसे दूसरे भी अपना सकें।
AI की मदद से डेवलपमेंट, सॉफ़्टवेयर सुरक्षा, रक्षात्मक सुरक्षा, स्पेक-ड्रिवन डेवलपमेंट, सुरक्षा हार्डनिंग, एजेंट-संचालित वर्कफ़्लो, बंद हो पाना (closability), संदर्भ को समझने वाली सुरक्षा, ज़रूरत पड़ने पर ही लोड होने वाला ज्ञान, एजेंट से स्वतंत्र टूलिंग।
I. भूमिका: AI की मदद से डेवलपमेंट ने सुरक्षा में जो खाई खोली
सॉफ़्टवेयर ज़्यादा से ज़्यादा ऐसे लोग, और ऐसे AI एजेंट, शिप कर रहे हैं जो किसी असुरक्षित पैटर्न को भरोसे के साथ नहीं पहचान सकते: लीक हुआ सीक्रेट, ऑथराइज़ेशन की छूटी हुई जाँच, इंजेक्शन के लायक़ क्वेरी। ये कोई अनोखे जोखिम नहीं हैं। ये उन जोखिम वर्गों में आते हैं जो असली घटनाओं में सबसे ज़्यादा दिखते हैं और जिन्हें सार्वजनिक संदर्भ बरसों से दर्ज करते आए हैं [6], [7], और हाल के अध्ययन बताते हैं कि AI से बने कोड का अच्छा-ख़ासा हिस्सा ठीक ऐसी ही ख़ामियों के साथ शिप होता है [8]। AI कोडिंग असिस्टेंट ने ग़ैर-डेवलपर को भी असली सॉफ़्टवेयर शिप करने की सुविधा देकर यह समस्या और गंभीर बना दी, लेकिन यह खाई किसी एक वर्ग के उपयोगकर्ताओं से कहीं बड़ी है। ज़्यादातर प्रोजेक्ट को कभी ऐसी सुरक्षा जाँच नहीं मिलती जो उनके असल काम के हिसाब से हो। "चल रहा है, शिप कर दो" जैसे हर जल्दबाज़ी वाले फ़ैसले के साथ पूरा इकोसिस्टम और नाज़ुक होता जाता है।
सामान्य सुरक्षा सलाह से यह खाई नहीं भरती। कोई स्थिर चेकलिस्ट इस बात को ध्यान में नहीं रखती कि सिस्टम क्या करता है, इसलिए वह छोटे प्रोजेक्ट को बेमतलब के आइटम से भर देती है और फिर भी वह जोखिम छोड़ देती है जो उस एक प्रोजेक्ट के लिए मायने रखता है। समस्या यह नहीं कि दुनिया में सुरक्षा के ज्ञान की कमी है। समस्या है सही ज्ञान को उस सिस्टम से मिलाना जो उपयोगकर्ता के सामने सचमुच है, और यह काम ऐसे व्यक्ति के लिए करना जिसे शायद यह भी न पता हो कि क्या पूछना है।
SDH इसका जवाब एक ही उलटाव से देता है: सुरक्षा का ज्ञान स्पेक में और ज़रूरत पड़ने पर ही लोड होने वाली उसकी विशेषज्ञताओं में रहता है, जो एक ऐसा आधार है जिस पर हर उपयोगकर्ता आगे बढ़ सकता है। पद्धति संदर्भ पहचानती है, उस संदर्भ से जुड़े जोखिमों की प्राथमिकता तय करती है, और सुधारों की राह दिखाती है, इसलिए डेवलपर और ग़ैर-डेवलपर, दोनों एक ही फ़्लो से काम चला लेते हैं। निष्कर्ष और सुझाव आसान भाषा में रहते हैं, ताकि पढ़ने वाले की तकनीकी समझ चाहे जितनी हो, वह उन पर अमल कर सके। इससे विशेषज्ञ पर कोई बंदिश नहीं लगती, बल्कि उसकी क्षमता बढ़ती है, और इस दोहरी भूमिका को हम §VI में विस्तार से देखेंगे।
मूल उलटाव: सुरक्षा का ज्ञान स्पेक में और ज़रूरत पड़ने पर ही लोड होने वाली उसकी विशेषज्ञताओं में रहता है, जो एक ऐसा आधार है जिस पर हर उपयोगकर्ता आगे बढ़ सकता है। पद्धति समझती है कि सिस्टम क्या करता है, सुरक्षा के काम को उसी के हिसाब से ढालती है, और उपयोगकर्ता पहले से जो जानता है उसे आगे बढ़ाती है।
मान लीजिए एक डेवलपर किसी AI असिस्टेंट से कहता है, "मेरे ऐप में उपयोगकर्ता प्रोफ़ाइल फ़ोटो अपलोड कर सकते हैं।" सुरक्षा जाँच के बिना, असिस्टेंट ऐसा कोड बना देता है जो चलता तो है, लेकिन क्लाइंट जो भी भेजे उस पर चुपचाप भरोसा कर लेता है: बताया गया फ़ाइल टाइप, फ़ाइल का नाम, साइज़। अपलोड शिप हो जाता है, और तब इमेज का भेस धरी फ़ाइल अपने साथ कोड ला सकती है, जान-बूझकर गढ़ा गया नाम स्टोरेज पाथ से बाहर निकल सकता है, और बहुत बड़ी फ़ाइल सर्वर के संसाधन ख़त्म कर सकती है। डेमो में इनमें से कुछ भी नहीं दिखता, इसलिए यह शिप हो जाता है।
वही कोड SDH से गुज़रे, तो कहानी बदल जाती है। SDH पहचानता है कि सिस्टम बाहर से फ़ाइलें लेता है (पहचान), इसे उन जोखिमों में बाँटता है जो अपलोड के साथ आते हैं (ट्राइएज), फ़ाइल का असली टाइप और साइज़ जाँचने, सेव करते समय नाम बदलने, और फ़ाइलें ऐसी जगह रखने का प्रस्ताव देता है जहाँ कोड न चल सके (निवारण), और फिर नतीजा पढ़कर पुष्टि करता है कि हर नियंत्रण सचमुच कारगर है (पुष्टि)। डेवलपर को "unrestricted file upload" जैसा शब्द कभी जानना ही नहीं पड़ा। पद्धति ने उसकी ओर से यह कमी पूरी कर दी।
यह दस्तावेज़ ये योगदान देता है:
- SDH की एक सटीक परिभाषा, किसी एक इम्प्लीमेंटेशन से स्वतंत्र पद्धति के रूप में, उसके डिज़ाइन सिद्धांतों के साथ (§III)।
- पाँच चरणों वाला रक्षात्मक जीवनचक्र, जिसमें ज़िम्मेदारियों का बँटवारा अपने आप में योगदान है: पहचान कभी कुछ गढ़ती नहीं, योजना कभी कोड नहीं पढ़ती, सिर्फ़ एक चरण कोड बदलता है, और पुष्टि अपने फ़ैसले में कभी नरमी नहीं बरतती (§IV)।
- बंद हो पाना (closability) एक पद्धतिगत रुख़ के रूप में: हर निष्कर्ष का एक अंत होता है, वह किसी अंतहीन लूप में नहीं घूमता (§V)।
- डेवलपर के ज्ञान को आगे बढ़ाने वाली दोहरी भूमिका: एक ही फ़्लो, जो नौसिखिए की रक्षा करता है और विशेषज्ञ की क्षमता बढ़ाता है (§VI)।
- सीधे न चलाई जा सकने वाली विशेषज्ञताएँ और प्रॉम्प्ट-ऑन-डिमांड: सुरक्षा का केंद्रित ज्ञान, जिसे एजेंट तभी लोड करता है जब प्रोजेक्ट का संदर्भ उसकी माँग करे, डिफ़ॉल्ट रूप से कभी नहीं (§VII)।
- स्थिति से स्वतंत्रता और बिना थोपे ढलने की क्षमता: SDH डेवलपमेंट की किसी भी स्थिति में फ़िट बैठता है और तय दायरा थोपने के बजाय हालात के हिसाब से ढल जाता है (§VIII)।
- एक निवारक मोड: आम काम बनाते समय वही रक्षा साथ चलती है, ताकि कोड डिफ़ॉल्ट रूप से सुरक्षित होकर आए और चरणों के पास सुधारने को कम बचे (§IX)।
- Spec-Driven Development से एक अलग तुलना, यानी उस परंपरा से जिससे SDH निकला और फिर अलग राह पर चल पड़ा (§X)।
- वे इंजीनियरिंग अनुशासन जिनकी बदौलत पद्धति रीफ़ैक्टर के बाद भी टिकी रहती है और किसी एजेंट पर निर्भर नहीं रहती: नाम से पहचान वाली ट्रैकिंग (§XI) और एजेंट से स्वतंत्र वाहक (§XII)।
II. पृष्ठभूमि और संबंधित काम
SDH पहले हुए काम पर टिका है। उसे स्पेक-फ़र्स्ट, एजेंट-संचालित डेवलपमेंट [1], [2], [3] से एक आज़माया हुआ ढाँचा विरासत में मिला है: टेम्पलेट, एजेंट के इस्तेमाल के लिए स्लैश कमांड, सभी चरणों को दिशा देने वाला एक दस्तावेज़, और चरणों को चलाने वाला एजेंट। SDH उसी ढाँचे को रक्षा के मक़सद से दोबारा बनाता है। यह परंपरा जान-बूझकर अपनाई गई है, और SDH का एक कामकाजी सिद्धांत इसे सीधे शब्दों में कहता है: वर्कफ़्लो को आज़माए हुए ढाँचे से बनाएँ, फिर उसे सुरक्षा के लिए ढालें।
SDH सामान्य सुझावों की कोई स्थिर चेकलिस्ट नहीं है। चेकलिस्ट आम तौर पर सुरक्षा के बारे में बहुत कुछ जानती है, लेकिन अपने सामने के प्रोजेक्ट के बारे में कुछ नहीं। SDH यह ज़ोर उलट देता है। वह अपनी पहली मेहनत पहचान पर लगाता है, यानी यह जानने पर कि सिस्टम क्या करता है, और उसके बाद ही उस ज्ञान तक पहुँचता है जिसे पहचान ने प्रासंगिक बनाया है।
SDH सुरक्षा विशेषज्ञों या विशेष Blue Team टूलिंग की जगह भी नहीं लेता। वह डेवलपर के ज्ञान को आगे बढ़ाता है (§VI)। जिस टीम में सुरक्षा का अलग विभाग है, उसे उसे बनाए रखना चाहिए। SDH ऐसी टीम को एक संरचित वाहक देता है, और जिस टीम के पास ऐसा विभाग नहीं है, उसे एक ठोस आधार देता है।
SDH नियतात्मक सुरक्षा स्कैनर (स्टैटिक एनालिसिस, लिंटर) [4], [5] के साथ-साथ भी खड़ा है। ये टूल इसीलिए क़ीमती हैं कि ये नियतात्मक हैं और बार-बार एक जैसा नतीजा देते हैं। SDH ज़्यादातर एजेंट के तर्क पर चलता है, जो सख़्त नियतात्मकता के बदले संदर्भ की समझ देता है। पद्धति इससे इनकार नहीं करती। जहाँ नियतात्मकता मायने रखती है, वहाँ वह तर्क के भीतर एक नियतात्मक इंजन जोड़ देती है (§VII): कोई इनपुट जाँचने लायक़ है या नहीं, यह एजेंट तय करता है, और वह इनपुट ख़तरनाक है या नहीं, यह एक नियतात्मक प्रोग्राम तय करता है।
सबसे सीधा पूर्ववर्ती काम Spec-Driven Development (SDD) है, स्पेक-फ़र्स्ट पद्धतियों का वह परिवार जो चलाने लायक़ स्पेसिफ़िकेशन से बिल्ड को आगे बढ़ाता है। हम SDD को एक वर्ग के रूप में देखते हैं। व्यवहार में काम आने वाली पद्धति के रूप में इसका सबसे साफ़ वर्णन Piskala की रिपोर्ट [1] है, और इसका सबसे जाना-माना एजेंट-संचालित टूलकिट GitHub का Spec Kit [2] है, जबकि OpenSpec [3] उसी परिवार का दूसरा टूल है। §X की तुलना के लिए यही मानक संदर्भ हैं।
III. SDH: परिभाषा और डिज़ाइन सिद्धांत
Security-Driven Hardening एक संरचित, AI-संचालित सुरक्षा पद्धति है जो किसी कोडबेस को ज़्यादा सुरक्षित बनाती है, और यह काम तात्कालिक सुधारों से नहीं, बल्कि एजेंट के चलाए जाने वाले स्पेक से आगे बढ़ाती है। यह नाम Blue Teams से प्रेरित है, यानी सुरक्षा के क्षेत्र में बचाव करने वाली टीमें। SDH रक्षा, हार्डनिंग और पुष्टि के बारे में है, हमले के बारे में कभी नहीं।
Security-Driven Hardening (SDH): एक संरचित, AI-संचालित, केवल रक्षा के लिए बनी सुरक्षा पद्धति, जो पहले यह पहचानती है कि सिस्टम असल में क्या करता है, फिर संदर्भ के हिसाब से सुरक्षा का काम आगे बढ़ाती है, डिफ़ॉल्ट रूप से सुरक्षित सिद्धांतों के तहत और आसान भाषा में।
SDH को कुछ बाध्यकारी सिद्धांत परिभाषित करते हैं। हर सिद्धांत एक नियम है, और हर एक उपयोगकर्ता को एक ख़ास गारंटी देता है।
| सिद्धांत | नियम | उपयोगकर्ता को क्या गारंटी मिलती है |
|---|---|---|
| डिफ़ॉल्ट रूप से सुरक्षित, आसान भाषा में, सबके लिए बराबर | हर डिफ़ॉल्ट, संदेश और सुधार शुरू से ही सुरक्षित है और हर पाठक की समझ में आता है, चाहे वह डेवलपर हो या न हो। किसी उपयोगकर्ता वर्ग को विशेष दर्जा नहीं मिलता। | नौसिखिए को बिना माँगे सुरक्षित आधार मिलता है, और वह नतीजा अपनी भाषा में पढ़ता है। |
| सामान्य सलाह की जगह संदर्भ की समझ | हर चरण detect चरण में पहचाने गए संदर्भ से शुरू होता है, और सिस्टम असल में जो करता है उसी पर काम करता है। | सुझाव प्रोजेक्ट पर फ़िट बैठते हैं, किसी चेकलिस्ट पर नहीं। सुरक्षा का ज्ञान स्पेक में और ज़रूरत पड़ने पर ही लोड होने वाली उसकी विशेषज्ञताओं में रहता है, और उपयोगकर्ता जो भी जानता है उसे आगे बढ़ाता है। |
| कठोरता की जगह लचीलापन | सिद्धांत, ज़रूरतें और सुझाव शुरुआती बिंदु हैं। उपयोगकर्ता किसी भी चीज़ को दोबारा लिख सकता है, हटा सकता है, जोड़ सकता है या उसका दायरा छोटा कर सकता है। | पद्धति प्रोजेक्ट और उपयोगकर्ता के हिसाब से ढलती है, और उपयोगकर्ता जितनी सख़्ती चाहे उससे ज़्यादा कभी नहीं करती। लचीलापन डिफ़ॉल्ट रूप से सुरक्षित आधार को कभी कमज़ोर नहीं करता। |
| सिर्फ़ जोड़ते न जाना, मौजूदा स्थिति से मिलाकर अपडेट करना | आर्टिफ़ैक्ट जीवंत दस्तावेज़ हैं, लॉग नहीं। हर रन हर एंट्री को दोबारा जाँचता है: जो अब भी सही है उसे रखता है, जो बदला है उसे दोबारा लिखता है, और जो अब लागू नहीं होता उसे हटाता है। | रिकॉर्ड हमेशा वर्तमान को दिखाता है, इसलिए वह कभी पुराने पड़ चुके बैकलॉग में नहीं बदलता। |
| केवल रक्षा के लिए | SDH ऑडिट करता है, सुरक्षा मज़बूत करता है और पुष्टि करता है। वह कभी आक्रामक टूलिंग, बुरी नीयत से इस्तेमाल के लिए एक्सप्लॉइट, या नुक़सान पहुँचाने के लिए पकड़ से बचने की तकनीकें नहीं बनाता। | पद्धति को हथियार नहीं बनाया जा सकता। दोहरे इस्तेमाल वाली सामग्री सिर्फ़ साफ़ तौर पर रक्षात्मक संदर्भ में आती है। |
| स्पेक पहले, एजेंट से संचालित, सुरक्षा के लिए ढला हुआ | वर्कफ़्लो टेम्पलेट, कमांड, सभी चरणों को दिशा देने वाले सुरक्षा सिद्धांतों और चरणों को चलाने वाले एजेंट से बना है। | डेवलपमेंट का एक आज़माया हुआ ढाँचा, नए मक़सद के लिए ढाला गया, ताकि सुरक्षा का असली काम एजेंट करे। |
तालिका 1. SDH के डिज़ाइन सिद्धांत, और हर सिद्धांत उपयोगकर्ता को जो गारंटी देता है।
ये सिद्धांत सजावटी नहीं हैं। ये वे बंदिशें हैं जिनका आगे के हर चरण को पालन करना होता है, और §XV की चर्चा पद्धति की सीमाएँ तय करने के लिए इन्हीं पर लौटती है।
बाक़ी दस्तावेज़ नौ नामित स्तंभों को विस्तार से रखता है। ये वे हिस्से हैं जिन्हें पाठक को याद रखना चाहिए, और जिन्हें दोबारा बनाकर ही कोई दूसरी टीम कह सकती है कि वह SDH कर रही है।
| स्तंभ | यह क्या देता है | खंड |
|---|---|---|
| संदर्भ को समझने वाला उलटाव | सुरक्षा का ज्ञान स्पेक में और ज़रूरत पड़ने पर ही लोड होने वाली उसकी विशेषज्ञताओं में रहता है, इसलिए नौसिखिया और विशेषज्ञ एक ही फ़्लो साझा करते हैं। | §I, §VI |
| पाँच चरणों वाला रक्षात्मक जीवनचक्र | ज़िम्मेदारियों का बँटवारा: नीति, पहचान, ट्राइएज, निवारण, पुष्टि, हर एक का एक ही काम। | §IV |
| बंद हो पाना | हर निष्कर्ष का एक अंत होता है, कोई अंतहीन लूप नहीं। पूरा हो चुका काम बंद कर दिया जाता है। | §V |
| डेवलपर के ज्ञान को आगे बढ़ाने वाली दोहरी भूमिका | एक ही फ़्लो, जो नौसिखिए की रक्षा करता है और विशेषज्ञ की क्षमता बढ़ाता है, किसी की जगह लिए बिना। | §VI |
| प्रॉम्प्ट-ऑन-डिमांड, सीधे न चलाया जा सकने वाला ज्ञान | प्रोजेक्ट जो है, उसके लिए प्रासंगिक सुरक्षा ज्ञान लोड होता है, डिफ़ॉल्ट रूप से कभी नहीं। | §VII |
| स्थिति से स्वतंत्रता और बिना थोपे ढलने की क्षमता | किसी भी स्टैक में डेवलपमेंट की किसी भी स्थिति में फ़िट बैठता है, और दायरा थोपने के बजाय हालात के हिसाब से ढल जाता है। | §VIII |
| निवारक मोड | नया काम बनते समय वही रक्षा साथ चलती है, इसलिए कोड डिफ़ॉल्ट रूप से सुरक्षित होकर आता है। | §IX |
| नाम से पहचान वाली ट्रैकिंग | निष्कर्ष सभी चरणों में एक ही आइटम रहता है, और फ़ाइल का नाम बदलने पर लिंक सिर्फ़ एक जगह टूटता है। | §XI |
| एजेंट से स्वतंत्र वाहक | सुरक्षा की असली सामग्री एक बार लिखी जाती है और किसी एजेंट या स्टैक पर निर्भर नहीं करती। | §XII |
तालिका 2. SDH के नौ नामित स्तंभ, और हर एक को कहाँ विस्तार दिया गया है।
IV. 5 चरणों वाला Blue Team फ़्लो
SDH काम को पाँच चरणों वाले रक्षात्मक जीवनचक्र में बाँटता है (चित्र 1)। हर चरण रक्षा पर केंद्रित है, हर चरण पिछले चरण पर टिका है, और ये चरण Blue Team के असली कामकाज का अनुसरण करते हैं: नीति तय करना, पहचान, ट्राइएज, निवारण, पुष्टि।
चित्र 1. पाँच चरणों वाला फ़्लो: हर चरण क्या पढ़ता है, क्या लिखता है, और वह अटल नियम जिस पर वह टिका है। दोनों वापसी के रास्ते verify चरण से निकलते हैं: अस्वीकार हुआ नियंत्रण harden चरण को दोबारा खोलता है, और बंद साबित हुआ निष्कर्ष पूरी चेन से बंद कर दिया जाता है, इतिहास में एक पंक्ति के साथ।
ज़िम्मेदारियों का बँटवारा ही योगदान है। क्योंकि हर चरण का एक ही काम है, कोई भी गड़बड़ी एक ही जगह तक सीमित रहती है, और पाठक हर आर्टिफ़ैक्ट के दावे पर भरोसा कर सकता है।
Applied का मतलब पुष्टि नहीं: harden चरण दर्ज करता है कि सुधार लागू हुआ। verify चरण कोड का उस रिकॉर्ड से मिलान करके उसकी पुष्टि करता है, और फ़ैसले को रिकॉर्ड से मेल खाने के लिए कभी नरम नहीं करता। हो सकता है कोई नियंत्रण कोड में मौजूद हो और फिर भी जोखिम तक पहुँचा जा सके, और तब ईमानदार फ़ैसला "Risk not closed" होता है।
charter (नीति)
charter चरण प्रोजेक्ट के सुरक्षा सिद्धांत तय करता है, यानी वे नियम जिनका आगे के हर चरण को पालन करना है। यह सभी चरणों को दिशा देने वाली परत है, प्रोजेक्ट की सुरक्षा स्थिति के लिए एक तरह का कंपाइल-टाइम चेक। हर सिद्धांत का एक साफ़ नाम होता है, एक ऐसा अटल नियम जिसे कोड से जाँचा जा सके, और एक Why: पंक्ति जो सिर्फ़ सुधार नहीं, बल्कि वह जोखिम बताती है जिसे यह सिद्धांत रोकता है। charter चरण हमेशा प्रोजेक्ट को ख़ुद पढ़ता है (उसके मैनिफ़ेस्ट, संरचना और डिपेंडेंसी), और अगर उपयोगकर्ता कोई विवरण देता है, तो वह एक दिशा होती है, जिसे यह पढ़ाई उपयोगकर्ता की बताई बातों से आगे तक ले जाती है। कोई विवरण न हो, तो प्रोजेक्ट ही इकलौता स्रोत है। दोनों एक-दूसरे से होड़ नहीं करते, बल्कि एक-दूसरे को पूरा करते हैं, और charter चरण वह नीति दर्ज करता है जिस पर प्रोजेक्ट को टिके रहना चाहिए, न कि उसके कोड की मौजूदा हालत। एक ग़ैर-डेवलपर भी इसे पढ़कर नियम और जोखिम, दोनों समझ सके, ऐसा होना चाहिए।
detect (पहचान)
detect चरण कोड पढ़ता है और यह खाका बनाता है कि सिस्टम असल में ऐसा क्या करता है जिसका सुरक्षा पर असर है। इसका मूल निर्देश है "पहचानना है, गढ़ना नहीं": सिर्फ़ वही दर्ज करना जिसकी पुष्टि कोड से हो, उस सबूत के साथ जिसकी आगे के चरणों को ज़रूरत है। detect चरण निष्पक्ष है। वह अपने निष्कर्षों को ज़बरदस्ती सुरक्षा सिद्धांतों में फ़िट नहीं करता, क्योंकि जोखिमों को सिद्धांतों के नियमों से मिलाना plan चरण का काम है। हर निष्कर्ष के तीन हिस्से होते हैं: यह क्या है (आसान भाषा में विवरण), यह क्यों मायने रखता है (जोखिम, सिर्फ़ तथ्य नहीं), और सबूत (वह फ़ंक्शन या रूट जहाँ यह मौजूद है)। सबूत में कोई फ़ाइल पाथ नहीं होता। पाथ सिर्फ़ ट्रैकिंग मैप में रहता है (§XI), इसलिए टेक्स्ट में कभी ऐसा पाथ नहीं होता जो पुराना पड़ जाए।
plan (ट्राइएज)
plan चरण हर निष्कर्ष को एक सुधार में बदलता है, जिसका नाम उसके जोखिम वर्ग से रखा जाता है (जहाँ स्थापित संदर्भ, CWE और OWASP, उसे आधार देते हों, वहाँ उनका हवाला देते हुए) और जिसे उस सुरक्षा सिद्धांत से जोड़ा जाता है जिसे वह सुधार क़ायम रखता है। प्राथमिकता (क्रिटिकल, उच्च, मध्यम, निम्न) मनमर्ज़ी से नहीं चुनी जाती: plan चरण हर निष्कर्ष को CVSS v4.0 के Base और Environmental तरीक़े से स्कोर देता है, इसलिए प्राथमिकता का स्तर आसान शब्दों में वही स्कोर है, जिसका औचित्य एक सरल पंक्ति बताती है कि जोखिम कितना खुला है और दाँव पर क्या है, और दो रन एक ही क्रम पर पहुँचते हैं। वेक्टर विशेषज्ञ के लिए सटीक आधार है, और स्तर व उसका औचित्य वही रेटिंग है जिसे कोई भी समझ सकता है। plan चरण सिर्फ़ detect मैप से काम करता है और कभी कोड नहीं पढ़ता। यह सोची-समझी बंदिश है, कमी नहीं: इससे हर सुधार को उसी चीज़ की ओर इशारा करना पड़ता है जिसे detect चरण ने सचमुच पहचाना। अगर किसी दायरे का खाका कभी बना ही नहीं, तो plan चरण अंदाज़ा लगाने के बजाय रुक जाता है और उपयोगकर्ता को वापस detect चरण पर भेजता है।
harden (निवारण)
harden इकलौता चरण है जो कोड बदलता है, इसलिए वह सावधानी से आगे बढ़ता है। किसी बदलाव के लिए उपयोगकर्ता की मंज़ूरी चाहिए या नहीं, यह एजेंट और उसके परमिशन मोड का मामला है, इसलिए harden चरण अपनी ओर से पुष्टि का कोई पड़ाव नहीं जोड़ता। वह एक बार में एक सुधार लागू करता है, पहले डिपेंडेंसी, फिर सबसे ऊँची प्राथमिकता, ताकि हर बदलाव छोटा रहे, आसानी से रिव्यू हो सके और आसानी से वापस लिया जा सके। वह किसी नए सुधार को फ़िट करने के लिए मौजूदा नियंत्रण को कभी कमज़ोर नहीं करता, और कभी किसी सुरक्षा सिद्धांत को नहीं तोड़ता। अगर कोई सुधार किसी सिद्धांत से टकराता हो, तो harden चरण उसे लागू करने के बजाय रुक जाता है और टकराव सामने रखता है। harden चरण हर ब्लॉक को Applied, Partial या Blocked के रूप में दर्ज करता है। "Applied का मतलब अभी पुष्टि नहीं", और अगला चरण इसी चिंता को सँभालता है।
verify (पुष्टि)
verify चरण कोड पढ़कर और उसका harden चरण के दर्ज किए ब्योरे से मिलान करके, लागू हुए हर नियंत्रण की पुष्टि करता है। पुष्टि यही मिलान है, कोड बनाम रिकॉर्ड, और यह स्टैटिक है: यह पक्का करती है कि नियंत्रण कोड में मौजूद और सही है, यह नहीं कि चलते हुए सिस्टम पर हमला होने पर भी नियंत्रण कारगर रहेगा। वह रनटाइम जाँच, जिसमें लाइव सिस्टम पर असली या नक़ली हमले चलाए जाते हैं, डिज़ाइन से ही दायरे से बाहर है। verify चरण तीन में से एक फ़ैसला देता है: Risk closed, Risk not closed, या Cannot tell from the code। वह अपना कोई आर्टिफ़ैक्ट नहीं बनाता: harden और verify चरण हार्डनिंग रिकॉर्ड साझा करते हैं, जिसमें क्या किया गया यह harden का हिस्सा है और फ़ैसला व उसका कारण verify का, और कोई भी दूसरे के फ़ील्ड में कभी नहीं लिखता। अस्वीकार हुआ नियंत्रण harden के लिए दोबारा खुला काम बन जाता है, और अगली बार चलने पर harden चरण कोड की अपनी समझ से ऊपर उस फ़ैसले को रखता है और ठीक उसी कमी को ध्यान में रखकर सुधार दोबारा लागू करता है जो कारण में बताई गई है। verify चरण रिकॉर्ड से ज़्यादा कोड पर भरोसा करता है, क्योंकि रिकॉर्ड कोड की असल क्षमता से ज़्यादा का दावा कर सकता है। वह उपयोगकर्ता के कोड को सिर्फ़ पढ़ता है, और फ़ैसले को रिकॉर्ड से मेल खाने के लिए कभी नरम नहीं करता। हो सकता है नियंत्रण मौजूद हो और फिर भी किसी दूसरे रास्ते से जोखिम तक पहुँचा जा सके, और ऐसे में ईमानदार फ़ैसला "Risk not closed" होता है। अगर पढ़ते समय verify चरण को कोई ऐसी सुरक्षा समस्या दिखती है जो detect मैप में कभी आई ही नहीं, तो वह उसके लिए कोई फ़ैसला नहीं गढ़ता, क्योंकि पहचान detect चरण का काम है: वह समस्या सामने रखता है और उपयोगकर्ता को वापस detect चरण पर भेजता है, ताकि निष्कर्ष उसी फ़्लो से दाख़िल हो, उसे दरकिनार करके नहीं।
शुरू से अंत तक एक उदाहरण: फ़ाइल अपलोड। एक ही निष्कर्ष पूरी रीढ़ को शुरू से आख़िर तक दिखाता है।
- detect चरण इसे पकड़ता है: सिस्टम उपयोगकर्ताओं से फ़ाइलें लेता है, और अपलोड हैंडलर फ़ाइल का असली टाइप जाँचे बिना उस MIME टाइप पर भरोसा कर लेता है जो क्लाइंट भेजता है। यह क्यों मायने रखता है: इमेज का भेस धरी फ़ाइल में बुरी नीयत वाला कोड छिपा हो सकता है।
- plan चरण सुधार तय करता है, प्राथमिकता क्रिटिकल, "जब तक इनपुट की जाँच न हो जाए, हर इनपुट अविश्वसनीय है" सिद्धांत को क़ायम रखते हुए: फ़ाइल का असली टाइप और साइज़ जाँचें, सेव करते समय उसका नाम बदलें, और अपलोड ऐसी जगह रखें जहाँ उन्हें कोड की तरह चलाया न जा सके।
- harden चरण इसे लागू करता है, स्टेटस Applied: हैंडलर अब कंटेंट से असली टाइप पहचानता है, साइज़ की सीमा लागू करता है, अनचाही हर चीज़ अस्वीकार करता है, सेव करते समय नाम बदलता है, और फ़ाइलें ऐसी जगह रखता है जहाँ कोड न चल सके।
- verify चरण हैंडलर पढ़ता है, उसका रिकॉर्ड से मिलान करता है, और फ़ैसला देता है Risk closed: कोड ठीक वही करता है जिसका रिकॉर्ड दावा करता है।
निष्कर्ष का वही नाम detect मैप, योजना और हार्डनिंग रिकॉर्ड से होकर गुज़रता है, और verify चरण उसी नाम के तहत उस रिकॉर्ड पर काम करता है: खुला फ़ैसला निष्कर्ष के ब्लॉक पर लिखा जाता है, और बंद साबित हुआ निष्कर्ष बंद कर दिया जाता है (§V)। यही साझा नाम उसकी पहचान है (§XI)।
V. बंद हो पाना: हर निष्कर्ष का एक अंत होता है
ज़्यादातर सुरक्षा टूलिंग उपयोगकर्ता के पास एक ऐसा बैकलॉग छोड़ जाती है जो बस बढ़ता जाता है। SDH का रुख़ अलग है: निष्कर्ष बंद हो सकता है, इसलिए किसी अंतहीन बैकलॉग में पड़े रहने के बजाय उसका एक अंत होता है (चित्र 2)। यह सीधे मौजूदा स्थिति से मिलाकर अपडेट करने के सिद्धांत से निकलता है।
बंद हो पाना (closability): जिस जोखिम का बंद होना पुष्ट हो चुका है, उसे पूरे फ़्लो से बंद कर दिया जाता है, जिससे वह निष्कर्ष स्थिर हो जाता है और सिर्फ़ कोड बदलने पर दोबारा खुलता है। हर निष्कर्ष का एक अंत होता है, भले ही सुरक्षा का कार्यक्रम ख़ुद लगातार चलता रहे।
SDH के आर्टिफ़ैक्ट जीवंत दस्तावेज़ हैं, लॉग नहीं। जब भी कोई चरण दोबारा चलता है, वह हर मौजूदा एंट्री को मौजूदा सच्चाई से दोबारा जाँचता है और तीन में से एक काम करता है: जो अब भी सही है उसे रखता है, जो बदला है उसे दोबारा लिखता है, या जो अब लागू नहीं होता उसे हटाता है। जिस निष्कर्ष के बारे में कोड दिखाता है कि वह अब सुलझ चुका है, उसे बस हटा दिया जाता है। कामकाजी रिकॉर्ड वर्तमान को दिखाता है, अतीत को नहीं।
बंद करना उसी मिलान की आख़िरी मंज़िल है। जब verify चरण किसी जोखिम के बंद होने की पुष्टि करता है, तो वह उस निष्कर्ष को पूरे फ़्लो से बंद कर देता है: detect मैप, योजना, हार्डनिंग रिकॉर्ड और ट्रैकिंग मैप, सबसे। इसी वजह से verify इकलौता चरण है जो दूसरे चरणों के आर्टिफ़ैक्ट में लिखता है: यही वह चरण है जो चक्र पूरा करता है। जैसे ही निष्कर्ष चेन से बाहर जाता है, बंद करने की प्रक्रिया उसका सार निकालकर इतिहास के रिकॉर्ड में एक छोटी एंट्री बना देती है, और यह रिकॉर्ड कामकाजी चेन से बाहर रहता है और कभी दोबारा प्रोसेस नहीं होता। ग़ायब होने और बंद होने के बीच यही रेखा है: जिस निष्कर्ष को मिलान ने इसलिए हटाया कि वह सच नहीं रहा, वह पीछे कुछ नहीं छोड़ता, जबकि बंद साबित हुआ निष्कर्ष इतिहास में अपनी पंक्ति कमाता है। बंद किया गया निष्कर्ष उसके बाद किसी भी कामकाजी आर्टिफ़ैक्ट में नहीं होता, और यह ग़ैरमौजूदगी अपेक्षित है, टूटी हुई चेन नहीं।
चित्र 2. बंद हो पाने की स्टेट मशीन। निष्कर्ष OPEN (खुला) → STOOD DOWN (बंद) → SETTLED (स्थिर) की ओर बढ़ता है, और सिर्फ़ कोड बदलने पर दोबारा खुलता है।
जब दायरे की हर चीज़ बंद हो जाती है, तो चक्र स्थिर हो जाता है, और इस स्थिर अवस्था का एक ठोस रूप है: जिस आर्टिफ़ैक्ट का आख़िरी निष्कर्ष बंद हुआ, उसे पूरा हटा दिया जाता है, इसलिए पूरी तरह बंद चेन में सिर्फ़ सुरक्षा सिद्धांत और इतिहास बचते हैं, यानी नीति और प्रमाण। चक्र सिर्फ़ कोड बदलने पर दोबारा खुलता है। पद्धति हर निष्कर्ष को एक तय अंत देती है, और ठीक यही वह चीज़ है जो कोई अंतहीन बैकलॉग नहीं दे सकता।
VI. डेवलपर के ज्ञान को आगे बढ़ाने वाली दोहरी भूमिका
SDH लोगों की जगह नहीं लेता, और विशेष Blue Team टूलिंग की जगह भी नहीं लेता। यह डेवलपर के अपने ज्ञान को आगे बढ़ाता है। डेवलपर सुरक्षा को जितना ज़्यादा समझता है, उतनी ही सटीकता से वह फ़्लो को दिशा दे सकता है, और उसके पास उतनी ही ज़्यादा आज़ादी होती है। जो डेवलपर कम समझता है, उसे भी सुरक्षित नतीजा मिलता है, क्योंकि ऑटोमैटिक मोड उसकी हिफ़ाज़त करता है।
§I का उलटाव, यानी सुरक्षा का ज्ञान स्पेक में रहता है, दोनों दिशाओं में लागू होता है। नौसिखिए के लिए यह सुरक्षा है: उसे यह जानने की ज़रूरत नहीं कि क्या पूछना है, क्योंकि स्पेक ख़ुद प्रस्ताव रखता है। विशेषज्ञ के लिए यह ताक़त बढ़ाने वाला है: वही स्पेक उसे किसी तय चेकलिस्ट से जूझने के बजाय फ़्लो को सटीक निशाने पर लगाने देता है।
हर चरण अपने कामकाज में यह दोहरी भूमिका निभाता है (चित्र 3)। बिना इनपुट के चलाने पर, वह उपयोगकर्ता की ओर से पूरे दायरे पर काम करता है। दिशा मिलने पर, वही चरण ठीक उतने तक सिमट जाता है जितने पर उपयोगकर्ता ने उसे लगाया।
चित्र 3. डेवलपर के ज्ञान को आगे बढ़ाने वाली दोहरी भूमिका। एक उलटाव दो तरह के उपयोगकर्ताओं के काम आता है: ऑटोमैटिक मोड नौसिखिए की रक्षा करता है, और निर्देशित मोड विशेषज्ञ की क्षमता बढ़ाता है, उन्हीं पाँच चरणों से होकर।
ज़रूरत पड़ने पर ही लोड होने वाली विशेषज्ञताएँ (§VII) अपने टेक्स्ट में यह दोहरी भूमिका साफ़ लिखती हैं। हर विशेषज्ञता एजेंट से कहती है कि उसका ज्ञान "तुम्हारे विवेक को आगे बढ़ाता है", और उसे विशेषज्ञता की दी हुई बातों से आगे भी सोचते रहने को कहती है। ज्ञान एक निचली सीमा है, ऊपरी सीमा नहीं। यही चीज़ दस्तावेज़ के इच्छित संतुलन में दोनों तरह के उपयोगकर्ताओं के काम आती है: डेवलपर समुदाय को एक ठोस औज़ार मिलता है, और Blue Team विशेषज्ञ को एक संरचित वाहक मिलता है जो उसका काम उसकी जगह करने का दिखावा नहीं करता।
VII. सीधे न चलाई जा सकने वाली विशेषज्ञताएँ और प्रॉम्प्ट-ऑन-डिमांड
यह पद्धति का सबसे नया पैटर्न है। SDH सुरक्षा का केंद्रित ज्ञान विशेषज्ञताओं के रूप में रखता है, जो ज़रूरत पड़ने पर ही लोड होती हैं, और कौन-सी लोड हो, यह एजेंट ख़ुद प्रोजेक्ट के संदर्भ से मिलान करके तय करता है। हम इसे प्रॉम्प्ट-ऑन-डिमांड कहते हैं: एजेंट के लिए यह चुनने का तरीक़ा कि जिस प्रोजेक्ट में वह है उसके दायरे के आधार पर कौन-सा ज्ञान सक्रिय करना है, बजाय इसके कि हर जाँच डिफ़ॉल्ट रूप से चले। विशेषज्ञताएँ लगातार विकसित होती रहती हैं, और इनमें से कोई भी कभी भी बदली जा सकती है या उसकी जगह कोई दूसरी आ सकती है। योगदान यह पैटर्न है, ख़ुद विशेषज्ञताएँ नहीं।
प्रॉम्प्ट-ऑन-डिमांड (prompt-on-demand): एजेंट सुरक्षा के ज्ञान को अपने सामने के प्रोजेक्ट के दायरे से मिलाकर तय करता है कि कौन-सा ज्ञान सक्रिय करना है, ताकि प्रोजेक्ट असल में जो है उसके लिए प्रासंगिक ज्ञान लाया जाए, न कि हर जाँच डिफ़ॉल्ट रूप से चले।
सीधे न चलाई जा सकने वाली विशेषज्ञता (non-invocable specialization): किसी एक संदर्भ के लिए सुरक्षा ज्ञान की एक केंद्रित, भाषा से स्वतंत्र इकाई, जैसे फ़ाइल अपलोड या ब्राउज़र में चलने वाला कोड। यह ऑडिट करती है और समझाती है, कोड को कभी दोबारा नहीं लिखती, और कभी हमले का इनपुट नहीं बनाती। यह कोई कमांड नहीं है: यह तब लोड होती है जब इसका संदर्भ दायरे में हो, या जब कोई प्रॉम्प्ट इसे नाम से माँगे।
हर विशेषज्ञता अपने जोखिमों के लिए ज़्यादा सुरक्षित रूप बताती है, और एजेंट को बताती है कि जिस-जिस चरण में उसका इस्तेमाल होता है, उसमें किसी निष्कर्ष पर कैसे काम करना है: पहचान के समय उसे कैसे परखना है, निवारण के समय उसका सुधार सुरक्षित ढंग से कैसे लागू करना है, और पुष्टि के समय उसे कैसे साबित करना है।
इसकी ख़ास पहचान यह है कि विशेषज्ञता अपने आप में सीधे नहीं चलाई जा सकती: यह कोई कमांड नहीं है, और फ़्लो के भीतर मिलान ही इसे लोड करता है। पहचान वाला चरण कैटलॉग की सूची एक बार निकालता है, प्रोजेक्ट के संदर्भ को हर एंट्री के विषय से मिलाता है, और सिर्फ़ वे विशेषज्ञताएँ लोड करता है जिनका संदर्भ दायरे में मौजूद है। आगे के चरण दोबारा सूची निकालने के बजाय उसी मिलान की गई सूची को इस्तेमाल करते हैं, इसलिए एक मिलान पूरी चेन के काम आता है, और निवारक मोड (§IX) यही मिलान उस काम पर चलाता है जो बनने वाला है। जिस विशेषज्ञता का संदर्भ मौजूद नहीं, उसे छोड़ दिया जाता है, और छोड़ने का हिसाब भी उतना ही देना होता है जितना लोड करने का: कैटलॉग की हर एंट्री को साफ़ फ़ैसला मिलता है, लागू या छोड़ी गई, कोड से पढ़े गए कारण के साथ, ताकि अप्रासंगिक होने का धुंधला अंदाज़ा कभी ग़ैरमौजूदगी की जगह न ले। एक भी लागू न मिलना भी एक वैध नतीजा है।
कैटलॉग डेटा है, और इसे बढ़ाने का मतलब है एक ज्ञान फ़ाइल और कैटलॉग की एक पंक्ति, कभी कोई नई कमांड नहीं। बिल्ट-इन विशेषज्ञताएँ श्रेणियों में बँटी हैं, जैसे OWASP, कोई भाषा, या AI इंटीग्रेशन, और कोई प्रोजेक्ट जिस कैटलॉग का इस्तेमाल करता है उसमें उसकी चुनी हुई श्रेणियों की बिल्ट-इन विशेषज्ञताएँ और उसकी अपनी विशेषज्ञताएँ होती हैं। प्रोजेक्ट यह चुनाव अपनी बाक़ी स्थिति के साथ दर्ज करता है, ताकि पूरी टीम एक ही कैटलॉग से मिलान करे। यह वही संदर्भ को समझने वाला सिद्धांत है जो चरणों पर लागू होता है, बस ज्ञान पर लागू किया गया: प्रोजेक्ट असल में जो है उसके लिए प्रासंगिक ज्ञान लाया जाता है, न कि हर जाँच डिफ़ॉल्ट रूप से चलती है। यही गुण सिर्फ़ मेंटेनर को नहीं, उपयोगकर्ता को भी कैटलॉग बढ़ाने देता है: उपयोगकर्ता जो सुरक्षा स्रोत या विषय देता है, उसका सार निकालकर एक नई विशेषज्ञता बनाई जाती है जो प्रोजेक्ट की अपनी होती है, श्रेणियाँ चाहे जो हों उसके कैटलॉग में शामिल होती है, और ठीक बिल्ट-इन की तरह लोड होती है, उसी नाम वाली बिल्ट-इन की जगह लेते हुए। विशेषज्ञता लिखना ख़ुद भी केवल रक्षा के लिए है और उसी सीमा का पालन करता है जिसे विशेषज्ञताएँ लागू करती हैं: किसी हमले का ब्योरा स्रोत हो सकता है, लेकिन उससे बनी विशेषज्ञता ऑडिट करती है और समझाती है, कभी काम करने वाला एक्सप्लॉइट नहीं देती। इस तरह §I का उलटाव, यानी समझ का स्पेक में रहना, ख़ुद कैटलॉग तक फैल जाता है, जिसे उपयोगकर्ता कोड लिखे बिना अपने संदर्भ के लिए और गहरा कर सकता है।
एक छोटा उदाहरण प्रॉम्प्ट-ऑन-डिमांड को समझाता है। detect चरण ब्राउज़र में चलने वाले कोड का एक फ़ोल्डर पढ़ता है। वह कैटलॉग में इस संदर्भ का मिलान करता है, उसे कवर करने वाली विशेषज्ञता लोड करता है, और अपने सामान्य क़दमों से क्लाइंट-साइड का एक निष्कर्ष सामने रखता है। जिन विशेषज्ञताओं का संदर्भ इस दायरे में नहीं है, उनका मिलान नहीं होता, इसलिए वे कभी लोड नहीं होतीं, और हर एक को छोड़ी गई के रूप में दर्ज किया जाता है। कौन-सा ज्ञान प्रासंगिक है, यह प्रोजेक्ट ने तय किया, किसी तय कॉन्फ़िगरेशन ने नहीं।
नियतात्मकता ठीक वहीं आती है जहाँ वह मायने रखती है। विशेषज्ञता सिर्फ़ टेक्स्ट नहीं, एक नियतात्मक चेकर भी साथ रख सकती है: जहाँ किसी जोखिम वर्ग के लिए फ़ैसला करने का साफ़ तरीक़ा मौजूद है, वहाँ एक छोटा प्रोग्राम किसी दिए गए इनपुट के लिए एक तय फ़ैसला लौटाता है, जैसे safe, unsafe या invalid input जैसे कुछ गिने-चुने शब्द। कुछ जोखिम वर्ग ठीक इसी तरह नियतात्मक ढंग से तय किए जा सकते हैं, और फ़ैसला करने के उस तरीक़े के पीछे पहले हुए काम का अच्छा-ख़ासा भंडार है [9], [10], [11]। चेकर या तो एजेंट के दिए उम्मीदवारों को स्कोर देता है या ख़ुद दायरे को स्कैन करके उन्हें ढूँढता है, और दोनों ही हालात में फ़ैसला एजेंट नहीं, चेकर लौटाता है। जो विशेषज्ञता इतनी व्यापक हो कि हर जगह लागू हो, उसे कैटलॉग में ज़रूरी चिह्नित किया जा सकता है, और तब वह हमेशा लागू होती है, उसका चेकर पूरे दायरे पर चलता है। सिर्फ़ यही एक स्थिति है जिसमें ज्ञान संदर्भ के मिलान के बिना लोड होता है, और यह कैटलॉग के डेटा में घोषित होता है, कभी उसी पल एजेंट तय नहीं करता। यहीं SDH अपने एजेंट के तर्क को किसी दोहराए जा सकने वाले आधार पर टिकाता है, बिना यह दिखावा किए कि पूरा फ़्लो नियतात्मक है।
आख़िर में, विशेषज्ञताएँ अलग से भी इस्तेमाल हो सकती हैं। क्योंकि ज्ञान अपने आप में पूरा है, उपयोगकर्ता किसी एक विशेषज्ञता को सीधे ऐसे प्रॉम्प्ट में चला सकता है जिसका पूरे SDH फ़्लो से कोई लेना-देना नहीं, और इस तरह आम डेवलपमेंट के साथ-साथ सुरक्षा बनाए रख सकता है। उदाहरण के लिए, नियतात्मक चेकर वाली विशेषज्ञता आम कोडिंग के दौरान बने हर उम्मीदवार की जाँच करके सिर्फ़ सुरक्षित उम्मीदवारों को रख सकती है। अलग से इस्तेमाल हो पाने की यही ख़ूबी इस बात की एक वजह है कि SDH इतनी सारी स्थितियों में ढल जाता है, जो §VIII का विषय है, और इसका पूरा रूप निवारक मोड (§IX) में दिखता है, जहाँ वही ज्ञान आम डेवलपमेंट की शुरू से आख़िर तक रखवाली करता है।
VIII. स्थिति से स्वतंत्रता और बिना थोपे ढलने की क्षमता
दो गुण SDH को कठोर स्पेक पद्धतियों से अलग करते हैं।
स्थिति से स्वतंत्रता
स्थिति से स्वतंत्रता (state-independence): पद्धति डेवलपमेंट की स्थिति पर निर्भर नहीं करती। यह किसी खाली डायरेक्टरी, चल रहे प्रोजेक्ट, एक पुल रिक्वेस्ट या बड़े लेगेसी कोडबेस में, किसी भी स्टैक में, फ़िट बैठती है, क्योंकि यह शुरुआती बिंदु को पढ़कर समझती है।
हर चरण एक ही तरह काम करता है, चाहे प्रोजेक्ट बिल्कुल नया हो या पहले से मौजूद हो। charter चरण जो भी कोड मौजूद है उससे सिद्धांत निकालता है। detect चरण जो भी कोड है उसका खाका बनाता है, भले ही वह बहुत थोड़ा हो। पहले से मान लिया गया कोई शुरुआती बिंदु नहीं है।
बिना थोपे ढलने की क्षमता
बिना थोपे ढलने की क्षमता (non-authoritative adaptivity): पद्धति कोई ऐसा तय दायरा नहीं थोपती जिसे उपयोगकर्ता को मानना पड़े, बल्कि हालात के हिसाब से ढलती है। जब उपयोगकर्ता को नहीं पता कि क्या कहना है, तो यह उस माहौल को पढ़ती है जिसमें इसे चलाया गया, संदर्भ तैयार करती है, और वे सवाल पूछती है जिनसे तय होता है कि आगे क्या करना है।
charter चरण का प्रस्ताव मोड इसका सबसे साफ़ उदाहरण है: SDH प्रोजेक्ट का विश्लेषण करके डिफ़ॉल्ट रूप से सुरक्षित सिद्धांत तैयार करता है, उपयोगकर्ता से सिर्फ़ तब पूछता है जब कोई कमी सचमुच नतीजा बदलती हो, फिर उन्हें लिखता है और हर सिद्धांत को उस जोखिम के साथ आसान भाषा में सामने रखता है जिसे वह रोकता है। सुरक्षा सिद्धांत एक जीवंत दस्तावेज़ हैं, जिन्हें उपयोगकर्ता चरण दोबारा चलाकर बदलता है, कोई ऐसा अनुबंध नहीं जो मंज़ूरी के प्रॉम्प्ट के पीछे बंद हो, इसलिए उपयोगकर्ता को यह जानने की ज़रूरत कभी नहीं पड़ती कि क्या पूछना है।
यह ढलने की क्षमता इनपुट के रूप के प्रति संवेदनशीलता में दिखती है: वही चरण पढ़ता है कि उसे क्या दिया गया और एक मोड चुनता है (चित्र 4)। प्रॉम्प्ट में एक फ़ाइल, सूची का एक निष्कर्ष, कोई चिंता, किसी जानी-पहचानी कमज़ोर जगह पर केंद्रित मिशन, या पूरे ब्रूट-फ़ोर्स स्कैन का अनुरोध: हर एक उपयोगकर्ता की ज़रूरत पर फ़िट बैठता है, क्योंकि फ़्लो डिज़ाइन से ही कुछ नहीं थोपता। इनमें से कुछ भी डिफ़ॉल्ट रूप से सुरक्षित आधार को कमज़ोर नहीं करता। लचीलापन तय करता है कि आधार कैसे लागू हो, उसे कभी नीचे नहीं लाता।
चित्र 4. बिना थोपे ढलने की क्षमता। वही चरण अपने इनपुट का रूप पढ़कर एक मोड चुनता है, इसलिए दायरा हमेशा उपयोगकर्ता का होता है, कभी थोपा नहीं जाता।
IX. यूनिवर्सल निवारक मोड: काम बनते समय वही रक्षा
SDH में एक पूरक मोड भी है: आम डेवलपमेंट, जिसमें कोड लिखते समय वही रक्षा सक्रिय रहती है। उपयोगकर्ता ख़ुद काम माँगता है, जैसे लॉगिन पेज, अपलोड, कोई एंडपॉइंट, और पद्धति निर्माण के दौरान ही उसकी रखवाली करती है, ताकि नतीजा बाद की किसी हार्डनिंग के बाद नहीं, बल्कि जिस पल वह आए उसी पल डिफ़ॉल्ट रूप से सुरक्षित हो।
निवारक मोड (preventive mode): SDH की दिशा देने वाली परत और उसके ज्ञान के तहत चलने वाला आम डेवलपमेंट। सुरक्षा सिद्धांत निर्माण को बाँधते हैं, जो बनने वाला है उससे जुड़ी विशेषज्ञताएँ ज़रूरत पड़ने पर ही लोड होती हैं, और काम को पूरा कहने से पहले नतीजे का ठीक उसी रक्षा से मिलान किया जाता है जो इस्तेमाल हुई थी।
यह मोड वही हिस्से दोबारा इस्तेमाल करता है जो चरणों के पास पहले से हैं, बस उनका निशाना वह कोड होता है जो अभी मौजूद ही नहीं। संदर्भ की पहचान कोड से हटकर इरादे पर आ जाती है: एजेंट सोचता है कि वह क्या बनाने वाला है और वह काम किन सीमाओं को पार करता है (लॉगिन का मतलब है क्रेडेंशियल, सेशन और बाहर से आने वाला इनपुट), और ज्ञान के कैटलॉग का मिलान इसी सोच से किया जाता है। प्रॉम्प्ट-ऑन-डिमांड (§VII) यहाँ और व्यापक हो जाता है: संदर्भ सिर्फ़ मौजूदा कोड में नहीं, कोड की योजना में भी पहचाना जा सकता है। सुरक्षा सिद्धांत हमेशा की तरह दिशा देते हैं, और जो अनुरोध किसी सिद्धांत को तोड़े उसे टकराव के रूप में सामने रखा जाता है, कभी बनाया नहीं जाता। रक्षा उसी पल लागू होती है जब हर हिस्सा लिखा जाता है, सीमा पर जाँच करते हुए और पहली बार में ही सुरक्षित तरीक़ा अपनाते हुए, इसलिए चलने वाला लेकिन असुरक्षित वर्ज़न कभी बनता ही नहीं जिसे बाद में सुधारना पड़े।
यह मोड वहीं ख़त्म होता है जहाँ से verify शुरू होता है। काम को पूरा कहने से पहले, बनाने वाला अपने नतीजे का उस रक्षा से मिलान करता है जो उसने इस्तेमाल की: नियंत्रण को जोखिम के रास्ते पर होना चाहिए, उसके बगल में नहीं, उसे पूरा होना चाहिए, और जहाँ किसी विशेषज्ञता के पास नियतात्मक चेकर है, वहाँ एजेंट की अपनी समझ से ऊपर चेकर का फ़ैसला माना जाता है। यहाँ मिली कोई कमी उसी काम के हिस्से के रूप में दूर की जाती है, क्योंकि काम पूरा करने का मतलब है उसे सुरक्षित ढंग से पूरा करना।
यह मोड जो करने से इनकार करता है, वह भी उतना ही सोचा-समझा है जितना वह जो करता है। यह सिर्फ़ वही बनाता है जो माँगा गया और आसपास की किसी चीज़ का ऑडिट नहीं करता: जो मौजूद है उसका ऑडिट चरणों का काम है। यह कोई आर्टिफ़ैक्ट नहीं लिखता और कोई निष्कर्ष ट्रैक नहीं करता, क्योंकि निष्कर्ष मौजूदा चीज़ में पहचाना गया जोखिम होता है, और इस मोड का मक़सद ही यह है कि असुरक्षित वर्ज़न कभी आए ही नहीं। दोनों दिशाएँ एक-दूसरे को पूरा करती हैं: चरण वह बंद करते हैं जो पहले से मौजूद है (§V), और निवारक मोड नए काम को उसे दोबारा खोलने नहीं देता। स्थिर चेन इसलिए स्थिर नहीं रहती कि डेवलपमेंट रुक गया, बल्कि इसलिए कि उसके स्थिर रहते जो कुछ बनता है, वह रक्षा के साथ बनता है।
X. Security-Driven Hardening बनाम Spec-Driven Development
Security-Driven Hardening (SDH) Spec-Driven Development (SDD) की नींव से निकला और फिर उससे बहुत अलग हो गया। ढाँचे की विरासत असली है और इसे खुलकर माना जाता है: स्पेक-फ़र्स्ट, एजेंट-संचालित, दिशा देने वाला एक दस्तावेज़, और चरणों वाली कमांड का एक सेट जिसे एजेंट चलाता है। SDH इस ढाँचे को जान-बूझकर दोबारा इस्तेमाल करता है। फ़र्क़ है मक़सद, अधिकार के मॉडल, पहले से मानी गई स्थिति और समाप्ति की शर्त में। हम SDD को एक वर्ग के रूप में देखते हैं, जिसमें Piskala की रिपोर्ट [1] पद्धति का मानक वर्णन है, GitHub का Spec Kit [2] मानक एजेंट टूलकिट है, और OpenSpec [3] उसी परिवार का दूसरा टूल है।
SDD स्पेसिफ़िकेशन को चलाने लायक़ बनाकर पारंपरिक डेवलपमेंट को उलट देता है: स्पेक सिर्फ़ राह नहीं दिखाता, बल्कि सीधे एक चलने वाला इम्प्लीमेंटेशन बनाता है [1]। उसके चरण बिल्ड को आगे बढ़ाते हैं [2] (दिशा देने वाले सिद्धांत तय करना, क्या बनाना है यह बताना, टेक स्टैक की योजना बनाना, योजना को टास्क में बाँटना, फिर इम्प्लीमेंट करना)। उसका दिशा देने वाला दस्तावेज़, सिद्धांतों का एक संविधान, वह बुनियादी हिस्सा है जिसका एजेंट को पूरे समय पालन करना होता है। यही अंतर का मूल है। SDD का अधिकार स्पेक से बिल्ड की ओर बहता है, और इम्प्लीमेंटेशन से उसका पालन करने की उम्मीद की जाती है।
SDH उस अनुबंध के लगभग हर पहलू को उलट देता है (तालिका 3)।
मूल अंतर: SDD का अधिकार स्पेक से बिल्ड की ओर बहता है, और इम्प्लीमेंटेशन से उसका पालन करने की उम्मीद की जाती है। SDH कुछ नहीं थोपता और उलटी दिशा में बहता है, सिस्टम के पहचाने गए संदर्भ से भीतर की ओर, और जो पहले से है उसकी सुरक्षा मज़बूत करता है।
| पहलू | SDD | SDH |
|---|---|---|
| लक्ष्य | फ़ीचर डिलीवर करना। स्पेक एक चलने वाला इम्प्लीमेंटेशन बन जाता है। | जो मौजूद है या बन रहा है, उसकी सुरक्षा मज़बूत करना। हर चरण रक्षा के लिए ढला है। |
| अधिकार का मॉडल | अधिकार वाला। स्पेक और संविधान बिल्ड को एक ऐसे दायरे में बाँधते हैं जिसका उसे पालन करना है। | बिना थोपे। SDH हालात के हिसाब से ढलता है, और उपयोगकर्ता दोबारा लिख सकता है, हटा सकता है, या दायरा छोटा कर सकता है। |
| स्थिति की धारणा | स्पेसिफ़िकेशन से आगे की ओर बिल्ड। | स्थिति से स्वतंत्र: खाली डायरेक्टरी, चल रहा प्रोजेक्ट, एक PR, या लेगेसी। |
| समाप्ति की शर्त | फ़ीचर बन जाने पर ख़त्म। | बंद हो सकने वाला। निष्कर्ष स्थिर हो जाता है, और सिर्फ़ कोड बदलने पर दोबारा खुलता है। |
| दिशा देने वाला दस्तावेज़ | सिद्धांतों का संविधान, जिसका एजेंट को पालन करना है। | जोखिम पर आधारित सिद्धांत (हर एक में Why: पंक्ति), जो साफ़ तौर पर कोई तय अनुबंध नहीं हैं। |
| ज्ञान कैसे बढ़ता है | एक कमांड जोड़कर (या चरणों का सेट बढ़ाकर)। | एक सीधे न चलाई जा सकने वाली विशेषज्ञता जोड़कर, जिसे एजेंट ज़रूरत पड़ने पर ही लोड करता है: एक फ़ाइल और कैटलॉग की एक पंक्ति, कोई नई कमांड नहीं। |
| यह किसके काम आता है | फ़ीचर को आगे बढ़ाने वाला बिल्डर। | कोई भी उपयोगकर्ता, डेवलपर हो या न हो, एक ही फ़्लो से। |
| कोड क्या बदलता है | implement चरण बिल्ड बनाता है। | सिर्फ़ harden चरण कोड बदलता है, एक बार में एक सुधार। |
तालिका 3. आठ पहलुओं पर SDD बनाम SDH। ढाँचा उधार लिया हुआ, अनुबंध उलटा।
इस परंपरा के साथ न्याय करते हुए: SDD आज़माया हुआ पूर्ववर्ती काम है, और SDH जिस ढाँचे पर चलता है वह उसी की देन है। यह अलगाव SDD की आलोचना नहीं है, जो एक अलग समस्या (आगे की ओर बिल्ड करना) को अच्छी तरह हल करता है। SDH वही आज़माई हुई मशीनरी लेकर उसे रक्षा, ढलने की क्षमता और बंद होने की ओर मोड़ देता है। OpenSpec [3], जो बदलाव के प्रस्तावों, टास्क सूचियों और हर बदलाव के अपने स्पेक के इर्द-गिर्द बना है, इस पैटर्न की पुष्टि करता है: यह परिवार किसी स्पेक से बिल्ड को आगे बढ़ाता है, जबकि SDH किसी सिस्टम को उसके पहचाने गए संदर्भ से भीतर की ओर मज़बूत करता है। SDH का निवारक मोड (§IX) भी, जो इकलौती जगह है जहाँ वह आगे की ओर बढ़ते बिल्ड के साथ चलता है, उलटे अनुबंध को बनाए रखता है: वह तय करता है कि काम कैसे बने, कभी यह नहीं कि क्या बनाना है।
XI. इंजीनियरिंग की सख़्ती: ट्रैकिंग का अनुशासन
सिर्फ़ जोड़ते न जाने और मिलाकर अपडेट करने का अनुशासन (§V) एक ऐसी बुनियाद माँगता है जो रीफ़ैक्टर के बाद भी टिकी रहे। निष्कर्ष को उसे छूने वाले हर चरण में एक ही आइटम रहना चाहिए, और किसी फ़ाइल का नाम बदलने या उसे खिसकाने से चेन नहीं टूटनी चाहिए। SDH इसे नाम से पहचान और सिर्फ़ ट्रैकिंग में रखे गए पाथ से हल करता है।
नाम से पहचान (identity-by-name): निष्कर्ष की पहचान उसका नाम है, जो हर आर्टिफ़ैक्ट में बिल्कुल एक जैसा लिखा जाता है। टेक्स्ट में नाम रहता है, पाथ कभी नहीं। फ़ाइल पाथ सिर्फ़ ट्रैकिंग मैप में रहते हैं, इसलिए फ़ाइल का नाम बदलने या उसे खिसकाने पर लिंक ठीक एक ही जगह टूटता है।
detect चरण का हर निष्कर्ष एक ट्रैक किया गया आइटम है। उसकी पहचान उसका नाम है, यानी सेक्शन का शीर्षक, जो detect मैप, योजना और हार्डनिंग रिकॉर्ड में बिल्कुल एक जैसा लिखा जाता है। आगे के चरण उसी आइटम पर काम करते हुए उस नाम को हूबहू दोबारा इस्तेमाल करते हैं, और verify चरण उसी नाम के तहत हार्डनिंग रिकॉर्ड पर अपना फ़ैसला लिखता है। ट्रैकिंग मैप में ट्रैकिंग के अलावा कुछ नहीं होता, हर आइटम की एक एंट्री:
{ "name": "File uploads", "paths": ["src/routes/upload.ts"] }
मैप में न कोई टेक्स्ट होता है, न टिप्पणी, न अलग पहचानकर्ता, न चरण। शब्दों को टेक्स्ट वाले आर्टिफ़ैक्ट सँभालते हैं, और मैप सिर्फ़ पहचान और पाथ रखता है। फ़ाइल पाथ ही इकलौती बदलने वाली चीज़ हैं, और वे सिर्फ़ यहीं रहते हैं। फ़ाइल का नाम बदलने या उसे खिसकाने पर लिंक ठीक एक ही जगह टूट सकता है, कभी दो अलग-अलग होती प्रतियों में नहीं।
चित्र 5. पहचान की कन्वेयर बेल्ट। निष्कर्ष का एक ही नाम हर आर्टिफ़ैक्ट से होकर गुज़रता है, जबकि उसका पाथ सिर्फ़ ट्रैकिंग मैप में रहता है, इसलिए नाम बदलने पर सुधार एक ही जगह होता है।
सामान्य फ़्लो में दो काम मैप को सँभालते हैं, और तीसरा रखरखाव के तौर पर अलग खड़ा है। Track जोड़ने वाला पंजीकरण है: कोई चरण अपने लिखे निष्कर्षों की जानकारी देता है, और इंजन नए निष्कर्ष दर्ज करता है और बाक़ियों के बदले हुए पाथ का पीछा करता है, हर एक को नया, खिसका हुआ या बिना बदलाव वाला मानते हुए। वह ऐसी कोई चीज़ कभी नहीं हटाता जिसकी जानकारी चरण ने न दी हो। Untrack उन निष्कर्षों को बंद करता है जिन्हें verify चरण ने बंद पाया: एक ही नियतात्मक पास में वह हर निष्कर्ष का सार निकालकर उसकी इतिहास एंट्री बनाता है, आर्टिफ़ैक्ट से उसका पूरा सेक्शन हटाता है, जिस आर्टिफ़ैक्ट का आख़िरी निष्कर्ष चला गया उसे मिटा देता है, और उसकी ट्रैकिंग एंट्री हटा देता है, ताकि एजेंट को इनमें से कुछ भी हाथ से न करना पड़े। जहाँ नियतात्मक पास सुरक्षित ढंग से नहीं जा सकता, जैसे कोई बंद किया गया नाम जो अब भी किसी दूसरे निष्कर्ष के टेक्स्ट में उद्धृत हो, वहाँ वह अंदाज़े से बदलाव करने के बजाय एजेंट के लिए उस जगह को चिह्नित कर देता है। चरण चलते समय इन्हीं दोनों को बुलाते हैं। Repair रखरखाव का काम है: जब किसी चरण का अपना मिलान ट्रैकिंग को असंगत पाता है (दर्ज किया गया कोई पाथ जो अब मौजूद नहीं), तो वह चरण अपने आप यह काम repair को सौंप देता है, और वरना इसे ज़रूरत पड़ने पर चलाया जाता है। यह एक साथ पूरे मैप को फिर से ठीक बैठाता है, हर आर्टिफ़ैक्ट और मौजूदा कोड पढ़ता है, हर आइटम के पाथ सुधारता है, और जो वह अकेले तय नहीं कर सकता उसे सामने रखता है: कोई अनाथ आइटम (ऐसा ट्रैक किया गया आइटम जिसका अब कोई आर्टिफ़ैक्ट नाम नहीं लेता) या नाम बदलने का संभावित मामला (ऐसा आइटम जिसके पाथ किसी दूसरे बताए गए नाम से मेल खाते हों)।
repair रखरखाव है, छठा चरण नहीं। यह न उपयोगकर्ता के कोड को छूता है, न टेक्स्ट वाले आर्टिफ़ैक्ट को, सिर्फ़ ट्रैकिंग को। यह उपयोगकर्ता का सोर्स सिर्फ़ एक वजह से पढ़ता है, नाम बदली गई फ़ाइल का नया पाथ जानने के लिए, और कभी सुरक्षा सामग्री नहीं लिखता। जिस एक सवाल पर इंजन अंदाज़ा लगाने से इनकार करता है, उस पर आख़िरी फ़ैसला इंसान का होता है: कोई ग़ायब हुआ आइटम सुलझ गया था या सिर्फ़ उसका नाम बदला था। अंदाज़ा लगाने से बेहतर है पूछना, क्योंकि ग़लती से हटाया गया आइटम चेन तोड़ देता है।
पद्धति अपना रक्षा अनुशासन ख़ुद पर भी लागू करती है। नियतात्मक इंजन कमांड-लाइन प्रोग्राम के रूप में चलाए जाते हैं, और हर इनपुट अपने अलग प्रोसेस आर्ग्युमेंट के रूप में दिया जाता है, जिससे वह निष्क्रिय रहता है, इसलिए कोट या बैकटिक वाली कोई वैल्यू कभी कमांड में इंजेक्ट नहीं हो सकती। अनजान चेक जवाब देने के बजाय फ़ेल हो जाता है, इसलिए ग़लत लिखा गया चेक कभी साफ़ नतीजे जैसा नहीं दिखता। SDH अपनी अंदरूनी व्यवस्था को भी डिफ़ॉल्ट रूप से सुरक्षित सिद्धांत से छूट नहीं देता।
XII. वाहक: पोर्टेबिलिटी के प्रमाण के रूप में एजेंट से स्वतंत्र आर्किटेक्चर
SDH ऐसा कन्वेंशन बन सके जिसे दूसरे अपनाएँ, इसके लिए ज़रूरी है कि वह किसी एक एजेंट या एक स्टैक से बँधा न हो, इसलिए उसका वाहक तीन चीज़ों को अलग रखता है (चित्र 6)। Lagune साबित करता है कि यह मुमकिन है।
सुरक्षा की असली सामग्री एक बार लिखी जाती है और उसे पता नहीं होता कि उसे कौन-सा एजेंट चलाता है: चरणों के निर्देश और वे टेम्पलेट जिन्हें वे भरते हैं, ज्ञान का कैटलॉग, और नियतात्मक इंजन। डिलीवरी हल्की है: उसका इकलौता काम उस सामग्री को किसी एजेंट तक उस रूप में और उस जगह पहुँचाना है जिसकी एजेंट उम्मीद करता है, और उसमें अपना कोई सुरक्षा लॉजिक नहीं होता। प्रोजेक्ट की स्थिति प्रोजेक्ट की होती है: सुरक्षा सिद्धांत, चरणों के आर्टिफ़ैक्ट, ट्रैकिंग मैप, उसकी चुनी हुई श्रेणियाँ और उसकी अपनी विशेषज्ञताएँ, जो उसके बाक़ी कोड की तरह कमिट की जाती हैं और रिव्यू की जा सकती हैं।
चित्र 6. एजेंट से स्वतंत्र वाहक। सुरक्षा की असली सामग्री एक बार लिखी जाती है, हल्की डिलीवरी उसे हर एजेंट तक पहुँचाती है, और स्थिति प्रोजेक्ट की ही रहती है।
क्योंकि डिलीवरी में कोई सुरक्षा लॉजिक नहीं होता, वह कैसे बनी है इससे SDH में कुछ नहीं बदलता। कोई वाहक डिलीवरी ख़ुद बना सकता है या उसे किसी ऐसे इकोसिस्टम को सौंप सकता है जो पहले से एजेंट स्किल बाँटता है, जैसा रेफ़रेंस इम्प्लीमेंटेशन करता है, और चरण, उनके आर्टिफ़ैक्ट और उनकी गारंटियाँ वैसी ही रहती हैं। इसमें से कुछ भी किसी भाषा या रनटाइम से भी बँधा नहीं है। रेफ़रेंस इम्प्लीमेंटेशन संयोग से एक स्टैक में लिखा गया है, लेकिन पद्धति इन चीज़ों के बीच की सीमा है, उन्हें बनाने वाला टूलचेन नहीं। यही डिज़ाइन पूरी तरह किसी दूसरी भाषा में दोबारा बनाया जा सकता है, और SDH जो है उसमें कोई बदलाव नहीं आएगा।
XIII. व्यावहारिक उदाहरण: SDH शुरू से अंत तक
अपलोड और एडमिन सरफ़ेस की रक्षात्मक हार्डनिंग। संदर्भ: एक छोटा ऐप जो उपयोगकर्ताओं की अपलोड की गई फ़ाइलें लेता है और उन्हें एक एडमिन पेज पर सूची में दिखाता है। पैटर्न: charter → detect (संदर्भ से सक्रिय हुए, ज़रूरत पड़ने पर ही लोड होने वाले ज्ञान के साथ) → plan → harden → verify, एक बंद होने और एक असली नाकामी के साथ। नतीजा (क्षमता): एक जोखिम जिसका बंद होना पुष्ट हुआ और जिसे पूरी चेन से बंद किया गया, और एक नियंत्रण जिसके बारे में पुष्टि हुई कि वह बंद नहीं है और जिसे वापस harden चरण पर भेजा गया। फ़ैसला रिकॉर्ड को नहीं, कोड को दिखाता है।
यह पद्धति के तंत्र को समझाने वाला एक उदाहरण है, मैदान में मापा गया अध्ययन नहीं, और इसमें प्रभावशीलता का कोई आँकड़ा नहीं दिया गया है।
एक लगातार चलने वाला उदाहरण पद्धति को सिर्फ़ उसके हिस्सों में नहीं, काम करते हुए दिखाता है। हम §IV के फ़ाइल अपलोड वाले उदाहरण को आगे बढ़ाकर उसमें ज़रूरत पड़ने पर ज्ञान का सक्रिय होना और एक निष्कर्ष का बंद होना जोड़ते हैं, और एक असली नाकामी भी शामिल करते हैं।
- charter चरण "जब तक इनपुट की जाँच न हो जाए, हर इनपुट अविश्वसनीय है" सिद्धांत का प्रस्ताव रखता है, साथ में आसान भाषा में उसका जोखिम: बिना जाँचा गया इनपुट किसी सिस्टम में सेंध लगने का सबसे आम रास्ता है।
- detect चरण अपलोड रूट और अपलोड की गई फ़ाइलों की सूची दिखाने वाले छोटे एडमिन पेज को स्कैन करता है। वह अपलोड वाला निष्कर्ष पहचानता है (हैंडलर क्लाइंट के MIME टाइप पर भरोसा करता है)। एडमिन पेज ब्राउज़र में चलता है, और यह ऐसा संदर्भ है जिसे प्रॉम्प्ट-ऑन-डिमांड (§VII) पहचानता है, इसलिए detect चरण उस संदर्भ की विशेषज्ञता लोड करता है और दूसरा निष्कर्ष सामने रखता है: एक जगह जहाँ फ़ाइल का नाम पेज में टेक्स्ट के बजाय मार्कअप के रूप में लिखा जाता है, इसलिए जान-बूझकर गढ़ा गया नाम विज़िटर के ब्राउज़र में स्क्रिप्ट की तरह चल सकता है। जिन विशेषज्ञताओं का संदर्भ इस दायरे में नहीं है, वे कभी लोड नहीं होतीं, और हर बार छोड़े जाने को कोड से पढ़ी गई ग़ैरमौजूदगी के साथ दर्ज किया जाता है।
- plan चरण अपलोड वाले सुधार को क्रिटिकल प्राथमिकता देता है, जो उस सिद्धांत से जुड़ा है: फ़ाइल का असली टाइप और साइज़ जाँचें, सेव करते समय नाम बदलें, और ऐसी जगह रखें जहाँ कोड न चल सके। दूसरे सुधार को वह उच्च प्राथमिकता देता है: फ़ाइल का नाम मार्कअप नहीं, टेक्स्ट के रूप में दिखाएँ।
- harden चरण पहले अपलोड वाला सुधार लागू करता है (सबसे ऊँची प्राथमिकता) और उसे Applied दर्ज करता है, फिर दूसरा, वह भी Applied।
- verify चरण हर जगह को पढ़ता है और कोड का रिकॉर्ड से मिलान करता है। अपलोड वाला नियंत्रण कारगर है: हैंडलर कंटेंट से असली टाइप पहचानता है, साइज़ की सीमा लागू करता है, और बाक़ी सब अस्वीकार करता है। फ़ैसला: Risk closed। verify चरण अपलोड वाले निष्कर्ष को पूरी चेन से बंद कर देता है, और उसका सार इतिहास में दर्ज हो जाता है।
अब असली नाकामी। मान लीजिए harden चरण के दूसरे सुधार ने टेक्स्ट को सुरक्षित ढंग से दिखाने वाला एक हेल्पर जोड़ दिया, लेकिन मार्कअप लिखने वाला पुराना कॉल किसी दूसरे कोड पाथ पर अब भी पहुँच में छोड़ दिया। verify चरण पेज पढ़ता है, सुरक्षित हेल्पर देखता है, और यह भी देखता है कि असुरक्षित रास्ता अब भी चालू है। नियंत्रण मौजूद है, लेकिन जोखिम बंद नहीं हुआ। verify चरण रिकॉर्ड से मेल खाने के लिए फ़ैसले को नरम करने से इनकार करता है। वह "Risk not closed" फ़ैसला देता है, कमी दर्ज करता है, और वापस harden चरण की ओर इशारा करता है। जो नियंत्रण जोखिम को पूरी तरह नहीं सँभालता, वह पास नहीं है।
एक उदाहरण में यही पद्धति का स्वभाव है: संदर्भ को समझने वाली पहचान, सिद्धांतों से जुड़े और प्राथमिकता वाले सुधार, सावधानी से लागू करना, और ऐसी पुष्टि जो रिकॉर्ड चाहे जो कहे, कोड की असली हालत बताती है।
XIV. SDH कब इस्तेमाल करें, और उसकी सीमाएँ
SDH शायद ही कभी उस तरह ज़रूरत से ज़्यादा भारी पड़ता है जैसे कोई भारी प्रक्रिया पड़ सकती है, क्योंकि यह स्थिति से स्वतंत्र और बंद हो सकने वाला है: यह सिमटकर एक फ़ाइल और एक चिंता तक आ सकता है, और कोई स्थायी बोझ छोड़ने के बजाय स्थिर अवस्था तक पहुँचता है। इसकी सीमा प्रोजेक्ट का आकार नहीं, बल्कि भरोसे की गहराई है।
चित्र 7. SDH कब इस्तेमाल करें। पहला सवाल सुरक्षा से जुड़ाव का है, फिर भरोसे की गहराई का, प्रोजेक्ट के आकार का कभी नहीं।
SDH अपनी सीमा पर कहाँ पहुँचता है: ऐसा व्यवहार जो सिर्फ़ सिस्टम चलने पर दिखता है (verify चरण कोड पढ़ता है, सिस्टम चलाता नहीं), ऐसा जोखिम जो किसी ऐसे कॉन्फ़िगरेशन या माहौल पर निर्भर है जिसे एजेंट पढ़ नहीं सकता, और बहुत ऊँचे दाँव वाले ऐसे संदर्भ जहाँ विशेषज्ञ रिव्यू हर हाल में ज़रूरी है। इन सबमें भी SDH एक संरचित पहली जाँच के रूप में काम का रहता है, लेकिन वह निचली सीमा है, ऊपरी सीमा नहीं।
सीमा: SDH की सीमा भरोसे की गहराई है, प्रोजेक्ट का आकार नहीं। यह लगभग हर जगह एक ठोस आधार बन सकता है, और जहाँ दाँव ऊँचे हों वहाँ विशेषज्ञ रिव्यू में मदद करता है, लेकिन यह चलते सिस्टम की टेस्टिंग या सुरक्षा पेशेवर के विवेक की जगह नहीं लेता।
XV. चर्चा: SDH की जगह, उसकी सीमाएँ, और वह किन बातों का दावा नहीं करता
SDH अपनी सीमाओं को लेकर सटीक है।
यह आगे बढ़ाता है, जगह नहीं लेता
SDH सुरक्षा पेशेवरों या विशेष Blue Team टूलिंग की जगह नहीं लेता। यह डेवलपर के ज्ञान को आगे बढ़ाता है (§VI)। संतुलित दावा ही सही दावा है: ठीक से लागू किया जाए तो SDH असली जोखिमों को असरदार ढंग से बंद कर सकता है, ख़ासकर उन प्रोजेक्ट में जिन्हें वरना कोई सुरक्षा जाँच मिलती ही नहीं। यह कोई गारंटी नहीं है, और जहाँ दाँव विशेषज्ञ रिव्यू की माँग करें, वहाँ उसका विकल्प नहीं है।
बनावट से ही केवल रक्षा के लिए
SDH ऑडिट करता है, सुरक्षा मज़बूत करता है और पुष्टि करता है। यह कभी आक्रामक टूलिंग, एक्सप्लॉइट, या नुक़सान पहुँचाने के लिए पकड़ से बचने की तकनीकें नहीं बनाता। दोहरे इस्तेमाल वाली सुरक्षा सामग्री सिर्फ़ साफ़ तौर पर रक्षात्मक और अधिकृत संदर्भ में ही स्वीकार्य है। यह एक पक्की सीमा है, पसंद-नापसंद का मामला नहीं।
पुष्टि ठोस है, दिखावटी नहीं
verify चरण सिस्टम चलाकर नहीं, बल्कि कोड पढ़कर और उसका रिकॉर्ड से मिलान करके पुष्टि करता है। यह स्टैटिक पुष्टि है: यह पक्का करती है कि नियंत्रण कोड में मौजूद और सही है, और यह साबित नहीं करती कि रनटाइम पर हमला होने पर भी नियंत्रण कारगर रहेगा। इसलिए "Cannot tell from the code" एक जायज़ फ़ैसला है, पास होते नतीजे के पीछे छिपी नाकामी नहीं। जब सबूत कोड में नहीं होता (वह कॉन्फ़िगरेशन पर, या किसी ऐसे पाथ पर निर्भर है जिसे एजेंट पढ़ नहीं सकता), तो SDH अंदाज़ा लगाने के बजाय साफ़ यही कहता है।
नियतात्मकता का दायरा तय है, और उसका नाम लिया गया है
SDH का ज़्यादातर हिस्सा एजेंट के तर्क पर चलता है, और इसी से उसमें संदर्भ की समझ आती है। नियतात्मकता नियतात्मक इंजनों के लिए सुरक्षित रखी गई है: वे चेकर जो कोई विशेषज्ञता साथ रख सकती है (§VII), और ट्रैकिंग इंजन (§XI)। दस्तावेज़ इस रेखा को धुंधला नहीं करता। जहाँ नतीजा नियतात्मक है, वहाँ वह किसी प्रोग्राम का नतीजा है। जहाँ वह तर्क से निकला है, वहाँ वह कोड के बारे में एजेंट की समझ है, और आख़िरी फ़ैसला उपयोगकर्ता का होता है।
लागत और पैमाना
पूरा स्कैन बहुत टोकन खाता है। मैनुअल मोड (§VI, §VIII) कुछ हद तक इसीलिए हैं कि लागत चिंता के अनुपात में रहे।
आख़िरी फ़ैसला उपयोगकर्ता का है
SDH इंसान से यह तय करने को कहता है कि आइटम का नाम बदला या वह सुलझ गया, और उसके कोड बदलावों की मंज़ूरी वहीं रहती है जहाँ उपयोगकर्ता पहले से अपने एजेंट को नियंत्रित करता है, यानी उस परमिशन मोड में जिसमें वह उसे चलाता है। पद्धति प्रस्ताव रखती है और पुष्टि करती है। यह व्यक्ति के फ़ैसले को पलटती नहीं।
आपत्तियाँ और जवाब
एक निष्पक्ष संशयवादी कई आपत्तियाँ उठाएगा। जो ठोस हैं, उन्हें उन्हीं के शब्दों में रखना ठीक है।
"क्या यह बस एक स्टैटिक एनालाइज़र नहीं है जिस पर LLM चिपका दिया गया है?" नहीं। स्टैटिक एनालाइज़र अपने सारे नियम डिफ़ॉल्ट रूप से चलाता है। SDH पहले पहचानता है कि सिस्टम क्या है, फिर प्रासंगिक ज्ञान तक पहुँचता है (§II, §VII), और नियतात्मक चेकर को सिर्फ़ वहीं जोड़ता है जहाँ किसी जोखिम वर्ग के लिए फ़ैसला करने का साफ़ तरीक़ा हो। तर्क संदर्भ से शुरू होता है, नियतात्मकता सोच-समझकर निशाने पर लगाई जाती है।
"क्या यह बस एक सुरक्षा चेकलिस्ट नहीं है?" नहीं। SDH चेकलिस्ट को उलट देता है: पहचान पहले आती है, और ज्ञान उसके लिए लाया जाता है जो प्रोजेक्ट असल में करता है (§II, §VII)।
"क्या यह बस सुरक्षा के नाम पर नया लेबल लगाया गया SDD नहीं है?" नहीं। SDH SDD का ढाँचा उधार लेता है और उसका अनुबंध उलट देता है: अधिकार, स्थिति की धारणा, समाप्ति की शर्त और यह किसके काम आता है, सब अलग है (§X)। वही मशीनरी, उलटी दिशा।
"क्या AI के तर्क पर चलने वाला तरीक़ा मनगढ़ंत निष्कर्ष नहीं देगा?" डिज़ाइन मॉडल के ठीक बर्ताव पर भरोसा करने के बजाय गढ़ने पर ही रोक लगाता है। detect चरण सिर्फ़ वही दर्ज करता है जिसकी पुष्टि कोड से हो ("पहचानना है, गढ़ना नहीं", §IV), verify चरण कोड का रिकॉर्ड से मिलान करता है और जवाब में "Cannot tell from the code" भी दे सकता है (§XV), नियतात्मक चेकर तय किए जा सकने वाले मामलों को ठोस आधार देते हैं (§VII), और आख़िरी फ़ैसला उपयोगकर्ता का होता है। इससे एजेंट अचूक नहीं बन जाता, लेकिन उसके दावों की जाँच की जा सकती है।
SDH की जगह के बारे में एक बात। SDH को यहाँ उसके रेफ़रेंस इम्प्लीमेंटेशन से अलग परिभाषित किया गया है। पाँच चरण, जोखिम पर आधारित सुरक्षा सिद्धांत, सिर्फ़ जोड़ते न जाने और मिलाकर अपडेट करने का अनुशासन और उससे आने वाला बंद हो पाना, प्रॉम्प्ट-ऑन-डिमांड ज्ञान, निवारक मोड, नाम से पहचान वाली ट्रैकिंग, और केवल रक्षा की सीमा, यही पद्धति है। कोई दूसरी टीम इन्हें किसी दूसरे स्टैक और दूसरे एजेंट इकोसिस्टम में लागू कर सकती है, और नतीजा फिर भी SDH ही होगा। Lagune इसका प्रमाण है, इसकी परिभाषा नहीं।
XVI. आम ख़तरे, और SDH अपनी बनावट से उनसे कैसे बचता है
इस परिवार की पद्धतियों में नाकामी के कुछ जाने-पहचाने तरीक़े साझा होते हैं। इनमें से ज़्यादातर का SDH का जवाब ढाँचागत है, जो अनुशासन के भरोसे छोड़ने के बजाय फ़्लो में ही बुना गया है।
| ख़तरा | नाकामी | SDH का ढाँचागत जवाब |
|---|---|---|
| स्पेक का सड़ना, पुराना पड़ चुका बैकलॉग | आर्टिफ़ैक्ट में बेकार एंट्री जमा होती जाती हैं, जिन पर कोई भरोसा नहीं करता | सिर्फ़ जोड़ते न जाना, मिलाकर अपडेट करना (§V): हर रन हर एंट्री को दोबारा जाँचता है और जो सुलझ चुका है उसे हटाता है |
| झूठा भरोसा, पास होता नतीजा | मान लिया जाता है कि मौजूद नियंत्रण जोखिम को बंद कर देता है | verify चरण कोड का रिकॉर्ड से मिलान करता है, इसलिए "Risk not closed" और "Cannot tell" भी पूरे दर्जे के फ़ैसले हैं (§IV, §XV) |
| चेकलिस्ट की बाढ़ | सामान्य आइटम उस एक जोखिम को ढक देते हैं जो मायने रखता है | सामान्य सलाह की जगह संदर्भ की समझ, और प्रॉम्प्ट-ऑन-डिमांड सिर्फ़ वही लोड करता है जो दायरा माँगता है (§VII) |
| टूलिंग में बँध जाना | तरीक़ा किसी एक वेंडर या एजेंट से चिपक जाता है | एजेंट से स्वतंत्र वाहक: सुरक्षा की असली सामग्री एक बार लिखी जाती है, और हर एजेंट तक उसकी डिलीवरी में कोई सुरक्षा लॉजिक नहीं होता (§XII) |
| अंतहीन लूप | बैकलॉग कभी बंद नहीं होता, काम कभी थमता नहीं | बंद हो पाना और स्थिर अवस्था (§V) |
तालिका 4. इस पद्धति परिवार के जाने-पहचाने ख़तरे, और हर एक के लिए SDH का ढाँचागत जवाब।
असल बात ख़तरे का नाम लेना और उस तंत्र की ओर इशारा करना है: ये सावधान रहने की चेतावनियाँ नहीं, फ़्लो के गुण हैं।
XVII. आगे का काम
पद्धति और उसके रेफ़रेंस इम्प्लीमेंटेशन के अगले क़दम साफ़ हैं।
- ज्ञान का कैटलॉग बढ़ाना: हर नई चीज़ §VII वाला रूप ही रखती है: एक ज्ञान फ़ाइल और कैटलॉग की एक पंक्ति, कोई नई कमांड नहीं। उपयोगकर्ता की ओर का रास्ता वहाँ पहले से मौजूद है: उपयोगकर्ता ज़रूरत पड़ने पर अपनी विशेषज्ञताओं का सार निकालता है। ज़्यादा बिल्ट-इन भाषाएँ, रनटाइम और जोखिम वर्ग, हर एक किसी श्रेणी में शामिल होते हुए, मेंटेनर की ओर की दिशा हैं, और उम्मीद है कि विशेषज्ञताएँ विकसित होती रहेंगी।
- और नियतात्मक चेकर: जहाँ किसी जोखिम वर्ग के लिए फ़ैसला करने का साफ़ तरीक़ा हो, वहाँ विशेषज्ञता एक नियतात्मक चेकर रख सकती है जो एजेंट के तर्क को दोहराए जा सकने वाले फ़ैसले पर टिकाता है। इसे और जोखिम वर्गों तक ले जाना एक स्वाभाविक दिशा है।
- अनुभवजन्य मूल्यांकन: सबसे बड़ा खुला सवाल मापी गई प्रभावशीलता का है: असली कोडबेस में बंद करने की गुणवत्ता और ग़लत फ़ैसलों की दर। SDH के सुरक्षा नतीजों का अध्ययन आगे का काम है, और यहाँ किए गए दावे उसी हिसाब से सीमित हैं।
XVIII. उपसंहार
AI की मदद से होने वाले डेवलपमेंट ने सुरक्षा में ऐसी खाई खोली है जिसे सामान्य चेकलिस्ट नहीं भर सकतीं, क्योंकि जो जोखिम मायने रखता है वह इस पर निर्भर करता है कि सिस्टम असल में क्या करता है, और उसे शिप करने वाले व्यक्ति को शायद पता न हो कि क्या पूछना है। SDH यह खाई संदर्भ को समझने वाले, केवल रक्षा के लिए बने और बंद हो सकने वाले फ़्लो से भरता है, जिसमें सुरक्षा का ज्ञान पद्धति में और ज़रूरत पड़ने पर ही लोड होने वाली उसकी विशेषज्ञताओं में रहता है, जो एक ऐसा आधार है जिस पर हर उपयोगकर्ता आगे बढ़ सकता है। यह सिस्टम के असली संदर्भ को पहचानता है, उस संदर्भ से जुड़े जोखिमों की प्राथमिकता तय करता है, सावधानी से सुधार लागू करता है, और हर एक की पुष्टि करता है, फिर जो बंद हो चुका है उसे बंद कर देता है, ताकि हर निष्कर्ष अपने अंत तक पहुँचे। नया काम बनते समय भी वही रक्षा निवारक ढंग से चलती है, इसलिए फ़्लो जो बंद करता है वह बंद ही रहता है। यह किसी भी स्टैक में डेवलपमेंट की किसी भी स्थिति के हिसाब से ढल जाता है, और जो लोग और टूल पहले से यह काम करते हैं उनकी जगह लेने के बजाय डेवलपर के ज्ञान को आगे बढ़ाता है।
Lagune प्रमाण है, लेकिन योगदान कन्वेंशन है। SDH को AI के साथ डेवलपमेंट के दौर के लिए ज़रूरी सुरक्षा फ़्लो के रूप में पेश किया गया है, ताकि दूसरे इसे अपनाएँ, निखारें और अपने-अपने स्टैक में लागू करें।
संदर्भ
[1] D. B. Piskala, "Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants," arXiv preprint arXiv:2602.00180v1 [cs.SE], Jan. 2026. (Submitted to AIWare 2026.) [Online]. Available: https://arxiv.org/abs/2602.00180
[2] GitHub, "Spec Kit: Toolkit for Spec-Driven Development." [Online]. Available: https://github.com/github/spec-kit. Accessed: 2026.
[3] Fission AI, "OpenSpec: Spec-Driven Development for AI Coding Assistants." [Online]. Available: https://github.com/Fission-AI/OpenSpec. Accessed: 2026.
[4] B. Chess and G. McGraw, "Static Analysis for Security," IEEE Security & Privacy, vol. 2, no. 6, pp. 76-79, 2004, doi: 10.1109/MSP.2004.111.
[5] OWASP Foundation, "Source Code Analysis Tools." [Online]. Available: https://owasp.org/www-community/Source_Code_Analysis_Tools. Accessed: 2026.
[6] OWASP Foundation, "OWASP Top 10:2021." [Online]. Available: https://owasp.org/Top10/. Accessed: 2026.
[7] MITRE, "Common Weakness Enumeration (CWE)." [Online]. Available: https://cwe.mitre.org/. Accessed: 2026.
[8] N. Perry, M. Srivastava, D. Kumar, and D. Boneh, "Do Users Write More Insecure Code with AI Assistants?," in Proc. ACM SIGSAC Conf. on Computer and Communications Security (CCS '23), 2023, pp. 2785-2799, doi: 10.1145/3576915.3623157. [Online]. Available: https://arxiv.org/abs/2211.03622
[9] J. Davis and contributors, "safe-regex: Detect Possibly Catastrophic, Exponential-Time Regular Expressions." [Online]. Available: https://github.com/davisjam/safe-regex. Accessed: 2026.
[10] D. Soshnikov, "regexp-tree: Regular Expressions Processor in JavaScript." [Online]. Available: https://github.com/DmitrySoshnikov/regexp-tree. Accessed: 2026.
[11] T. Jenkinson, "redos-detector: A CLI and Library to Score How Vulnerable a Regex Pattern Is to ReDoS Attacks." [Online]. Available: https://github.com/tjenkinson/redos-detector. Accessed: 2026.
परिशिष्ट A: सिद्धांत, हूबहू
- डिफ़ॉल्ट रूप से सुरक्षित, आसान भाषा में, सबके लिए बराबर: हर डिफ़ॉल्ट, संदेश और सुधार शुरू से ही सुरक्षित होना चाहिए और हर उपयोगकर्ता की समझ में आना चाहिए, चाहे वह डेवलपर हो या न हो। किसी उपयोगकर्ता वर्ग को दूसरे पर तरजीह नहीं मिलती।
- सामान्य सलाह की जगह संदर्भ की समझ: हर चरण को detect चरण में पहचाने गए संदर्भ से शुरू करना चाहिए और सिस्टम असल में जो करता है उस पर काम करना चाहिए। सामान्य चेकलिस्ट के बजाय उस संदर्भ से जुड़े सुझावों को प्राथमिकता दें। सुरक्षा का ज्ञान स्पेक में और ज़रूरत पड़ने पर ही लोड होने वाली उसकी विशेषज्ञताओं में रहता है, और उपयोगकर्ता जो भी जानता है उसे आगे बढ़ाता है।
- कठोरता की जगह लचीलापन: SDH प्रोजेक्ट और उपयोगकर्ता के हिसाब से ढलता है। सिद्धांत, ज़रूरतें और सुझाव शुरुआती बिंदु हैं, कोई तय अनुबंध नहीं। उपयोगकर्ता को किसी भी चीज़ को दोबारा लिखने, हटाने, जोड़ने या उसका दायरा छोटा करने दें। लचीलापन डिफ़ॉल्ट रूप से सुरक्षित आधार को कभी कमज़ोर नहीं करता, यह सिर्फ़ उपयोगकर्ता को यह तय करने देता है कि वह आधार कैसे लागू हो।
- सिर्फ़ जोड़ते न जाना, मौजूदा स्थिति से मिलाकर अपडेट करना: आर्टिफ़ैक्ट जीवंत दस्तावेज़ हैं, लॉग नहीं। जब कोई चरण दोबारा चले, तो हर मौजूदा एंट्री को मौजूदा सच्चाई से मिलाकर अपडेट करें: जो अब भी सही है उसे रखें, जो बदला है उसे दोबारा लिखें, और जो अब लागू नहीं होता उसे हटाएँ। बंद करना उसी मिलान की आख़िरी मंज़िल है।
- केवल रक्षा के लिए: SDH ऑडिट करता है, सुरक्षा मज़बूत करता है और पुष्टि करता है। यह कभी आक्रामक टूलिंग, बुरी नीयत से इस्तेमाल के लिए एक्सप्लॉइट, या नुक़सान पहुँचाने के लिए पकड़ से बचने की तकनीकें नहीं बनाता। दोहरे इस्तेमाल वाली सुरक्षा सामग्री सिर्फ़ साफ़ तौर पर रक्षात्मक और अधिकृत संदर्भ में ही स्वीकार्य है।
- स्पेक पहले, एजेंट से संचालित, सुरक्षा के लिए ढला हुआ: वर्कफ़्लो को एक आज़माए हुए ढाँचे से बनाएँ: टेम्पलेट, कमांड, सभी चरणों को दिशा देने वाले सुरक्षा सिद्धांत, और चरणों को चलाने वाला एजेंट। उस ढाँचे को रक्षा के मक़सद से दोबारा बनाएँ।