# Lagune > किसी भी कोडबेस के लिए Security-Driven Hardening Lagune एक ओपन सोर्स Security-Driven Hardening (SDH) वर्कफ़्लो है, जो केवल रक्षा के लिए बना है। यह आपके AI एजेंट को किसी भी भाषा के किसी भी कोडबेस की सुरक्षा हर पल मज़बूत करने में मदद करता है: charter आपके बनाना शुरू करने से पहले सुरक्षा नियम तय करता है, यूनिवर्सल /lagune कमांड लिखते समय ही काम की सुरक्षा मज़बूत करती है, और पाँच चरणों वाला Blue Team फ़्लो पहचानता है कि आपका सिस्टम असल में क्या करता है और उस संदर्भ के लिए ज़रूरी सुधार आगे बढ़ाता है। इसकी कमांड skills CLI से आपके एजेंट में इंस्टॉल होती हैं, और इसके लिए किसी API कुंजी की ज़रूरत नहीं है। --- # इंस्टॉल करें: किसी भी AI एजेंट के लिए सुरक्षा हार्डनिंग > किसी भी प्रोजेक्ट में Lagune इंस्टॉल करें, जहाँ आपका एजेंट सपोर्ट करे वहाँ प्लगइन के रूप में और बाकी जगह skills CLI से, फिर अपने प्रोजेक्ट के हिसाब से सुरक्षा विशेषज्ञताएँ चुनें। कैनोनिकल: https://lagune.ai/hi-IN/docs भाषा: hi-IN मूल: https://lagune.ai/docs आख़िरी अपडेट: 2026-11-06 **Lagune** आपके AI एजेंट को प्रोजेक्ट ज़्यादा सुरक्षित बनाने में मदद करता है। आप इसे अपने कोड पर चलाते हैं, एजेंट समझता है कि आपका सिस्टम असल में क्या करता है, और फिर आपको वह सुरक्षा का काम कराता है जो उस सिस्टम के लिए मायने रखता है। **Lagune** [Security-Driven Hardening (SDH)](https://lagune.ai/hi-IN/docs/references/paper) पद्धति का पहला प्रोजेक्ट है। **ओपन सोर्स का साथ दें** **Lagune** पसंद आया? [**GitHub** पर हमें एक ⭐ दें](https://github.com/wellwelwel/lagune) ## अपना एजेंट चुनें - [Claude Code](https://lagune.ai/hi-IN/docs/install/claude-code): Anthropic का एजेंटिक कोडिंग टूल - [Codex](https://lagune.ai/hi-IN/docs/install/codex): OpenAI का कोडिंग एजेंट - [Cursor](https://lagune.ai/hi-IN/docs/install/cursor): AI कोड एडिटर - [GitHub Copilot](https://lagune.ai/hi-IN/docs/install/github-copilot-cli): GitHub का AI पेयर प्रोग्रामर - [Gemini CLI](https://lagune.ai/hi-IN/docs/install/gemini-cli): Google का ओपन सोर्स टर्मिनल एजेंट - [Antigravity](https://lagune.ai/hi-IN/docs/install/antigravity-cli): Google का एजेंटिक डेवलपमेंट प्लेटफ़ॉर्म - [OpenCode](https://lagune.ai/hi-IN/docs/install/opencode): ओपन सोर्स कोडिंग एजेंट - [Devin for Terminal](https://lagune.ai/hi-IN/docs/install/devin-cli): Cognition का टर्मिनल एजेंट - [Factory Droid](https://lagune.ai/hi-IN/docs/install/factory-droid): Factory का सॉफ़्टवेयर डेवलपमेंट एजेंट - [Grok Build](https://lagune.ai/hi-IN/docs/install/grok-build): xAI का कोडिंग एजेंट - [Qwen Code](https://lagune.ai/hi-IN/docs/install/qwen-code): Qwen का टर्मिनल कोडिंग एजेंट - [Kimi Code](https://lagune.ai/hi-IN/docs/install/kimi-code): Moonshot AI का कोडिंग एजेंट - [Muse Code](https://lagune.ai/hi-IN/docs/install/muse-code): Meta का कोडिंग एजेंट - [Pi](https://lagune.ai/hi-IN/docs/install/pi): एक मिनिमल टर्मिनल कोडिंग एजेंट - [Hermes Agent](https://lagune.ai/hi-IN/docs/install/hermes-agent): Nous Research का ओपन सोर्स एजेंट - [यूनिवर्सल](https://lagune.ai/hi-IN/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed और 66 अन्य **जानकारी** - **Lagune** अंदर से **Node.js** पर चलता है, लेकिन आप अपनी पसंद की कोई भी भाषा इस्तेमाल कर सकते हैं। - पूरी तरह ऑफ़लाइन चलाने के लिए `npm i -D lagune@0.18.1` से अपने प्रोजेक्ट में **Lagune** इंस्टॉल करें। ## श्रेणियाँ **Lagune** का सुरक्षा ज्ञान [**विशेषज्ञताओं**](https://lagune.ai/hi-IN/docs/catalog) के रूप में आता है, जो [**श्रेणियों**](https://lagune.ai/hi-IN/docs/categories) में बँटी हैं। - **OWASP** (`owasp`): OWASP जिन ऐप्लिकेशन सुरक्षा जोखिमों पर नज़र रखता है, उनके ख़िलाफ़ मज़बूत करें: इंजेक्शन, कमज़ोर एक्सेस कंट्रोल (Broken Access Control), ऑथेंटिकेशन और क्रिप्टो की विफलताएँ - **इन्फ़्रास्ट्रक्चर** (`infra`): कंटेनर, वर्कलोड और सर्वरलेस कॉन्फ़िगरेशन को मज़बूत करें: Dockerfile, Compose, Pod सुरक्षा, FaaS IAM और ट्रिगर - **AI / LLM** (`ai`): प्रॉम्प्ट इंजेक्शन और टूल, एजेंट, रिट्रीवल और MCP की असुरक्षित वायरिंग के ख़िलाफ़ AI और LLM इंटीग्रेशन को मज़बूत करें - **Lovable** (`lovable`): AI से बने Supabase ऐप (Lovable और इसी तरह के) मज़बूत करें: RLS की कमियाँ, लीक हुई service_role कुंजियाँ और असुरक्षित डिफ़ॉल्ट - **JavaScript** (`javascript`): JavaScript और उसके रनटाइम को eval और child_process RCE, पाथ ट्रैवर्सल और प्रोटोटाइप पॉल्यूशन के ख़िलाफ़ मज़बूत करें - **Python** (`python`): Python को pickle और YAML डीसीरियलाइज़ेशन RCE, str.format स्ट्रिंग ट्रैवर्सल और क्लास पॉल्यूशन के ख़िलाफ़ मज़बूत करें - **Rust** (`rust`): Rust को अनसाउंड unsafe API, transmute के ग़लत इस्तेमाल, इंटीजर ओवरफ़्लो और FFI बाउंड्री पर अपरिभाषित व्यवहार के ख़िलाफ़ मज़बूत करें - **Java** (`java`): Java को ObjectInputStream डीसीरियलाइज़ेशन गैजेट चेन के ख़िलाफ़ मज़बूत करें, जो रिमोट कोड एक्ज़ीक्यूशन तक पहुँचती हैं - **Ruby** (`ruby`): Ruby को Marshal.load और YAML डीसीरियलाइज़ेशन गैजेट चेन के ख़िलाफ़ मज़बूत करें, जो रिमोट कोड एक्ज़ीक्यूशन तक पहुँचती हैं - **PHP** (`php`): PHP को टाइप जगलिंग से ऑथेंटिकेशन बायपास, ऑब्जेक्ट इंजेक्शन गैजेट चेन और असुरक्षित डिफ़ॉल्ट कॉन्फ़िगरेशन के ख़िलाफ़ मज़बूत करें - **Go** (`go`): Go को typed-nil इंटरफ़ेस बग, goroutine डेटा रेस और सुरक्षा से जुड़े कोड पाथ पर असुरक्षित कॉन्करेंसी के ख़िलाफ़ मज़बूत करें - **C / C++** (`c-cpp`): C और C++ को फ़ॉर्मैट-स्ट्रिंग बग, बफ़र ओवरफ़्लो और आउट-ऑफ़-बाउंड्स राइट के ख़िलाफ़ मज़बूत करें, जिनसे कोड एक्ज़ीक्यूशन मुमकिन होता है - **.NET** (`dotnet`): .NET और C# को BinaryFormatter डीसीरियलाइज़ेशन RCE और XSS तक पहुँचने वाले एनकोडर बायपास के ख़िलाफ़ मज़बूत करें आप जो श्रेणियाँ चुनें, उनकी कुंजियों के साथ `npx lagune write add --categories` चलाएँ। **टिप** हर प्रोजेक्ट `owasp` श्रेणी से शुरू होता है, और [`/lagune-charter`](https://lagune.ai/hi-IN/docs/commands/charter) कमांड प्रोजेक्ट को पढ़कर वे श्रेणियाँ जोड़ती है जिनका आधार उसे प्रोजेक्ट में मिलता है। ## ज़रूरतें आपके सिस्टम पर [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager) इंस्टॉल होना चाहिए। ## बैज लगाएँ ✨ **Lagune** इस्तेमाल कर रहे हैं? अपनी **README** में एक बैज जोड़ें: **दो रंग** ![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952) ```md [![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952)](https://lagune.ai) ``` ![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952) ```md [![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952)](https://lagune.ai) ``` ![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952) ```md [![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952)](https://lagune.ai) ``` **एक रंग** ![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white) ```md [![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white) ```md [![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white) ```md [![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ## आगे क्या देखें कि **Lagune** की हर [**स्किल**](https://lagune.ai/hi-IN/docs/get-started/commands) क्या करती है। ## अक्सर पूछे जाने वाले सवाल ### Lagune क्या है? Lagune एक ओपन सोर्स, केवल रक्षा के लिए बना सुरक्षा वर्कफ़्लो है, जो आपके AI एजेंट को किसी भी कोडबेस की सुरक्षा मज़बूत करने में मदद करता है। आप इसे अपने कोड पर चलाते हैं, यह पहचानता है कि आपका सिस्टम असल में क्या करता है, और फिर उस संदर्भ के लिए ज़रूरी सुरक्षा सुधारों में मार्गदर्शन करता है। ### Lagune कैसे इंस्टॉल करूँ? अपना एजेंट चुनें: Claude Code, GitHub Copilot CLI, Muse Code, Antigravity CLI, Cursor, Kimi Code, OpenCode, Codex CLI, Factory Droid, Grok Build, Devin CLI और Hermes Agent में Lagune प्लगइन के रूप में इंस्टॉल होता है, Gemini CLI और Qwen Code में एक्सटेंशन के रूप में, Pi में पैकेज के रूप में, और बाकी किसी भी एजेंट में npx skills add wellwelwel/lagune से। यह नए और पुराने, दोनों तरह के प्रोजेक्ट में काम करता है। ### क्या Lagune को API कुंजी चाहिए? नहीं। यह आपके अपने AI एजेंट के ज़रिए चलता है, इसलिए किसी API कुंजी की ज़रूरत नहीं है। ### इसकी ज़रूरतें क्या हैं? आपके सिस्टम पर Node.js (LTS) इंस्टॉल होना चाहिए। ### Lagune कौन-सी प्रोग्रामिंग भाषाएँ सपोर्ट करता है? सभी। Lagune अंदर से Node.js पर चलता है, लेकिन यह किसी भी प्रोग्रामिंग भाषा में लिखे प्रोजेक्ट का ऑडिट करता है और उसकी सुरक्षा मज़बूत करता है। ### Lagune मेरे प्रोजेक्ट में क्या जोड़ता है? एक .lagune/ डायरेक्टरी, जिसमें आपके प्रोजेक्ट की सुरक्षा स्थिति रहती है। इसे वह पहली कमांड बनाती है जो कुछ लिखती है। skills CLI स्लैश कमांड भी प्रोजेक्ट में इंस्टॉल करता है, जहाँ से आपका एजेंट उन्हें पढ़ता है, जबकि प्लगइन उन्हें एजेंट के अंदर ही रखता है। ### Lagune को अपडेट कैसे करूँ? जैसे इंस्टॉल किया था, वैसे ही। हर एजेंट का इंस्टॉल पेज बताता है कि वहाँ Lagune को कैसे अपडेट करें, और skills CLI इसे npx skills update से अपडेट करता है। आपके सुरक्षा सिद्धांत, चरणों के आर्टिफ़ैक्ट और आपकी अपनी विशेषज्ञताएँ जैसी हैं वैसी ही रहती हैं। ### कोई प्रोजेक्ट कौन-सी विशेषज्ञताएँ इस्तेमाल करता है? उसकी श्रेणियों की बिल्ट-इन विशेषज्ञताएँ, और साथ में उसकी अपनी। charter चरण प्रोजेक्ट को पढ़कर वे श्रेणियाँ दर्ज करता है जिनका आधार उसे मिलता है, और npx lagune write add --categories से आप उन्हें बदल सकते हैं। ### क्या प्रोजेक्ट सुरक्षित करने से पहले मुझे उसे पूरा बना लेना होगा? नहीं। /lagune कमांड काम लिखे जाते समय ही उसकी सुरक्षा मज़बूत करती है: यह कोई भी प्रॉम्प्ट लेती है, आपने जो माँगा वह बनाती है, और सुरक्षा सिद्धांतों के मार्गदर्शन में सुरक्षित डिफ़ॉल्ट के साथ उसे मज़बूत करती है। जो पहले से मौजूद है, उसका ऑडिट पाँच चरणों वाला Blue Team फ़्लो करता है। ### क्या Lagune किसी मौजूदा प्रोजेक्ट का ऑडिट कर सकता है? हाँ। पाँच चरणों वाला Blue Team फ़्लो पहले से मौजूद कोड का ऑडिट करता है: charter आपके सुरक्षा नियम तय करता है, detect पहचानता है कि सिस्टम क्या करता है और जोखिम कहाँ हैं, plan हर निष्कर्ष को स्कोर देकर उसके साथ एक सुधार जोड़ता है, harden सुधार लागू करता है, और verify साबित करता है कि वे कारगर हैं, फिर उन्हें बंद करता है। ### Lagune इस्तेमाल करने और एजेंट से सीधे कमज़ोरियाँ और सुरक्षा खामियाँ ढूँढने को कहने में क्या फ़र्क है? अपने आप कोड पढ़ने वाला एजेंट वह ढूँढ लेता है जो कमज़ोरी जैसा दिखता है, और जो नियंत्रण जैसा दिखता है उसे छोड़ देता है। ब्लॉक किए गए पतों की एक सूची देखकर लगता है कि किसी ने जोखिम पहले ही संभाल लिया है, इसलिए कोई नहीं जाँचता कि वह सूची ज़्यादातर पतों को छोड़ देती है, और कोड शिप हो जाता है। Lagune यह डिफ़ॉल्ट सोच उलट देता है: कोड में पहले से मौजूद कोई भी बचाव तब तक साबित नहीं माना जाता जब तक उसकी जाँच न हो जाए, कैटलॉग की हर विशेषज्ञता पर साफ़ फ़ैसला दिया जाता है, और verify चरण यह पूछता है कि जोखिम खत्म हुआ या नहीं, यह नहीं कि नियंत्रण मौजूद है या नहीं। हर निष्कर्ष कई रन के बाद भी एक ही ट्रैक किया गया आइटम रहता है, इसलिए उसे बंद हुआ साबित करके निपटाया जा सकता है, जबकि सीधे पूछने पर हर बार एक अलग रिपोर्ट मिलती है और तुलना करने को कुछ नहीं होता। ### Lagune के साथ डेवलप करने और एजेंट से सीधे सुरक्षित कोड लिखने को कहने में क्या फ़र्क है? सिर्फ़ सुरक्षित कोड माँगने पर "सुरक्षित" का मतलब एजेंट तय करता है, और यह मान लिया जाता है कि आपको पता है क्या माँगना है। सुरक्षा की ज़रूरत अक्सर आपके अनुरोध में पहले से छिपी होती है, और न आप उसे देखते हैं न एजेंट: ऐसा पेज माँगना जो यूज़र को उसकी पहुँच वाले कोर्स दिखाए, अपने आप में एक ऑथराइज़ेशन नियम है, और जो जाँच कभी लिखी ही नहीं गई, उसका कोड में कोई निशान नहीं रहता जिस पर किसी की नज़र पड़े। /lagune कमांड पहली लाइन लिखे जाने से पहले आपके सुरक्षा सिद्धांत और जो बनने वाला है उससे मेल खाती विशेषज्ञताएँ लोड करती है, फिर नतीजे को उसी बचाव के आधार पर दोबारा पढ़ती है जिसका उसने इस्तेमाल किया। सुरक्षित तरीका असुरक्षित तरीके से शायद ही कभी महँगा पड़ता है, इसलिए नतीजा इस पर टिका है कि सही तरीका कौन-सा है, यह पता हो, और यही जानकारी शुरुआत में ही मिल जाती है। ### क्या Lagune DAST (Dynamic Application Security Testing) चलाता है या मेरे चल रहे एप्लिकेशन को टेस्ट करता है? नहीं। Lagune सिर्फ़ कोड पढ़ता है, आपका सिस्टम कभी नहीं चलाता और न उसे जान-बूझकर गढ़े गए अनुरोध भेजता है। verify चरण पुष्टि करता है कि सोर्स कोड में नियंत्रण मौजूद है और सही है, और यह इस सवाल से अलग है कि वह किसी लाइव सिस्टम पर हमले के सामने टिकता है या नहीं, इसलिए "cannot tell from the code" (कोड से तय नहीं हो सकता) चुपचाप पास कर देने के बजाय एक जायज़ फ़ैसला है। DAST रनटाइम वाले सवाल का जवाब देता है और Lagune सोर्स कोड वाले सवाल का, इसलिए कोई भी दूसरे की जगह नहीं लेता। वैकल्पिक prove कमांड भी इसी सीमा में रहती है: उसके टेस्ट सुरक्षित व्यवहार की जाँच करते हैं, कभी किसी हमले के पेलोड की नहीं। ### क्या Lagune पेनटेस्ट (penetration test) की जगह ले सकता है? नहीं, बिल्कुल नहीं! पेनटेस्ट एक अधिकृत काम है, जिसमें कोई पेशेवर आपके लाइव सिस्टम पर अपनी समझ से परखता है, निष्कर्षों को आपस में जोड़ता है और उस बिज़नेस लॉजिक की पड़ताल करता है जिसे अटैक सरफ़ेस के हिसाब से बना कोई नियम नहीं बताता। पेनटेस्ट के निष्कर्ष detect चरण को सौंपी गई चिंताओं के रूप में Lagune के Blue Team फ़्लो में आ सकते हैं, ताकि पेशेवर ने जो बताया उसकी योजना बने, उसकी सुरक्षा मज़बूत हो और उसका सत्यापन हो। ## सुरक्षा नीति कृपया [SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md) देखें। ## लाइसेंस **Lagune** [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE) के तहत उपलब्ध है। Copyright © 2026-present [Weslley Araújo](https://github.com/wellwelwel) और [योगदानकर्ता](https://github.com/wellwelwel/lagune/graphs/contributors)। --- # Antigravity CLI में Lagune को प्लगइन के रूप में इंस्टॉल करें > Antigravity CLI में Lagune को प्लगइन के रूप में इंस्टॉल करें, उसे अपडेट रखें, और उसके इंजन को पहले से अनुमति दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/antigravity-cli भाषा: hi-IN मूल: https://lagune.ai/docs/install/antigravity-cli आख़िरी अपडेट: 2026-11-06 अपने टर्मिनल से प्लगइन इंस्टॉल करें: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## अपडेट **Lagune** को अपडेट करने के लिए उसे फिर से इंस्टॉल करें: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## कमांड कमांड प्लगइन के नाम के साथ टाइप करें, जैसे `/lagune:lagune-charter`, जो `/lagune-charter` कमांड है। --- **अनुमतियाँ** इंजन दो टूल के ज़रिए चलता है: `lagune_read` टूल सिर्फ़ आपका प्रोजेक्ट पढ़ता है, और `lagune_write` टूल सिर्फ़ `.lagune/` फ़ोल्डर में लिखता है। सेशन के पहले मैसेज के रूप में भेजी गई कमांड इन टूल के लोड होने से पहले चलती है, इसलिए वह इनकी जगह **npx** का इस्तेमाल करती है। टूल और **npx** को पहले से अनुमति देने के लिए, ये नियम `~/.gemini/antigravity-cli/settings.json` फ़ाइल में जोड़ें: ```json { "permissions": { "allow": [ "mcp(lagune_lagune/lagune_read)", "mcp(lagune_lagune/lagune_write)", "command(regex:npx --yes lagune@[0-9.]+)" ] } } ``` ## अक्सर पूछे जाने वाले सवाल ### Antigravity CLI में Lagune कैसे इंस्टॉल करें? agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity चलाएँ। ### Antigravity CLI में Lagune को कैसे अपडेट करें? agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity फिर से चलाएँ। ### Antigravity CLI में Lagune की कमांड कैसे चलाएँ? इन्हें प्लगइन के नाम के साथ टाइप करें, जैसे /lagune:lagune-charter। ### क्या Antigravity CLI बिना अनुमति माँगे Lagune चला सकता है? हाँ। Antigravity CLI की सेटिंग में mcp(lagune_lagune/lagune_read), mcp(lagune_lagune/lagune_write), और command(regex:npx --yes lagune@[0-9.]+) को अनुमति दें। npx वाला नियम उस कमांड के लिए है जो सेशन के पहले मैसेज के रूप में भेजी जाती है। --- # Claude Code में Lagune को प्लगइन के रूप में इंस्टॉल करें > Claude Code में Lagune को प्लगइन के रूप में इंस्टॉल करें, चाहे टर्मिनल हो, एक्सटेंशन हो या डेस्कटॉप ऐप, उसे अपडेट रखें, और उसके इंजन को पहले से अनुमति दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/claude-code भाषा: hi-IN मूल: https://lagune.ai/docs/install/claude-code आख़िरी अपडेट: 2026-11-06 **टर्मिनल** अपने टर्मिनल से प्लगइन इंस्टॉल करें: ```bash claude plugin install lagune --marketplace wellwelwel/lagune ``` या किसी **Claude Code** सेशन से: ```text /plugin marketplace add wellwelwel/lagune /plugin install lagune@lagune ``` **एक्सटेंशन** - `/plugin` टाइप करें और **Manage plugins** चुनें। - **Marketplaces** टैब में `wellwelwel/lagune` जोड़ें। - **Plugins** टैब में `lagune` इंस्टॉल करें। **डेस्कटॉप** - **Lagune** को टर्मिनल या एक्सटेंशन से इंस्टॉल करें, और एक्सटेंशन में **Install for you** चुनें। - डेस्कटॉप ऐप में नया सेशन शुरू करें। यह ऐप वे प्लगइन लोड करता है जिन्हें आप अपने लिए इंस्टॉल करते हैं। ## अपडेट **टर्मिनल** **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash claude plugin marketplace update lagune claude plugin update lagune@lagune ``` इसे हमेशा अपडेट रखने के लिए, `lagune` मार्केटप्लेस के लिए `/plugin` में **Enable auto-update** चुनें। **एक्सटेंशन** - `/plugin` टाइप करें और **Manage plugins** चुनें। - **Marketplaces** टैब खोलें। - `lagune` पर रिफ़्रेश आइकन चुनें। **डेस्कटॉप** - **Lagune** को टर्मिनल या एक्सटेंशन से अपडेट करें। - डेस्कटॉप ऐप में नया सेशन शुरू करें। ## कमांड कमांड उनके नाम से टाइप करें, जैसे `/lagune-charter`, या प्लगइन के नाम के साथ, जैसे `/lagune:lagune-charter`। --- **अनुमतियाँ** इंजन दो टूल के ज़रिए चलता है: `lagune_read` टूल सिर्फ़ आपका प्रोजेक्ट पढ़ता है, और `lagune_write` टूल सिर्फ़ `.lagune/` फ़ोल्डर में लिखता है। इन्हें पहले से अनुमति देने के लिए, ये नियम एक प्रोजेक्ट के लिए `.claude/settings.json` फ़ाइल में जोड़ें, या सभी प्रोजेक्ट के लिए `~/.claude/settings.json` फ़ाइल में: ```json { "permissions": { "allow": [ "mcp__plugin_lagune_lagune__lagune_read", "mcp__plugin_lagune_lagune__lagune_write" ] } } ``` जब इंजन **npx** के ज़रिए चलता है, जैसे **skills.sh** से इंस्टॉल करने पर, तो `Bash(npx --yes lagune@*)` को अनुमति दें। सैंडबॉक्स चालू हो, तो `registry.npmjs.org` को `sandbox.network.allowedDomains` में भी जोड़ें। ## अक्सर पूछे जाने वाले सवाल ### Claude Code में Lagune कैसे इंस्टॉल करें? claude plugin install lagune --marketplace wellwelwel/lagune चलाएँ। सेशन या एक्सटेंशन में, प्लगइन मैनेजर से wellwelwel/lagune मार्केटप्लेस जोड़ें और lagune इंस्टॉल करें। जब आप इसे टर्मिनल या एक्सटेंशन में अपने लिए इंस्टॉल कर लेते हैं, तो डेस्कटॉप ऐप भी इसे लोड कर लेता है। ### Claude Code में Lagune को कैसे अपडेट करें? claude plugin marketplace update lagune चलाएँ, फिर claude plugin update lagune@lagune चलाएँ, या /plugin में lagune मार्केटप्लेस के लिए Enable auto-update चुनें। एक्सटेंशन में, /plugin से Manage plugins खोलें और lagune मार्केटप्लेस पर रिफ़्रेश आइकन चुनें। डेस्कटॉप ऐप अपने अगले सेशन में अपडेट लोड कर लेता है। ### Claude Code में Lagune की कमांड कैसे चलाएँ? इन्हें उनके नाम से टाइप करें, जैसे /lagune-charter, या प्लगइन के नाम के साथ, जैसे /lagune:lagune-charter। ### क्या Claude Code बिना अनुमति माँगे Lagune चला सकता है? हाँ। अपनी Claude Code सेटिंग में mcp__plugin_lagune_lagune__lagune_read और mcp__plugin_lagune_lagune__lagune_write को अनुमति दें, और जब इंजन npx के ज़रिए चलता है, तो Bash(npx --yes lagune@*) को भी। --- # Codex CLI में Lagune को प्लगइन के रूप में इंस्टॉल करें > Codex CLI में Lagune को प्लगइन के रूप में इंस्टॉल करें, उसे अपडेट रखें, और उसका इंजन सैंडबॉक्स के अंदर चलाएँ। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/codex भाषा: hi-IN मूल: https://lagune.ai/docs/install/codex आख़िरी अपडेट: 2026-11-07 अपने टर्मिनल से प्लगइन इंस्टॉल करें: ```bash codex plugin marketplace add wellwelwel/lagune codex plugin add lagune@lagune ``` ## अपडेट **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash codex plugin marketplace upgrade lagune ``` ## कमांड `$` टाइप करें, फिर प्लगइन के नाम के साथ कमांड, और उसके बाद अपना इनपुट, जैसे `$lagune:lagune-charter`, जो `/lagune-charter` कमांड है। `$` टाइप करने पर कमांड की सूची दिखती है, और किसी एक को चुनने पर उसका पूरा नाम भर जाता है। --- **सैंडबॉक्स** **Codex** के सैंडबॉक्स में नेटवर्क एक्सेस नहीं है। इंजन को अपने टर्मिनल से अपने प्रोजेक्ट में इंस्टॉल करें, पहली बार और हर अपडेट के बाद: ```bash npm i -D lagune@0.18.1 ``` ## अक्सर पूछे जाने वाले सवाल ### Codex CLI में Lagune कैसे इंस्टॉल करें? codex plugin marketplace add wellwelwel/lagune चलाएँ, फिर codex plugin add lagune@lagune चलाएँ। ### Codex CLI में Lagune को कैसे अपडेट करें? codex plugin marketplace upgrade lagune चलाएँ। ### Codex CLI में Lagune की कमांड कैसे चलाएँ? $ टाइप करें, फिर प्लगइन के नाम के साथ कमांड, और उसके बाद अपना इनपुट, जैसे $lagune:lagune-charter। ### क्या Codex के सैंडबॉक्स के अंदर Lagune काम करता है? हाँ, बशर्ते आप अपने टर्मिनल से npm i -D lagune@0.18.1 चलाकर इंजन को अपने प्रोजेक्ट में इंस्टॉल करें, पहली बार और हर अपडेट के बाद। --- # Cursor में Lagune को प्लगइन के रूप में इंस्टॉल करें > Cursor और Cursor CLI में Lagune को प्लगइन के रूप में इंस्टॉल करें, उसे अपडेट रखें, और उसके इंजन को पहले से अनुमति दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/cursor भाषा: hi-IN मूल: https://lagune.ai/docs/install/cursor आख़िरी अपडेट: 2026-11-06 **Cursor** - **Customize** खोलें। - **From GitHub Repository** चुनें और `https://github.com/wellwelwel/lagune` डालें। - **Lagune** पर **Install** चुनें, फिर दायरा चुनें: प्रोजेक्ट या यूज़र। **Cursor CLI** - अपने टर्मिनल से मार्केटप्लेस जोड़ें: ```bash agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - `/plugins` कमांड को `agent` सेशन में टाइप करें। - **Lagune** इंस्टॉल करें। अगर **Lagune** पहले से **Claude Code** में इंस्टॉल है, तो **Cursor CLI** उसे वहीं से लोड कर लेता है। ## अपडेट **Cursor** - **Customize** खोलें। - `lagune` मार्केटप्लेस पर **Refresh** चुनें। **Cursor CLI** - अपने टर्मिनल से मार्केटप्लेस को बदलें: ```bash agent plugin marketplace remove lagune agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - `/plugins` कमांड को `agent` सेशन में टाइप करें। - **Lagune** फिर से इंस्टॉल करें। ## कमांड कमांड उनके नाम से टाइप करें, जैसे `/lagune-charter`। --- **अनुमतियाँ** **Cursor** में कमांड इंजन को **npx** के ज़रिए चलाती हैं, जिसे डिफ़ॉल्ट Auto-review मोड बिना पूछे अनुमति देता है। **Cursor CLI** में इंजन दो टूल के ज़रिए चलता है: `lagune_read` टूल सिर्फ़ आपका प्रोजेक्ट पढ़ता है, और `lagune_write` टूल सिर्फ़ `.lagune/` फ़ोल्डर में लिखता है। इन्हें पहले से अनुमति देने के लिए, ये नियम एक प्रोजेक्ट के लिए `.cursor/cli.json` फ़ाइल में जोड़ें, या सभी प्रोजेक्ट के लिए `~/.cursor/cli-config.json` फ़ाइल में: ```json { "permissions": { "allow": [ "Mcp(plugin-lagune-lagune:lagune_read)", "Mcp(plugin-lagune-lagune:lagune_write)" ] } } ``` जब इंजन **npx** के ज़रिए चलता है, जैसे **skills.sh** से इंस्टॉल करने पर, तो `Shell(npx:--yes lagune@*)` को अनुमति दें। ## अक्सर पूछे जाने वाले सवाल ### Cursor में Lagune कैसे इंस्टॉल करें? Cursor में, Customize खोलें, From GitHub Repository चुनें, https://github.com/wellwelwel/lagune डालें, और Lagune इंस्टॉल करें। Cursor CLI में, agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor चलाएँ, फिर /plugins से Lagune इंस्टॉल करें। ### Cursor में Lagune को कैसे अपडेट करें? Cursor में, Customize में lagune मार्केटप्लेस पर Refresh चुनें। Cursor CLI में, lagune मार्केटप्लेस हटाएँ, उसे फिर से जोड़ें, और फिर /plugins से Lagune दोबारा इंस्टॉल करें। ### Cursor में Lagune की कमांड कैसे चलाएँ? इन्हें उनके नाम से टाइप करें, जैसे /lagune-charter। ### क्या Cursor बिना अनुमति माँगे Lagune चला सकता है? हाँ। Cursor का डिफ़ॉल्ट Auto-review मोड इसे पहले से अनुमति देता है। Cursor CLI में, Mcp(plugin-lagune-lagune:lagune_read) और Mcp(plugin-lagune-lagune:lagune_write) को अनुमति दें, और जब इंजन npx के ज़रिए चलता है, तो Shell(npx:--yes lagune@*) को भी। --- # Devin CLI में Lagune को प्लगइन के रूप में इंस्टॉल करें > Devin CLI में Lagune को प्लगइन के रूप में इंस्टॉल करें, और उसे अपडेट रखें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/devin-cli भाषा: hi-IN मूल: https://lagune.ai/docs/install/devin-cli आख़िरी अपडेट: 2026-11-06 **Devin** में साइन इन करें, फिर अपने टर्मिनल से प्लगइन इंस्टॉल करें: ```bash devin auth login devin plugins install wellwelwel/lagune ``` ## अपडेट **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash devin plugins update lagune ``` ## कमांड कमांड प्लगइन के नाम के साथ टाइप करें, जैसे `/lagune:lagune-charter`, जो `/lagune-charter` कमांड है। `/` मेन्यू में भी इनकी सूची दिखती है। ## अक्सर पूछे जाने वाले सवाल ### Devin CLI में Lagune कैसे इंस्टॉल करें? devin auth login से साइन इन करें, फिर devin plugins install wellwelwel/lagune चलाएँ। ### Devin CLI में Lagune को कैसे अपडेट करें? devin plugins update lagune चलाएँ। ### Devin CLI में Lagune की कमांड कैसे चलाएँ? इन्हें प्लगइन के नाम के साथ टाइप करें, जैसे /lagune:lagune-charter। / मेन्यू में भी इनकी सूची दिखती है। --- # Factory Droid में Lagune को प्लगइन के रूप में इंस्टॉल करें > Factory Droid में Lagune को प्लगइन के रूप में इंस्टॉल करें, उसे अपडेट रखें, और उसके इंजन के टूल को अनुमति दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/factory-droid भाषा: hi-IN मूल: https://lagune.ai/docs/install/factory-droid आख़िरी अपडेट: 2026-11-07 अपने टर्मिनल से प्लगइन इंस्टॉल करें: ```bash droid plugin marketplace add wellwelwel/lagune droid plugin install lagune@lagune ``` ## अपडेट **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash droid plugin marketplace update lagune droid plugin update lagune@lagune ``` ## कमांड कमांड उनके नाम से टाइप करें, जैसे `/lagune-charter`। ## अक्सर पूछे जाने वाले सवाल ### Factory Droid में Lagune कैसे इंस्टॉल करें? droid plugin marketplace add wellwelwel/lagune चलाएँ, फिर droid plugin install lagune@lagune चलाएँ। ### Factory Droid में Lagune को कैसे अपडेट करें? droid plugin marketplace update lagune चलाएँ, फिर droid plugin update lagune@lagune चलाएँ। ### Factory Droid में Lagune की कमांड कैसे चलाएँ? इन्हें उनके नाम से टाइप करें, जैसे /lagune-charter। ### क्या Factory Droid बिना अनुमति माँगे Lagune चला सकता है? हाँ। जब Factory Droid पूछे, तो lagune_read और lagune_write के लिए हमेशा अनुमति देने का विकल्प चुनें। lagune मार्केटप्लेस का नया कमिट सिंक करने के बाद यह फिर से पूछता है। --- # Gemini CLI में Lagune को एक्सटेंशन के रूप में इंस्टॉल करें > Gemini CLI में Lagune को एक्सटेंशन के रूप में इंस्टॉल करें, उसे अपडेट रखें, और उसके इंजन को पहले से अनुमति दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/gemini-cli भाषा: hi-IN मूल: https://lagune.ai/docs/install/gemini-cli आख़िरी अपडेट: 2026-11-06 अपने टर्मिनल से एक्सटेंशन इंस्टॉल करें: ```bash gemini extensions install https://github.com/wellwelwel/lagune ``` ## अपडेट **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash gemini extensions update lagune ``` इसे हमेशा अपडेट रखने के लिए, इसे `--auto-update` के साथ इंस्टॉल करें। ## कमांड कमांड एक्सटेंशन के नाम के साथ टाइप करें, जैसे `/lagune:lagune-charter`, जो `/lagune-charter` कमांड है। --- **अनुमतियाँ** इंजन दो टूल के ज़रिए चलता है: `lagune_read` टूल सिर्फ़ आपका प्रोजेक्ट पढ़ता है, और `lagune_write` टूल सिर्फ़ `.lagune/` फ़ोल्डर में लिखता है। **Gemini CLI** इन्हें सिर्फ़ भरोसेमंद फ़ोल्डर में शुरू करता है। इन्हें पहले से अनुमति देने के लिए, यह नियम `~/.gemini/policies/lagune.toml` फ़ाइल के रूप में सेव करें: ```toml [[rule]] mcpName = "lagune" toolName = ["lagune_read", "lagune_write"] decision = "allow" priority = 100 ``` जब इंजन **npx** के ज़रिए चलता है, जैसे **skills.sh** से इंस्टॉल करने पर, तो उसी फ़ाइल में यह नियम भी जोड़ें: ```toml [[rule]] toolName = "run_shell_command" commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s' decision = "allow" priority = 100 ``` ## अक्सर पूछे जाने वाले सवाल ### Gemini CLI में Lagune कैसे इंस्टॉल करें? gemini extensions install https://github.com/wellwelwel/lagune चलाएँ। ### Gemini CLI में Lagune को कैसे अपडेट करें? gemini extensions update lagune चलाएँ, या एक्सटेंशन को --auto-update के साथ इंस्टॉल करें। ### Gemini CLI में Lagune की कमांड कैसे चलाएँ? इन्हें एक्सटेंशन के नाम के साथ टाइप करें, जैसे /lagune:lagune-charter। ### क्या Gemini CLI बिना अनुमति माँगे Lagune चला सकता है? हाँ। एक पॉलिसी नियम जोड़ें जो lagune सर्वर के lagune_read और lagune_write टूल को अनुमति दे, और साथ में run_shell_command के लिए एक नियम, जो npx --yes lagune@ और उसके बाद वर्शन वाली कमांड को अनुमति दे, जब इंजन npx के ज़रिए चलता है। --- # GitHub Copilot CLI पर Lagune को प्लगइन के रूप में इंस्टॉल करें > GitHub Copilot CLI पर Lagune को प्लगइन के रूप में इंस्टॉल करें और उसे अपडेट रखें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/github-copilot-cli भाषा: hi-IN मूल: https://lagune.ai/docs/install/github-copilot-cli आख़िरी अपडेट: 2026-11-06 अपने टर्मिनल से प्लगइन इंस्टॉल करें: ```bash copilot plugin marketplace add wellwelwel/lagune copilot plugin install lagune@lagune ``` एडिटर में, **GitHub Copilot** के लिए **Lagune** को [**skills.sh**](https://lagune.ai/hi-IN/docs/install/universal) से इंस्टॉल करें। ## अपडेट **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash copilot plugin marketplace update lagune copilot plugin update lagune@lagune ``` ## कमांड कमांड उनके नाम से टाइप करें, जैसे `/lagune-charter`। ## अक्सर पूछे जाने वाले सवाल ### GitHub Copilot CLI पर Lagune कैसे इंस्टॉल करें? copilot plugin marketplace add wellwelwel/lagune चलाएँ, फिर copilot plugin install lagune@lagune चलाएँ। ### GitHub Copilot CLI पर Lagune को कैसे अपडेट करें? copilot plugin marketplace update lagune चलाएँ, फिर copilot plugin update lagune@lagune चलाएँ। ### GitHub Copilot CLI पर Lagune की कमांड कैसे चलाएँ? उन्हें उनके नाम से टाइप करें, जैसे /lagune-charter कमांड। ### क्या मैं VS Code में GitHub Copilot के साथ Lagune इस्तेमाल कर सकता हूँ? हाँ। VS Code या किसी दूसरे एडिटर में, प्लगइन की जगह skills.sh से Lagune इंस्टॉल करें। --- # Grok Build पर Lagune को प्लगइन के रूप में इंस्टॉल करें > Grok Build पर Lagune को प्लगइन के रूप में इंस्टॉल करें, उसे अपडेट रखें, और उसके इंजन को पहले से अनुमति दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/grok-build भाषा: hi-IN मूल: https://lagune.ai/docs/install/grok-build आख़िरी अपडेट: 2026-11-06 अपने टर्मिनल से प्लगइन इंस्टॉल करें: ```bash grok plugin install wellwelwel/lagune@plugin-grok --trust ``` ## अपडेट **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash grok plugin update lagune ``` ## कमांड कमांड उनके नाम से टाइप करें, जैसे `/lagune-charter`, या प्लगइन के नाम के साथ, जैसे `/lagune:lagune-charter`। --- **अनुमतियाँ** इंजन दो टूल के ज़रिए चलता है: `lagune_read` टूल सिर्फ़ आपका प्रोजेक्ट पढ़ता है, और `lagune_write` टूल सिर्फ़ `.lagune/` फ़ोल्डर में लिखता है। इन्हें पहले से अनुमति देने के लिए, `~/.grok/config.toml` फ़ाइल में ये नियम जोड़ें: ```toml [permission] allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"] ``` जब इंजन **npx** के ज़रिए चलता है, जैसे **skills.sh** से इंस्टॉल करने पर, तो `Bash(npx --yes lagune@*)` नियम को अनुमति दें। ## अक्सर पूछे जाने वाले सवाल ### Grok Build पर Lagune कैसे इंस्टॉल करें? grok plugin install wellwelwel/lagune@plugin-grok --trust चलाएँ। ### Grok Build पर Lagune को कैसे अपडेट करें? grok plugin update lagune चलाएँ। ### Grok Build पर Lagune की कमांड कैसे चलाएँ? इन्हें उनके नाम से टाइप करें, जैसे /lagune-charter, या प्लगइन के नाम के साथ, जैसे /lagune:lagune-charter। ### क्या Grok Build अनुमति माँगे बिना Lagune चला सकता है? हाँ। Grok Build की कॉन्फ़िग में MCPTool(lagune__lagune_read) और MCPTool(lagune__lagune_write) को अनुमति दें, और जब इंजन npx के ज़रिए चलता है, तो Bash(npx --yes lagune@*) को भी। --- # Hermes Agent पर Lagune को प्लगइन के रूप में इंस्टॉल करें > Hermes Agent पर Lagune को प्लगइन के रूप में इंस्टॉल करें और उसे अपडेट रखें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/hermes-agent भाषा: hi-IN मूल: https://lagune.ai/docs/install/hermes-agent आख़िरी अपडेट: 2026-11-06 अपने टर्मिनल से प्लगइन इंस्टॉल करें: ```bash hermes plugins install wellwelwel/lagune --enable ``` - जब **Hermes Agent** अपने कैटलॉग से बाहर के प्लगइन की पुष्टि करने को कहे, तो **पुष्टि करें**। - जब वह रिपॉज़िटरी की **Node.js** डिपेंडेंसी इंस्टॉल करने की पेशकश करे, तो **मना करें**। ## अपडेट **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash hermes plugins update lagune ``` ## कमांड कमांड प्लगइन के नाम के साथ टाइप करें, जैसे `/lagune:lagune-charter`, जो `/lagune-charter` कमांड है, और `/lagune:lagune`, जो `/lagune` कमांड है। ## अक्सर पूछे जाने वाले सवाल ### Hermes Agent पर Lagune कैसे इंस्टॉल करें? hermes plugins install wellwelwel/lagune --enable चलाएँ। पूछे जाने पर प्लगइन की पुष्टि करें, और रिपॉज़िटरी की Node.js डिपेंडेंसी इंस्टॉल करने से मना करें। ### Hermes Agent पर Lagune को कैसे अपडेट करें? hermes plugins update lagune चलाएँ। ### Hermes Agent पर Lagune की कमांड कैसे चलाएँ? इन्हें प्लगइन के नाम के साथ टाइप करें, जैसे /lagune:lagune-charter और /lagune:lagune। --- # Kimi Code पर Lagune को प्लगइन के रूप में इंस्टॉल करें > Kimi Code पर Lagune को प्लगइन के रूप में इंस्टॉल करें और उसे अपडेट रखें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/kimi-code भाषा: hi-IN मूल: https://lagune.ai/docs/install/kimi-code आख़िरी अपडेट: 2026-11-06 **Kimi Code** सेशन में प्लगइन इंस्टॉल करें, **Trust and install** चुनें, फिर उसे लोड करने के लिए नया सेशन शुरू करें: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## अपडेट **Lagune** को अपडेट करने के लिए उसे फिर से इंस्टॉल करें: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## कमांड कमांड प्लगइन के नाम के साथ टाइप करें, जैसे `/lagune:lagune-charter`, जो `/lagune-charter` कमांड है। `/` मेन्यू में ये `/skill:lagune:lagune-charter` के रूप में दिखती हैं, और इस रूप में टाइप करने पर भी ये काम करती हैं। ## अक्सर पूछे जाने वाले सवाल ### Kimi Code पर Lagune कैसे इंस्टॉल करें? Kimi Code सेशन में /plugins install https://github.com/wellwelwel/lagune चलाएँ, Trust and install चुनें, फिर /new चलाएँ। ### Kimi Code पर Lagune को कैसे अपडेट करें? /plugins install https://github.com/wellwelwel/lagune फिर से चलाएँ, उसके बाद /new चलाएँ। ### Kimi Code पर Lagune की कमांड कैसे चलाएँ? इन्हें प्लगइन के नाम के साथ टाइप करें, जैसे /lagune:lagune-charter, या उसी रूप में जैसे / मेन्यू इन्हें दिखाता है, जैसे /skill:lagune:lagune-charter। --- # Muse Code पर Lagune को प्लगइन के रूप में इंस्टॉल करें > Muse Code पर Lagune को प्लगइन के रूप में इंस्टॉल करें, उसे अपडेट रखें, और उसका इंजन सैंडबॉक्स के अंदर चलाएँ। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/muse-code भाषा: hi-IN मूल: https://lagune.ai/docs/install/muse-code आख़िरी अपडेट: 2026-11-07 अपने टर्मिनल से प्लगइन इंस्टॉल करें: ```bash muse plugins marketplace add lagune wellwelwel/lagune muse plugins install lagune@lagune ``` ## अपडेट **Lagune** को अपडेट करने के लिए मार्केटप्लेस को रीफ़्रेश करें और प्लगइन को दोबारा इंस्टॉल करें: ```bash muse plugins marketplace update lagune muse plugins remove lagune muse plugins install lagune@lagune ``` ## कमांड कमांड उनके नाम से टाइप करें, जैसे `/lagune-charter`, या प्लगइन के नाम के साथ, जैसे `/lagune:lagune-charter`। --- **सैंडबॉक्स** **Muse Code** का सैंडबॉक्स इंजन डाउनलोड नहीं कर सकता। इसे अपने टर्मिनल से अपने प्रोजेक्ट में इंस्टॉल करें, पहली बार और हर अपडेट के बाद: ```bash npm i -D lagune@0.18.1 ``` ## अक्सर पूछे जाने वाले सवाल ### Muse Code पर Lagune कैसे इंस्टॉल करें? muse plugins marketplace add lagune wellwelwel/lagune चलाएँ, फिर muse plugins install lagune@lagune चलाएँ। ### Muse Code पर Lagune को कैसे अपडेट करें? muse plugins marketplace update lagune चलाएँ, फिर muse plugins remove lagune और muse plugins install lagune@lagune से प्लगइन दोबारा इंस्टॉल करें। ### Muse Code पर Lagune की कमांड कैसे चलाएँ? इन्हें उनके नाम से टाइप करें, जैसे /lagune-charter, या प्लगइन के नाम के साथ, जैसे /lagune:lagune-charter। ### क्या Lagune, Muse Code के सैंडबॉक्स में काम करता है? हाँ, जब आप अपने टर्मिनल से npm i -D lagune@0.18.1 चलाकर इंजन को अपने प्रोजेक्ट में इंस्टॉल कर लें, पहली बार और हर अपडेट के बाद। --- # OpenCode पर Lagune को प्लगइन के रूप में इंस्टॉल करें > OpenCode 1.x और 2.x पर Lagune को प्लगइन के रूप में इंस्टॉल करें और उसे अपडेट रखें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/opencode भाषा: hi-IN मूल: https://lagune.ai/docs/install/opencode आख़िरी अपडेट: 2026-11-07 **OpenCode 2.x** अपने टर्मिनल से प्लगइन इंस्टॉल करें: ```bash opencode plugin add lagune ``` या इसे `plugins` लिस्ट में जोड़ें, जो `opencode.json` फ़ाइल में है: ```json { "plugins": ["lagune"] } ``` **OpenCode 1.x** अपने टर्मिनल से प्लगइन को अपने प्रोजेक्ट में इंस्टॉल करें, या `-g` जोड़कर उसे अपने सभी प्रोजेक्ट के लिए इंस्टॉल करें: ```bash opencode plugin lagune ``` या इसे `plugin` लिस्ट में जोड़ें, जो `opencode.json` फ़ाइल में है: ```json { "plugin": ["lagune"] } ``` ## अपडेट **OpenCode 2.x** **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash opencode plugin update lagune opencode reload ``` **OpenCode 1.x** **Lagune** को अपडेट करने के लिए नई रिलीज़ को पुरानी रिलीज़ के ऊपर इंस्टॉल करें, और अगर आपने उसे अपने सभी प्रोजेक्ट के लिए इंस्टॉल किया था, तो `-g` जोड़ें: ```bash opencode plugin lagune@0.18.1 --force ``` ## कमांड **OpenCode 2.x** `@` टाइप करें और कमांड चुनें, जैसे `@lagune-charter`, फिर उसी मैसेज में अपना इनपुट लिखें। **OpenCode 1.x** कमांड उनके नाम से टाइप करें, जैसे `/lagune-charter`। ये `/skills` के अंदर दिखती हैं, `/` मेन्यू में नहीं। ## अक्सर पूछे जाने वाले सवाल ### OpenCode पर Lagune कैसे इंस्टॉल करें? OpenCode 2.x पर opencode plugin add lagune चलाएँ। OpenCode 1.x पर opencode plugin lagune चलाएँ, और उसे अपने सभी प्रोजेक्ट के लिए इंस्टॉल करने के लिए -g जोड़ें। ### OpenCode पर Lagune को कैसे अपडेट करें? OpenCode 2.x पर opencode plugin update lagune चलाएँ, फिर opencode reload चलाएँ। OpenCode 1.x पर opencode plugin lagune@0.18.1 --force चलाएँ। ### OpenCode पर Lagune की कमांड कैसे चलाएँ? OpenCode 2.x पर @ टाइप करें और कमांड चुनें, जैसे @lagune-charter, फिर उसी मैसेज में अपना इनपुट लिखें। OpenCode 1.x पर कमांड उनके नाम से टाइप करें, जैसे /lagune-charter, या उन्हें /skills के अंदर ढूँढें। ### क्या Lagune के चलने से पहले OpenCode अनुमति माँगता है? नहीं। OpenCode इंजन के दोनों टूल, lagune_read और lagune_write, बिना पूछे चलाता है। --- # Pi पर Lagune को पैकेज के रूप में इंस्टॉल करें > Pi पर Lagune को npm या GitHub से पैकेज के रूप में इंस्टॉल करें और उसे अपडेट रखें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/pi भाषा: hi-IN मूल: https://lagune.ai/docs/install/pi आख़िरी अपडेट: 2026-11-06 **npm** अपने टर्मिनल से पैकेज इंस्टॉल करें: ```bash pi install npm:lagune ``` **GitHub** **GitHub** से लेटेस्ट कमिट इंस्टॉल करें, जो इंजन को **npx** के ज़रिए चलाता है: ```bash pi install git:github.com/wellwelwel/lagune ``` ## अपडेट **npm** **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash pi update npm:lagune ``` **GitHub** **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash pi update git:github.com/wellwelwel/lagune ``` `pi update --extensions` कमांड आपके इंस्टॉल किए हर पैकेज को अपडेट करती है, जबकि सिर्फ़ `pi update` चलाने पर केवल **Pi** अपडेट होता है। ## कमांड कमांड `skill:` प्रीफ़िक्स के साथ टाइप करें। जैसे, `/skill:lagune-charter` टाइप करने पर `/lagune-charter` कमांड चलती है। ## अक्सर पूछे जाने वाले सवाल ### Pi पर Lagune कैसे इंस्टॉल करें? pi install npm:lagune चलाएँ, या GitHub से लेटेस्ट कमिट के लिए pi install git:github.com/wellwelwel/lagune चलाएँ। ### Pi पर Lagune को कैसे अपडेट करें? pi update npm:lagune चलाएँ, या GitHub से इंस्टॉल करने पर pi update git:github.com/wellwelwel/lagune चलाएँ। pi update --extensions कमांड आपके इंस्टॉल किए हर पैकेज को अपडेट करती है। ### Pi पर Lagune की कमांड कैसे चलाएँ? उन्हें skill: प्रीफ़िक्स के साथ टाइप करें, जैसे /skill:lagune-charter कमांड। --- # Qwen Code पर Lagune को एक्सटेंशन के रूप में इंस्टॉल करें > Qwen Code पर Lagune को एक्सटेंशन के रूप में इंस्टॉल करें, उसे अपडेट रखें, और उसके इंजन को पहले से अनुमति दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/qwen-code भाषा: hi-IN मूल: https://lagune.ai/docs/install/qwen-code आख़िरी अपडेट: 2026-11-06 अपने टर्मिनल से एक्सटेंशन इंस्टॉल करें: ```bash qwen extensions install lagune ``` ## अपडेट **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash qwen extensions update lagune ``` इसे हमेशा अपडेट रखने के लिए, इसे `--auto-update` के साथ इंस्टॉल करें। ## कमांड कमांड एक्सटेंशन के नाम के साथ टाइप करें, जैसे `/lagune:lagune-charter`, जो `/lagune-charter` कमांड है। --- **अनुमतियाँ** इंजन दो टूल के ज़रिए चलता है: `lagune_read` टूल सिर्फ़ आपका प्रोजेक्ट पढ़ता है, और `lagune_write` टूल सिर्फ़ `.lagune/` फ़ोल्डर में लिखता है। इन्हें पहले से अनुमति देने के लिए, एक प्रोजेक्ट के लिए `.qwen/settings.json` फ़ाइल में, या सभी प्रोजेक्ट के लिए `~/.qwen/settings.json` फ़ाइल में ये नियम जोड़ें: ```json { "permissions": { "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"] } } ``` जब इंजन **npx** के ज़रिए चलता है, जैसे **skills.sh** से इंस्टॉल करने पर, तो `Shell(npx --yes lagune@*)` नियम को अनुमति दें। ## अक्सर पूछे जाने वाले सवाल ### Qwen Code पर Lagune कैसे इंस्टॉल करें? qwen extensions install lagune चलाएँ। ### Qwen Code पर Lagune को कैसे अपडेट करें? qwen extensions update lagune चलाएँ, या एक्सटेंशन को --auto-update के साथ इंस्टॉल करें। ### Qwen Code पर Lagune की कमांड कैसे चलाएँ? इन्हें एक्सटेंशन के नाम के साथ टाइप करें, जैसे /lagune:lagune-charter। ### क्या Qwen Code अनुमति माँगे बिना Lagune चला सकता है? हाँ। Qwen Code की सेटिंग में mcp__lagune__lagune_read और mcp__lagune__lagune_write को अनुमति दें, और जब इंजन npx के ज़रिए चलता है, तो Shell(npx --yes lagune@*) को भी। --- # skills.sh या GitHub CLI से किसी भी एजेंट में Lagune इंस्टॉल करें > skills CLI या GitHub CLI से किसी भी AI एजेंट में Lagune इंस्टॉल करें, और उसे अपडेट रखें। कैनोनिकल: https://lagune.ai/hi-IN/docs/install/universal भाषा: hi-IN मूल: https://lagune.ai/docs/install/universal आख़िरी अपडेट: 2026-11-07 **skills.sh** [**skills.sh**](https://www.skills.sh/wellwelwel/lagune) के ज़रिए अपने टर्मिनल से **Lagune** की कमांड अपने प्रोजेक्ट में इंस्टॉल करें, और इंस्टॉलेशन का दायरा **Project** ही रहने दें: ```bash npx skills add wellwelwel/lagune --skill '*' ``` या यह प्रॉम्प्ट अपने एजेंट में पेस्ट करें: ```md `npx --yes skills add wellwelwel/lagune` चलाओ और इससे बने स्किल निर्देशों का अभी पालन करो। इसका पूरा आउटपुट पढ़ो, ज़रूरत हो तो पहले उसे किसी अस्थायी फ़ाइल में रीडायरेक्ट करो। रिलेटिव पाथ उस सपोर्टिंग-फ़ाइल डायरेक्टरी से तय करो जो यह देता है। ``` **GitHub CLI** [**GitHub CLI**](https://cli.github.com/) 2.90.0 या उससे नए वर्शन के ज़रिए अपने टर्मिनल से **Lagune** की कमांड अपने प्रोजेक्ट में इंस्टॉल करें: ```bash gh skill install wellwelwel/lagune --all --scope project ``` या यह प्रॉम्प्ट अपने एजेंट में पेस्ट करें: ```md `gh skill install wellwelwel/lagune --all --scope project` चलाओ और इसका पूरा आउटपुट पढ़ो, ज़रूरत हो तो पहले उसे किसी अस्थायी फ़ाइल में रीडायरेक्ट करो। ``` ## अपडेट **skills.sh** **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash npx skills update ``` या यह प्रॉम्प्ट अपने एजेंट में पेस्ट करें: ```md `npx --yes skills update -y` चलाओ और इसका पूरा आउटपुट पढ़ो, ज़रूरत हो तो पहले उसे किसी अस्थायी फ़ाइल में रीडायरेक्ट करो। ``` **GitHub CLI** **Lagune** को अपडेट करने के लिए यह चलाएँ: ```bash gh skill update --all ``` या यह प्रॉम्प्ट अपने एजेंट में पेस्ट करें: ```md `gh skill update --all` चलाओ और इसका पूरा आउटपुट पढ़ो, ज़रूरत हो तो पहले उसे किसी अस्थायी फ़ाइल में रीडायरेक्ट करो। ``` --- **सैंडबॉक्स** जिस सैंडबॉक्स में नेटवर्क एक्सेस नहीं है, उसमें कमांड इंजन डाउनलोड नहीं कर सकतीं। इसे अपने टर्मिनल से अपने प्रोजेक्ट में इंस्टॉल करें, पहली बार और हर अपडेट के बाद: ```bash npm i -D lagune@0.18.1 ``` ## अक्सर पूछे जाने वाले सवाल ### किसी भी AI एजेंट में Lagune कैसे इंस्टॉल करें? अपने प्रोजेक्ट में npx skills add wellwelwel/lagune --skill '*' या gh skill install wellwelwel/lagune --all --scope project चलाएँ, या इंस्टॉल प्रॉम्प्ट अपने एजेंट में पेस्ट करें। ### किसी भी AI एजेंट में Lagune को कैसे अपडेट करें? अगर आपने इसे skills.sh से इंस्टॉल किया है, तो npx skills update चलाएँ, और अगर GitHub CLI से इंस्टॉल किया है, तो gh skill update --all चलाएँ। आप अपडेट प्रॉम्प्ट अपने एजेंट में पेस्ट भी कर सकते हैं। ### क्या मैं Lagune को एक से ज़्यादा तरीकों से इंस्टॉल कर सकता हूँ? नहीं। दो तरीकों से इंस्टॉल करने पर एजेंट हर कमांड दो बार दिखाता है, या एक कॉपी इस्तेमाल करता है और दूसरी छिपा देता है। --- # AI एजेंट के लिए सुरक्षा स्किल > Lagune से आपके AI एजेंट को मिलने वाली स्किल: किसी मौजूदा प्रोजेक्ट का ऑडिट करें या बनाते समय ही नए काम को सुरक्षित करें, और सब कुछ सुरक्षा सिद्धांतों के अनुसार चलता है। कैनोनिकल: https://lagune.ai/hi-IN/docs/get-started/commands भाषा: hi-IN मूल: https://lagune.ai/docs/get-started/commands आख़िरी अपडेट: 2026-11-06 **Lagune** [इंस्टॉल](https://lagune.ai/hi-IN/docs) होने के बाद आपके **AI** एजेंट को कई स्किल मिल जाती हैं। इन्हें इस्तेमाल करने के दो तरीके हैं, और दोनों **सुरक्षा सिद्धांतों** के अनुसार चलते हैं: बनाते समय ही नए काम को सुरक्षित करें, या किसी प्रोजेक्ट पर पूरा ऑडिट चलाएँ। **⌨️ बिल्ड / डेवलपमेंट** काम को सुरक्षित करने से पहले उसे पूरा करना ज़रूरी नहीं है। जो काम आप **अभी** लिख रहे हैं, उसके लिए [**`/lagune`**](https://lagune.ai/hi-IN/docs/commands/lagune) कमांड इस्तेमाल करें: | स्किल | यह आपके लिए क्या करती है | | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | [**/lagune-charter**](https://lagune.ai/hi-IN/docs/commands/charter) | आपके प्रोजेक्ट के सुरक्षा नियम तय करती है, वही नींव जिस पर `/lagune` कमांड काम बनाती है | | [**/lagune**](https://lagune.ai/hi-IN/docs/commands/lagune) | आपने जो माँगा वह बनाती है और सुरक्षा सिद्धांतों के मार्गदर्शन में लिखते समय ही उसकी सुरक्षा मज़बूत करती है | **कभी भी इस्तेमाल करें** [**`/lagune`**](https://lagune.ai/hi-IN/docs/commands/lagune) कमांड जब भी चलती है, आपके सुरक्षा सिद्धांतों के नियमों का पालन करती है। यह कोई भी प्रॉम्प्ट लेती है, आपने जो माँगा वह बनाती है, और साथ-साथ सुरक्षित डिफ़ॉल्ट के साथ उसकी सुरक्षा मज़बूत करती है, बाद में नहीं। --- #### खास स्किल | स्किल | यह क्या करती है | | --------------------------------------------------- | ------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/hi-IN/docs/commands/specialize) | लेखों, एक्सप्लॉइट या विषयों से **Lagune** को एक नई सुरक्षा विशेषज्ञता सिखाती है | **🔬 ऑडिट: Blue Team फ़्लो** पूरा **Blue Team फ़्लो**: प्रोजेक्ट क्या करता है यह पढ़ें, उसके जोखिमों का खाका बनाएँ, और उन्हें बंद करें। हर स्किल पिछली स्किल के नतीजे पर आगे बढ़ती है, इसलिए सूची को ऊपर से नीचे तक क्रम से चलाना ही काफ़ी है: | # | स्किल | यह आपके लिए क्या करती है | | --- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | 1 | [**/lagune-charter**](https://lagune.ai/hi-IN/docs/commands/charter) | आपके प्रोजेक्ट के सुरक्षा नियम तय करती है, जो आपके लिए सुझाए जाते हैं या आपकी बात के हिसाब से ढलते हैं | | 2 | [**/lagune-detect**](https://lagune.ai/hi-IN/docs/commands/detect) | आपका कोड पढ़ती है और खाका बनाती है कि आपका सिस्टम क्या करता है और जोखिम कहाँ हैं | | 3 | [**/lagune-plan**](https://lagune.ai/hi-IN/docs/commands/plan) | detect चरण ने जो पाया उसे रक्षा योजना में बदलती है, हर निष्कर्ष के लिए एक सुधार के साथ | | 4 | [**/lagune-harden**](https://lagune.ai/hi-IN/docs/commands/harden) | योजना के सुधार आपके कोड पर सुरक्षित ढंग से, एक-एक करके लागू करती है | | 5 | [**/lagune-verify**](https://lagune.ai/hi-IN/docs/commands/verify) | साबित करती है कि लागू किया गया हर सुधार कारगर है, और जो कारगर हैं उन्हें निपटाती है | --- #### खास स्किल | स्किल | यह क्या करती है | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/hi-IN/docs/commands/specialize) | लेखों, एक्सप्लॉइट या विषयों से **Lagune** को एक नई सुरक्षा विशेषज्ञता सिखाती है | | [**/lagune-prove**](https://lagune.ai/hi-IN/docs/commands/prove) | पहचाने गए हर निष्कर्ष को ज़िम्मेदार खुलासे के लिए एक ऐसे प्रमाण में बदलती है जो चलाया जा सके और केवल रक्षा के लिए हो | --- #### आंतरिक स्किल | स्किल | यह क्या करती है | | ------------------------------------------- | ----------------------------------------- | | [**/lagune-repair**](https://lagune.ai/hi-IN/docs/commands/repair) | **Lagune** की आंतरिक ट्रैकिंग ठीक करती है | **टिप** सुरक्षा खर्च नहीं, निवेश है: शुरुआत में आप जो लगाते हैं, उससे कई गुना उन घटनाओं में बचाते हैं जो कभी होती ही नहीं 🙋🏻‍♂️ ## अक्सर पूछे जाने वाले सवाल ### Lagune कौन-सी स्किल जोड़ता है? बनाते समय ही काम की सुरक्षा मज़बूत करने के लिए /lagune, और पाँच चरणों वाला Blue Team ऑडिट फ़्लो: /lagune-charter, /lagune-detect, /lagune-plan, /lagune-harden, /lagune-verify। इनके अलावा /lagune-specialize और /lagune-prove भी। ### Lagune का Blue Team फ़्लो क्या है? पाँच चरणों वाला ऑडिट: charter (नियम तय करना), detect (जोखिमों का खाका बनाना), plan (स्कोर देना और सुधारों की योजना बनाना), harden (सुधार लागू करना), verify (साबित करना कि वे कारगर हैं और उन्हें बंद करना)। ### /lagune और ऑडिट फ़्लो में क्या फ़र्क है? /lagune नए काम को लिखते समय ही सुरक्षित करती है, इसमें कोई फ़्लो नहीं अपनाना पड़ता। ऑडिट फ़्लो किसी मौजूदा प्रोजेक्ट पर पाँचों चरण क्रम से चलाता है। --- # डैशबोर्ड > अपने प्रोजेक्ट के सुरक्षा सिद्धांत, निष्कर्ष और कैटलॉग एक लाइव, लोकल व्यू में देखें, जो एक ही कमांड से खुलता है। कैनोनिकल: https://lagune.ai/hi-IN/docs/get-started/dashboard भाषा: hi-IN मूल: https://lagune.ai/docs/get-started/dashboard आख़िरी अपडेट: 2026-11-06 `.lagune/` फ़ोल्डर का इंटरैक्टिव लाइव व्यू देखने के लिए **Lagune** को बिना किसी सबकमांड के सीधे चलाएँ। यह एक डैशबोर्ड चालू करता है और उसे किसी रैंडम पोर्ट पर खोलता है: ```bash npx lagune ``` - [x] **लाइव रीलोड** - [x] **प्राइवेट** और **लोकल** - [x] पहले सुरक्षा सिद्धांत से लेकर `.lagune/` फ़ोल्डर में जो कुछ भी है, सब दिखाता है - [x] प्रोजेक्ट की श्रेणियाँ और उसके हुक क्या स्कैन करते हैं, यह सीधे अपने ब्राउज़र से **मैनेज** करें - [x] `node_modules` या `package.json` की कोई ज़रूरत नहीं 📦 ![Lagune डैशबोर्ड में सुरक्षा सिद्धांत](https://lagune.ai/img/dashboard/02.webp) ![Lagune डैशबोर्ड में निष्कर्ष](https://lagune.ai/img/dashboard/03.webp) ![Lagune डैशबोर्ड में side quests](https://lagune.ai/img/dashboard/04.webp) ![Lagune डैशबोर्ड में किसी निष्कर्ष का ब्योरा](https://lagune.ai/img/dashboard/05.webp) ![Lagune डैशबोर्ड में कैटलॉग](https://lagune.ai/img/dashboard/06.webp) **टिप** - 🚪 अपनी पसंद का पोर्ट चुनने के लिए `--port` इस्तेमाल करें। - ⏏️ बंद करने के लिए `Ctrl+C` दबाएँ। ## अक्सर पूछे जाने वाले सवाल ### Lagune डैशबोर्ड कैसे खोलूँ? अपने प्रोजेक्ट के रूट में बिना किसी सबकमांड के npx lagune चलाएँ। यह किसी रैंडम पोर्ट पर .lagune/ का लाइव व्यू चालू करता है और उसे आपके ब्राउज़र में खोलता है। ### क्या डैशबोर्ड प्राइवेट है? हाँ। यह सिर्फ़ आपकी अपनी मशीन पर, एक लोकल पते पर चलता है, जहाँ कोई दूसरा कंप्यूटर नहीं पहुँच सकता। ### क्या मैं डैशबोर्ड से अपना प्रोजेक्ट बदल सकता हूँ? सिर्फ़ उसकी श्रेणियाँ, और उसके हुक किन चीज़ों को छोड़ते हैं, वह भी अपने ब्राउज़र से। डैशबोर्ड पर दिखने वाली बाकी हर चीज़ सिर्फ़ पढ़ने के लिए है। --- # /lagune: AI के कोड लिखते समय ही उसे सुरक्षित बनाएँ > जो आप माँगें वह बनाएँ, और सुरक्षा सिद्धांतों के अनुसार लिखते समय ही उसकी सुरक्षा मज़बूत करें, बिना किसी फ़्लो का पालन किए। कैनोनिकल: https://lagune.ai/hi-IN/docs/commands/lagune भाषा: hi-IN मूल: https://lagune.ai/docs/commands/lagune आख़िरी अपडेट: 2026-11-06 ⌨️ आपने जो काम माँगा है, वह लिखते समय ही सुरक्षित बनकर पूरा होता है। **`/lagune`** किसी भी पड़ाव पर कोई भी प्रॉम्प्ट लेता है, आप जो चाहते हैं वह बनाता है, और काम लौटाने से पहले सुरक्षित डिफ़ॉल्ट के साथ उसकी सुरक्षा मज़बूत करता है। ## इस्तेमाल कैसे करें किसी भी प्रॉम्प्ट पर **`/lagune`** लगाएँ, और काम को वैसे ही बताएँ जैसे हमेशा बताते हैं। **📘 एजेंट के निर्देश** ```md # एजेंटों के लिए मेरे प्रोजेक्ट के निर्देश ## सुरक्षा - जब भी कोड बनाओ या बदलो, `/lagune` स्किल इस्तेमाल करो, ताकि सुरक्षा डिफ़ॉल्ट रूप से बेहतर हो। ``` - उदाहरण के लिए: **AGENTS.md**, **CLAUDE.md**, **.github/copilot-instructions.md**, **.cursorrules** आदि। **💬 कोई फ़ीचर** ```prompt /lagune यूज़र्स को अपनी प्रोफ़ाइल पर अपनी पसंद की फ़ोटो अपलोड करने दो। ``` **💬 कोई बग फ़िक्स** ```prompt /lagune यूज़र फ़ॉर्म सबमिट करता है तो कुछ नहीं होता। देखो कि वजह क्या हो सकती है, और उसे ठीक करो। ``` **💬 कोई रीफ़ैक्टर** ```prompt /lagune पेलोड लॉजिक को अलग करो और बेहतर बनाओ ``` **सुरक्षा सिद्धांत वैकल्पिक हैं, पर उनके साथ बेहतर** **`/lagune`** सुरक्षा सिद्धांतों के साथ भी चलता है और उनके बिना भी। सिद्धांत हों, तो आपके प्रोजेक्ट के अपने नियम हर काम को आकार देते हैं। इन्हें [`/lagune-charter`](https://lagune.ai/hi-IN/docs/commands/charter) कमांड से एक बार तय कर लें। ## यह कैसे काम करता है यह Lagune में कुछ भी लिखे बिना, काम को तीन क़दमों में पूरा करता है: 1. अगर आपके सुरक्षा सिद्धांत मौजूद हैं, तो यह उन्हें लोड करता है, और पूरा काम उन्हीं के अनुसार होता है। अगर अभी तक कोई सिद्धांत तय नहीं हैं, तो यह डिफ़ॉल्ट रूप से सुरक्षित एक बुनियादी स्तर अपनाता है। 2. यह आपके प्रोजेक्ट का [कैटलॉग](https://lagune.ai/hi-IN/docs/catalog) देखता है और सिर्फ़ वही विशेषज्ञताएँ लोड करता है जिनसे आपका काम जुड़ा है, यानी वही ज्ञान जिसे ऑडिट फ़्लो ज़रूरत पड़ने पर ही लोड करता है। 3. यह कोड लिखे जाने के साथ-साथ रक्षा लागू करता है, फिर काम लौटाने से पहले अपना नतीजा दोबारा पढ़कर पुष्टि करता है कि नियंत्रण सच में कारगर हैं। नतीजा: आपके प्रोजेक्ट में काम करने वाला कोड, जो पहली लाइन से ही सुरक्षित है। **कभी भी इस्तेमाल करें** न detect, न plan, न बाद में कोई साफ़-सफ़ाई। **`/lagune`** नए-नए बने प्रोजेक्ट ढाँचे पर भी उतना ही ठीक बैठता है जितना किसी परिपक्व कोडबेस में बदलाव पर, और यह काम के साथ-साथ ही सुरक्षा मज़बूत करता है, बाद में नहीं। ## यह क्या नहीं करता - यह `.lagune` डायरेक्टरी में कुछ नहीं लिखता, न कोई आर्टिफ़ैक्ट, न कोई ट्रैकिंग, इसलिए इसका इकलौता नतीजा वह मज़बूत किया गया कोड है जो आपने माँगा था। - यह किसी प्रॉम्प्ट को पूरा करने के लिए किसी नियम को ढीला नहीं करता, इसलिए अगर आपकी माँग किसी सुरक्षा सिद्धांत को तोड़ती हो, तो यह उसे सीधे असुरक्षित तरीक़े से बनाने के बजाय रुककर पहले आपको बताता है। ## अक्सर पूछे जाने वाले सवाल ### /lagune क्या करता है? यह किसी भी पड़ाव पर कोई भी प्रॉम्प्ट लेता है, आपने जो माँगा वह बनाता है, और काम लौटाने से पहले सुरक्षित डिफ़ॉल्ट के साथ उसकी सुरक्षा मज़बूत करता है। रक्षा बाद में नहीं, कोड लिखे जाने के साथ-साथ लागू होती है। ### क्या /lagune इस्तेमाल करने के लिए सुरक्षा सिद्धांत तय करना ज़रूरी है? नहीं। यह सिद्धांतों के साथ भी चलता है और उनके बिना भी। सिद्धांत हों, तो आपके प्रोजेक्ट के अपने नियम हर काम को आकार देते हैं। न हों, तो यह डिफ़ॉल्ट रूप से सुरक्षित एक बुनियादी स्तर अपनाता है। ### /lagune और Blue Team फ़्लो में क्या फ़र्क़ है? /lagune नया काम लिखते समय ही उसे सुरक्षित बनाता है, बिना किसी फ़्लो का पालन किए। Blue Team फ़्लो किसी मौजूदा प्रोजेक्ट पर ऑडिट के पाँच चरण क्रम से चलाता है। ### क्या /lagune निष्कर्ष ट्रैक करता है या आर्टिफ़ैक्ट लिखता है? नहीं। यह .lagune डायरेक्टरी में कुछ नहीं लिखता, न कोई आर्टिफ़ैक्ट, न कोई ट्रैकिंग। इसका इकलौता नतीजा वह मज़बूत किया गया कोड है जो आपने माँगा था। ### मैं अपने एजेंट से /lagune अपने आप कैसे इस्तेमाल करवाऊँ? अपने एजेंट की निर्देश फ़ाइल (AGENTS.md, CLAUDE.md, .cursorrules वगैरह) में एक निर्देश जोड़ें, जो उससे कहे कि जब भी वह कोड बनाए या बदले, /lagune स्किल इस्तेमाल करे। --- # /lagune-charter: अपने सुरक्षा सिद्धांत तय करें > अपने प्रोजेक्ट के सुरक्षा सिद्धांत तय करें, यानी वे नियम जिनका पालन आगे का हर चरण करता है, और प्रोजेक्ट को पढ़कर जिन विशेषज्ञता श्रेणियों का आधार मिलता है उन्हें दर्ज करें। कैनोनिकल: https://lagune.ai/hi-IN/docs/commands/charter भाषा: hi-IN मूल: https://lagune.ai/docs/commands/charter आख़िरी अपडेट: 2026-11-06 🧬 **Lagune** को बताएँ कि आपका प्रोजेक्ट क्या है, और यह उसे आपके सुरक्षा नियमों में बदल देता है (या, कोई विवरण न हो तो सिर्फ़ प्रोजेक्ट को देखकर नियम निकाल लेता है)। सुरक्षा सिद्धांत सभी चरणों को दिशा देने वाली परत हैं: सुरक्षा को सबसे पहले रखने वाले सिद्धांतों का एक सेट, जिसका पालन आगे के हर चरण को करना होता है। इसे अपने प्रोजेक्ट की सुरक्षा स्थिति के लिए कंपाइल-टाइम जाँच समझें। ## इस्तेमाल कैसे करें **खुद बताएँ** ```prompt /lagune-charter मेरा प्रोजेक्ट एक ऑनलाइन स्टोर है जो वीडियो गेम बेचता है। ग्राहक प्रोडक्ट कार्ट में डालते हैं और क्रेडिट कार्ड या बैंक ट्रांसफ़र से पेमेंट करते हैं। वे अपने ऑर्डर और हर ऑर्डर का स्टेटस देख सकते हैं। ``` **Lagune को सुझाने दें** ```prompt /lagune-charter ``` > _मुझे एक पेमेंट लाइब्रेरी, लॉगिन का सेटअप और ग्राहक से जुड़ा एक ऑर्डर मॉडल दिख रहा है। यह कुछ बेचने वाला ऑनलाइन स्टोर लगता है। ग्राहक पेमेंट करते हैं और अपने ऑर्डर ट्रैक करते हैं..._ ☁️ ## यह क्या समझ लेता है **Lagune** आपके विवरण या **PRD** को दिशा मानकर समझता है कि सुरक्षा के लिहाज़ से उसका क्या मतलब है, फिर प्रोजेक्ट को पढ़कर आपकी बताई बातों से आगे जाता है। उदाहरण के लिए: - ऑर्डर रखने वाले कार्ट का मतलब है कि कोई **डेटाबेस** है: - जैसे, `"डेटा कहाँ स्टोर होता है?"`, `"उस तक कौन पहुँच सकता है?"`, `"क्या वह लीक होता है?"`। - ग्राहक अपने ऑर्डर देख सकते हैं, इसका मतलब है कि किसी तरह का **लॉगिन या एक्सेस कंट्रोल** है: - जैसे, `"क्या एक ग्राहक दूसरे के ऑर्डर तक पहुँच सकता है?"`, `"क्या सेशन सुरक्षित हैं?"`। - कार्ड और बैंक ट्रांसफ़र से पेमेंट लेने का मतलब है कि **पैसा और संवेदनशील डेटा शामिल हैं**: - जैसे, `"क्या कार्ड का डेटा सेव होता है?"`, `"क्या पेमेंट की पुष्टि होती है?"`। आपका विवरण और प्रोजेक्ट मिलकर पूरी तस्वीर बनाते हैं: आपका विवरण इरादा तय करता है, और डिपेंडेंसी, README और कॉन्फ़िगरेशन पढ़ने से वह सामने आता है जिसका आपने ज़िक्र नहीं किया। अगर कोई ज़रूरी बात फिर भी साफ़ नहीं होती, तो **Lagune** अंदाज़ा लगाने के बजाय एक छोटा, सीधा सवाल पूछता है। इसके आधार पर **Lagune** प्रोजेक्ट के लिए खास तौर पर तैयार सुरक्षा नियमों का सेट बनाता है, जिसे आप जब चाहें देख और बदल सकते हैं। **पूरा फ़ायदा उठाएँ** - आप प्रोजेक्ट के लिए अपने सुरक्षा नियम खुद भी तय कर सकते हैं। - आप जितनी काम की जानकारी देंगे, आखिरी रिपोर्ट उतनी ही बेहतर होगी: - बताएँ कि प्रोजेक्ट क्या है, कैसे काम करता है, और अंदर क्या होता है। - असली यूज़र कौन है? यूज़र क्या कर सकते हैं, और क्या नहीं? - व्यवहार से जुड़ी जानकारी उतनी ही कीमती है जितनी तकनीकी जानकारी। - सुरक्षा सिद्धांतों की मेमोरी `.lagune/memory/charter.md` में रहती है। ## यह कौन-सी श्रेणियाँ दर्ज करता है विशेषज्ञताएँ, यानी वह सुरक्षा ज्ञान जिसे आगे के चरण ज़रूरत पड़ने पर ही लोड करते हैं, [श्रेणी](https://lagune.ai/hi-IN/docs/categories) के हिसाब से आपके प्रोजेक्ट के [कैटलॉग](https://lagune.ai/hi-IN/docs/catalog) में जुड़ती हैं। जब तक आपके प्रोजेक्ट में कोई श्रेणी दर्ज नहीं है, charter चरण प्रोजेक्ट को पढ़कर हर वह श्रेणी दर्ज करता है जिसका आधार उसे मिलता है, जैसे आपके प्रोजेक्ट की भाषा, किसी LLM को किए गए कॉल या कंटेनर, और अपने सारांश में उनके नाम बताता है। श्रेणियाँ दर्ज हो जाने के बाद charter चरण उन्हें वैसे ही रहने देता है और सिर्फ़ ऐसी श्रेणी का नाम बताता है जिसे आपका प्रोजेक्ट अभी इस्तेमाल नहीं करता। आप इन्हें कभी भी खुद बदल सकते हैं: ```bash npx lagune write add --categories python npx lagune write remove --categories python ``` ## कौन-से फ़ोल्डर छोड़ने का सुझाव देता है जब charter चरण को पढ़ते समय ऐसे कमिट किए गए फ़ोल्डर मिलते हैं जो बचाने लायक आपके प्रोजेक्ट का कोड नहीं हैं, जैसे जान-बूझकर कमज़ोर दिखने के लिए लिखे गए टेस्ट फ़िक्स्चर, तो यह अपने सारांश के आखिर में उन्हें नंबर देकर दिखाता है। यह कभी अपने आप कोई फ़ोल्डर नहीं छोड़ता, क्योंकि कोई दुर्भावनापूर्ण रिपॉज़िटरी अपने कोड को फ़िक्स्चर जैसा दिखा सकती है, इसलिए सिर्फ़ वही नंबर दर्ज होते हैं जो आप जवाब में भेजते हैं। इन्हें खुद बदलने का तरीका [हुक कॉन्फ़िगर करें](https://lagune.ai/hi-IN/docs/hooks/configure) में बताया गया है। ## आगे क्या नियम तय हो जाने के बाद, खाका बनाएँ कि आपका सिस्टम असल में क्या करता है: [`/lagune-detect`](https://lagune.ai/hi-IN/docs/commands/detect)। ## अक्सर पूछे जाने वाले सवाल ### Lagune में charter क्या है? charter, यानी सुरक्षा सिद्धांत, Lagune में सभी चरणों को दिशा देने वाली परत है: सुरक्षा को सबसे पहले रखने वाले सिद्धांतों का एक सेट, जिसका पालन आगे के हर चरण को करना होता है। इसे अपने प्रोजेक्ट की सुरक्षा स्थिति के लिए कंपाइल-टाइम जाँच समझें। ### सुरक्षा सिद्धांत कहाँ सेव होते हैं? .lagune/memory/charter.md में। ### क्या मैं सुरक्षा सिद्धांतों के नियम खुद लिख सकता हूँ? हाँ। Lagune आपके विवरण और आपके कोड से नियम सुझाता है, और आप उन्हें दोबारा लिख सकते हैं, हटा सकते हैं, नए जोड़ सकते हैं, या उनका दायरा छोटा कर सकते हैं। ### क्या charter चरण मेरी विशेषज्ञता श्रेणियाँ चुनता है? सिर्फ़ तब, जब कोई श्रेणी दर्ज न हो। ऐसे में यह प्रोजेक्ट को पढ़कर हर वह श्रेणी दर्ज करता है जिसका आधार उसे मिलता है, जैसे आपकी भाषा या किसी LLM को किए गए कॉल। श्रेणियाँ एक बार दर्ज हो जाने के बाद यह उन्हें कभी नहीं बदलता। --- # /lagune-detect: अपने सिस्टम और उसके जोखिमों का खाका बनाएँ > आपका कोड पढ़कर खाका बनाता है कि आपका सिस्टम क्या करता है और जोखिम कहाँ हैं। कैनोनिकल: https://lagune.ai/hi-IN/docs/commands/detect भाषा: hi-IN मूल: https://lagune.ai/docs/commands/detect आख़िरी अपडेट: 2026-11-06 🔬 जानें कि आपका सिस्टम असल में क्या करता है और जोखिम कहाँ हैं। detect चरण कोड पढ़ता है और सिर्फ़ वही दर्ज करता है जो उसे सच में मिलता है, उस सबूत के साथ जिसकी आगे के चरणों को ज़रूरत होती है। इसका मूल नियम है: पहचानना, गढ़ना नहीं। ## इस्तेमाल कैसे करें **पूरा स्कैन** ```prompt /lagune-detect ``` **पाथ बताएँ** ```prompt /lagune-detect src/routes/ src/auth.ts ``` **कोई चिंता बताएँ** ```prompt /lagune-detect पक्का करो कि ग्राहकों का डेटा कभी उजागर न हो ``` ## यह किसका खाका बनाता है **Lagune** कोड पढ़ता है और जो पाता है उसका खाका बनाता है। हर निष्कर्ष में होता है कि वह क्या है, क्यों मायने रखता है, और उसका सबूत क्या है। उदाहरण के लिए: - **फ़ाइल अपलोड**, सिस्टम यूज़र से फ़ाइलें लेता है: - _क्यों मायने रखता है:_ इमेज के भेस में आई फ़ाइल में नुकसानदेह कोड छिपा हो सकता है। - _सबूत:_ `POST /upload` हैंडलर फ़ाइल का असली टाइप जाँचे बिना, क्लाइंट का भेजा हुआ MIME टाइप मान लेता है। - **लॉगिन और सेशन**, यूज़र अपने अकाउंट तक पहुँचने के लिए साइन इन करते हैं: - _क्यों मायने रखता है:_ कमज़ोर सेशन हैंडलिंग से किसी का अकाउंट कोई और हथिया सकता है। - _सबूत:_ सेशन जारी करने वाला लॉजिक, जहाँ सेशन बिना किसी एक्सपायरी के जारी होते हैं। इस दौरान detect चरण आपके प्रोजेक्ट के [कैटलॉग](https://lagune.ai/hi-IN/docs/catalog) की हर विशेषज्ञता को कोड से मिलाकर उस पर फ़ैसला देता है, जिनका संदर्भ कोड में मौजूद है उन्हें लागू करता है, और उन्हें **Applied specializations** के तहत दर्ज करता है, यानी वह सूची जिसे harden और verify चरण दोबारा इस्तेमाल करते हैं। इसके बाद आपके पास एक साफ़ खाका होता है कि आपका सिस्टम क्या करता है और जोखिम कहाँ हैं, जिस पर आगे के चरण तुरंत काम कर सकते हैं। **टिप** - इसे दोबारा चलाने पर खाका अपडेट होता है: हल हो चुके निष्कर्ष हट जाते हैं, नए जुड़ जाते हैं। - detect मैप `.lagune/memory/detect.md` में रहता है। ## आगे क्या खाके को योजना में बदलें: [`/lagune-plan`](https://lagune.ai/hi-IN/docs/commands/plan)। ## अक्सर पूछे जाने वाले सवाल ### /lagune-detect क्या करता है? यह आपका कोड पढ़ता है और खाका बनाता है कि आपका सिस्टम क्या करता है और जोखिम कहाँ हैं, और सिर्फ़ वही दर्ज करता है जो उसे सच में मिलता है। इसका नियम है: पहचानना, गढ़ना नहीं। ### Lagune में निष्कर्ष क्या होता है? निष्कर्ष एक पहचाना गया जोखिम है, जिसमें होता है कि वह क्या है, क्यों मायने रखता है, और कोड में उसका सबूत क्या है। यह ट्रैक की जाने वाली वह इकाई है जिसे plan, harden और verify चरण आगे ले जाते हैं। ### detect मैप कहाँ सेव होता है? .lagune/memory/detect.md में। ### detect चरण कौन-सी विशेषज्ञताएँ इस्तेमाल करता है? आपके प्रोजेक्ट के कैटलॉग की हर विशेषज्ञता को कोड से मिलाकर फ़ैसला दिया जाता है। detect चरण उन्हें लागू करता है जिनका संदर्भ मौजूद है, और उन्हें Applied specializations के तहत दर्ज करता है। --- # /lagune-plan: निष्कर्षों को स्कोर दें और सुधारों की योजना बनाएँ > detect चरण ने जो पाया उसे रक्षा योजना में बदलता है, हर निष्कर्ष को एक श्रेणी और CVSS v4.0 स्कोर देता है, और उसके साथ एक सुधार जोड़ता है। कैनोनिकल: https://lagune.ai/hi-IN/docs/commands/plan भाषा: hi-IN मूल: https://lagune.ai/docs/commands/plan आख़िरी अपडेट: 2026-11-06 🛡️ detect चरण ने जो पाया उसे रक्षा योजना में बदलें: हर निष्कर्ष को एक श्रेणी और CVSS v4.0 स्कोर दें, फिर उसके साथ लागू करने वाला सुधार जोड़ें। ## इस्तेमाल कैसे करें **सब कुछ प्लान करें** ```prompt /lagune-plan ``` **पाथ बताएँ** ```prompt /lagune-plan src/routes/upload.ts ``` **किसी चिंता पर ध्यान दें** ```prompt /lagune-plan वे जगहें जहाँ से संवेदनशील डेटा लीक हो सकता है ``` ## यह कैसे काम करता है यह चरण detect चरण के बाद आता है। आपका सिस्टम क्या करता है और हर हिस्से में क्या जोखिम है, यह detect चरण पहले ही पता कर चुका है, इसलिए plan चरण जोखिम को दोहराता नहीं, बल्कि यह आँकता है कि वह कितना गंभीर है और तय करता है कि उसके बारे में क्या करना है। plan चरण कभी कोड नहीं पढ़ता, जिससे हर सुधार को उसी चीज़ की ओर इशारा करना पड़ता है जिसे detect चरण ने सच में पहचाना। यह हर निष्कर्ष को CVSS v4.0 पद्धति से स्कोर देता है: एक श्रेणी, एक CVSS v4.0 वेक्टर जो detect चरण और सुरक्षा सिद्धांतों में दर्ज बातों के आधार पर तय होता है और जिसका स्कोर [`cvss` हुक](https://lagune.ai/hi-IN/docs/hooks/cvss) निकालता है, और वह प्राथमिकता स्तर जिसमें वह स्कोर आता है। हर सुधार के साथ सुरक्षा सिद्धांतों का वह सिद्धांत भी लिखा होता है जिसे वह कायम रखता है। उदाहरण के लिए: - **फ़ाइल अपलोड** (प्राथमिकता: **Critical**) - _श्रेणी:_ बिना पाबंदी के फ़ाइल अपलोड (CWE-434)। - _CVSS:_ CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (9.3, Critical)। - _यह प्राथमिकता क्यों:_ इंटरनेट से कोई भी अपलोड तक पहुँच सकता है, और यह उस सर्वर पर है जहाँ ग्राहकों की फ़ाइलें रखी जाती हैं। - _कायम रखता है:_ III. हर इनपुट तब तक अविश्वसनीय है जब तक उसकी जाँच न हो जाए। - _सुधार:_ फ़ाइल का असली टाइप और साइज़ जाँचें, सेव करते समय उसका नाम बदलें, और अपलोड की गई फ़ाइलें ऐसी जगह रखें जहाँ उन्हें कोड की तरह चलाया न जा सके। इसके बाद आपके पास स्कोर और प्राथमिकता के साथ सुधारों की एक सूची होती है, जिसमें हर सुधार किसी निष्कर्ष से जुड़ा होता है और अगले चरण में लागू होने के लिए तैयार होता है। स्कोर का अंदाज़ा नहीं लगाया जाता, उसे हमेशा गणना से निकाला जाता है: वेक्टर में प्रोजेक्ट का एक्सपोज़र और दाँव पर लगी चीज़ें Environmental मेट्रिक्स के रूप में दर्ज होती हैं, और कोई भी उसे FIRST या NVD कैलकुलेटर में पेस्ट करके वही स्कोर दोबारा निकाल सकता है। **टिप** - यह पूरी तरह detect चरण के नतीजों पर टिका है। अगर किसी फ़ाइल या चिंता का खाका कभी बना ही नहीं, तो यह आपको पहले उस पर `/lagune-detect` चलाने को कहता है। - इसे दोबारा चलाने पर योजना अपडेट होती है: पूरे हो चुके सुधार हट जाते हैं, नए जुड़ जाते हैं। - रक्षा योजना `.lagune/memory/plan.md` में रहती है। **detect चरण पर निर्भर** plan चरण सिर्फ़ उसी से काम करता है जिसका खाका [`/lagune-detect`](https://lagune.ai/hi-IN/docs/commands/detect) पहले ही बना चुका है, इसलिए पहले detect चरण चलाएँ। ## आगे क्या योजना लागू करें: [`/lagune-harden`](https://lagune.ai/hi-IN/docs/commands/harden)। ## अक्सर पूछे जाने वाले सवाल ### Lagune कमज़ोरियों की प्राथमिकता कैसे तय करता है? /lagune-plan हर निष्कर्ष को एक श्रेणी और cvss हुक से निकाला गया CVSS v4.0 स्कोर देती है, फिर उसके साथ लागू करने वाला सुधार जोड़ती है। ### क्या Lagune CVSS v4.0 इस्तेमाल करता है? हाँ। हर निष्कर्ष को एक CVSS v4.0 वेक्टर और स्कोर मिलता है, जिसे cvss हुक उसी गणित से निकालता है जो FIRST कैलकुलेटर इस्तेमाल करता है, इसलिए कोई भी वेक्टर वहाँ पेस्ट करके वही स्कोर दोबारा निकाल सकता है। ### क्या plan चरण मेरा कोड पढ़ता है? नहीं। plan चरण कभी कोड नहीं पढ़ता, जिससे हर सुधार को उसी चीज़ की ओर इशारा करना पड़ता है जिसे detect चरण ने सच में पहचाना। --- # /lagune-harden: अपने कोड में सुरक्षा सुधार लागू करें > रक्षा योजना के सुधार एक-एक करके, सुरक्षित तरीक़े से अपने कोड में लागू करें। कैनोनिकल: https://lagune.ai/hi-IN/docs/commands/harden भाषा: hi-IN मूल: https://lagune.ai/docs/commands/harden आख़िरी अपडेट: 2026-11-06 🔧 रक्षा योजना के सुधार एक-एक करके, सुरक्षित तरीक़े से अपने कोड में लागू करें। ## इस्तेमाल कैसे करें **सब कुछ लागू करें** ```prompt /lagune-harden ``` **पाथ बताएँ** ```prompt /lagune-harden src/routes/upload.ts ``` **प्राथमिकता के हिसाब से** ```prompt /lagune-harden Critical और High ``` ## यह कैसे काम करता है हर सुधार रक्षा योजना में पहले ही तय हो चुका है, इसलिए harden चरण बस उसे लागू करता है। यही एक चरण है जो आपके कोड को छूता है, इसलिए यह सावधानी से काम करता है: यह एक बार में एक ही सुधार लागू करता है, ताकि हर बदलाव की समीक्षा आसान रहे, और किसी सुधार को फ़िट करने के लिए कभी किसी नियंत्रण को कमज़ोर नहीं करता। उदाहरण के लिए, अपलोड वाला सुधार: - **फ़ाइल अपलोड** (स्थिति: **Applied**) - _क्या बदला:_ फ़ाइल का असली प्रकार और साइज़ जाँचता है, कुछ भी अनपेक्षित हो तो उसे अस्वीकार करता है, सेव करते समय फ़ाइल का नाम बदलता है, और उसे ऐसी जगह रखता है जहाँ वह कोड की तरह चल न सके। - _कहाँ:_ `handleUpload` फ़ंक्शन, और वह स्टोरेज हेल्पर जिसे यह फ़ंक्शन कॉल करता है। अगर कोई सुधार पूरी तरह लागू नहीं हो पाता, तो harden चरण उतना लागू करता है जितना सुरक्षित रूप से हो सकता है, और बाक़ी को **Partial** या **Blocked** चिह्नित करके खुला छोड़ देता है। **Applied का मतलब साबित हो जाना नहीं** Applied का मतलब यह नहीं कि सुधार साबित हो चुका है। यह काम [verify](https://lagune.ai/hi-IN/docs/commands/verify) चरण का है। **टिप** - यह पूरी तरह रक्षा योजना पर आधारित है। अगर किसी सुधार या फ़ाइल की योजना कभी बनी ही नहीं, तो यह आपको पहले उस पर `/lagune-plan` कमांड चलाने को कहता है। - इसे दोबारा चलाने पर रिकॉर्ड मौजूदा स्थिति से मिलाकर अपडेट होता है: वापस लिए गए बदलाव हट जाते हैं, और नए लागू सुधार जुड़ जाते हैं। - हार्डनिंग रिकॉर्ड `.lagune/memory/harden.md` फ़ाइल में रहता है। **plan चरण पर निर्भर, और आपका कोड बदलता है** harden चरण [`/lagune-plan`](https://lagune.ai/hi-IN/docs/commands/plan) कमांड के नतीजे पर आधारित है। यही एक चरण है जो आपका कोड बदलता है। ## आगे क्या [`/lagune-verify`](https://lagune.ai/hi-IN/docs/commands/verify) कमांड से साबित करें कि हर सुधार कारगर है। ## अक्सर पूछे जाने वाले सवाल ### क्या /lagune-harden मेरा कोड बदलता है? हाँ। यही एक चरण है जो आपके कोड को छूता है, और यह रक्षा योजना के सुधार एक-एक करके लागू करता है। ### Applied, Partial और Blocked का क्या मतलब है? ये वह स्थिति हैं जो Lagune हर सुधार के लिए दर्ज करता है। Applied का मतलब है कि सुधार कर दिया गया, Partial का मतलब है कि उसका सिर्फ़ एक हिस्सा हुआ, और Blocked का मतलब है कि उसे लागू नहीं किया जा सका। Applied का मतलब यह नहीं कि सुधार साबित हो चुका है। ### क्या Lagune बिना पूछे सुधार लागू कर देता है? किसी बदलाव के लिए आपकी मंज़ूरी चाहिए या नहीं, यह Lagune नहीं, बल्कि आपका एजेंट और वह परमिशन मोड तय करता है जिसमें आप उसे चलाते हैं। Lagune अपनी ओर से पुष्टि की कोई अलग जाँच नहीं जोड़ता। फिर भी यह किसी सुधार के लिए कभी किसी नियंत्रण को कमज़ोर नहीं करता, और अगर कोई सुधार सुरक्षा सिद्धांतों के किसी नियम से टकराता हो, तो यह रुककर पहले आपको बताता है। --- # /lagune-verify: साबित करें कि सुरक्षा नियंत्रण कारगर हैं > साबित करें कि लागू किया गया हर सुधार कारगर है, फिर जो कारगर हैं उन्हें निपटाएँ। कैनोनिकल: https://lagune.ai/hi-IN/docs/commands/verify भाषा: hi-IN मूल: https://lagune.ai/docs/commands/verify आख़िरी अपडेट: 2026-11-06 ⚖️ कोड पढ़कर और harden चरण के दर्ज किए गए रिकॉर्ड से उसका मिलान करके साबित करें कि लागू किया गया हर सुधार कारगर है, फिर जो कारगर हैं उन्हें निपटाएँ। ## इस्तेमाल कैसे करें **सब कुछ जाँचें** ```prompt /lagune-verify ``` **पाथ बताएँ** ```prompt /lagune-verify src/routes/upload.ts ``` **प्राथमिकता के हिसाब से** ```prompt /lagune-verify Critical और High ``` ## यह कैसे काम करता है harden चरण ने जिस-जिस जगह को दर्ज किया है, यह वहाँ का कोड पढ़ता है और पुष्टि करता है कि वह सच में दावे से मेल खाता है। यही मिलान, यानी कोड को रिकॉर्ड के सामने रखकर परखना, प्रमाण है। हर नियंत्रण को तीन में से एक फ़ैसला मिलता है: | फ़ैसला | मतलब | | ---------------------------- | --------------------------------------------------------------------- | | ✅ Risk closed | कोड ठीक वही करता है जिसका दावा रिकॉर्ड में है। | | ❌ Risk not closed | नियंत्रण अभी भी खुला है। verify चरण आपको harden चरण पर वापस भेजता है। | | ❓ Cannot tell from the code | सबूत सिर्फ़ कोड में दिखाई नहीं देता। | जिस जोखिम का बंद होना साबित हो जाता है, उसे आपकी पुष्टि के साथ पूरी चेन से बंद कर दिया जाता है। उदाहरण के लिए: - **फ़ाइल अपलोड** (फ़ैसला: **✅ Risk closed**) - _कैसे साबित हुआ:_ अपलोड हैंडलर पढ़ा और देखा कि वह फ़ाइल का असली प्रकार उसकी सामग्री से पहचानता है, साइज़ की सीमा लागू करता है, और बाक़ी सब कुछ अस्वीकार करता है, ठीक वैसे ही जैसा रिकॉर्ड में दावा है। - _सबूत:_ `handleUpload` फ़ंक्शन, जो सामग्री से फ़ाइल का असली प्रकार पहचानता है। अगर जोखिम बंद नहीं हुआ है, तो verify चरण यह साफ़-साफ़ बताता है और आपको [`/lagune-harden`](https://lagune.ai/hi-IN/docs/commands/harden) कमांड पर वापस भेजता है, क्योंकि सुधार अभी भी खुला है। **टिप** - यह पूरी तरह हार्डनिंग रिकॉर्ड पर आधारित है। - यह आपके कोड को सिर्फ़ परखने के लिए पढ़ता है, और कोई फ़ैसला पास करवाने के लिए कभी किसी नियंत्रण को कमज़ोर नहीं करता, न ही कोड दोबारा लिखता है। - इसे दोबारा चलाने पर फ़ैसले मौजूदा स्थिति से मिलाकर अपडेट होते हैं: पुराने फ़ैसले हट जाते हैं, और जो जोखिम अब बंद नहीं है, उसे फिर से पकड़ा जाता है। - जब किसी जोखिम का बंद होना साबित हो जाता है, तो यह एक बार पूछता है, फिर उस निष्कर्ष को पूरी चेन (detect, plan, harden और ट्रैकिंग) से हटा देता है। - यह अपनी कोई अलग रिपोर्ट नहीं लिखता: हर फ़ैसला `.lagune/memory/harden.md` फ़ाइल में अपने नियंत्रण वाले ब्लॉक में दर्ज होता है, जहाँ harden चरण अगली बार चलने पर उसे पढ़ता है। **harden चरण पर निर्भर** verify चरण [`/lagune-harden`](https://lagune.ai/hi-IN/docs/commands/harden) कमांड के नतीजे पर आधारित है। ## चक्र पूरा होता है जब दायरे में आने वाला सब कुछ बंद हो जाता है, तो चक्र स्थिर हो जाता है। यह तभी दोबारा खुलता है जब कोड बदलता है। सुरक्षा बंद हो सकने वाली चीज़ है, इसलिए इस फ़्लो का एक अंत है, यह कभी न ख़त्म होने वाला लूप नहीं है। ## अक्सर पूछे जाने वाले सवाल ### Lagune किसी सुधार की जाँच कैसे करता है? /lagune-verify कोड पढ़ता है और harden चरण के दर्ज किए गए रिकॉर्ड से उसका मिलान करता है, फिर तीन में से एक फ़ैसला देता है: Risk closed (जोखिम बंद), Risk not closed (जोखिम बंद नहीं) या Cannot tell from the code (सिर्फ़ कोड से तय नहीं हो सकता)। ### किसी निष्कर्ष को बंद करना क्या है? जब verify चरण साबित कर देता है कि कोई जोखिम बंद हो गया है, तो उस निष्कर्ष को बंद कर दिया जाता है: आपकी पुष्टि के साथ उसे पूरी चेन से हटा दिया जाता है, ताकि उस पर दोबारा काम न हो। ### क्या सुरक्षा का काम कभी पूरा हो सकता है? हाँ। SDH में सुरक्षा बंद हो सकने वाली चीज़ है: जिस निष्कर्ष का बंद होना साबित हो जाता है, उसे बंद कर दिया जाता है, इसलिए इस फ़्लो का एक अंत है, यह कभी न ख़त्म होने वाला लूप नहीं है। --- # श्रेणियाँ > Lagune प्रोजेक्ट किन विशेषज्ञता श्रेणियों का इस्तेमाल कर सकता है, OWASP से लेकर JavaScript, Python, Go और Rust की भाषा-विशेष हार्डनिंग तक, और उन्हें कैसे बदलें। कैनोनिकल: https://lagune.ai/hi-IN/docs/categories भाषा: hi-IN मूल: https://lagune.ai/docs/categories आख़िरी अपडेट: 2026-11-06 **Lagune** अपनी बिल्ट-इन [**विशेषज्ञताओं**](https://lagune.ai/hi-IN/docs/catalog) को **13 श्रेणियों** में बाँटता है। प्रोजेक्ट जिन श्रेणियों का इस्तेमाल करता है, उन्हीं से तय होता है कि कौन-सी बिल्ट-इन विशेषज्ञताएँ उसके [**कैटलॉग**](https://lagune.ai/hi-IN/docs/catalog) में शामिल होंगी। ये श्रेणियाँ दो हिस्सों में बँटी हैं: सिस्टम क्या करता है, और वह किस भाषा में लिखा गया है। जब तक कोई श्रेणी दर्ज नहीं होती, प्रोजेक्ट सिर्फ़ `owasp` का इस्तेमाल करता है। [`/lagune-charter`](https://lagune.ai/hi-IN/docs/commands/charter) कमांड प्रोजेक्ट को पढ़कर हर वह श्रेणी दर्ज करती है जिसका उसे प्रोजेक्ट में आधार मिलता है, और आप जब चाहें इन्हें ख़ुद बदल सकते हैं। ## सिस्टम क्या करता है | श्रेणी | कुंजी | यह किसे मज़बूत करती है | | ----------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | OWASP | `owasp` | वे ऐप्लिकेशन सुरक्षा जोखिम जिन्हें OWASP ट्रैक करता है: इंजेक्शन, कमज़ोर एक्सेस कंट्रोल (Broken Access Control), ऑथेंटिकेशन और क्रिप्टो की विफलताएँ | | इन्फ़्रास्ट्रक्चर | `infra` | कंटेनर, वर्कलोड और सर्वरलेस कॉन्फ़िगरेशन: Dockerfile, Compose, Pod सुरक्षा, FaaS IAM और ट्रिगर | | AI / LLM | `ai` | AI और LLM इंटीग्रेशन, प्रॉम्प्ट इंजेक्शन और टूल, एजेंट, रिट्रीवल और MCP की असुरक्षित वायरिंग के ख़िलाफ़ | | Lovable | `lovable` | AI से बने Supabase ऐप (Lovable और उस जैसे): RLS की कमियाँ, लीक हुई `service_role` कुंजियाँ और असुरक्षित डिफ़ॉल्ट | ## सिस्टम किस भाषा में लिखा गया है | श्रेणी | कुंजी | यह किसे मज़बूत करती है | | ---------- | ------------ | ------------------------------------------------------------------------------------------------------------------------- | | JavaScript | `javascript` | `eval` और `child_process` से RCE, पाथ ट्रैवर्सल और प्रोटोटाइप पॉल्यूशन, इसके सभी रनटाइम में | | Python | `python` | `pickle` और YAML डीसीरियलाइज़ेशन से RCE, `str.format` से स्ट्रिंग ट्रैवर्सल और क्लास पॉल्यूशन | | Rust | `rust` | अनसाउंड `unsafe` API, `transmute` का ग़लत इस्तेमाल, इंटीजर ओवरफ़्लो और FFI सीमा पर अपरिभाषित व्यवहार (undefined behavior) | | C / C++ | `c-cpp` | फ़ॉर्मैट स्ट्रिंग बग, बफ़र ओवरफ़्लो और आउट-ऑफ़-बाउंड्स राइट, जो कोड एक्ज़ीक्यूशन का रास्ता खोलते हैं | | PHP | `php` | टाइप जगलिंग से ऑथेंटिकेशन बायपास, ऑब्जेक्ट इंजेक्शन गैजेट चेन और असुरक्षित डिफ़ॉल्ट कॉन्फ़िगरेशन | | Go | `go` | typed nil इंटरफ़ेस बग, गोरूटीन डेटा रेस और सुरक्षा से जुड़े कोड पाथ पर असुरक्षित कॉन्करेंसी | | Java | `java` | `ObjectInputStream` डीसीरियलाइज़ेशन गैजेट चेन, जो आख़िरकार रिमोट कोड एक्ज़ीक्यूशन तक पहुँचती हैं | | Ruby | `ruby` | `Marshal.load` और YAML डीसीरियलाइज़ेशन गैजेट चेन, जो रिमोट कोड एक्ज़ीक्यूशन तक पहुँचती हैं | | .NET / C# | `dotnet` | `BinaryFormatter` डीसीरियलाइज़ेशन से RCE और वे एनकोडर बायपास जो XSS तक पहुँचते हैं | **टिप** **Lagune** किसी एक भाषा से बंधा नहीं है: पूरा फ़्लो आपके प्रोजेक्ट को पढ़ता है, वह चाहे किसी भी भाषा में लिखा हो, और ये श्रेणियाँ बस किसी एक भाषा के ख़ास जोखिमों पर और गहराई जोड़ती हैं। ## कभी भी जोड़ें और हटाएँ श्रेणी एक शुरुआत है, कोई पक्का वादा नहीं। अभी प्रोजेक्ट पर जो फ़िट बैठे, उसका इस्तेमाल करें, और `write add` और `write remove` से कुंजी के ज़रिए उसे कभी भी बदलें। टर्मिनल में बिना किसी वैल्यू के `--categories` देने पर एक इंटरैक्टिव पिकर खुलता है (स्पेस से चुनें या हटाएँ, एंटर से पक्का करें, कुछ न चुनें तो यह स्किप हो जाता है)। टर्मिनल के बाहर, श्रेणियाँ इसके बाद लिखकर दें। **जोड़ें** ```bash npx lagune write add --categories # interactive npx lagune write add --categories owasp npx lagune write add --categories owasp rust ``` **हटाएँ** ```bash npx lagune write remove --categories # interactive npx lagune write remove --categories owasp npx lagune write remove --categories owasp rust ``` `write add` या `write remove` पहली बार चलाने पर शुरुआत `owasp` से होती है, इसलिए हर श्रेणी हटाने पर सूची ख़ाली रह जाती है, डिफ़ॉल्ट पर कभी नहीं लौटती। हर बदलाव `.lagune/configs.json` में दर्ज होता है, ताकि पूरी टीम एक ही सेट के साथ काम करे। ## देखें कि प्रोजेक्ट क्या इस्तेमाल करता है `read list --categories` हर श्रेणी दिखाता है, और यह भी कि प्रोजेक्ट उसका इस्तेमाल करता है या नहीं: ```bash npx lagune read list --categories # Categories # • owasp [used] Harden against the application security risks OWASP tracks # • javascript [available] Harden JavaScript and its runtimes # • php [available] Harden PHP against type-juggling auth bypass # • go [available] Harden Go against typed-nil interface bugs # ... # # No category is recorded yet, so this project uses the default: owasp. ``` हर श्रेणी में कौन-सी विशेषज्ञताएँ हैं, यह [**कैटलॉग**](https://lagune.ai/hi-IN/docs/catalog) में देखें। [`/lagune-specialize`](https://lagune.ai/hi-IN/docs/commands/specialize) से लिखी आपकी अपनी विशेषज्ञताएँ कैटलॉग में शामिल होती हैं, श्रेणियाँ चाहे जो हों। ## अक्सर पूछे जाने वाले सवाल ### मैं कोई श्रेणी कैसे जोड़ूँ? श्रेणी की कुंजी --categories को दें, जैसे npx lagune write add --categories javascript चलाएँ। जब तक कोई श्रेणी दर्ज नहीं होती, charter चरण भी प्रोजेक्ट को पढ़कर वे श्रेणियाँ दर्ज करता है जिनका उसे आधार मिलता है। ### क्या मैं एक से ज़्यादा श्रेणियाँ इस्तेमाल कर सकता हूँ? हाँ। उन्हें एक ही लाइन में, एक के बाद एक लिखें। ### प्रोजेक्ट को कौन-सी श्रेणी इस्तेमाल करनी चाहिए? डिफ़ॉल्ट owasp से शुरू करें, फिर अपनी भाषा या स्टैक वाली श्रेणी जोड़ें। विशेषज्ञताएँ सिर्फ़ ज़रूरत पड़ने पर ही लोड होती हैं, इसलिए किसी श्रेणी का तब तक कोई बोझ नहीं पड़ता, जब तक किसी चरण को उसकी किसी विशेषज्ञता की ज़रूरत न हो। --- # कैटलॉग: ज़रूरत पड़ने पर ही लोड होने वाली सुरक्षा विशेषज्ञताएँ > आपके प्रोजेक्ट के कैटलॉग की विशेषज्ञताएँ कैसे लोड होती हैं, ज़रूरत पड़ने पर किसी चरण के ज़रिए और सीधे आपके ज़रिए। कैनोनिकल: https://lagune.ai/hi-IN/docs/catalog भाषा: hi-IN मूल: https://lagune.ai/docs/catalog आख़िरी अपडेट: 2026-11-06 🧠 **Lagune** की विशेषज्ञताएँ सुरक्षा ज्ञान के केंद्रित मॉड्यूल हैं, जो किसी एक प्रोग्रामिंग भाषा से बंधे नहीं हैं और डिफ़ॉल्ट रूप से कभी लोड नहीं होते, सिर्फ़ ज़रूरत पड़ने पर ही लोड होते हैं। ये कमांड नहीं हैं। आपके प्रोजेक्ट का कैटलॉग वह सेट है जिसका प्रोजेक्ट इस्तेमाल करता है: उसकी [श्रेणियों](https://lagune.ai/hi-IN/docs/categories) की बिल्ट-इन विशेषज्ञताएँ और उसकी अपनी विशेषज्ञताएँ। detect और verify चरण चलते समय इनका सहारा लेते हैं, और आप भी किसी भी समय कोई विशेषज्ञता सीधे लोड कर सकते हैं। **परिचय** *इंटरैक्टिव कैटलॉग ओवरव्यू वेब पेज पर है। हर बिल्ट-इन विशेषज्ञता नीचे दी गई टेबल में है।* **यह कैसे काम करता है** ## ख़ुद चलाएँ किसी विशेषज्ञता का सीधे इस्तेमाल करने के लिए, अपने एजेंट से उसे `read catalog ` से लोड करने को कहें और उसी प्रॉम्प्ट में अपना काम भी लिखें। फिर वह ज्ञान आपके माँगे गए काम पर लागू होता है। यह किसी भी प्रॉम्प्ट में काम करता है, उसमें भी जिसका **Lagune** फ़्लो से कोई लेना-देना नहीं है। उदाहरण के लिए, **Python** में सुरक्षित **RegExp** का संग्रह बनाने के लिए एक सीधा, अपने शब्दों में लिखा प्रॉम्प्ट: ```prompt `npx lagune read catalog regex` से regex विशेषज्ञता लोड करो, फिर @src/utils/regex.py में ईमेल और यूज़रनेम जाँचने के लिए रेगुलर एक्सप्रेशन का एक संग्रह बनाओ। ``` इसमें एक नियतात्मक हुक हर **RegExp** को **ReDoS** के ख़िलाफ़ टेस्ट करता है, सुरक्षित पैटर्न रखता है, और कुछ ऐसा नतीजा देता है: ```python import re EMAIL = re.compile(r"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$") USERNAME = re.compile(r"^[a-zA-Z0-9_]{3,20}$") def is_email(value: str) -> bool: return EMAIL.match(value) is not None def is_username(value: str) -> bool: return USERNAME.match(value) is not None ``` **ReDoS चेकर आज़माएँ** किसी पैटर्न को [**devina.io/redos-checker**](https://devina.io/redos-checker) पर ख़ुद टेस्ट करें। ## बिल्ट-इन विशेषज्ञताएँ बिल्ट-इन विशेषज्ञताएँ [**श्रेणियों**](https://lagune.ai/hi-IN/docs/categories) में बँटी हुई हैं। **Lagune** के साथ आने वाला सेट यह है: | विशेषज्ञता | श्रेणी | मुख्य विषय | | --------------------- | --------------------------- | ----------------------------------------------------------------------------------------------- | | `regex` | `owasp` | **ReDoS**: ऐसे पैटर्न जो जान-बूझकर गढ़े गए इनपुट पर बेक़ाबू हो जाते हैं। | | `network` | `owasp` | **SSRF और रीडायरेक्ट**: यूज़र के दिए फ़ेच या रीडायरेक्ट के गंतव्य। | | `interpreter` | `owasp`, `lovable` | **कोड इंजेक्शन**: `eval`, डायनैमिक include, नाम के आधार पर डिस्पैच। | | `sql` | `owasp` | **रिलेशनल डेटाबेस**: इंजेक्शन, रॉ ORM कॉल, अधिकार, इंजन की पहुँच। | | `path` | `owasp` | **फ़ाइल सिस्टम पाथ**: पाथ ट्रैवर्सल, null byte, NTFS स्ट्रीम, फ़ाइल प्लांटिंग। | | `upload` | `owasp` | **फ़ाइल अपलोड**: टाइप और सिग्नेचर, नुक़सानदेह कंटेंट, स्टोरेज, सीमाएँ। | | `access-control` | `owasp`, `lovable` | **ऑथेंटिकेशन, ऑथराइज़ेशन, सेशन**: IDOR, मास असाइनमेंट, टेनेंट, सेशन। | | `credential-endpoint` | `owasp`, `lovable` | **अंदाज़े वाले हमले और बॉट**: ब्रूट फ़ोर्स, पासवर्ड स्प्रेइंग, क्रेडेंशियल स्टफ़िंग, थ्रॉटलिंग। | | `federation` | `owasp` | **टोकन पर भरोसा**: OAuth/OIDC, SAML, JWT वैलिडेशन, QR लॉगिन। | | `http-request` | `owasp` | **रिक्वेस्ट का स्रोत**: CSRF, CORS की ग़लत कॉन्फ़िगरेशन, नक़ली क्लाइंट IP। | | `transport` | `owasp` | **चैनल सुरक्षा**: TLS कॉन्फ़िगरेशन, HTTPS और प्लेनटेक्स्ट, HSTS, पिनिंग। | | `crypto` | `owasp`, `lovable` | **स्टोर किए गए डेटा की क्रिप्टोग्राफ़ी**: कमज़ोर या ख़ुद बनाए एल्गोरिदम, CSPRNG, कुंजी प्रबंधन। | | `secrets` | `owasp`, `lovable` | **हार्डकोड किए गए क्रेडेंशियल**: सोर्स कोड में सीधे लिखी कुंजियाँ, टोकन, पासवर्ड। | | `api-endpoint` | `owasp` | **REST के अलावा दूसरे सरफ़ेस**: GraphQL, gRPC, WebSocket ऑथराइज़ेशन, DoS, स्कीमा। | | `payment` | `owasp`, `lovable` | **चेकआउट फ़्लो**: सर्वर-साइड पर गेटवे की पुष्टि, साइन किए गए कॉलबैक, आइडेम्पोटेंसी। | | `xml` | `owasp` | **XML पार्सिंग**: XXE, एक्सटर्नल एंटिटी, billion laughs एक्सपैंशन। | | `csv` | `owasp` | **फ़ॉर्मूला इंजेक्शन**: `=`/`+`/`-`/`@` से शुरू होने वाले स्प्रेडशीट सेल। | | `container` | `owasp`, `infra` | **कंटेनर कॉन्फ़िगरेशन**: root यूज़र, कैपेबिलिटीज़, सॉकेट माउंट, इमेज हार्डनिंग। | | `infra` | `infra` | **इन्फ़्रास्ट्रक्चर ऐज़ कोड**: Terraform, Dockerfile, GitHub Actions। | | `serverless` | `owasp`, `infra`, `lovable` | **FaaS फ़ंक्शन**: कम से कम अधिकार वाला IAM, इवेंट इनपुट, कॉन्टेक्स्ट, सीक्रेट। | | `llm` | `ai`, `lovable` | **AI और LLM जोखिम**: प्रॉम्प्ट इंजेक्शन, ज़रूरत से ज़्यादा अधिकार (agency), RAG, MCP, आउटपुट। | | `supabase` | `lovable` | **Supabase बैकएंड**: डिफ़ॉल्ट रूप से बंद RLS, AI की ग़लत बनाई पॉलिसियाँ, कुंजी मॉडल। | | `browser` | `javascript`, `lovable` | **क्लाइंट-साइड जोखिम**: XSS, CSP, फ़्रेमिंग, स्टोरेज आदि। | | `javascript` | `javascript` | **भाषा के स्तर के जोखिम**: RCE, प्रोटोटाइप पॉल्यूशन आदि। | | `python` | `python` | **भाषा के स्तर के जोखिम**: `pickle` RCE, क्लास पॉल्यूशन, `-O` आदि। | | `rust` | `rust` | **`unsafe` की साउंडनेस**: safe कॉलर से पैदा होने वाला UB, `transmute`, ओवरफ़्लो। | | `java` | `java` | **डीसीरियलाइज़ेशन और मोबाइल कोड**: `readObject` चेन, ऑब्जेक्ट हाइजैक। | | `ruby` | `ruby` | **डीसीरियलाइज़ेशन और `open`**: `Marshal`/YAML से ऑब्जेक्ट रिवाइवल, पाइप से जुड़ा अनोखा व्यवहार। | | `php` | `php` | **टाइप जगलिंग और `unserialize`**: मैजिक हैश, POP चेन। | | `go` | `go` | **typed nil और डेटा रेस**: `nil != nil`, मेमोरी साझा करने वाले गोरूटीन। | | `c-cpp` | `c-cpp` | **फ़ॉर्मैट स्ट्रिंग**: `printf(user_input)`, `%n` से write-what-where। | | `dotnet` | `dotnet` | **प्लैटफ़ॉर्म के स्तर के जोखिम**: `BinaryFormatter` RCE, `@Html.Raw`, enum की कमियाँ। | ज़्यादातर बिल्ट-इन ज्ञान OWASP से सार निकालकर बना है। हर विशेषज्ञता का उसके मूल OWASP अटैक और Cheat Sheet पेजों से पूरा मिलान [**OWASP स्रोत**](https://lagune.ai/hi-IN/docs/references/owasp-sources) में देखें। कुछ स्टैक-विशेष मॉड्यूल इसके बजाय वेंडर के अपने दिशानिर्देशों से बने हैं: उदाहरण के लिए, `supabase` Supabase के डॉक्स और CVE-2025-48757 से लिया गया है। ## आपकी अपनी विशेषज्ञताएँ बिल्ट-इन विशेषज्ञताएँ एक ज्ञान फ़ाइल और इंडेक्स की एक पंक्ति जोड़कर बढ़ती हैं, नई कमांड जोड़कर कभी नहीं। आप अपनी विशेषज्ञताएँ भी इसी तरह [`/lagune-specialize`](https://lagune.ai/hi-IN/docs/commands/specialize) कमांड से जोड़ते हैं: इसे कोई लेख या विषय दें, और यह उसका सार निकालकर आपके प्रोजेक्ट में एक नई विशेषज्ञता बना देती है, यानी `.lagune/catalog/` में फ़ाइल और `.lagune/configs.json` में उसकी एंट्री। आपकी अपनी विशेषज्ञताएँ कैटलॉग में हमेशा रहती हैं, उसकी श्रेणियाँ चाहे जो हों, और आपकी कोई विशेषज्ञता उसी नाम की बिल्ट-इन विशेषज्ञता की जगह ले लेती है। **Lagune अंदर ही अंदर, ज़रूरत पड़ने पर विशेषज्ञताएँ अपने-आप लोड करता है** जब detect या verify चरण किसी ऐसे संदर्भ पर पहुँचता है जिसे कोई विशेषज्ञता कवर करती है, तो वह चरण ख़ुद `read catalog ` से उस विशेषज्ञता को लोड करता है। यह चरण के हिस्से के रूप में अपने-आप होता है। इसके काम करने के लिए आपको कुछ भी हाथ से नहीं करना पड़ता। ## देखें कि क्या उपलब्ध है टर्मिनल में अपने प्रोजेक्ट का कैटलॉग देखें, हर पंक्ति में एक विशेषज्ञता और उसके टैग के साथ: ```bash npx lagune read catalog # regex: Regular Expression [required] # network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect # interpreter: Evaluator, Sink, Shell, Dynamic Execution # ... ``` `[required]` वाली विशेषज्ञता हमेशा लागू होती है, काम चाहे जो हो। सूची में कौन-सी बिल्ट-इन विशेषज्ञताएँ होंगी, यह आपके प्रोजेक्ट की [**श्रेणियों**](https://lagune.ai/hi-IN/docs/categories) पर निर्भर करता है। **विशेषज्ञताएँ डिफ़ॉल्ट रूप से लोड नहीं होतीं** हर जाँच डिफ़ॉल्ट रूप से चलाने के बजाय, प्रोजेक्ट असल में जैसा है, उसी के हिसाब से ज़रूरी ज्ञान लोड होता है। ## अक्सर पूछे जाने वाले सवाल ### Lagune की विशेषज्ञता क्या है? सुरक्षा ज्ञान का एक केंद्रित मॉड्यूल, जो किसी एक प्रोग्रामिंग भाषा से बंधा नहीं है और डिफ़ॉल्ट रूप से कभी नहीं, सिर्फ़ ज़रूरत पड़ने पर ही लोड होता है। यह एजेंट स्किल्स की तरह कमांड नहीं है। ### प्रोजेक्ट का कैटलॉग क्या है? वे विशेषज्ञताएँ जिनका प्रोजेक्ट इस्तेमाल करता है: उसकी श्रेणियों की बिल्ट-इन विशेषज्ञताएँ और उसकी अपनी विशेषज्ञताएँ। जब तक कोई श्रेणी दर्ज नहीं होती, प्रोजेक्ट सिर्फ़ OWASP का इस्तेमाल करता है। ### क्या विशेषज्ञताएँ डिफ़ॉल्ट रूप से लोड होती हैं? नहीं। ये सिर्फ़ ज़रूरत पड़ने पर ही लोड होती हैं, प्रोजेक्ट असल में जैसा है उसके हिसाब से। ### मैं किसी विशेषज्ञता को सीधे कैसे लोड करूँ? अपने काम वाले उसी प्रॉम्प्ट में एजेंट से npx lagune read catalog चलाने को कहें। --- # /lagune-specialize: सादे टेक्स्ट से नई सुरक्षा विशेषज्ञता सिखाएँ > आपके दिए गए किसी सुरक्षा स्रोत या विषय का सार निकालकर एक नई विशेषज्ञता बनाएँ, जो ज़रूरत पड़ने पर ही लोड होती है। कैनोनिकल: https://lagune.ai/hi-IN/docs/commands/specialize भाषा: hi-IN मूल: https://lagune.ai/docs/commands/specialize आख़िरी अपडेट: 2026-11-06 🎓 कोई स्रोत या विषय देकर **Lagune** को एक नई विशेषज्ञता सिखाएँ। यह सामग्री पढ़ता है और उसका सार निकालकर एक केंद्रित विशेषज्ञता बनाता है, जो केवल रक्षा के लिए होती है और ठीक [बिल्ट-इन विशेषज्ञताओं](https://lagune.ai/hi-IN/docs/catalog) जैसी बनी होती है, ताकि बाद में detect और verify चरण उसे किसी भी दूसरी विशेषज्ञता की तरह लोड करें। यह सिर्फ़ ऑडिट करता है और समझाता है: यह कभी अटैक इनपुट या एक्सप्लॉइट नहीं लिखता, और आपके कोड को कभी नहीं छूता। **किसी लेख से** ```prompt # कोई लिंक या संदर्भ: Lagune उसका सार निकालकर उसे रक्षा में बदल देता है /lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection ``` **किसी एक्सप्लॉइट से** ```prompt # स्रोत के रूप में कोई अटैक: विशेषज्ञता फिर भी रक्षा ही होती है /lagune-specialize "' OR 1=1 -- क्वेरी के टेक्स्ट में SQL जोड़ देता है" ``` **किसी विषय से** ```prompt # या बस बताओ कि किस विषय को कवर करना है /lagune-specialize SQL इंजेक्शन ``` **अटैक स्रोत हो सकता है, आउटपुट कभी नहीं** जब मक़सद किसी अटैक से बचाव करना हो, तो उसे स्रोत के रूप में देना ठीक है: किसी एक्सप्लॉइट का विश्लेषण पढ़ने की सामग्री है, जिसका यह सार निकालकर रक्षा में बदल देता है। इससे बनने वाली विशेषज्ञता हमेशा ऑडिट करती है और समझाती है, यह कभी काम करने वाला एक्सप्लॉइट, पेलोड या पकड़ से बचने की तकनीक नहीं बनाती। ## यह क्या लिखता है नतीजा आपके प्रोजेक्ट में दो फ़ाइलें होती हैं, जो आपके कोड के साथ कमिट होती हैं और जिनकी समीक्षा की जा सकती है: - `.lagune/catalog/.md` पर विशेषज्ञता, जो [बिल्ट-इन विशेषज्ञताओं](https://lagune.ai/hi-IN/docs/catalog) जैसी बनी होती है। - `.lagune/configs.json` फ़ाइल में उसकी एंट्री, जहाँ आपका प्रोजेक्ट अपनी विशेषज्ञताओं का इंडेक्स रखता है, ताकि कैटलॉग उन्हें बिल्ट-इन विशेषज्ञताओं के साथ मिला सके। फिर यह कैटलॉग की सूची देखकर पुष्टि करता है कि नई एंट्री उसमें है। आपकी अपनी विशेषज्ञताएँ हमेशा कैटलॉग में रहती हैं, चाहे उसकी श्रेणियाँ कुछ भी हों। आपको न कोई कमांड जोड़नी पड़ती है, न पैकेज को छूना पड़ता है: नई विशेषज्ञता बस एक नॉलेज फ़ाइल और एक इंडेक्स एंट्री है, जो आपके अपने प्रोजेक्ट में लिखी जाती है। ## निखारें, कभी ओवरराइट नहीं किसी ऐसे नाम की विशेषज्ञता बनाने पर जो पहले से मौजूद है, चाहे वह `regex` जैसी बिल्ट-इन हो या आपकी पहले बनाई हुई, यह मौजूदा फ़ाइल को बदलने के बजाय उसे **मौजूदा स्थिति से मिलाकर अपडेट** करता है। यह जो पहले से है उसे पढ़ता है, नई जानकारी उसमें जोड़ता है, जो अब भी सही है उसे रखता है, और जो बदल गया है उसे दोबारा लिखता है। बिना देखे कुछ भी नहीं हटाया जाता। आपकी अपनी विशेषज्ञता उसी नाम की बिल्ट-इन विशेषज्ञता की जगह ले लेती है, इसलिए आप बिल्ट-इन को खोए बिना उसे अपने प्रोजेक्ट के लिए और धारदार बना सकते हैं। **टिप** - नई विशेषज्ञता ठीक बिल्ट-इन की तरह लोड होती है: detect और verify चरण ज़रूरत पड़ने पर ही उसे लेते हैं, या आप `npx lagune read catalog ` कमांड से उसे ख़ुद लोड करके कोई काम दे सकते हैं। - जब सामग्री का स्रोत पहचाना जा सके (कोई लेख, लेखक, लिंक या मानक), तो विशेषज्ञता उसका श्रेय देती है। सिर्फ़ विषय देने पर कोई स्रोत दर्ज नहीं होता। **नोट** **यह तभी चलता है जब आप इसे बुलाते हैं**: एजेंट इसे कभी अपने आप शुरू नहीं करता। ## अक्सर पूछे जाने वाले सवाल ### मैं अपनी ख़ुद की सुरक्षा विशेषज्ञता कैसे जोड़ूँ? किसी स्रोत या विषय के साथ /lagune-specialize चलाएँ। यह उसका सार निकालकर केवल रक्षा के लिए एक विशेषज्ञता बनाता है, जो .lagune/catalog/.md में लिखी जाती है, और उसकी एंट्री .lagune/configs.json में जुड़ती है। ### क्या Lagune किसी एक्सप्लॉइट के विश्लेषण से सीख सकता है? हाँ, स्रोत के रूप में, आउटपुट के रूप में कभी नहीं। अटैक स्रोत हो सकता है, नतीजा कभी नहीं। specialize कभी अटैक इनपुट या एक्सप्लॉइट नहीं लिखता। ### क्या specialize बिल्ट-इन विशेषज्ञताओं को ओवरराइट कर देता है? नहीं। यह उन्हें निखारता है, कभी ओवरराइट नहीं करता। --- # /lagune-prove: केवल रक्षा के लिए प्रूफ़ ऑफ़ कॉन्सेप्ट (PoC) > पहचाने गए हर निष्कर्ष को ज़िम्मेदार खुलासे के लिए, चलाया जा सकने वाला और केवल रक्षा के लिए बना प्रूफ़ ऑफ़ कॉन्सेप्ट (PoC) और सुरक्षा एडवाइज़री बनाएँ। कैनोनिकल: https://lagune.ai/hi-IN/docs/commands/prove भाषा: hi-IN मूल: https://lagune.ai/docs/commands/prove आख़िरी अपडेट: 2026-11-06 🧪 पहचाने गए हर निष्कर्ष को ज़िम्मेदार खुलासे के लिए ऐसे सबूत में बदलें, जिसे चलाया जा सके और जो केवल रक्षा के लिए हो। detect मैप में दर्ज हर निष्कर्ष के लिए यह एक ऐसी सुरक्षा एडवाइज़री लिखता है जो अपने आप में पूरी हो, और एक टेस्ट लिखता है जो **सुरक्षित रास्ते** की पुष्टि करता है। इसलिए जब तक समस्या मौजूद है, टेस्ट फ़ेल होता है, और कोड ठीक होते ही पास हो जाता है। **टिप** **Lagune** के टेस्ट आपके अपने टेस्ट सूट से अलग, `.lagune/` फ़ोल्डर में रहते हैं। ## इस्तेमाल कैसे करें **हर निष्कर्ष** ```prompt /lagune-prove ``` **नाम से कोई एक निष्कर्ष** पहले से ट्रैक किए गए निष्कर्षों के नाम देखें: ```prompt npx lagune read list --findings # Findings # ... # • यूज़र लुकअप में SQL इंजेक्शन # ... ``` ```prompt # फिर उनमें से किसी एक को साबित करो /lagune-prove यूज़र लुकअप में SQL इंजेक्शन ``` ## यह कैसे काम करता है हर निष्कर्ष जिस सोर्स कोड की ओर इशारा करता है, यह उसे पढ़ता है, और साबित किए गए हर निष्कर्ष के लिए `.lagune/proofs/` फ़ोल्डर में एक डायरेक्टरी बनाता है, जिसमें ठीक दो फ़ाइलें होती हैं: | फ़ाइल | यह क्या है | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `report.test.mjs` (या `.cjs`) | टेस्ट। अगर आपका प्रोजेक्ट पहले से Poku इस्तेमाल करता है, तो यह Poku पर चलता है, वरना Node.js के अपने रनर पर, इसलिए कुछ भी इंस्टॉल करने की ज़रूरत नहीं है। | | `report.md` | अपने आप में पूरी सुरक्षा एडवाइज़री: गंभीरता, असर, समस्या को दोबारा कैसे पैदा करें, और चलाने की कमांड, जिसे अलग से पढ़ा जा सकता है। | प्रमाण हमेशा JavaScript में होते हैं, इसलिए आपका प्रोजेक्ट चाहे किसी भी भाषा में लिखा हो, वे कहीं भी चल जाते हैं। एक `README.md` इंडेक्स हर प्रमाण का लिंक देता है, और सभी को एक साथ चलाने के लिए एक ही कमांड बताता है। **टिप** - यह **वैकल्पिक और स्वतंत्र** है: यह पाँच चरणों में से एक नहीं है, और ट्रैकिंग चेन का हिस्सा भी नहीं है। - यह सिर्फ़ `.lagune/proofs/` फ़ोल्डर में लिखता है, और चरणों के आर्टिफ़ैक्ट या आपके कोड को कभी नहीं छूता, उन्हें सिर्फ़ पढ़ता है। - जिस निष्कर्ष का टेस्ट समस्या को दोबारा पैदा नहीं कर पाता, उसे कोई प्रमाण नहीं मिलता, और यह आपसे कहता है कि उस जगह पर [`/lagune-detect`](https://lagune.ai/hi-IN/docs/commands/detect) कमांड चलाकर उसे मौजूदा स्थिति से मिलाकर अपडेट करें। - इसे दोबारा चलाने पर प्रमाण मौजूदा स्थिति से मिलाकर अपडेट होते हैं: जो निष्कर्ष अब नहीं रहा या अब दोबारा पैदा नहीं होता, उसकी डायरेक्टरी हटा दी जाती है। **नोट** **यह तभी चलता है जब आप इसे बुलाते हैं**: एजेंट इसे कभी अपने आप शुरू नहीं करता। **detect चरण पर आधारित** prove [`/lagune-detect`](https://lagune.ai/hi-IN/docs/commands/detect) कमांड का बनाया detect मैप पढ़ता है, इसलिए पहले detect चरण चलाएँ। ## केवल रक्षा के लिए, और अनुमति के साथ कुछ भी बनाने से पहले यह पुष्टि करता है कि आपको टार्गेट को टेस्ट करने की अनुमति है, और काम करने वाले एक्सप्लॉइट, अटैक पेलोड या पकड़ से बचने की तकनीक के हर अनुरोध को ठुकरा देता है। प्रमाण सुरक्षित व्यवहार दिखाता है, यह कभी कोई अटैक इनपुट नहीं बनाता। ## प्रमाण से खुलासे तक कमज़ोरी की रिपोर्ट करने के लिए, साबित किए गए हर निष्कर्ष की दोनों फ़ाइलें एक साथ एक **प्राइवेट GitHub Gist** में रखें। ये एक ऐसी समस्या के सबूत हैं जो अभी मौजूद है और जिसका खुलासा नहीं हुआ है, इसलिए एक `.gitignore` फ़ाइल, जो `.lagune/proofs/` फ़ोल्डर के अंदर है, इन्हें हर कमिट से बाहर रखती है: जब तक मेंटेनर इसे हल न कर दें, इन्हें सिर्फ़ उसी Gist के ज़रिए साझा करें। **Lagune** चेन में किसी निष्कर्ष को बंद करना अब भी [`/lagune-harden`](https://lagune.ai/hi-IN/docs/commands/harden) और [`/lagune-verify`](https://lagune.ai/hi-IN/docs/commands/verify) कमांड का काम है: prove सबूत बनाता है, किसी चीज़ को बंद नहीं करता। ## अक्सर पूछे जाने वाले सवाल ### क्या Lagune एक्सप्लॉइट बनाता है? नहीं। /lagune-prove केवल रक्षा के लिए सबूत लिखता है: एक टेस्ट जो सुरक्षित रास्ते की पुष्टि करता है, इसलिए समस्या मौजूद रहने तक फ़ेल होता है और कोड ठीक होते ही पास हो जाता है, साथ में ज़िम्मेदार खुलासे के लिए एक सुरक्षा एडवाइज़री। ### prove क्या आउटपुट देता है? हर निष्कर्ष के लिए दो फ़ाइलें: एक टेस्ट (report.test.mjs या .cjs) और एक सुरक्षा एडवाइज़री (report.md)। ### Lagune को मिले बग का ज़िम्मेदारी से खुलासा कैसे करूँ? prove एक ऐसी सुरक्षा एडवाइज़री लिखता है जो अपने आप में पूरी हो, और जिसे आप ज़िम्मेदार खुलासे के नियमों के अनुसार किसी प्राइवेट चैनल, जैसे प्राइवेट GitHub Gist, के ज़रिए साझा कर सकते हैं। --- # हुक कॉन्फ़िगर करें: चुनें कि वे क्या स्कैन करें > फ़ाइलें स्कैन करने वाले हुक किन चीज़ों को छोड़ें, यह सभी हुक के लिए एक साथ या किसी एक के लिए अलग से तय करें। कैनोनिकल: https://lagune.ai/hi-IN/docs/hooks/configure भाषा: hi-IN मूल: https://lagune.ai/docs/hooks/configure आख़िरी अपडेट: 2026-11-06 `checkers` ब्लॉक, जो `.lagune/configs.json` फ़ाइल में होता है, तय करता है कि फ़ाइलें स्कैन करने वाले हुक किन चीज़ों को छोड़ें, सभी हुक के लिए एक साथ या किसी एक के लिए अलग से। ## कॉन्फ़िगर करें कमांड लाइन से पाथ और पैटर्न जोड़ें या हटाएँ। पैटर्न को कोट में रखें, ताकि शेल उसे वैसा ही छोड़ दे जैसा लिखा है: ```bash npx lagune write add --ignore test/fixtures npx lagune write add --ignore 'packages/*/dist' --checker secrets npx lagune write remove --ignore test/fixtures ``` या उन्हें [डैशबोर्ड](https://lagune.ai/hi-IN/docs/get-started/dashboard) के Settings पेज में चुनें, या सीधे फ़ाइल में सेट करें: ```json { "checkers": { "ignore": ["test/fixtures"], "secrets": { "gitignore": false, "ignore": ["test/fixtures", "temp"] } } } ``` ### सेटिंग्स | कुंजी | वैल्यू | डिफ़ॉल्ट | विवरण | | ----------- | ------------------------------ | -------- | ---------------------------------------------------------------------------------------------------------------------- | | `gitignore` | `true` या `false` | `true` | जिसे **Git** अनदेखा करता है, उसे छोड़ दें। **Git** जिस फ़ाइल को ट्रैक करता है, वह हर हाल में स्कैन होती है। | | `ignore` | प्रोजेक्ट रूट से पाथ या पैटर्न | `[]` | हर पाथ या पैटर्न जिससे मेल खाता है, उसे और उसके नीचे की हर चीज़ को छोड़ दें, भले ही **Git** उस फ़ाइल को ट्रैक करता हो। | `checkers` के सबसे ऊपरी स्तर पर रखी कुंजी हर चेकर पर लागू होती है। किसी चेकर के नाम के नीचे रखी कुंजी सिर्फ़ उसी चेकर पर लागू होती है और साझा कुंजी की जगह ले लेती है। इसलिए उदाहरण में `secrets` वह भी स्कैन करता है जिसे **Git** अनदेखा करता है, और `test/fixtures` और `temp` को छोड़ देता है। जब `write add --ignore` किसी चेकर को पहली बार उसकी अपनी सूची देता है, तो वह सूची साझा सूची की कॉपी से शुरू होती है। ### पैटर्न पैटर्न प्रोजेक्ट रूट से शुरू होता है, इसलिए `*.generated.ts` सिर्फ़ रूट की फ़ाइलों तक पहुँचता है और `**/*.generated.ts` किसी भी गहराई पर मौजूद फ़ाइलों तक। नाम हूबहू मेल खाने चाहिए, बड़े और छोटे अक्षरों समेत। | पैटर्न | क्या छोड़ता है | | ------------------- | ------------------------------------------------------ | | `dist` | प्रोजेक्ट रूट पर मौजूद `dist` | | `packages/*/dist` | `dist`, जो `packages` के नीचे हर फ़ोल्डर में हो | | `**/dist` | हर `dist`, किसी भी गहराई पर | | `**/*.generated.ts` | हर वह फ़ाइल जिसका नाम `.generated.ts` पर ख़त्म होता है | | `fixture-?` | `fixture-a`, `fixture-1` और ऐसे ही दूसरे नाम | | `[ab]-cache` | `a-cache` और `b-cache` | | `[*]x` | `*x`, जिसमें `*` एक साधारण अक्षर है | ## नतीजा कैसे पढ़ें रिपोर्ट के आख़िर में लिखा होता है कि स्कैन ने कितने पाथ छोड़े, और उन्हें किसने अनदेखा किया: ```text Skipped 25 paths that Git ignores and 3 paths that .lagune/configs.json ignores. Name one with --dir or --file to scan it. ``` `--dir` या `--file` से दिया गया पाथ हर हाल में स्कैन होता है, सेटिंग्स चाहे जो कहें। जिस सेटिंग को इंजन पढ़ नहीं पाता, वह चेकर को एक एरर के साथ रोक देती है जिसमें उस सेटिंग का नाम होता है, जैसे ऐसा पैटर्न जो `!` या स्पेस से शुरू होता हो, प्रोजेक्ट से बाहर निकल जाता हो, कोई ब्रैकेट खुला छोड़ देता हो, या मेल खाने में बहुत ज़्यादा समय लेता हो। ## अक्सर पूछे जाने वाले सवाल ### क्या Lagune ये सेटिंग्स मेरे लिए खुद तय करता है? नहीं। charter चरण उन कमिट किए गए फ़ोल्डरों की सूची बनाता है जिनके बारे में प्रोजेक्ट पढ़कर वह पाता है कि वे बचाने लायक आपका कोड नहीं हैं, जैसे कमज़ोर दिखने के लिए लिखे गए टेस्ट फ़िक्स्चर, और सिर्फ़ वही फ़ोल्डर दर्ज करता है जिन्हें आप नंबर से चुनते हैं। ### चेकर को वह सब कब स्कैन करना चाहिए जिसे Git अनदेखा करता है? जब रिपॉज़िटरी ऐसी हो जिस पर आप भरोसा नहीं कर सकते, क्योंकि उसकी अपनी .gitignore फ़ाइलें कोड छिपा सकती हैं, या जब किसी बिल्ड फ़ोल्डर में बिल्ड के समय इनलाइन की गई कोई कुंजी हो सकती है। हर चेकर के लिए या किसी एक के लिए gitignore को false पर सेट करें। --- # agent हुक: बिना सीमा वाले एजेंट लूप पकड़ें > कमांड लाइन से कोडबेस में ऐसी एजेंट या LLM कॉल खोजें जिन पर स्टेप या समय की कोई सीमा नहीं है, या किसी एक कॉल को स्कोर दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/hooks/agent भाषा: hi-IN मूल: https://lagune.ai/docs/hooks/agent आख़िरी अपडेट: 2026-11-06 `agent` हुक **बिना टर्न, बजट या समय सीमा के लूप में चलने वाले एजेंट रनटाइम** पकड़ता है। यह बेकाबू स्वायत्तता वाली वह खामी है जो जान-बूझकर गढ़े गए एक इनपुट को असीमित ख़र्च या बढ़ते प्रॉम्प्ट इंजेक्शन हमले में बदल देती है। यह **भाषा को पहचानता है** और एजेंट फ़्रेमवर्क के दो इकोसिस्टम कवर करता है: **JavaScript** (**Claude** एजेंट SDK का `query` रनटाइम) और **Python** (**LangChain**, **LangGraph**, **CrewAI**, **OpenAI Agents**)। यह [`llm` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) के पीछे का नियतात्मक इंजन है, जिसे आप खुद **scan** या **check** मोड में चला सकते हैं। ## चलाएँ **कोडबेस स्कैन करें** ```bash npx lagune read agent # scans the whole project npx lagune read agent --dir src/ai # scans a directory npx lagune read agent --file chat.ts # scans a single file ``` **कोई कॉल जाँचें** ```bash npx lagune read agent --lang javascript --pattern 'query({ prompt })' # => uncapped npx lagune read agent --lang javascript --pattern 'query({ prompt, options: { maxTurns: 5 } })' # => safe npx lagune read agent --lang python --pattern 'AgentExecutor(agent=a, max_iterations=None)' # => uncapped ``` **Uncapped agent loops found** के नीचे की हर लाइन किसी ऐसी फ़ाइल में मिली है जो एजेंट SDK इंपोर्ट करती है, और वह दो में से एक चीज़ है: या तो बिना टर्न, बजट या समय सीमा के बुलाया गया Claude एजेंट SDK का `query` रनटाइम (JavaScript, जहाँ डिफ़ॉल्ट रूप से कोई सीमा नहीं होती), या किसी फ़्रेमवर्क की डिफ़ॉल्ट सीमा को साफ़ तौर पर हटाना, जैसे `max_iterations=None` / `max_turns=None` (Python, जहाँ डिफ़ॉल्ट रूप से सीमा होती है)। दोनों ही मामलों में हुक नॉन-ज़ीरो एग्ज़िट कोड देता है। Vercel AI SDK के `generateText`/`streamText` डिफ़ॉल्ट रूप से एक ही स्टेप चलाते हैं (`stopWhen: stepCountIs(1)`), इसलिए वहाँ बिना विकल्पों वाली कॉल लूप नहीं कर सकती और पकड़ी नहीं जाती, और एक आम `db.query(...)` को कभी एजेंट कॉल नहीं समझा जाता। कुछ न मिलने पर यह `no uncapped agent loops found` छापता है। ## फ़ैसला कैसे पढ़ें | फ़ैसला | मतलब | | ---------- | ------------------------------------------------------------------------------------------------------------------ | | `uncapped` | बिना सीमा वाली `query` रनटाइम कॉल (JS), या सीमा को साफ़ तौर पर हटाना (`=None`, Py)। | | `safe` | सीमा तय करने वाली `query` कॉल, एक स्टेप वाला जनरेशन, या ऐसे फ़्रेमवर्क की कॉल जिसमें डिफ़ॉल्ट रूप से सीमा होती है। | | `invalid` | कोड के टुकड़े में फ़ैसले के लिए कोई पहचानने लायक एजेंट कॉल नहीं है। | ### CLI विकल्प | विकल्प | वैल्यू | विवरण | | ----------- | ------------- | ------------------------------------------------------------------------------------------------- | | `--pattern` | कोड का टुकड़ा | एक कॉल जाँचें। कई कॉल जाँचने के लिए इसे दोहराएँ, हर लाइन में एक फ़ैसला। | | `--lang` | एक भाषा | `--pattern` के साथ ज़रूरी: `javascript` या `python`। | | `--dir` | एक डायरेक्टरी | स्कैन को एक डायरेक्टरी तक सीमित करें। इसे दोहराया जा सकता है और `--file` के साथ जोड़ा जा सकता है। | | `--file` | एक फ़ाइल | स्कैन को एक फ़ाइल तक सीमित करें। इसे दोहराया जा सकता है और `--dir` के साथ जोड़ा जा सकता है। | कोई विकल्प न देने पर यह पूरा प्रोजेक्ट स्कैन करता है। `--pattern` के साथ `--lang` चाहिए, और इसे `--dir` या `--file` के साथ नहीं जोड़ा जा सकता। ### चुनें कि यह क्या स्कैन करे यह उन चीज़ों को छोड़ देता है जिन्हें **Git** अनदेखा करता है। और ज़्यादा छोड़ने के लिए, या **Git** की अनदेखी चीज़ों को भी स्कैन करने के लिए, `agent` को उसकी अपनी सेटिंग्स दें: ```bash npx lagune write add --ignore test/fixtures --checker agent ``` ```json { "checkers": { "agent": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` हर सेटिंग की जानकारी [हुक कॉन्फ़िगर करें](https://lagune.ai/hi-IN/docs/hooks/configure) पेज पर है। **पूरी कोशिश, पर हर चीज़ नहीं** हाथ से लिखा गया एजेंट लूप, किसी भी भाषा में, स्टैटिक स्कैन की पकड़ से बाहर है। इसे एक मज़बूत न्यूनतम आधार मानें, पूरी सूची नहीं। **टिप** हुक सिर्फ़ सीमा के बारे में फ़ैसला करता है: क्षमताओं का दायरा, अलग-अलग भरोसे वाले इनपुट का आपस में मिलना और ऑथराइज़ेशन ऐसे मामले हैं जिनमें विवेक चाहिए, और उन्हें अब भी [`llm` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) कवर करती है। ## अक्सर पूछे जाने वाले सवाल ### एजेंट लूप पर सीमा क्यों लगानी चाहिए? बिना सीमा वाले एजेंट को असीमित रिकर्शन, ख़र्च या बढ़ते प्रॉम्प्ट इंजेक्शन हमले की ओर धकेला जा सकता है। maxTurns/maxBudgetUsd/stopWhen/signal सेट करने से उसकी हद तय होती है, और agent हुक ऐसी query रनटाइम कॉल को पकड़ता है जिसमें इनमें से कुछ भी सेट न हो। --- # cors हुक: CORS ऑरिजिन का ऑडिट करें > कमांड लाइन से सोर्स कोड में ऐसी CORS ऑरिजिन अनुमति सूची खोजें जिसे बायपास किया जा सके, या किसी एक ऑरिजिन वैल्यू को स्कोर देकर देखें कि वह ज़रूरत से ज़्यादा एक्सेस तो नहीं देती। कैनोनिकल: https://lagune.ai/hi-IN/docs/hooks/cors भाषा: hi-IN मूल: https://lagune.ai/docs/hooks/cors आख़िरी अपडेट: 2026-11-06 `cors` हुक [`http-request` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) के पीछे का नियतात्मक इंजन है, और आप इसे खुद चला सकते हैं। एक ही कमांड से यह दो मोड में काम करता है: **scan**, जो सोर्स कोड में **बायपास की जा सकने वाली ऑरिजिन अनुमति सूची** खोजता है (होस्ट जाँचने वाला ऐसा regex जिससे हमलावर का होस्ट बचकर निकल जाता है), और **score**, जो किसी एक **CORS ऑरिजिन** वैल्यू को `wildcard`, `null` या `safe` के रूप में आँकता है। ## कोडबेस स्कैन करें कोई फ़्लैग न देने पर यह पूरा प्रोजेक्ट स्कैन करता है। **पूरा प्रोजेक्ट** ```bash npx lagune read cors ``` **एक डायरेक्टरी** ```bash npx lagune read cors --dir src/server ``` **एक फ़ाइल** ```bash npx lagune read cors --file internal/auth/origin.go ``` यह बायपास की जा सकने वाली हर अनुमति सूची को एक ही हेडर के नीचे, फ़ाइल के हिसाब से समूहों में दिखाता है। अगर होस्ट जाँचने वाले regex में `.+`/`.*` भरोसेमंद होस्ट वाले सफ़िक्स से पहले authority हिस्से में हो (`^https?://.+\.trusted\.com`), तो `your-site.com.attacker.com` जैसा हमलावर होस्ट बचकर निकल जाता है। ```text Origin-allowlist patterns with a greedy wildcard (bypassable, review): internal/auth/origin.go ^https?://.+\.trusted\.com ``` यह समीक्षा के लिए एक सुराग है, पक्का निष्कर्ष नहीं: regex किसी असली भरोसे वाले फ़ैसले को नियंत्रित करता है या नहीं, यह सिर्फ़ टेक्स्ट से तय नहीं हो सकता, इसलिए स्कैन कभी एग्ज़िट कोड नहीं बदलता। हर एक को पढ़ें और पक्का करें कि अनुमति सूची पूरी वैल्यू का हूबहू मिलान करती है। कुछ न मिलने पर यह सिर्फ़ एक लाइन छापता है। ```bash npx lagune read cors --dir src/clean # => no bypassable origin allowlist found ``` ## ऑरिजिन को स्कोर दें हर ऑरिजिन `--origin` के साथ दें। हुक हर ऑरिजिन के लिए एक शब्द छापता है, और कोई भी `wildcard` या `null` मिलने पर नॉन-ज़ीरो एग्ज़िट कोड देता है। **एक ऑरिजिन** ```bash npx lagune read cors --origin '*' # => wildcard npx lagune read cors --origin 'null' # => null npx lagune read cors --origin 'https://app.example.com' # => safe ``` **कई ऑरिजिन** पूरी अनुमति सूची को एक ही कॉल में स्कोर देने के लिए `--origin` दोहराएँ। हर लाइन में एक फ़ैसला आता है, उसी क्रम में। ```bash npx lagune read cors \ --origin 'https://app.example.com' \ --origin '*' \ --origin 'null' # => safe # => wildcard # => null ``` | फ़ैसला | मतलब | | ---------- | ------------------------------------------------------------------------------------------------ | | `safe` | न `*`, न `null`, न ही कोई `*`-glob। इससे यह गारंटी नहीं मिलती कि ऑरिजिन सही ढंग से लिखा गया है। | | `wildcard` | `*`, या कोई सबडोमेन, होस्ट या पोर्ट glob: कोई भी साइट (या साइटों का बड़ा समूह) जवाब पढ़ सकती है। | | `null` | `null` ऑरिजिन, जिसे सैंडबॉक्स किए गए iframe और रीडायरेक्ट जाली बना सकते हैं। | सिर्फ़ `safe` का मतलब अनुमति है, और `--origin` एक वैल्यू ऑरेकल है: यह वैल्यू को आँकता है, हैंडलर को नहीं, इसलिए हैंडलर की पुष्टि `http-request` विशेषज्ञता से करें। ### CLI विकल्प | विकल्प | वैल्यू | विवरण | | ---------- | ------------- | ------------------------------------------------------------------------------------------------- | | `--origin` | एक ऑरिजिन | एक ऑरिजिन वैल्यू को स्कोर दें। कई को स्कोर देने के लिए इसे दोहराएँ, हर लाइन में एक। | | `--dir` | एक डायरेक्टरी | स्कैन को एक डायरेक्टरी तक सीमित करें। इसे दोहराया जा सकता है और `--file` के साथ जोड़ा जा सकता है। | | `--file` | एक फ़ाइल | स्कैन को एक फ़ाइल तक सीमित करें। इसे दोहराया जा सकता है और `--dir` के साथ जोड़ा जा सकता है। | कोई विकल्प न देने पर यह पूरा प्रोजेक्ट स्कैन करता है। `--origin` score मोड है, और इसे `--dir` या `--file` के साथ नहीं जोड़ा जा सकता। ### चुनें कि यह क्या स्कैन करे यह उन चीज़ों को छोड़ देता है जिन्हें **Git** अनदेखा करता है। और ज़्यादा छोड़ने के लिए, या **Git** की अनदेखी चीज़ों को भी स्कैन करने के लिए, `cors` को उसकी अपनी सेटिंग्स दें: ```bash npx lagune write add --ignore test/fixtures --checker cors ``` ```json { "checkers": { "cors": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` हर सेटिंग की जानकारी [हुक कॉन्फ़िगर करें](https://lagune.ai/hi-IN/docs/hooks/configure) पेज पर है। **यह क्या कवर नहीं करता** स्कैन **बायपास किए जा सकने वाले regex** का पैटर्न पढ़ता है, और `--origin` ऑरिजिन की **वैल्यू** को स्कोर देता है। सोर्स कोड के दो पैटर्न इसकी पहुँच से बाहर रहते हैं: रिक्वेस्ट के `Origin` को लौटाना (सर्वर आए हुए `Origin` को ही वापस भेज देता है, या उसे क्रेडेंशियल के साथ जोड़ देता है), और `endsWith` या सबस्ट्रिंग पर आधारित ढीली अनुमति सूची। इन्हें कोड में पहचानें और उसी तरह संभालें जैसा [`http-request` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) बताती है। ## अक्सर पूछे जाने वाले सवाल ### null CORS ऑरिजिन ख़तरनाक क्यों है? सैंडबॉक्स किए गए iframe और कुछ रीडायरेक्ट Origin: null भेजते हैं, इसलिए जो अनुमति सूची null पर भरोसा करती है, वह इन संदर्भों को जवाब पढ़ने का एक्सेस दे देती है। cors हुक इसे वाइल्डकार्ड के साथ-साथ पकड़ता है। ### बायपास की जा सकने वाली CORS ऑरिजिन अनुमति सूची कैसे पकड़ूँ? कोडबेस पर npx lagune read cors चलाएँ। यह होस्ट जाँचने वाले ऐसे regex को पकड़ता है जिसका ग्रीडी वाइल्डकार्ड भरोसेमंद सफ़िक्स से पहले आता है, जिससे your-site.com.attacker.com जैसा हमलावर होस्ट बचकर निकल जाता है। --- # crypto हुक: कमज़ोर क्रिप्टोग्राफ़ी पकड़ें > कमांड लाइन से कोडबेस में कमज़ोर क्रिप्टोग्राफ़िक प्रिमिटिव खोजें, या कोड के किसी एक टुकड़े को स्कोर दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/hooks/crypto भाषा: hi-IN मूल: https://lagune.ai/docs/hooks/crypto आख़िरी अपडेट: 2026-11-06 `crypto` हुक कॉल की जगह पर ही **कमज़ोर क्रिप्टोग्राफ़िक प्रिमिटिव** पकड़ता है: अप्रचलित सिफ़र, असुरक्षित मोड या टूटा हुआ डाइजेस्ट। यह **भाषा को पहचानता है** और हर फ़ाइल को उसकी अपनी भाषा के नियमों से पढ़ता है, ताकि Rust फ़ाइल में Python का कोई कंस्ट्रक्ट कभी न पकड़ा जाए। यह [`crypto` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) के पीछे का नियतात्मक इंजन है, जिसे आप खुद **scan** या **check** मोड में चला सकते हैं। ## चलाएँ **कोडबेस स्कैन करें** ```bash npx lagune read crypto # scans the whole project npx lagune read crypto --dir src # scans a directory npx lagune read crypto --file hash.ts # scans a single file ``` **कोड का टुकड़ा जाँचें** ```bash npx lagune read crypto --lang javascript --pattern 'createCipher("aes-256-cbc", k)' # => weak npx lagune read crypto --lang python --pattern 'hashlib.md5(data)' # => review npx lagune read crypto --lang go --pattern 'sha256.Sum256(data)' # => safe ``` स्कैन ज़्यादा से ज़्यादा दो सेक्शन छापता है। **Weak cryptography found** निष्कर्षों का सेट है (DES/3DES/RC4/Blowfish/RC2, ECB मोड): इनमें से हर एक टूटा हुआ सिफ़र प्रिमिटिव है, इसलिए हुक नॉन-ज़ीरो एग्ज़िट कोड देता है। **Cryptography to review manually** ऐसे सुरागों का सेट है जिन पर हुक अकेले फ़ैसला नहीं कर सकता: MD5/SHA-1 डाइजेस्ट (सुरक्षा के काम के लिए टूटा हुआ, पर साधारण चेकसम के रूप में जायज़, इसलिए फ़ैसला इस्तेमाल के इरादे पर निर्भर है), सुरक्षा वाले संदर्भ में नॉन-क्रिप्टोग्राफ़िक RNG, या ऐसी तुलना जो टाइमिंग के लिहाज़ से असुरक्षित हो। कुछ न मिलने पर यह `no weak cryptography found` छापता है। ## फ़ैसला कैसे पढ़ें | फ़ैसला | मतलब | | --------- | ----------------------------------------------------------------------------------------------------------------------- | | `weak` | कोड का टुकड़ा टूटा हुआ सिफ़र प्रिमिटिव इस्तेमाल करता है (DES/3DES, RC4, Blowfish, RC2, या ECB मोड)। | | `review` | ऐसा प्रिमिटिव जिसका फ़ैसला इरादे पर निर्भर है: MD5/SHA-1 डाइजेस्ट, या सुरक्षा वाले संदर्भ में नॉन-क्रिप्टोग्राफ़िक RNG। | | `safe` | कोड का टुकड़ा क्रिप्टो इस्तेमाल करता है, और कोई कमज़ोर प्रिमिटिव नहीं मिला। | | `invalid` | कोड के टुकड़े में फ़ैसले के लिए कोई पहचानने लायक क्रिप्टोग्राफ़िक कंस्ट्रक्ट नहीं है। | ### CLI विकल्प | विकल्प | वैल्यू | विवरण | | ----------- | ------------- | ----------------------------------------------------------------------------------------------------------- | | `--pattern` | कोड का टुकड़ा | कोड का एक टुकड़ा जाँचें। कई जाँचने के लिए इसे दोहराएँ, हर लाइन में एक फ़ैसला। | | `--lang` | एक भाषा | `--pattern` के साथ ज़रूरी: javascript, python, go, java, kotlin, php, ruby, rust, csharp, c, cpp में से एक। | | `--dir` | एक डायरेक्टरी | स्कैन को एक डायरेक्टरी तक सीमित करें। इसे दोहराया जा सकता है और `--file` के साथ जोड़ा जा सकता है। | | `--file` | एक फ़ाइल | स्कैन को एक फ़ाइल तक सीमित करें। इसे दोहराया जा सकता है और `--dir` के साथ जोड़ा जा सकता है। | कोई विकल्प न देने पर यह पूरा प्रोजेक्ट स्कैन करता है। `--pattern` के साथ `--lang` चाहिए, और इसे `--dir` या `--file` के साथ नहीं जोड़ा जा सकता। ### चुनें कि यह क्या स्कैन करे यह उन चीज़ों को छोड़ देता है जिन्हें **Git** अनदेखा करता है। और ज़्यादा छोड़ने के लिए, या **Git** की अनदेखी चीज़ों को भी स्कैन करने के लिए, `crypto` को उसकी अपनी सेटिंग्स दें: ```bash npx lagune write add --ignore test/fixtures --checker crypto ``` ```json { "checkers": { "crypto": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` हर सेटिंग की जानकारी [हुक कॉन्फ़िगर करें](https://lagune.ai/hi-IN/docs/hooks/configure) पेज पर है। ### समर्थित भाषाएँ स्कैन इन भाषाओं को फ़ाइल एक्सटेंशन से पहचानकर पढ़ता है, और हर भाषा को उसके अपने क्रिप्टोग्राफ़िक API के हिसाब से जाँचता है। | भाषा | कमज़ोर सिफ़र (निष्कर्ष), डाइजेस्ट और RNG (समीक्षा) | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **JavaScript / TypeScript** | `createCipher`, `CryptoJS.DES/RC4`, कोट में लिखा `*-ecb`; MD5/SHA-1 वाला `createHash`/`subtle.digest`; `Math.random()` | | **Python** | pycryptodome का `DES/ARC4/Blowfish.new`, `algorithms.TripleDES`, `MODE_ECB`; `hashlib.md5/sha1`; `random.*` | | **Go** | `des.NewCipher`, `rc4.NewCipher`, `blowfish.NewCipher`, `NewECBEncrypter`; `md5/sha1.Sum`; `math/rand` | | **Java / Kotlin** | `Cipher.getInstance("DES"/…/ECB")`; `MessageDigest.getInstance("MD5")`, `HmacMD5`; `java.util.Random` | | **PHP** | `openssl_encrypt("des-…"/"…-ecb")`, `mcrypt_*`; `md5()`/`sha1()`, `hash("md5", …)`; `rand()`/`mt_rand()` | | **Ruby** | `OpenSSL::Cipher.new("des-…")`, `:ECB`; `Digest::MD5/SHA1`; `rand()`/`Random` | | **Rust** | `Rc4::`, `Blowfish::`, `des::`, `ecb::`; `Md5::`, `Sha1::`, `Hmac`; `SmallRng`/`XorShiftRng` | | **C#** | `DES/TripleDES/RC2.Create`, `CipherMode.ECB`; `MD5/SHA1.Create`, `HMACMD5`; `new Random()` | | **C / C++** | OpenSSL के `DES_*`/`RC4`/`EVP_des_*`, `EVP_*_ecb`; `MD5()`/`SHA1()`, `EVP_md5`; `rand()`/`random()` | **पूरी कोशिश, पर हर चीज़ नहीं** यह सोर्स कोड को टेक्स्ट की तरह पढ़ता है, इसलिए रनटाइम पर जोड़ा गया, किसी alias के पीछे छिपा, या ऐसे रूप में लिखा गया प्रिमिटिव जिसे यह नहीं पहचानता, बचकर निकल सकता है। इस टेबल को एक मज़बूत शुरुआती आधार मानें, पूरी सूची नहीं। **टिप** हुक न्यूनतम आधार की गारंटी देता है (ये कंस्ट्रक्ट मौजूद हैं): कुंजी प्रबंधन, IV का दोबारा इस्तेमाल और RSA पैडिंग ऐसे मामले हैं जिनमें विवेक चाहिए, और उन्हें अब भी [`crypto` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) कवर करती है। ## अक्सर पूछे जाने वाले सवाल ### कोडबेस में कमज़ोर क्रिप्टोग्राफ़ी कैसे स्कैन करूँ? crypto हुक को बिना किसी फ़्लैग के चलाएँ। टूटे हुए सिफ़र और ECB मोड निष्कर्ष हैं, जिन पर हुक नॉन-ज़ीरो एग्ज़िट कोड देता है। MD5/SHA-1 डाइजेस्ट समीक्षा के लिए एक सुराग है, क्योंकि वह सुरक्षा के काम के लिए टूटा हुआ है, पर साधारण चेकसम के रूप में जायज़ है। ### क्या crypto हुक Math.random() को पकड़ता है? सिर्फ़ सुरक्षा वाले संदर्भ में, समीक्षा के सुराग के रूप में, कभी अपने-आप बनने वाले निष्कर्ष के रूप में नहीं, क्योंकि जिटर या UI के क्रम के लिए रैंडमनेस का इस्तेमाल जायज़ है। --- # cvss हुक: CVSS v4.0 वेक्टर को स्कोर दें > कमांड लाइन से एक या कई CVSS v4.0 वेक्टर को FIRST कैलकुलेटर वाले ही गणित से स्कोर दें, और हर वेक्टर का मतलब आसान शब्दों में पढ़ें। कैनोनिकल: https://lagune.ai/hi-IN/docs/hooks/cvss भाषा: hi-IN मूल: https://lagune.ai/docs/hooks/cvss आख़िरी अपडेट: 2026-11-06 `cvss` हुक किसी **CVSS v4.0 वेक्टर** को स्कोर देता है और उसका स्कोर और गंभीरता का स्तर छापता है। यही वह रेटिंग है जो [`/lagune-plan`](https://lagune.ai/hi-IN/docs/commands/plan) कमांड हर सुधार पर और [`/lagune-prove`](https://lagune.ai/hi-IN/docs/commands/prove) कमांड हर सुरक्षा एडवाइज़री पर लिखती है। यह उन रेटिंग के पीछे का नियतात्मक इंजन है, जो [FIRST कैलकुलेटर](https://www.first.org/cvss/calculator/4.0) वाला ही गणित इस्तेमाल करता है, और आप इसे खुद चला सकते हैं। ## चलाएँ हर वेक्टर `--vector` के साथ दें। हुक हर वेक्टर के लिए एक लाइन छापता है: उसका स्कोर और स्तर। **एक वेक्टर** ```bash npx lagune read cvss --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' # => 9.3, Critical ``` **कई वेक्टर** एक साथ कई वेक्टर को स्कोर देने के लिए `--vector` दोहराएँ। हर वेक्टर के लिए एक लाइन आती है, उसी क्रम में। ```bash npx lagune read cvss \ --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' \ --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A' # => 9.3, Critical # => 8.7, High ``` **आसान शब्दों में** हर मेट्रिक का मतलब आसान शब्दों में पढ़ने के लिए `--explain` जोड़ें। जब Threat या Environmental मेट्रिक स्कोर बदलते हैं, तो पहले सिर्फ़ Base स्कोर आता है। ```bash npx lagune read cvss --explain --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A' # => 8.7, High # => Base metrics alone: 9.3, Critical # => Attack Vector: Network, modified to Adjacent # => Attack Complexity: Low # => ... ``` ## नतीजा कैसे पढ़ें | स्तर | स्कोर | | ---------- | ----------- | | `None` | 0.0 | | `Low` | 0.1 से 3.9 | | `Medium` | 4.0 से 6.9 | | `High` | 7.0 से 8.9 | | `Critical` | 9.0 से 10.0 | सिर्फ़ Base मेट्रिक वाला वेक्टर ख़ामी को ही स्कोर देता है और सबसे बुरी स्थिति मानकर चलता है: हर सुरक्षा ज़रूरत High है और ख़ामी पर असल दुनिया में हमले हो रहे हैं। Environmental मेट्रिक (`MAV` और बाकी मॉडिफ़ाइड मेट्रिक, साथ में `CR`, `IR` और `AR`) स्कोर को किसी एक डिप्लॉयमेंट के हिसाब से तय करते हैं, और Threat मेट्रिक (`E`) एक्सप्लॉइट के बारे में जो जानकारी है उसके हिसाब से। अमान्य वेक्टर पर `invalid vector:` के साथ यह छपता है कि क्या ग़लत है, और हुक नॉन-ज़ीरो एग्ज़िट कोड देता है। ### CLI विकल्प | विकल्प | वैल्यू | विवरण | | ----------- | -------------------- | ---------------------------------------------------------------------------------------------------- | | `--vector` | एक `CVSS:4.0` वेक्टर | एक वेक्टर को स्कोर दें। कई को स्कोर देने के लिए इसे दोहराएँ, हर वेक्टर के लिए एक लाइन, उसी क्रम में। | | `--explain` | | हर रेटिंग लाइन के नीचे हर मेट्रिक का मतलब आसान शब्दों में जोड़ें। | कम से कम एक `--vector` ज़रूरी है। वेक्टर कभी अकेला पोज़िशनल आर्ग्युमेंट नहीं होता, इसलिए उसे फ़्लैग समझने की ग़लती नहीं हो सकती। **फ़्लैग वैल्यू क्यों** हर वेक्टर फ़्लैग वैल्यू के रूप में दिया जाता है, उसे कभी कमांड के अंदर जोड़कर नहीं लिखा जाता। कोट या बैकटिक वाली वैल्यू भी बेअसर रहती है और शेल में इंजेक्ट नहीं हो सकती। इसे हमेशा सिंगल कोट में रखें, ताकि आपका शेल पहले ही इसे एक्सपैंड न कर दे। **यह क्या कवर नहीं करता** सिर्फ़ CVSS v4.0: v2.0, v3.0 या v3.1 वेक्टर को स्कोर देने के बजाय ठुकरा दिया जाता है, क्योंकि **Lagune** हर निष्कर्ष को v4.0 में स्कोर देता है। **टिप** plan चरण की जाँच हर CVSS लाइन पर यही गणित दोबारा चलाती है, इसलिए अपने वेक्टर से भटका हुआ स्कोर योजना स्वीकार होने से पहले ही पकड़ में आ जाता है। ## अक्सर पूछे जाने वाले सवाल ### Lagune CVSS स्कोर कैसे निकालता है? cvss हुक CVSS v4.0 के लिए FIRST के रेफ़रेंस कैलकुलेटर का पालन करता है, इसलिए किसी वेक्टर का स्कोर ठीक वही आता है जो FIRST की साइट पर आता है। ### क्या मैं इससे CVSS v3.1 वेक्टर को स्कोर दे सकता हूँ? नहीं। Lagune हर निष्कर्ष को CVSS v4.0 में स्कोर देता है, और हुक किसी भी दूसरे वर्ज़न को स्कोर देने के बजाय ठुकरा देता है। ### --explain फ़्लैग क्या करता है? यह हर मेट्रिक का मतलब आसान शब्दों में बताता है और कुल स्कोर के बगल में Base स्कोर दिखाता है, ताकि कोई भी देख सके कि वेक्टर क्या कहता है और प्रोजेक्ट के संदर्भ ने स्कोर को कैसे बदला। --- # infra हुक: IaC की ग़लत कॉन्फ़िगरेशन पकड़ें > कमांड लाइन से Terraform, Dockerfile और GitHub Actions में ग़लत कॉन्फ़िगरेशन खोजें, या कोड के किसी एक टुकड़े को स्कोर दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/hooks/infra भाषा: hi-IN मूल: https://lagune.ai/docs/hooks/infra आख़िरी अपडेट: 2026-11-06 `infra` हुक **इंफ़्रास्ट्रक्चर-ऐज़-कोड की ऐसी ग़लत कॉन्फ़िगरेशन** पकड़ता है जो फ़ाइल को देखकर ही तय की जा सकती है: पूरी दुनिया के लिए खुला नेटवर्क, वाइल्डकार्ड परमिशन, मैनिफ़ेस्ट में रखा सीक्रेट, root के रूप में चलने वाला कंटेनर, CI शेल में पहुँचने वाली अविश्वसनीय वैल्यू। यह सिर्फ़ IaC फ़ाइलें पढ़ता है (`.tf`/`.tf.json`/`.hcl`, `Dockerfile*`, `.github/workflows/**`)। यह [`infra` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) के पीछे का नियतात्मक इंजन है, जो **scan** या **check** मोड में चलता है। ## चलाएँ **कोडबेस स्कैन करें** ```bash npx lagune read infra # scans every IaC file npx lagune read infra --dir infra # scans a directory npx lagune read infra --file Dockerfile # scans a single file ``` **कोड का टुकड़ा जाँचें** कोड का टुकड़ा `--pattern` के साथ दें और उसका प्रकार `--kind` के साथ (`terraform`, `dockerfile` या `github-actions`)। ```bash npx lagune read infra --kind terraform --pattern 'actions = ["*"]' # => iam-wildcard npx lagune read infra --kind dockerfile --pattern 'FROM node:20' # => mutable-tag ``` स्कैन ज़्यादा से ज़्यादा दो सेक्शन छापता है। **Infrastructure risks found** नॉन-ज़ीरो एग्ज़िट कोड देता है और उसमें वे ख़ामियाँ होती हैं जो फ़ाइल से तय की जा सकती हैं (किसी संवेदनशील पोर्ट पर `0.0.0.0/0` इनग्रेस, वाइल्डकार्ड IAM स्टेटमेंट, मैनिफ़ेस्ट में रखा सीक्रेट, `encrypted = false`, बिना पिन किया गया git मॉड्यूल, साफ़ तौर पर root के रूप में चलने वाली इमेज, `curl | sh`, CI स्क्रिप्ट इंजेक्शन, `permissions: write-all`)। **Infrastructure hardening advisories** एग्ज़िट कोड नहीं बदलता (बदल सकने वाला बेस टैग, टैग से पिन किया गया action)। कुछ न मिलने पर यह `no infrastructure risks found` छापता है। ## फ़ैसला कैसे पढ़ें check मोड मेल खाने वाले टैग में से सबसे ज़्यादा गंभीरता वाला टैग छापता है (जैसे `public-ingress`, `iam-wildcard`, `root-user`, `curl-pipe`, `script-injection`, `write-all`), या कोई एडवाइज़री टैग (`mutable-tag`, `unpinned-action`), या `safe`। सिर्फ़ निष्कर्ष के स्तर की गंभीरता वाले टैग पर ही हुक नॉन-ज़ीरो एग्ज़िट कोड देता है। ### CLI विकल्प | विकल्प | वैल्यू | विवरण | | ----------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------- | | `--pattern` | कोड का टुकड़ा | कोड का एक टुकड़ा जाँचें। इसके साथ `--kind` ज़रूरी है। कई के लिए इसे दोहराएँ। | | `--kind` | `terraform` \| `dockerfile` \| `github-actions` | कोड के टुकड़े को किस प्रकार के रूप में आँका जाए। | | `--dir` | एक डायरेक्टरी | स्कैन को एक डायरेक्टरी तक सीमित करें। इसे दोहराया जा सकता है और `--file` के साथ जोड़ा जा सकता है। | | `--file` | एक फ़ाइल | स्कैन को एक फ़ाइल तक सीमित करें। इसे दोहराया जा सकता है और `--dir` के साथ जोड़ा जा सकता है। | कोई विकल्प न देने पर यह प्रोजेक्ट की हर IaC फ़ाइल स्कैन करता है। `--pattern` को `--dir` या `--file` के साथ नहीं जोड़ा जा सकता। ### चुनें कि यह क्या स्कैन करे यह उन चीज़ों को छोड़ देता है जिन्हें **Git** अनदेखा करता है। और ज़्यादा छोड़ने के लिए, या **Git** की अनदेखी चीज़ों को भी स्कैन करने के लिए, `infra` को उसकी अपनी सेटिंग्स दें: ```bash npx lagune write add --ignore examples --checker infra ``` ```json { "checkers": { "infra": { "gitignore": false, "ignore": ["examples"] } } } ``` हर सेटिंग की जानकारी [हुक कॉन्फ़िगर करें](https://lagune.ai/hi-IN/docs/hooks/configure) पेज पर है। **टिप** हुक सीधे और तय किए जा सकने वाले मामले पकड़ता है: एन्क्रिप्शन का न होना, `pull_request_target` से होने वाला एक्सपोज़र और सही IAM दायरा ऐसे मामले हैं जिनमें विवेक चाहिए, और उन्हें अब भी [`infra` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) कवर करती है। ## अक्सर पूछे जाने वाले सवाल ### infra हुक कौन-सी इंफ़्रास्ट्रक्चर फ़ाइलें पढ़ता है? Terraform/HCL (.tf, .tf.json, .hcl), Dockerfile, और .github/ के अंदर GitHub Actions की वर्कफ़्लो और action YAML फ़ाइलें। सोर्स स्कैनर इन फ़ाइलों को छोड़ देते हैं, फिर भी यह हुक इन तक पहुँचता है। --- # interpreter हुक: डायनैमिक कोड एक्ज़ीक्यूशन सिंक पकड़ें > कमांड लाइन से कोडबेस को स्कैन करके कई भाषाओं में डायनैमिक कोड एक्ज़ीक्यूशन सिंक पकड़ें, या कोड के एक टुकड़े को स्कोर दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/hooks/interpreter भाषा: hi-IN मूल: https://lagune.ai/docs/hooks/interpreter आख़िरी अपडेट: 2026-11-06 `interpreter` हुक **डायनैमिक कोड एक्ज़ीक्यूशन सिंक** पकड़ता है: ऐसी बनावटें जो डेटा को चलने वाले कोड में बदल देती हैं या उसे शेल को सौंप देती हैं, `eval` से लेकर नेटिव डीसीरियलाइज़ेशन तक। यह भाषा को समझता है और हर फ़ाइल को उसकी अपनी भाषा के नियमों से पढ़ता है। यही [`interpreter` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) के पीछे का नियतात्मक इंजन है, जिसे आप खुद **scan** या **check** मोड में चला सकते हैं। ## चलाएँ **कोडबेस स्कैन करें** ```bash npx lagune read interpreter # scans the whole project npx lagune read interpreter --dir src # scans a directory npx lagune read interpreter --file app.py # scans a single file ``` **कोड का टुकड़ा जाँचें** ```bash npx lagune read interpreter --lang javascript --pattern 'eval(x)' # => careful npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe ``` ये सिंक दोहरे इस्तेमाल वाले हैं: हमलावर के असर वाला इनपुट किसी सिंक तक पहुँचता है या नहीं, यह कोई स्टैटिक स्कैन तय नहीं कर सकता, इसलिए हर मैच **समीक्षा के लिए एक चेतावनी** है, पक्का निष्कर्ष कभी नहीं। स्कैन फ़ाइल के हिसाब से समूह बनाकर एक ही **Dynamic-execution sinks to review** सेक्शन प्रिंट करता है। कुछ न मिलने पर यह `no dynamic-execution sinks found` प्रिंट करता है। **पकड़ा गया कोड पढ़ें, उसे कभी न चलाएँ!** हर सिंक को **स्टैटिक** तरीके से परखें, यह खोजते हुए कि अविश्वसनीय इनपुट उस तक पहुँचता है या नहीं। पकड़ा गया कोड क्या करता है, यह "टेस्ट" करने के लिए उसे कभी न चलाएँ, न ही `eval` करें। यही बात उस रिमोट कोड या रनटाइम पर लाए गए कोड पर भी लागू होती है, जिसे वह अपने साथ खींच लाता है। ## फ़ैसला कैसे पढ़ें | फ़ैसला | मतलब | | --------- | ------------------------------------------------------------------------------------------------- | | `careful` | कोड के इस टुकड़े में उसकी भाषा का एक डायनैमिक एक्ज़ीक्यूशन सिंक है। इसे चलाकर नहीं, पढ़कर जाँचें। | | `safe` | दी गई भाषा के लिए कोई डायनैमिक एक्ज़ीक्यूशन सिंक नहीं मिला। | ### CLI विकल्प | विकल्प | मान | विवरण | | ----------- | ---------------- | ----------------------------------------------------------------------------------------------------------- | | `--pattern` | कोड का एक टुकड़ा | कोड का एक टुकड़ा जाँचें। कई टुकड़े जाँचने के लिए इसे दोहराएँ, हर लाइन पर एक फ़ैसला मिलेगा। | | `--lang` | एक भाषा | `--pattern` के साथ ज़रूरी: javascript, python, php, ruby, java, kotlin, go, rust, c, cpp, csharp में से एक। | | `--dir` | एक डायरेक्टरी | स्कैन को एक डायरेक्टरी तक सीमित करें। इसे दोहराया जा सकता है और `--file` के साथ जोड़ा जा सकता है। | | `--file` | एक फ़ाइल | स्कैन को एक फ़ाइल तक सीमित करें। इसे दोहराया जा सकता है और `--dir` के साथ जोड़ा जा सकता है। | कोई विकल्प न देने पर यह पूरे प्रोजेक्ट को स्कैन करता है। `--pattern` के लिए `--lang` ज़रूरी है, और इसे `--dir` या `--file` के साथ नहीं जोड़ा जा सकता। ### क्या स्कैन हो, यह चुनें **Git** जिन चीज़ों को अनदेखा करता है, यह उन्हें छोड़ देता है। और चीज़ें छोड़ने के लिए, या **Git** की अनदेखी की गई चीज़ों को भी स्कैन करने के लिए, `interpreter` को उसकी अपनी सेटिंग दें: ```bash npx lagune write add --ignore test/fixtures --checker interpreter ``` ```json { "checkers": { "interpreter": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [हुक कॉन्फ़िगर करें](https://lagune.ai/hi-IN/docs/hooks/configure) पेज पर हर सेटिंग की जानकारी है। ### समर्थित भाषाएँ स्कैन इन भाषाओं को फ़ाइल एक्सटेंशन से पहचानकर पढ़ता है, और हर भाषा को उसके अपने डायनैमिक एक्ज़ीक्यूशन सिंक की सूची से जाँचता है। | # | भाषा | एक्सटेंशन | यह कौन-से सिंक पकड़ता है | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | `eval()`, Function कंस्ट्रक्टर, स्ट्रिंग बॉडी वाला `setTimeout`/`setInterval`, `vm` मॉड्यूल, `child_process` exec, डायनैमिक `require()`, डायनैमिक `import()` | | 2 | **Python** | `.py`, `.pyi` | `eval`/`exec`, `__import__()`, `os.system`/`os.popen`, `subprocess` `shell=True`, `pickle.load`/`loads`, `yaml.load` (असुरक्षित) | | 3 | **Ruby** | `.rb` | eval परिवार (`instance_eval`/`class_eval`/`module_eval`/`eval`), `system`/`exec`, बैकटिक या `%x`, `Kernel#open` / `IO.popen`/`read`/`binread` / `Open3`, `Process.spawn`, `Marshal.load` | | 4 | **Go** | `.go` | `exec.Command`/`exec.CommandContext`, `plugin.Open` | | 5 | **PHP** | `.php` | `eval()`, स्ट्रिंग पर `assert()`, `create_function()`, शेल exec (`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`), `call_user_func`/`call_user_func_array`, रनटाइम पाथ के साथ `include`/`require` | | 6 | **Rust** | `.rs` | `Command::new`, `process::Command` | | 7 | **Java** | `.java` | `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 8 | **Kotlin** | `.kt`, `.kts` | JVM वाले सिंक: `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 9 | **C#** | `.cs` | `Process.Start` / `new Process`, `BinaryFormatter`, `Assembly.Load` | | 10 | **C** | `.c`, `.h` | `system()`, `popen()`, `exec*` परिवार (`execl`, `execve`, `execvp`, …) | | 11 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | `system()`, `popen()`, `exec*` परिवार (`execl`, `execve`, `execvp`, …) | **पूरी कोशिश, पर हर मामला नहीं** यह सोर्स कोड को टेक्स्ट की तरह पढ़ता है, इसलिए रनटाइम पर जोड़ा गया, किसी एलियास के पीछे छिपा, या ऐसे रूप में लिखा गया सिंक जिसे यह नहीं पहचानता, इसकी पकड़ से छूट सकता है। इस टेबल को पूरी सूची नहीं, बल्कि एक मज़बूत शुरुआती आधार मानें। **टिप** हुक न्यूनतम आधार की गारंटी देता है (ये सिंक मौजूद हैं, और कहाँ हैं): कोई अविश्वसनीय मान सच में किसी सिंक तक पहुँचता है या नहीं, यह आकलन [`interpreter` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) के दायरे में आता है। ## अक्सर पूछे जाने वाले सवाल ### क्या interpreter हुक किसी कमज़ोरी की पुष्टि करता है? नहीं। यह डायनैमिक एक्ज़ीक्यूशन सिंक को समीक्षा के लिए एक चेतावनी के रूप में पकड़ता है, पक्के निष्कर्ष के रूप में कभी नहीं, क्योंकि हमलावर के असर वाला इनपुट सिंक तक पहुँचता है या नहीं, यह कोई स्टैटिक स्कैन तय नहीं कर सकता। ### interpreter हुक किन भाषाओं को सपोर्ट करता है? यह "समर्थित भाषाएँ" टेबल की भाषाओं को फ़ाइल एक्सटेंशन से पहचानकर पढ़ता है, और हर भाषा को उसके अपने सिंक की सूची से जाँचता है। दूसरी भाषाओं में यह कोई सिंक नहीं बताता। --- # jwt हुक: बिना तय एल्गोरिदम वाला JWT वेरिफ़िकेशन पकड़ें > कमांड लाइन से कोडबेस को स्कैन करके बिना तय एल्गोरिदम वाला JWT वेरिफ़िकेशन खोजें, या किसी एक कॉल को स्कोर दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/hooks/jwt भाषा: hi-IN मूल: https://lagune.ai/docs/hooks/jwt आख़िरी अपडेट: 2026-11-06 `jwt` हुक **बिना तय एल्गोरिदम वाला JWT वेरिफ़िकेशन** पकड़ता है, यानी एल्गोरिदम कन्फ़्यूज़न की वह कमज़ोरी जिसमें वेरिफ़ाई करने वाला कोड टोकन के अपने `alg` हेडर पर भरोसा कर लेता है, और साथ ही **पूरी तरह बंद किया गया वेरिफ़िकेशन** भी पकड़ता है। यह **भाषा को समझता है** और हर फ़ाइल को उसकी अपनी JWT लाइब्रेरी के हिसाब से पढ़ता है। यही [`federation` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) के पीछे का नियतात्मक इंजन है, जिसे आप खुद **scan** या **check** मोड में चला सकते हैं। ## चलाएँ **कोडबेस स्कैन करें** ```bash npx lagune read jwt # scans the whole project npx lagune read jwt --dir src # scans a directory npx lagune read jwt --file auth.ts # scans a single file ``` **एक कॉल जाँचें** ```bash npx lagune read jwt --lang javascript --pattern 'jwt.verify(token, secret)' # => unpinned npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, options={"verify_signature": False})' # => unpinned npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, algorithms=["HS256"])' # => safe ``` **Unpinned JWT verification found** के नीचे की हर लाइन एक ऐसी वेरिफ़ाई कॉल है जो या तो कोई `algorithms` अनुमति सूची तय नहीं करती (जहाँ लाइब्रेरी को इसकी ज़रूरत है), या असुरक्षित सूची स्वीकार करती है (`none`, या HMAC के साथ मिला कोई एसिमेट्रिक एल्गोरिदम), या सिग्नेचर की जाँच ही पूरी तरह बंद कर देती है, और इस तरह टोकन के अपने `alg` पर भरोसा कर लेती है। यह पुष्ट जोखिम है, इसलिए हुक नॉन-ज़ीरो कोड के साथ बाहर निकलता है। कुछ न मिलने पर यह `no unpinned JWT verification found` प्रिंट करता है। ## फ़ैसला कैसे पढ़ें | फ़ैसला | मतलब | | ---------- | -------------------------------------------------------------------------------------------------------------------- | | `unpinned` | ऐसी वेरिफ़ाई कॉल जिसमें एल्गोरिदम की अनुमति सूची नहीं है (जहाँ ज़रूरी है), सूची असुरक्षित है, या वेरिफ़िकेशन बंद है। | | `safe` | ऐसी वेरिफ़ाई कॉल जो एल्गोरिदम की सुरक्षित अनुमति सूची तय करती है, या जिसकी लाइब्रेरी इसे अपने आप तय कर देती है। | | `invalid` | कोड के इस टुकड़े में जाँचने लायक कोई पहचानी जा सकने वाली वेरिफ़ाई कॉल नहीं है। | ### CLI विकल्प | विकल्प | मान | विवरण | | ----------- | ---------------- | --------------------------------------------------------------------------------------------------- | | `--pattern` | कोड का एक टुकड़ा | एक कॉल जाँचें। कई कॉल जाँचने के लिए इसे दोहराएँ, हर लाइन पर एक फ़ैसला मिलेगा। | | `--lang` | एक भाषा | `--pattern` के साथ ज़रूरी: javascript, python, go, java, kotlin, php, ruby, rust, csharp में से एक। | | `--dir` | एक डायरेक्टरी | स्कैन को एक डायरेक्टरी तक सीमित करें। इसे दोहराया जा सकता है और `--file` के साथ जोड़ा जा सकता है। | | `--file` | एक फ़ाइल | स्कैन को एक फ़ाइल तक सीमित करें। इसे दोहराया जा सकता है और `--dir` के साथ जोड़ा जा सकता है। | कोई विकल्प न देने पर यह पूरे प्रोजेक्ट को स्कैन करता है। `--pattern` के लिए `--lang` ज़रूरी है, और इसे `--dir` या `--file` के साथ नहीं जोड़ा जा सकता। ### क्या स्कैन हो, यह चुनें **Git** जिन चीज़ों को अनदेखा करता है, यह उन्हें छोड़ देता है। और चीज़ें छोड़ने के लिए, या **Git** की अनदेखी की गई चीज़ों को भी स्कैन करने के लिए, `jwt` को उसकी अपनी सेटिंग दें: ```bash npx lagune write add --ignore test/fixtures --checker jwt ``` ```json { "checkers": { "jwt": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [हुक कॉन्फ़िगर करें](https://lagune.ai/hi-IN/docs/hooks/configure) पेज पर हर सेटिंग की जानकारी है। ### समर्थित भाषाएँ स्कैन इन लाइब्रेरी को फ़ाइल एक्सटेंशन से पहचानकर पढ़ता है। कुछ लाइब्रेरी एल्गोरिदम को अपने आप तय कर देती हैं (वहाँ अलग से सूची न होना सुरक्षित है), इसलिए "अनुमति सूची नहीं ⇒ unpinned" वाला नियम सिर्फ़ वहीं लागू होता है जहाँ लाइब्रेरी अलग से सूची की उम्मीद करती है। इस तरह सही ढंग से कॉन्फ़िगर की गई कॉल कभी नहीं पकड़ी जाती। | भाषा | लाइब्रेरी | अनुमति सूची न होने पर unpinned मानता है? | हमेशा पकड़ता है | | --------------------------- | ----------------------- | -------------------------------------------------------------------------- | ------------------------------------------------ | | **JavaScript / TypeScript** | jsonwebtoken, jose | हाँ | `none`, एसिमेट्रिक और HMAC का मेल | | **Python** | PyJWT, python-jose | हाँ (PyJWT में यह ज़रूरी है, python-jose का डिफ़ॉल्ट `algorithms=None` है) | `none`, `verify_signature: False` | | **Go** | golang-jwt | हाँ (`WithValidMethods` न होने पर) | `none`, `ParseUnverified` | | **Ruby** | ruby-jwt | हाँ | `none`, `verify = false` | | **Java / Kotlin** | jjwt, nimbus | नहीं (एल्गोरिदम कुंजी से तय होता है) | `none`, बिना सिग्नेचर वाला या `unsecured` पार्सर | | **PHP** | firebase/php-jwt | नहीं (`Key` में एल्गोरिदम शामिल रहता है) | `none` | | **Rust** | jsonwebtoken | नहीं (`Validation` में एल्गोरिदम बताना ज़रूरी है) | `none`, `insecure_disable_signature_validation` | | **C#** | Microsoft.IdentityModel | नहीं (पैरामीटर कई लाइनों में फैले होते हैं) | `none`, `RequireSignedTokens = false` | **टिप** हुक सिर्फ़ एल्गोरिदम तय होने का फ़ैसला करता है: क्लेम, कुंजी और फ़्लो की जाँच ऐसे आकलन हैं जो अब भी [`federation` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) के दायरे में आते हैं। ## अक्सर पूछे जाने वाले सवाल ### JWT एल्गोरिदम कन्फ़्यूज़न क्या है? अगर वेरिफ़ाई करने वाला कोड टोकन के हेडर से एल्गोरिदम पढ़ता है, तो हमलावर RS256 की जगह HS256 रखकर पब्लिक कुंजी से साइन कर सकता है। कोड में एल्गोरिदम की सुरक्षित अनुमति सूची तय करने से यह रुकता है, और jwt हुक ऐसी वेरिफ़ाई कॉल पकड़ता है जो कोई सूची तय नहीं करती या असुरक्षित सूची तय करती है। --- # network हुक: SSRF के लिए URL को स्कोर दें > कमांड लाइन से सीधे एक या कई फ़ेच डेस्टिनेशन को SSRF के लिहाज़ से स्कोर दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/hooks/network भाषा: hi-IN मूल: https://lagune.ai/docs/hooks/network आख़िरी अपडेट: 2026-11-06 `network` हुक तय करता है कि सर्वर की ओर से किया जाने वाला कोई फ़ेच डेस्टिनेशन **SSRF** से सुरक्षित है या नहीं (ऐसी रिक्वेस्ट जिसे इंटरनल सर्विस, क्लाउड मेटाडेटा या प्राइवेट होस्ट की ओर मोड़ा जा सकता है)। यही [`network` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) के पीछे का नियतात्मक इंजन है, और आप इसे खुद भी चला सकते हैं। ## चलाएँ हर डेस्टिनेशन `--url` के साथ दें। हुक हर डेस्टिनेशन के लिए एक शब्द प्रिंट करता है, जिसका मतलब नीचे की टेबल में देखें। **एक डेस्टिनेशन** ```bash npx lagune read network --url 'http://example.com/' # => safe npx lagune read network --url 'http://0x7f000001/' # => private-target ``` **कई डेस्टिनेशन** पूरी अनुमति सूची या ब्लॉक सूची को एक ही कॉल में स्कोर देने के लिए `--url` दोहराएँ। फ़ैसले उसी क्रम में, हर लाइन पर एक, मिलते हैं। ```bash npx lagune read network \ --url 'http://example.com/' \ --url 'http://[::1]/' \ --url 'http://allowed.com@evil.example/' # => safe # => private-target # => parser-divergent ``` यह होस्ट को ठीक उसी तरह पढ़ता है जैसे नेटवर्क पढ़ता है, इसलिए किसी इंटरनल पते के एनकोड किए गए रूप इसकी पकड़ से नहीं बचते: हेक्स, ऑक्टल, बिना डॉट वाला डेसिमल, छोटा रूप, IPv6 और IPv4-mapped, सभी का फ़ैसला `private-target` आता है। और जहाँ कोई ढीला वैलिडेटर और असली फ़ेच करने वाला कोड अलग-अलग होस्ट पढ़ें, वहाँ फ़ैसला `parser-divergent` आता है। ## फ़ैसला कैसे पढ़ें | फ़ैसला | मतलब | | ------------------ | ------------------------------------------------------------------------------------------------ | | `safe` | डेस्टिनेशन किसी पब्लिक होस्ट से जुड़ता है, और कोई ढीला वैलिडेटर भी वही होस्ट पढ़ेगा। | | `private-target` | होस्ट किसी प्राइवेट, लूपबैक, लिंक-लोकल, अनिर्दिष्ट या क्लाउड मेटाडेटा पते पर पहुँचता है। | | `parser-divergent` | कोई ढीला टेक्स्ट वैलिडेटर उस होस्ट से अलग असली होस्ट पढ़ेगा, जिससे फ़ेच करने वाला कोड जुड़ता है। | | `invalid url` | यह स्ट्रिंग URL के रूप में पार्स नहीं होती, इसलिए फ़ेच करने के लिए कुछ है ही नहीं। | सिर्फ़ `safe` का मतलब अनुमति है। `private-target`, `parser-divergent` और `invalid url`, तीनों को ब्लॉक मानें। ### CLI विकल्प | विकल्प | मान | विवरण | | ------- | --------------- | -------------------------------------------------------------------------------- | | `--url` | एक URL या होस्ट | एक डेस्टिनेशन जाँचें। कई जाँचने के लिए इसे दोहराएँ, हर लाइन पर एक फ़ैसला मिलेगा। | कम से कम एक `--url` ज़रूरी है। डेस्टिनेशन कभी अकेले पोज़िशनल आर्ग्युमेंट के रूप में नहीं दिया जाता, इसलिए उसे किसी फ़्लैग के रूप में गलत नहीं समझा जा सकता। **फ़्लैग का मान क्यों** हर डेस्टिनेशन फ़्लैग के मान के रूप में दिया जाता है, उसे कमांड के अंदर कभी जोड़ा नहीं जाता। कोट या बैकटिक वाला मान भी बेअसर रहता है और शेल में इंजेक्ट नहीं हो सकता। इसे हमेशा सिंगल कोट में रखें, ताकि आपका शेल पहले ही उसे एक्सपैंड न कर दे। **यह किन चीज़ों को कवर नहीं करता** हुक पूरी तरह ऑफ़लाइन जाँच करता है और कभी DNS रिज़ॉल्व नहीं करता, इसलिए रनटाइम की दो कमियाँ इसके दायरे से बाहर हैं: **DNS रीबाइंडिंग** (ऐसा नाम जो जाँच के समय पब्लिक पते पर और फ़ेच के समय इंटरनल पते पर पहुँचता है) और **रीडायरेक्ट चेन** (पहला पड़ाव जाँच में पास हो जाता है, फिर अंदर की ओर रीडायरेक्ट करता है)। इन्हें बंद करने के लिए नाम को एक ही बार रिज़ॉल्व करें और जाँचे गए पते से ही जुड़ें, और रीडायरेक्ट को मना कर दें। आरक्षित लूपबैक नामों (`localhost` और `.localhost` परिवार) को यह बिना लुकअप के इंटरनल मान लेता है, लेकिन बाकी हर DNS नाम का फ़ैसला `safe` आता है, क्योंकि यह कहने के लिए कि वह अंदर की ओर पहुँचता है, उसे रिज़ॉल्व करना पड़ेगा: ऐसे नामों की रखवाली अनुमति सूची करती है, और यह चेकर उसी सूची को जाँचता है। **टिप** यह वही जाँच है जो [`network` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) यह साबित करने के लिए चलाती है कि डेस्टिनेशन फ़िल्टर कारगर है। ## अक्सर पूछे जाने वाले सवाल ### किसी URL में SSRF का जोखिम है या नहीं, यह कैसे टेस्ट करूँ? network हुक चलाएँ। यह फ़ेच डेस्टिनेशन को स्कोर देता है और safe, private-target, parser-divergent या invalid url लौटाता है। सिर्फ़ safe का मतलब अनुमति है। ### parser-divergent URL क्या है? ऐसा URL जिसे अलग-अलग पार्सर अलग-अलग तरह से पढ़ते हैं, जो SSRF से बचने का एक जाना-माना तरीका है। network हुक इसे अनुमति देने के बजाय पकड़ लेता है। --- # regex हुक: ReDoS पैटर्न पकड़ें > कमांड लाइन से कोडबेस को स्कैन करके ReDoS के खतरे वाले रेगेक्स खोजें, या किसी एक पैटर्न को स्कोर दें। कैनोनिकल: https://lagune.ai/hi-IN/docs/hooks/regex भाषा: hi-IN मूल: https://lagune.ai/docs/hooks/regex आख़िरी अपडेट: 2026-11-06 `regex` हुक वह नियतात्मक रेगेक्स-सुरक्षा इंजन है जिसे [`regex` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) चलाती है, और आप इसे खुद भी चला सकते हैं। एक ही कमांड से यह दो मोड में काम करता है: **scan**, जो कोडबेस में **ReDoS** के खतरे वाले और रनटाइम पर बनने वाले पैटर्न खोजता है, और **check**, जो आपके दिए गए किसी एक पैटर्न को स्कोर देता है। ## कोडबेस स्कैन करें कोई फ़्लैग न देने पर यह पूरे प्रोजेक्ट को स्कैन करता है। `--dir` स्कैन को एक डायरेक्टरी तक और `--file` एक फ़ाइल तक सीमित करता है। दोनों को दोहराया जा सकता है और वे मिलकर एक ही रिपोर्ट बनाते हैं, जिसमें हर फ़ाइल एक ही बार आती है, चाहे वह एक से ज़्यादा टारगेट के दायरे में हो। **पूरा प्रोजेक्ट** ```bash npx lagune read regex ``` **एक डायरेक्टरी** ```bash npx lagune read regex --dir src/services ``` **एक फ़ाइल** ```bash npx lagune read regex --file bin/import.pl ``` **कई टारगेट** ```bash npx lagune read regex --dir core --dir workers --file Sources/App/Router.swift ``` **सीमा के साथ** `--limit` स्कैन के लिए ReDoS की सीमा तय करता है (डिफ़ॉल्ट 25), जो check मोड वाली सीमा ही है। सीमा जितनी कम, जाँच उतनी सख़्त। ```bash npx lagune read regex --dir src/services --limit 15 ``` आउटपुट सादा टेक्स्ट है, और हर सेक्शन का हेडर बताता है कि उसे कैसे पढ़ें। कोई सेक्शन तभी दिखता है जब उसमें कोई निष्कर्ष हो। ```text Vulnerable regular expressions found: cmd/server/main.go ([a-z]+)+$ (exponential, search) Dynamically built regular expressions (review manually by simulating a constructed regex): app/payments.php crates/parser/lexer.rs lib/validate.py Static regex wrapped in a constructor (use a literal instead): config/token.rb ``` कुछ न मिलने पर यह एक ही लाइन प्रिंट करता है। ```bash npx lagune read regex --dir src/clean # => no unsafe patterns found ``` ### सेक्शन कैसे पढ़ें | सेक्शन | मतलब | | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Vulnerable regular expressions found` | ReDoS के खतरे वाले पैटर्न, फ़ाइल के हिसाब से समूह में, हर पैटर्न उसके नीचे इंडेंट करके। उसके बाद कोष्ठक में बताया जाता है कि वह असुरक्षित क्यों है, और अगर हों तो उसका स्कोप और उसके फ़्लैग भी। हर लाइन असुरक्षित है, इसलिए फ़ैसला दोहराया नहीं जाता। | | `Regular expressions the analysis could not settle (review manually)` | वे पैटर्न जिन पर विश्लेषण अपनी काम की सीमा के अंदर किसी नतीजे पर नहीं पहुँच सका, उसी तरह सूचीबद्ध। | | `Dynamically built regular expressions (review manually by simulating a constructed regex)` | वे फ़ाइलें जो किसी वेरिएबल से, स्ट्रिंगें जोड़कर या इंटरपोलेशन से रेगेक्स बनाती हैं। | | `Static regex wrapped in a constructor (use a literal instead)` | वे फ़ाइलें जो रेगेक्स कंस्ट्रक्टर को सादा स्ट्रिंग लिटरल देती हैं, जबकि रेगेक्स लिटरल ज़्यादा आसान है और रनटाइम कंपाइल से भी बचाता है। | पहला सेक्शन सुरक्षा से जुड़ा निष्कर्ष है। दूसरा और तीसरा अपने आप में निष्कर्ष नहीं हैं: वे ऐसे कोड की ओर इशारा करते हैं जिस पर कोई स्टैटिक जाँच फ़ैसला नहीं कर सकती, इसलिए उन्हें किसी इंसान को पढ़ना होगा। चौथा कोड को साफ़ बनाने का सुझाव है, सुरक्षा से जुड़ा निष्कर्ष नहीं। ### CLI विकल्प | विकल्प | मान | विवरण | | ----------- | ------------------------- | ------------------------------------------------------------------------------------------------------------- | | `--pattern` | रेगेक्स का सोर्स | एक पैटर्न जाँचें। कई पैटर्न जाँचने के लिए इसे दोहराएँ, हर पैटर्न के लिए एक फ़ैसला, उसी क्रम में। | | `--flags` | रेगेक्स फ़्लैग | हर `--pattern` को इन फ़्लैग के साथ जाँचें, जैसे `im`। यह सिर्फ़ check मोड पर लागू होता है। | | `--dir` | एक डायरेक्टरी | स्कैन को एक डायरेक्टरी तक सीमित करें। इसे दोहराया जा सकता है और `--file` के साथ जोड़ा जा सकता है। | | `--file` | एक फ़ाइल | स्कैन को एक फ़ाइल तक सीमित करें। इसे दोहराया जा सकता है और `--dir` के साथ जोड़ा जा सकता है। | | `--limit` | शून्य या धनात्मक पूर्णांक | ReDoS में दोहराव की सीमा तय करें (डिफ़ॉल्ट 25)। यह दोनों मोड पर लागू होता है। सीमा जितनी कम, जाँच उतनी सख़्त। | कोई विकल्प न देने पर यह पूरे प्रोजेक्ट को स्कैन करता है। `--pattern` check मोड है, और इसे `--dir` या `--file` के साथ नहीं जोड़ा जा सकता। ### क्या स्कैन हो, यह चुनें **Git** जिन चीज़ों को अनदेखा करता है, यह उन्हें छोड़ देता है। और चीज़ें छोड़ने के लिए, या **Git** की अनदेखी की गई चीज़ों को भी स्कैन करने के लिए, `regex` को उसकी अपनी सेटिंग दें: ```bash npx lagune write add --ignore test/fixtures --checker regex ``` ```json { "checkers": { "regex": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [हुक कॉन्फ़िगर करें](https://lagune.ai/hi-IN/docs/hooks/configure) पेज पर हर सेटिंग की जानकारी है। ### समर्थित भाषाएँ स्कैन इन भाषाओं को फ़ाइल एक्सटेंशन से पहचानकर पढ़ता है, हर भाषा को उसके अपने नियमों से, ताकि एक भाषा के पैटर्न को कभी दूसरी भाषा के नियमों से न जाँचा जाए। बाकी सब कुछ गलत नियमों से स्कैन करने के बजाय छोड़ दिया जाता है। | # | भाषा | एक्सटेंशन | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | | 2 | **Python** | `.py`, `.pyi` | | 3 | **Ruby** | `.rb` | | 4 | **Go** | `.go` | | 5 | **PHP** | `.php` | | 6 | **Rust** | `.rs` | | 7 | **Java** | `.java` | | 8 | **C#** | `.cs` | | 9 | **C** | `.c`, `.h` | | 10 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | | 11 | **Kotlin** | `.kt`, `.kts` | | 12 | **Swift** | `.swift` | | 13 | **Scala** | `.scala`, `.sc` | | 14 | **Dart** | `.dart` | | 15 | **PowerShell** | `.ps1`, `.psm1`, `.psd1` | | 16 | **Elixir** | `.ex`, `.exs` | | 17 | **Objective-C** | `.m`, `.mm` | | 18 | **R** | `.r` | | 19 | **Julia** | `.jl` | | 20 | **Clojure** | `.clj`, `.cljs`, `.cljc`, `.edn` | | 21 | **Crystal** | `.cr` | | 22 | **Nim** | `.nim`, `.nims` | | 23 | **V** | `.v` | | 24 | **D** | `.d` | | 25 | **Perl** | `.pl`, `.pm` | **पूरी कोशिश, पर हर मामला नहीं** यह सोर्स कोड को टेक्स्ट की तरह पढ़ता है, इसलिए रनटाइम पर जोड़े गए पैटर्न को नहीं परख सकता, और कई लाइनों में फैला, किसी एलियास के पीछे छिपा, या ऐसे रूप में लिखा गया पैटर्न जिसे यह नहीं पहचानता, इसकी पकड़ से छूट सकता है। इन सेक्शन को पूरी सूची नहीं, बल्कि एक मज़बूत शुरुआती आधार मानें, और जहाँ ये नहीं पहुँच सकते, वहाँ कोड पढ़ते रहें। ## एक पैटर्न जाँचें किसी पैटर्न को स्कोर देने के लिए उसका सोर्स `--pattern` के साथ दें। हुक एक शब्द प्रिंट करता है: `safe`, `unsafe`, `undetermined` (जब विश्लेषण पैटर्न पर नतीजे तक पहुँचने से पहले अपनी काम की सीमा तक पहुँच जाए), या `invalid regex`। कई पैटर्न एक साथ स्कोर करने के लिए `--pattern` दोहराएँ, हर पैटर्न के लिए एक फ़ैसला, उसी क्रम में। **एक पैटर्न** ```bash npx lagune read regex --pattern '(a+)+$' # => unsafe npx lagune read regex --pattern '^[a-z0-9_]{3,20}$' # => safe ``` **कई पैटर्न** ```bash npx lagune read regex --pattern '(a+)+$' --pattern '^[a-z]+$' # => unsafe # => safe ``` **फ़्लैग के साथ** `--flags` कॉल के हर `--pattern` को उन्हीं फ़्लैग के साथ जाँचता है जिनके साथ वह चलता है, क्योंकि फ़्लैग से बदल जाता है कि पैटर्न किन कैरेक्टर से मैच करता है। ```bash npx lagune read regex --pattern '^(?:a|A)+$' # => safe npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i' # => unsafe ``` **सीमा के साथ** `--limit` दोहराव की सीमा तय करता है (डिफ़ॉल्ट 25) और कॉल के हर `--pattern` पर लागू होता है। सीमा जितनी कम, जाँच उतनी सख़्त। ```bash npx lagune read regex --pattern 'a?a?a?' --limit 2 # => unsafe ``` **आर्ग्युमेंट कोट में क्यों** हर पैटर्न फ़्लैग के मान के रूप में दिया जाता है, उसे कमांड के अंदर कभी जोड़ा नहीं जाता। कोट या बैकटिक वाला मान भी बेअसर रहता है और शेल में इंजेक्ट नहीं हो सकता। पैटर्न को हमेशा सिंगल कोट में रखें, ताकि आपका शेल पहले ही उसे एक्सपैंड न कर दे। **टिप** यह वही इंजन है जिसे [`regex` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) चलाती है: scan से ReDoS की जाँच शुरू होती है, और check उस जाँच में सामने आए पैटर्न की पुष्टि करता है। ## अक्सर पूछे जाने वाले सवाल ### CLI से किसी रेगेक्स में ReDoS की जाँच कैसे करूँ? npx lagune read regex --pattern '' चलाएँ। यह safe, unsafe, undetermined या invalid regex लौटाता है। ### पूरे प्रोजेक्ट में असुरक्षित रेगेक्स कैसे स्कैन करूँ? कोडबेस पर regex हुक को scan मोड में चलाएँ। यह 25 समर्थित भाषाओं में ReDoS के खतरे वाले पैटर्न की रिपोर्ट देता है। --- # secrets हुक: हार्डकोड किए गए सीक्रेट पकड़ें > कमांड लाइन से कोडबेस को स्कैन करके हार्डकोड किए गए क्रेडेंशियल खोजें। कैनोनिकल: https://lagune.ai/hi-IN/docs/hooks/secrets भाषा: hi-IN मूल: https://lagune.ai/docs/hooks/secrets आख़िरी अपडेट: 2026-11-06 `secrets` हुक ऐसे **क्रेडेंशियल पकड़ता है जो सोर्स कोड में ही लिख दिए गए हैं**, बजाय एनवायरनमेंट से पढ़े जाने के। यह मान की सामग्री को नहीं, उसके **स्रोत** को देखता है (लिटरल है या एनवायरनमेंट से पढ़ा गया मान), इसलिए इसे सर्विस प्रोवाइडर के प्रीफ़िक्स की कोई पूरी सूची नहीं चाहिए, और फ़ॉल्स पॉज़िटिव लगभग नहीं के बराबर आते हैं। यही [`secrets` विशेषज्ञता](https://lagune.ai/hi-IN/docs/catalog) के पीछे का नियतात्मक इंजन है। प्रोवाइडर फ़ॉर्मैट के सिग्नेचर, कनेक्शन स्ट्रिंग में लिखे क्रेडेंशियल, और सीक्रेट जैसे नाम वाले आइडेंटिफ़ायर को दिया गया लिटरल, ये सब **भाषा से स्वतंत्र** हैं: एक ही स्ट्रिंग हर फ़ाइल में एक जैसी पढ़ी जाती है। सिंटैक्स पर निर्भर दो अनुमान, यानी हार्डकोड किए गए डिफ़ॉल्ट वाला एनवायरनमेंट लुकअप और लॉग सिंक तक पहुँचने वाला सीक्रेट, **भाषा को समझते हैं**, इसलिए JavaScript का `console.log` कभी किसी Rust फ़ाइल में नहीं खोजा जाता, और Python का `os.getenv("X", "default")` उसके अपने रूप में पहचाना जाता है। ## चलाएँ ```bash npx lagune read secrets # scans the whole project npx lagune read secrets --dir src # scans a directory npx lagune read secrets --file config.ts # scans a single file ``` स्कैन ज़्यादा से ज़्यादा दो सेक्शन प्रिंट करता है। **Hardcoded secrets found** निष्कर्षों का सेट है (सीक्रेट जैसे नाम वाले एनवायरनमेंट वेरिएबल का हार्डकोड किया गया डिफ़ॉल्ट, कनेक्शन स्ट्रिंग में लिखा क्रेडेंशियल, या चुने हुए प्रोवाइडर फ़ॉर्मैट से मेल खाता मान), इसलिए हुक नॉन-ज़ीरो कोड के साथ बाहर निकलता है। **Secret handling to review manually** सुरागों का सेट है: सीक्रेट जैसे नाम वाले आइडेंटिफ़ायर को दिया गया सादा लिटरल (उसका स्रोत तय किया जा सकता है, पर मान सच में सीक्रेट है या नहीं, यह नहीं), और लॉग या रिस्पॉन्स सिंक तक पहुँचने वाला सीक्रेट जैसे नाम वाला मान। कुछ न मिलने पर यह `no hardcoded secrets found` प्रिंट करता है। ### CLI विकल्प | विकल्प | मान | विवरण | | -------- | ------------- | ------------------------------------------------------------------------------------------------- | | `--dir` | एक डायरेक्टरी | स्कैन को एक डायरेक्टरी तक सीमित करें। इसे दोहराया जा सकता है और `--file` के साथ जोड़ा जा सकता है। | | `--file` | एक फ़ाइल | स्कैन को एक फ़ाइल तक सीमित करें। इसे दोहराया जा सकता है और `--dir` के साथ जोड़ा जा सकता है। | कोई विकल्प न देने पर यह पूरे प्रोजेक्ट को स्कैन करता है। ### क्या स्कैन हो, यह चुनें **Git** जिन चीज़ों को अनदेखा करता है, यह उन्हें छोड़ देता है। और चीज़ें छोड़ने के लिए, या **Git** की अनदेखी की गई चीज़ों को भी स्कैन करने के लिए, `secrets` को उसकी अपनी सेटिंग दें: ```bash npx lagune write add --ignore test/fixtures --checker secrets ``` ```json { "checkers": { "secrets": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [हुक कॉन्फ़िगर करें](https://lagune.ai/hi-IN/docs/hooks/configure) पेज पर हर सेटिंग की जानकारी है। ### भाषाओं का कवरेज एनवायरनमेंट डिफ़ॉल्ट वाला निष्कर्ष और लॉग सिंक वाला सुराग हर भाषा के अपने तय रूप पढ़ते हैं, इसलिए ये नीचे दी गई भाषाओं को कवर करते हैं और बाकी जगह कुछ नहीं बताते। बाकी तीन संकेत **हर** फ़ाइल पर चलते हैं। | संकेत | भाषाएँ | | --------------------- | ------------------------------------------------------------------------------- | | एनवायरनमेंट डिफ़ॉल्ट | JavaScript/TypeScript, Python, Ruby, PHP, Kotlin, Java, Go (`cmp.Or`), Rust, C# | | लॉग या रिस्पॉन्स सिंक | JavaScript/TypeScript, Python, Ruby, PHP, Java, Kotlin, Go, Rust, C, C++, C# | **क्या यह किसी नीति के ख़िलाफ़ है?** नहीं। किसी सीक्रेट का फ़ॉर्मैट पहचानकर यह चेतावनी देना कि वह कमिट हो गया है, एक आम रक्षात्मक टूल का काम है, ठीक वही जो gitleaks, trufflehog और GitHub push-protection करते हैं। हुक में सिर्फ़ पहचानने वाले सिग्नेचर (टोकन के सार्वजनिक **फ़ॉर्मैट**) होते हैं, कोई असली सीक्रेट कभी नहीं, और यह सीक्रेट को बाहर भेजने के बजाय ऑडिट करता है और समझाता है। ## अक्सर पूछे जाने वाले सवाल ### secrets हुक फ़ॉल्स पॉज़िटिव से कैसे बचता है? यह मान की सामग्री को नहीं, उसके स्रोत को देखता है। ज़्यादा भरोसे वाले फ़ॉर्मैट (प्रोवाइडर टोकन, एनवायरनमेंट के डिफ़ॉल्ट मान, कनेक्शन स्ट्रिंग) निष्कर्ष होते हैं, जिन पर हुक नॉन-ज़ीरो कोड के साथ बाहर निकलता है। सीक्रेट जैसे नाम वाले आइडेंटिफ़ायर को दिया गया सादा लिटरल समीक्षा का एक सुराग है, जिसकी पुष्टि करनी होती है, और वही आइडेंटिफ़ायर अगर process.env से पढ़ा जाए, तो उसे बिल्कुल नहीं पकड़ा जाता। --- # Lagune प्रॉम्प्ट के उदाहरण: Blue Team फ़्लो को ऑटोमेट करें > कॉपी करके तुरंत इस्तेमाल करने लायक़ Lagune प्रॉम्प्ट: सिर्फ़ पढ़ने वाला स्कैन, पूरा Blue Team फ़्लो और ज़ीरो ट्रस्ट ऑडिट, साथ ही किसी कमिट, ब्रांच या PR के diff, या किसी असली सुरक्षा घटना तक सीमित पहचान। कैनोनिकल: https://lagune.ai/hi-IN/docs/examples/prompts भाषा: hi-IN मूल: https://lagune.ai/docs/examples/prompts आख़िरी अपडेट: 2026-11-06 Lagune के कॉपी करने लायक़ प्रॉम्प्ट, जिन्हें आप सीधे अपने AI एजेंट में पेस्ट कर सकते हैं। ## 💧 हल्का स्कैन सिर्फ़ पढ़ने वाला एक स्कैन, जो ख़ुद कोड पढ़ता है और हर कमी को उसके सुधार के साथ बताता है, Blue Team फ़्लो चलाए बिना और Lagune की ट्रैकिंग में कुछ लिखे बिना। **टिप** यह प्लानिंग मोड में, और सुरक्षा सिद्धांत (`/lagune-charter`) तय होने पर बेहतर काम करता है। **🪼 डिफ़ॉल्ट** | पहलू | फ़ायदा और नुक़सान | स्तर | | ------------ | ------------------------------------------------------------- | ------------------- | | **मेहनत** | एक एजेंट स्कैन करता है और रिपोर्ट देता है, कोई सब-एजेंट नहीं। | 1/5 | | **समय** | तेज़। सिर्फ़ पढ़ने वाला एक ही दौर, कुछ भी लागू नहीं होता। | 2/5 | | **टोकन खपत** | मध्यम, साझा। पूरा स्कैन एक ही कॉन्टेक्स्ट में चलता है। | 2/5 | ```md /lagune तुम रक्षात्मक सुरक्षा में गहरी विशेषज्ञता रखने वाले साइबर सुरक्षा शोधकर्ता हो, और अपना ज्ञान और सटीकता बढ़ाने के लिए Lagune का इस्तेमाल कर रहे हो। वर्कस्पेस को ख़ुद स्कैन करो और जो भी कमी मिले, उसके साथ एक ठोस सुधार बताओ। यह एक अलग स्कैन है, Blue Team फ़्लो नहीं: detect, plan, harden या verify मत चलाना, और Lagune की ट्रैकिंग में कुछ भी मत लिखना। आख़िर में, मिली हुई हर कमी की सूची दो, हर एक के साथ उसकी गंभीरता और एक ठोस सुधार। ``` **🐬 मल्टी एजेंट** | पहलू | फ़ायदा और नुक़सान | स्तर | | ------------ | -------------------------------------------------------------------------- | ------------------- | | **मेहनत** | हर फ़ाइल के लिए एक सब-एजेंट, आपके कोडबेस के आकार के हिसाब से। | 2/5 | | **समय** | हर फ़ाइल पर समानांतर काम, फिर सब एक रिपोर्ट में। अब भी सिर्फ़ पढ़ने वाला। | 3/5 | | **टोकन खपत** | ज़्यादा, लेकिन अलग-थलग। हर सब-एजेंट अपने ही कॉन्टेक्स्ट में स्कैन करता है। | 3/5 | ````md /lagune तुम एक साइबर सुरक्षा ऑर्केस्ट्रेटर हो, जो Lagune के ज़रिए पाथ की सूची बनाता है, हर पाथ के लिए एक सब-एजेंट भेजता है और उनकी रिपोर्टें जोड़ता है (सारा कंटेंट सब-एजेंट पढ़ते हैं)। तुम्हें मौजूदा प्रोजेक्ट के आकार के हिसाब से काम सब-एजेंट को सौंपना है: कोडबेस जितना बड़ा हो, उतने ज़्यादा सब-एजेंट भेजो, सबको एक साथ समानांतर में, और हर एक को नीचे वाला प्रॉम्प्ट दो: ```prompt /lagune तुम रक्षात्मक सुरक्षा में गहरी विशेषज्ञता रखने वाले साइबर सुरक्षा शोधकर्ता हो, और अपना ज्ञान और सटीकता बढ़ाने के लिए Lagune का इस्तेमाल कर रहे हो। को ख़ुद स्कैन करो और जो भी कमी मिले, उसके साथ एक ठोस सुधार बताओ। यह एक अलग स्कैन है, Blue Team फ़्लो नहीं: detect, plan, harden या verify मत चलाना, और Lagune की ट्रैकिंग में कुछ भी मत लिखना। आख़िर में, में मिली हर कमी की सूची दो, हर एक के साथ उसकी गंभीरता और एक ठोस सुधार। ``` आख़िर में, सभी सब-एजेंट की रिपोर्टों को कमियों और सुधारों की एक ऐसी सूची में जोड़ दो, जो प्राथमिकता के क्रम में हो। ```` **चेतावनी** हल्का स्कैन एक बड़ा, बिना दायरे वाला प्रॉम्प्ट होता है, इसलिए कुछ एजेंट इसे मना कर सकते हैं या बीच में ही छोड़ सकते हैं। अगर आपका एजेंट आनाकानी करे, तो इसके बजाय नीचे दिया पूरा **Blue Team फ़्लो** चलाएँ: इसके चरण दायरे में बँधे हैं और एक-एक कदम चलते हैं, इसलिए इनके रुकने की संभावना बहुत कम है। --- ## 🌊 ऑटो Blue Team ऑडिट फ़्लो [पूरा कमांड फ़्लो](https://lagune.ai/hi-IN/docs/get-started/commands) शुरू से आख़िर तक चलाता है। **🪼 डिफ़ॉल्ट** | पहलू | फ़ायदा और नुक़सान | स्तर | | ------------ | -------------------------------------------------------------------------------- | ------------------- | | **मेहनत** | एक एजेंट, कोई सब-एजेंट नहीं, कोडबेस का आकार चाहे जो हो। | 3/5 | | **समय** | मध्यम, लेकिन बड़े कोडबेस में कम गहराई से। हर कमांड एक बार, एक के बाद एक चलती है। | 4/5 | | **टोकन खपत** | कम, लेकिन कम अलग-थलग। हर कमांड एक ही कॉन्टेक्स्ट साझा करती है। | 4/5 | ```md ये कमांड एक-एक करके चलाओ: `/lagune-charter`, `/lagune-detect`, `/lagune-plan`, `/lagune-harden` और `/lagune-verify`। ## लूप जब `/lagune-verify` एक या ज़्यादा सुधार नामंज़ूर करे, तो `/lagune-harden` और फिर `/lagune-verify` तब तक दोहराओ, जब तक सारे निष्कर्ष ठीक से हल न हो जाएँ। ``` **🐋 मल्टी एजेंट (डीप स्कैन)** | पहलू | फ़ायदा और नुक़सान | स्तर | | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | | **मेहनत** | सब-एजेंट की संख्या आपके कोडबेस के आकार के हिसाब से तय होती है। | 5/5 | | **समय** | ज़्यादा लंबा, लेकिन ज़्यादा गहराई से। निष्कर्षों को समानांतर में पहचानने, उनकी योजना बनाने और उन्हें मज़बूत करने के लिए कई सब-एजेंट भेजता है। | 5/5 | | **टोकन खपत** | ज़्यादा, लेकिन ज़्यादा सुरक्षित। हर सब-एजेंट का अपना अलग कॉन्टेक्स्ट होता है, बिना किसी पूर्वाग्रह के। | 5/5 | ````md ये कमांड एक-एक करके चलाओ, हर कमांड एक सब-एजेंट को देकर (बैकटिक के बिना, सिर्फ़ कमांड): सब-एजेंट 1 का प्रॉम्प्ट: `/lagune-charter` सब-एजेंट 2 का प्रॉम्प्ट: `/lagune-detect` सब-एजेंट 3 का प्रॉम्प्ट: `/lagune-plan` सब-एजेंट 4 का प्रॉम्प्ट: `/lagune-harden` सब-एजेंट 5 का प्रॉम्प्ट: `/lagune-verify` `/lagune-detect`, `/lagune-plan`, `/lagune-harden` और `/lagune-verify` कमांड में तुम्हें मौजूदा प्रोजेक्ट के आकार के हिसाब से काम सब-एजेंट को सौंपना है: कोडबेस जितना बड़ा हो, उतने ज़्यादा सब-एजेंट भेजने चाहिए। उदाहरण के लिए: ```prompt /lagune-detect ``` ```prompt /lagune-plan ``` ```prompt /lagune-harden ``` ```prompt /lagune-verify ``` - एक ही कमांड पर लगे कई एजेंट समानांतर में भेजो। - सारे `/lagune-detect` सब-एजेंट पूरे होने पर, यह चलाओ: ```prompt /lagune-detect एक जैसे निष्कर्षों को मिलाकर एक करो। नए निष्कर्ष मत खोजो, और कोडबेस को दोबारा स्कैन मत करो। ``` ## लूप जब `/lagune-verify` एक या ज़्यादा सुधार नामंज़ूर करे, तो `/lagune-harden` और फिर `/lagune-verify` तब तक दोहराओ, जब तक सारे निष्कर्ष ठीक से हल न हो जाएँ। ```` --- ## 🪄 सीमित दायरे में पहचान [`/lagune-detect`](https://lagune.ai/hi-IN/docs/commands/detect) कमांड को पूरे प्रोजेक्ट के बजाय उसके किसी हिस्से पर चलाएँ। दायरा आम भाषा में बताएँ (कोई कमिट, कोई पुल रिक्वेस्ट या कोई असली स्थिति), और यह सिर्फ़ वहीं के सुरक्षा से जुड़े निष्कर्षों का खाका बनाती है। **टिप** यहाँ जो कुछ भी पकड़ा जाता है, वह सामान्य निष्कर्ष ही है, इसलिए आप उसे सीधे `/lagune-plan`, `/lagune-harden` और `/lagune-verify` तक ले जा सकते हैं, सिर्फ़ उन्हीं आइटम के दायरे में। **📌 किसी कमिट के बाद से** नए कमिट के एक बैच की अलग से सुरक्षा जाँच करें, सिर्फ़ उन्हीं के बदलावों के दायरे में, उदाहरण के लिए: ```prompt /lagune-detect कमिट `a1b2c3d` के बाद से जो कुछ भी बदला है, जाँच को सिर्फ़ उसी तक सीमित रखो। ``` **🔀 ब्रांच या PR का diff** किसी पुल रिक्वेस्ट को मर्ज होने से पहले सुरक्षा के लिहाज़ से जाँचें, सिर्फ़ उसके diff के दायरे में, उदाहरण के लिए: ```prompt /lagune-detect जाँच को सिर्फ़ उन बदलावों तक सीमित रखो जो यह ब्रांच `main` के मुक़ाबले लाती है। ``` **⛑️ किसी घटना के बाद** जो हुआ, उसे अपने शब्दों में बताएँ। Lagune किसी फ़्लैग को नहीं, बल्कि स्थिति को पढ़ता है, और उसे एक केंद्रित खोज में बदल देता है, उदाहरण के लिए: ```prompt /lagune-detect कुछ हफ़्ते पहले हमारी साइट से डेटा लीक हुआ था। मुझे ठीक-ठीक नहीं पता कि यह कैसे हुआ, और मुझे डर है कि कोई रास्ता अब भी खुला है जिससे डेटा फिर से लीक हो सकता है। कोड को ध्यान से देखो, ख़ासकर वहाँ जहाँ संवेदनशील डेटा पढ़ा, स्टोर या उजागर किया जाता है, और जो कुछ भी अब भी डेटा बाहर निकलने का रास्ता बन सकता है, उसका खाका बनाओ। इसे अभ्यास नहीं, असली घटना मानकर चलो। ``` --- ## 🚨 ज़ीरो ट्रस्ट ऑडिट पूरे वर्कस्पेस और हर डिपेंडेंसी को दुश्मन मानकर चलता है: यह इंटरप्रेटर, नेटवर्क कॉल, एनकोड किए गए पेलोड, और स्कैनर से बचने के लिए अनपेक्षित जगहों पर छिपाया गया कोड खोजता है, फिर आख़िर में go/no-go फ़ैसला देता है कि प्रोजेक्ट इस्तेमाल के लिए सुरक्षित है या नहीं। ये प्रॉम्प्ट इस ऑडिट के लिए ज़रूरी विशेषज्ञताएँ सीधे लोड करते हैं, आपके प्रोजेक्ट की श्रेणियाँ चाहे जो हों। कैटलॉग की बाक़ी विशेषज्ञताओं के लिए, जिन्हें `/lagune` मिलाकर चुनता है, पक्का करें कि प्रोजेक्ट **OWASP**, **AI/LLM** और अपने स्टैक की श्रेणी (जैसे **JavaScript**, **Python** आदि) का इस्तेमाल करता हो: ```bash npx lagune write add --categories owasp ai javascript ``` रिपॉज़िटरी की अपनी `.gitignore` फ़ाइलें और कॉन्फ़िगरेशन चेकर से फ़ाइलें छिपा सकते हैं, इसलिए [सब कुछ स्कैन करने](https://lagune.ai/hi-IN/docs/hooks/configure) के लिए `checkers` ब्लॉक को `.lagune/configs.json` में इस तरह सेट करें, और रिपॉज़िटरी के साथ आया कोई भी ब्लॉक इससे बदल दें: ```json { "checkers": { "gitignore": false } } ``` **ख़तरा** किसी अविश्वसनीय स्रोत के प्रोजेक्ट को अपने लोकल एनवायरनमेंट में चलाते समय सावधान रहें। नुक़सानदेह कोड को अपने सिस्टम पर असर डालने से रोकने के लिए किसी अलग-थलग एनवायरनमेंट का इस्तेमाल करें, जैसे **सैंडबॉक्स** (सुझाया गया), **VM** या ऐसा ही कुछ। **🪼 डिफ़ॉल्ट** | पहलू | फ़ायदा और नुक़सान | स्तर | | ------------ | ------------------------------------------------------------------------------------------ | ------------------- | | **मेहनत** | एक एजेंट पूरे वर्कस्पेस को स्कैन करता है, कोई सब-एजेंट नहीं। | 2/5 | | **समय** | मध्यम। एक एजेंट कोड और उसकी डिपेंडेंसी को क्रम से जाँचता है। | 3/5 | | **टोकन खपत** | मध्यम, लेकिन साझा। विशेषज्ञताएँ, कोड और डिपेंडेंसी, सब एक ही कॉन्टेक्स्ट में लोड होते हैं। | 3/5 | ```md /lagune तुम ज़ीरो ट्रस्ट रक्षात्मक सुरक्षा में गहरी विशेषज्ञता रखने वाले साइबर सुरक्षा शोधकर्ता हो, और अपना ज्ञान और सटीकता बढ़ाने के लिए Lagune का इस्तेमाल कर रहे हो। पूरे वर्कस्पेस को एक अविश्वसनीय स्रोत और संभावित रूप से नुक़सानदेह दायरा मानकर उसका खाका बनाओ। हर इंटरप्रेटर, fetch, base64 और ऐसी हर चीज़ को संभावित ख़तरा मानना है। अपना विश्लेषण डिपेंडेंसी और सब-डिपेंडेंसी तक ले जाओ: कोई प्रोजेक्ट स्कैनर से बचने के लिए नुक़सानदेह कोड को किसी अनपेक्षित जगह छिपाने की कोशिश कर सकता है। ज़रूरी विशेषज्ञताएँ (इन्हें `npx lagune read catalog ` से एक-एक करके लोड करो): - interpreter - secrets - llm - path साफ़ कह दूँ: खाके में आई हर कमज़ोरी को, बिना किसी अपवाद के, संभावित ख़तरा मानना है। आख़िर में, यह फ़ैसला दो कि यह प्रोजेक्ट मेरे इस्तेमाल के लिए सुरक्षित और भरोसेमंद है या नहीं। ``` **🐋 मल्टी एजेंट (डीप स्कैन)** | पहलू | फ़ायदा और नुक़सान | स्तर | | ------------ | -------------------------------------------------------------------------------------------------------------- | ------------------- | | **मेहनत** | हर फ़ाइल के लिए एक सब-एजेंट, आपके कोडबेस के आकार के हिसाब से। | 5/5 | | **समय** | ज़्यादा लंबा, लेकिन ज़्यादा गहराई से। फ़ाइलें समानांतर में स्कैन होती हैं, फिर सब एक फ़ैसले में जुड़ जाती हैं। | 4/5 | | **टोकन खपत** | सबसे ज़्यादा, लेकिन सबसे सुरक्षित। हर सब-एजेंट अपने अलग-थलग कॉन्टेक्स्ट में विशेषज्ञताएँ पढ़ता है। | 5/5 | ````md /lagune तुम एक साइबर सुरक्षा ऑर्केस्ट्रेटर हो, जो Lagune के ज़रिए फ़ाइलों की सूची बनाता है, हर फ़ाइल के लिए एक सब-एजेंट भेजता है और रिपोर्टें तैयार करता है (सारा कंटेंट सब-एजेंट पढ़ते हैं)। हर फ़ाइल के लिए एक सब-एजेंट भेजो, सबको समानांतर में, और हर एक को नीचे वाला प्रॉम्प्ट उसकी अपनी फ़ाइल के दायरे में दो: ```prompt /lagune तुम ज़ीरो ट्रस्ट रक्षात्मक सुरक्षा में गहरी विशेषज्ञता रखने वाले साइबर सुरक्षा शोधकर्ता हो, और अपना ज्ञान और सटीकता बढ़ाने के लिए Lagune का इस्तेमाल कर रहे हो। को एक अविश्वसनीय स्रोत और संभावित रूप से नुक़सानदेह दायरा मानो। हर इंटरप्रेटर, fetch, base64 और ऐसी हर चीज़ को संभावित ख़तरा मानना है। विश्लेषण को उस हर चीज़ तक ले जाओ जिसे इम्पोर्ट करती है, डिपेंडेंसी और सब-डिपेंडेंसी समेत, जहाँ स्कैनर से बचने के लिए नुक़सानदेह कोड छिपा हो सकता है। हर सब-एजेंट के लिए ज़रूरी विशेषज्ञताएँ (इन्हें `npx lagune read catalog ` से एक-एक करके लोड करो): - interpreter - secrets - llm - path साफ़ कह दूँ: खाके में आई हर कमज़ोरी को, बिना किसी अपवाद के, संभावित ख़तरा मानना है। आख़िर में, यह फ़ैसला दो कि यह प्रोजेक्ट मेरे इस्तेमाल के लिए सुरक्षित और भरोसेमंद है या नहीं। ``` आख़िर में, सभी सब-एजेंट की रिपोर्टों को जोड़कर एक अंतिम फ़ैसला दो। ```` --- # Security-Driven Hardening: AI के साथ डेवलपमेंट के दौर के लिए एक कन्वेंशन > Security-Driven Hardening (SDH) पद्धति: AI की मदद से और वाइब कोडिंग से बने सॉफ़्टवेयर का ऑडिट करने और उसकी सुरक्षा मज़बूत करने के लिए संदर्भ को समझने वाला Blue Team कन्वेंशन। कैनोनिकल: https://lagune.ai/hi-IN/docs/references/paper भाषा: hi-IN मूल: https://lagune.ai/docs/references/paper आख़िरी अपडेट: 2026-11-06 - **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 के असली कामकाज का अनुसरण करते हैं: नीति तय करना, पहचान, ट्राइएज, निवारण, पुष्टि। ```mermaid flowchart TB charter["1 · charter (नीति)
पढ़ता है: प्रोजेक्ट, और अगर दिया गया हो तो उपयोगकर्ता का विवरण
लिखता है: सुरक्षा सिद्धांत
हर सिद्धांत में वह जोखिम, जिसे वह रोकता है, आसान भाषा में"] detect["2 · detect (पहचान)
पढ़ता है: उपयोगकर्ता का कोड
लिखता है: detect मैप
पहचानना है, गढ़ना नहीं: सिर्फ़ वही दर्ज करना जिसकी पुष्टि कोड से हो"] plan["3 · plan (ट्राइएज)
पढ़ता है: detect मैप, कोड कभी नहीं
लिखता है: रक्षा योजना
हर सुधार उसी चीज़ की ओर इशारा करता है जिसे detect ने सचमुच पहचाना"] harden["4 · harden (निवारण)
पढ़ता है: रक्षा योजना, और वह कोड जिसे योजना छूती है
लिखता है: कोड, और हार्डनिंग रिकॉर्ड
कोड बदलने वाला इकलौता चरण, एक बार में एक सुधार, सबसे छोटा बदलाव जो कारगर रहे"] verify["5 · verify (पुष्टि)
पढ़ता है: कोड, और हार्डनिंग रिकॉर्ड
लिखता है: हर खुला फ़ैसला हार्डनिंग रिकॉर्ड पर
कोड का रिकॉर्ड से स्टैटिक मिलान, फ़ैसले में कभी नरमी नहीं"] charter --> detect --> plan --> harden --> verify verify -.->|"अस्वीकार: harden के लिए दोबारा खुला काम,
दर्ज कारण के हिसाब से फिर से लागू"| harden verify -.->|"बंद करना: जो बंद साबित हुआ उसे
पूरी चेन से बंद करता है,
इतिहास में एक पंक्ति"| detect ``` **चित्र 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 इकलौता चरण है जो दूसरे चरणों के आर्टिफ़ैक्ट में लिखता है: यही वह चरण है जो चक्र पूरा करता है। जैसे ही निष्कर्ष चेन से बाहर जाता है, बंद करने की प्रक्रिया उसका सार निकालकर इतिहास के रिकॉर्ड में एक छोटी एंट्री बना देती है, और यह रिकॉर्ड कामकाजी चेन से बाहर रहता है और कभी दोबारा प्रोसेस नहीं होता। ग़ायब होने और बंद होने के बीच यही रेखा है: जिस निष्कर्ष को मिलान ने इसलिए हटाया कि वह सच नहीं रहा, वह पीछे कुछ नहीं छोड़ता, जबकि बंद साबित हुआ निष्कर्ष इतिहास में अपनी पंक्ति कमाता है। बंद किया गया निष्कर्ष उसके बाद किसी भी कामकाजी आर्टिफ़ैक्ट में नहीं होता, और यह ग़ैरमौजूदगी अपेक्षित है, टूटी हुई चेन नहीं। ```mermaid stateDiagram-v2 direction TB [*] --> OPEN: detect चरण पहचानता है OPEN --> Plan: plan Plan --> Harden: harden Harden --> Verify: verify Verify --> StoodDown: Risk closed StoodDown --> SETTLED SETTLED --> OPEN: कोड बदलने पर निष्कर्ष दोबारा खुलता है Plan: plan Harden: harden Verify: verify StoodDown: STOOD DOWN · इतिहास में एक पंक्ति ``` **चित्र 2.** बंद हो पाने की स्टेट मशीन। निष्कर्ष OPEN (खुला) → STOOD DOWN (बंद) → SETTLED (स्थिर) की ओर बढ़ता है, और सिर्फ़ कोड बदलने पर दोबारा खुलता है। जब दायरे की हर चीज़ बंद हो जाती है, तो चक्र स्थिर हो जाता है, और इस स्थिर अवस्था का एक ठोस रूप है: जिस आर्टिफ़ैक्ट का आख़िरी निष्कर्ष बंद हुआ, उसे पूरा हटा दिया जाता है, इसलिए पूरी तरह बंद चेन में सिर्फ़ सुरक्षा सिद्धांत और इतिहास बचते हैं, यानी नीति और प्रमाण। चक्र सिर्फ़ कोड बदलने पर दोबारा खुलता है। पद्धति हर निष्कर्ष को एक तय अंत देती है, और ठीक यही वह चीज़ है जो कोई अंतहीन बैकलॉग नहीं दे सकता। --- ## VI. डेवलपर के ज्ञान को आगे बढ़ाने वाली दोहरी भूमिका SDH लोगों की जगह नहीं लेता, और विशेष Blue Team टूलिंग की जगह भी नहीं लेता। यह **डेवलपर के अपने ज्ञान को आगे बढ़ाता है**। डेवलपर सुरक्षा को जितना ज़्यादा समझता है, उतनी ही सटीकता से वह फ़्लो को दिशा दे सकता है, और उसके पास उतनी ही ज़्यादा आज़ादी होती है। जो डेवलपर कम समझता है, उसे भी सुरक्षित नतीजा मिलता है, क्योंकि ऑटोमैटिक मोड उसकी हिफ़ाज़त करता है। `§I` का उलटाव, यानी सुरक्षा का ज्ञान स्पेक में रहता है, दोनों दिशाओं में लागू होता है। नौसिखिए के लिए यह सुरक्षा है: उसे यह जानने की ज़रूरत नहीं कि क्या पूछना है, क्योंकि स्पेक ख़ुद प्रस्ताव रखता है। विशेषज्ञ के लिए यह ताक़त बढ़ाने वाला है: वही स्पेक उसे किसी तय चेकलिस्ट से जूझने के बजाय फ़्लो को सटीक निशाने पर लगाने देता है। हर चरण अपने कामकाज में यह दोहरी भूमिका निभाता है (चित्र 3)। बिना इनपुट के चलाने पर, वह उपयोगकर्ता की ओर से पूरे दायरे पर काम करता है। दिशा मिलने पर, वही चरण ठीक उतने तक सिमट जाता है जितने पर उपयोगकर्ता ने उसे लगाया। ```mermaid flowchart TB inversion["एक उलटाव, दो दिशाएँ:
सुरक्षा का ज्ञान स्पेक में रहता है"] inversion --> auto["ऑटोमैटिक मोड (कोई इनपुट नहीं)
चरण प्रस्ताव रखता है और काम करता है
पूरे दायरे पर"] inversion --> directed["निर्देशित मोड (इनपुट दिया गया)
चरण ठीक उतने तक सिमटता है
जितने पर उपयोगकर्ता ने उसे लगाया"] auto --> novice["नौसिखिया, सुरक्षित:
यह जाने बिना कि क्या पूछना है,
एक सुरक्षित नतीजा"] directed --> expert["विशेषज्ञ, ज़्यादा सक्षम:
फ़्लो सटीक निशाने पर,
कोई तय चेकलिस्ट नहीं"] novice -.-> phases["वही पाँच चरण दोनों के काम आते हैं:
charter · detect · plan · harden · verify"] expert -.-> phases ``` **चित्र 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)। प्रॉम्प्ट में एक फ़ाइल, सूची का एक निष्कर्ष, कोई चिंता, किसी जानी-पहचानी कमज़ोर जगह पर केंद्रित मिशन, या पूरे ब्रूट-फ़ोर्स स्कैन का अनुरोध: हर एक उपयोगकर्ता की ज़रूरत पर फ़िट बैठता है, क्योंकि फ़्लो डिज़ाइन से ही कुछ नहीं थोपता। इनमें से कुछ भी डिफ़ॉल्ट रूप से सुरक्षित आधार को कमज़ोर नहीं करता। लचीलापन तय करता है कि आधार कैसे लागू हो, उसे कभी नीचे नहीं लाता। ```mermaid flowchart TB shape["चरण पढ़ता है कि उसे
किस रूप में क्या दिया गया"] shape --> none["कोई इनपुट नहीं"] shape --> paths["एक या ज़्यादा पाथ"] shape --> concern["बताई गई कोई चिंता"] shape --> finding["नाम से बताया गया निष्कर्ष"] shape --> band["प्राथमिकता का एक स्तर"] none --> auto["ऑटोमैटिक मोड:
प्रस्ताव रखना, या
पूरे दायरे को स्कैन करना"] paths --> focus["सिर्फ़ उन्हीं फ़ाइलों
या डायरेक्टरी पर ध्यान"] concern --> scoped["दायरा उसी
एक चिंता तक"] finding --> item["उसी एक ट्रैक किए
गए आइटम पर काम"] band --> priority["सिर्फ़ क्रिटिकल, उच्च,
मध्यम या निम्न पर काम"] ``` **चित्र 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 चरण उसी नाम के तहत हार्डनिंग रिकॉर्ड पर अपना फ़ैसला लिखता है। ट्रैकिंग मैप में ट्रैकिंग के अलावा कुछ नहीं होता, हर आइटम की एक एंट्री: ```json { "name": "File uploads", "paths": ["src/routes/upload.ts"] } ``` मैप में न कोई टेक्स्ट होता है, न टिप्पणी, न अलग पहचानकर्ता, न चरण। शब्दों को टेक्स्ट वाले आर्टिफ़ैक्ट सँभालते हैं, और मैप सिर्फ़ पहचान और पाथ रखता है। फ़ाइल पाथ ही इकलौती बदलने वाली चीज़ हैं, और वे सिर्फ़ यहीं रहते हैं। फ़ाइल का नाम बदलने या उसे खिसकाने पर लिंक ठीक एक ही जगह टूट सकता है, कभी दो अलग-अलग होती प्रतियों में नहीं। ```mermaid flowchart TB detect["detect मैप"] --> name plan["रक्षा योजना"] --> name harden["हार्डनिंग रिकॉर्ड
verify चरण अपना फ़ैसला यहीं लिखता है"] --> name name["name = "File uploads"
टेक्स्ट में नाम रहता है, पाथ कभी नहीं"] name -.-> tracking tracking["ट्रैकिंग मैप
{ name: "File uploads",
paths: ["src/routes/upload.ts"] }
पाथ सिर्फ़ यहीं रहता है, इसलिए नाम बदलने पर सिर्फ़ यही एंट्री सुधारी जाती है"] ``` **चित्र 5.** पहचान की कन्वेयर बेल्ट। निष्कर्ष का एक ही नाम हर आर्टिफ़ैक्ट से होकर गुज़रता है, जबकि उसका पाथ सिर्फ़ ट्रैकिंग मैप में रहता है, इसलिए नाम बदलने पर सुधार एक ही जगह होता है। सामान्य फ़्लो में दो काम मैप को सँभालते हैं, और तीसरा रखरखाव के तौर पर अलग खड़ा है। **Track** जोड़ने वाला पंजीकरण है: कोई चरण अपने लिखे निष्कर्षों की जानकारी देता है, और इंजन नए निष्कर्ष दर्ज करता है और बाक़ियों के बदले हुए पाथ का पीछा करता है, हर एक को नया, खिसका हुआ या बिना बदलाव वाला मानते हुए। वह ऐसी कोई चीज़ कभी नहीं हटाता जिसकी जानकारी चरण ने न दी हो। **Untrack** उन निष्कर्षों को बंद करता है जिन्हें verify चरण ने बंद पाया: एक ही नियतात्मक पास में वह हर निष्कर्ष का सार निकालकर उसकी इतिहास एंट्री बनाता है, आर्टिफ़ैक्ट से उसका पूरा सेक्शन हटाता है, जिस आर्टिफ़ैक्ट का आख़िरी निष्कर्ष चला गया उसे मिटा देता है, और उसकी ट्रैकिंग एंट्री हटा देता है, ताकि एजेंट को इनमें से कुछ भी हाथ से न करना पड़े। जहाँ नियतात्मक पास सुरक्षित ढंग से नहीं जा सकता, जैसे कोई बंद किया गया नाम जो अब भी किसी दूसरे निष्कर्ष के टेक्स्ट में उद्धृत हो, वहाँ वह अंदाज़े से बदलाव करने के बजाय एजेंट के लिए उस जगह को चिह्नित कर देता है। चरण चलते समय इन्हीं दोनों को बुलाते हैं। **Repair** रखरखाव का काम है: जब किसी चरण का अपना मिलान ट्रैकिंग को असंगत पाता है (दर्ज किया गया कोई पाथ जो अब मौजूद नहीं), तो वह चरण अपने आप यह काम repair को सौंप देता है, और वरना इसे ज़रूरत पड़ने पर चलाया जाता है। यह एक साथ पूरे मैप को फिर से ठीक बैठाता है, हर आर्टिफ़ैक्ट और मौजूदा कोड पढ़ता है, हर आइटम के पाथ सुधारता है, और जो वह अकेले तय नहीं कर सकता उसे सामने रखता है: कोई अनाथ आइटम (ऐसा ट्रैक किया गया आइटम जिसका अब कोई आर्टिफ़ैक्ट नाम नहीं लेता) या नाम बदलने का संभावित मामला (ऐसा आइटम जिसके पाथ किसी दूसरे बताए गए नाम से मेल खाते हों)। repair रखरखाव है, छठा चरण नहीं। यह न उपयोगकर्ता के कोड को छूता है, न टेक्स्ट वाले आर्टिफ़ैक्ट को, सिर्फ़ ट्रैकिंग को। यह उपयोगकर्ता का सोर्स सिर्फ़ एक वजह से पढ़ता है, नाम बदली गई फ़ाइल का नया पाथ जानने के लिए, और कभी सुरक्षा सामग्री नहीं लिखता। जिस एक सवाल पर इंजन अंदाज़ा लगाने से इनकार करता है, उस पर आख़िरी फ़ैसला इंसान का होता है: कोई ग़ायब हुआ आइटम सुलझ गया था या सिर्फ़ उसका नाम बदला था। अंदाज़ा लगाने से बेहतर है पूछना, क्योंकि ग़लती से हटाया गया आइटम चेन तोड़ देता है। पद्धति अपना रक्षा अनुशासन ख़ुद पर भी लागू करती है। नियतात्मक इंजन कमांड-लाइन प्रोग्राम के रूप में चलाए जाते हैं, और हर इनपुट अपने अलग प्रोसेस आर्ग्युमेंट के रूप में दिया जाता है, जिससे वह निष्क्रिय रहता है, इसलिए कोट या बैकटिक वाली कोई वैल्यू कभी कमांड में इंजेक्ट नहीं हो सकती। अनजान चेक जवाब देने के बजाय फ़ेल हो जाता है, इसलिए ग़लत लिखा गया चेक कभी साफ़ नतीजे जैसा नहीं दिखता। SDH अपनी अंदरूनी व्यवस्था को भी डिफ़ॉल्ट रूप से सुरक्षित सिद्धांत से छूट नहीं देता। --- ## XII. वाहक: पोर्टेबिलिटी के प्रमाण के रूप में एजेंट से स्वतंत्र आर्किटेक्चर SDH ऐसा कन्वेंशन बन सके जिसे दूसरे अपनाएँ, इसके लिए ज़रूरी है कि वह किसी एक एजेंट या एक स्टैक से बँधा न हो, इसलिए उसका वाहक तीन चीज़ों को अलग रखता है (चित्र 6)। Lagune साबित करता है कि यह मुमकिन है। **सुरक्षा की असली सामग्री** एक बार लिखी जाती है और उसे पता नहीं होता कि उसे कौन-सा एजेंट चलाता है: चरणों के निर्देश और वे टेम्पलेट जिन्हें वे भरते हैं, ज्ञान का कैटलॉग, और नियतात्मक इंजन। **डिलीवरी** हल्की है: उसका इकलौता काम उस सामग्री को किसी एजेंट तक उस रूप में और उस जगह पहुँचाना है जिसकी एजेंट उम्मीद करता है, और उसमें अपना कोई सुरक्षा लॉजिक नहीं होता। **प्रोजेक्ट की स्थिति** प्रोजेक्ट की होती है: सुरक्षा सिद्धांत, चरणों के आर्टिफ़ैक्ट, ट्रैकिंग मैप, उसकी चुनी हुई श्रेणियाँ और उसकी अपनी विशेषज्ञताएँ, जो उसके बाक़ी कोड की तरह कमिट की जाती हैं और रिव्यू की जा सकती हैं। ```mermaid flowchart TB value["सुरक्षा की असली सामग्री, एक बार लिखी गई
चरणों के निर्देश · टेम्पलेट · ज्ञान का कैटलॉग · नियतात्मक इंजन
उसे पता नहीं कि कौन-सा एजेंट उसे चलाता है"] delivery["डिलीवरी
उस सामग्री को हर एजेंट तक उसकी अपेक्षित शक्ल में पहुँचाती है
कोई सुरक्षा लॉजिक नहीं"] agent["एजेंट
चरण चलाता है"] project["प्रोजेक्ट की स्थिति
उसके कोड के साथ कमिट की गई
सुरक्षा सिद्धांत · चरणों के आर्टिफ़ैक्ट · ट्रैकिंग · श्रेणियाँ · अपनी विशेषज्ञताएँ"] value --> delivery --> agent agent -->|"पढ़ता और लिखता है"| project ``` **चित्र 6.** एजेंट से स्वतंत्र वाहक। सुरक्षा की असली सामग्री एक बार लिखी जाती है, हल्की डिलीवरी उसे हर एजेंट तक पहुँचाती है, और स्थिति प्रोजेक्ट की ही रहती है। क्योंकि डिलीवरी में कोई सुरक्षा लॉजिक नहीं होता, वह कैसे बनी है इससे SDH में कुछ नहीं बदलता। कोई वाहक डिलीवरी ख़ुद बना सकता है या उसे किसी ऐसे इकोसिस्टम को सौंप सकता है जो पहले से एजेंट स्किल बाँटता है, जैसा रेफ़रेंस इम्प्लीमेंटेशन करता है, और चरण, उनके आर्टिफ़ैक्ट और उनकी गारंटियाँ वैसी ही रहती हैं। इसमें से कुछ भी किसी भाषा या रनटाइम से भी बँधा नहीं है। रेफ़रेंस इम्प्लीमेंटेशन संयोग से एक स्टैक में लिखा गया है, लेकिन पद्धति इन चीज़ों के बीच की सीमा है, उन्हें बनाने वाला टूलचेन नहीं। यही डिज़ाइन पूरी तरह किसी दूसरी भाषा में दोबारा बनाया जा सकता है, और SDH जो है उसमें कोई बदलाव नहीं आएगा। --- ## XIII. व्यावहारिक उदाहरण: SDH शुरू से अंत तक > **व्यावहारिक उदाहरण** > > **अपलोड और एडमिन सरफ़ेस की रक्षात्मक हार्डनिंग**। > **संदर्भ**: एक छोटा ऐप जो उपयोगकर्ताओं की अपलोड की गई फ़ाइलें लेता है और उन्हें एक एडमिन पेज पर सूची में दिखाता है। > **पैटर्न**: charter → detect (संदर्भ से सक्रिय हुए, ज़रूरत पड़ने पर ही लोड होने वाले ज्ञान के साथ) → plan → harden → verify, एक बंद होने और एक असली नाकामी के साथ। > **नतीजा (क्षमता)**: एक जोखिम जिसका बंद होना पुष्ट हुआ और जिसे पूरी चेन से बंद किया गया, और एक नियंत्रण जिसके बारे में पुष्टि हुई कि वह बंद _नहीं_ है और जिसे वापस harden चरण पर भेजा गया। फ़ैसला रिकॉर्ड को नहीं, कोड को दिखाता है। _यह पद्धति के तंत्र को समझाने वाला एक उदाहरण है, मैदान में मापा गया अध्ययन नहीं, और इसमें प्रभावशीलता का कोई आँकड़ा नहीं दिया गया है_। एक लगातार चलने वाला उदाहरण पद्धति को सिर्फ़ उसके हिस्सों में नहीं, काम करते हुए दिखाता है। हम `§IV` के फ़ाइल अपलोड वाले उदाहरण को आगे बढ़ाकर उसमें ज़रूरत पड़ने पर ज्ञान का सक्रिय होना और एक निष्कर्ष का बंद होना जोड़ते हैं, और एक असली नाकामी भी शामिल करते हैं। 1. **charter** चरण "जब तक इनपुट की जाँच न हो जाए, हर इनपुट अविश्वसनीय है" सिद्धांत का प्रस्ताव रखता है, साथ में आसान भाषा में उसका जोखिम: बिना जाँचा गया इनपुट किसी सिस्टम में सेंध लगने का सबसे आम रास्ता है। 2. **detect** चरण अपलोड रूट और अपलोड की गई फ़ाइलों की सूची दिखाने वाले छोटे एडमिन पेज को स्कैन करता है। वह अपलोड वाला निष्कर्ष पहचानता है (हैंडलर क्लाइंट के MIME टाइप पर भरोसा करता है)। एडमिन पेज ब्राउज़र में चलता है, और यह ऐसा संदर्भ है जिसे प्रॉम्प्ट-ऑन-डिमांड (`§VII`) पहचानता है, इसलिए detect चरण उस संदर्भ की विशेषज्ञता लोड करता है और दूसरा निष्कर्ष सामने रखता है: एक जगह जहाँ फ़ाइल का नाम पेज में टेक्स्ट के बजाय मार्कअप के रूप में लिखा जाता है, इसलिए जान-बूझकर गढ़ा गया नाम विज़िटर के ब्राउज़र में स्क्रिप्ट की तरह चल सकता है। जिन विशेषज्ञताओं का संदर्भ इस दायरे में नहीं है, वे कभी लोड नहीं होतीं, और हर बार छोड़े जाने को कोड से पढ़ी गई ग़ैरमौजूदगी के साथ दर्ज किया जाता है। 3. **plan** चरण अपलोड वाले सुधार को क्रिटिकल प्राथमिकता देता है, जो उस सिद्धांत से जुड़ा है: फ़ाइल का असली टाइप और साइज़ जाँचें, सेव करते समय नाम बदलें, और ऐसी जगह रखें जहाँ कोड न चल सके। दूसरे सुधार को वह उच्च प्राथमिकता देता है: फ़ाइल का नाम मार्कअप नहीं, टेक्स्ट के रूप में दिखाएँ। 4. **harden** चरण पहले अपलोड वाला सुधार लागू करता है (सबसे ऊँची प्राथमिकता) और उसे Applied दर्ज करता है, फिर दूसरा, वह भी Applied। 5. **verify** चरण हर जगह को पढ़ता है और कोड का रिकॉर्ड से मिलान करता है। अपलोड वाला नियंत्रण कारगर है: हैंडलर कंटेंट से असली टाइप पहचानता है, साइज़ की सीमा लागू करता है, और बाक़ी सब अस्वीकार करता है। फ़ैसला: Risk closed। verify चरण अपलोड वाले निष्कर्ष को पूरी चेन से बंद कर देता है, और उसका सार इतिहास में दर्ज हो जाता है। अब असली नाकामी। मान लीजिए harden चरण के दूसरे सुधार ने टेक्स्ट को सुरक्षित ढंग से दिखाने वाला एक हेल्पर जोड़ दिया, लेकिन मार्कअप लिखने वाला पुराना कॉल किसी दूसरे कोड पाथ पर अब भी पहुँच में छोड़ दिया। verify चरण पेज पढ़ता है, सुरक्षित हेल्पर देखता है, और यह भी देखता है कि असुरक्षित रास्ता अब भी चालू है। नियंत्रण मौजूद है, लेकिन जोखिम बंद नहीं हुआ। verify चरण रिकॉर्ड से मेल खाने के लिए फ़ैसले को नरम करने से इनकार करता है। वह "Risk not closed" फ़ैसला देता है, कमी दर्ज करता है, और वापस harden चरण की ओर इशारा करता है। जो नियंत्रण जोखिम को पूरी तरह नहीं सँभालता, वह पास नहीं है। एक उदाहरण में यही पद्धति का स्वभाव है: संदर्भ को समझने वाली पहचान, सिद्धांतों से जुड़े और प्राथमिकता वाले सुधार, सावधानी से लागू करना, और ऐसी पुष्टि जो रिकॉर्ड चाहे जो कहे, कोड की असली हालत बताती है। --- ## XIV. SDH कब इस्तेमाल करें, और उसकी सीमाएँ SDH शायद ही कभी उस तरह ज़रूरत से ज़्यादा भारी पड़ता है जैसे कोई भारी प्रक्रिया पड़ सकती है, क्योंकि यह स्थिति से स्वतंत्र और बंद हो सकने वाला है: यह सिमटकर एक फ़ाइल और एक चिंता तक आ सकता है, और कोई स्थायी बोझ छोड़ने के बजाय स्थिर अवस्था तक पहुँचता है। इसकी सीमा प्रोजेक्ट का आकार नहीं, बल्कि **भरोसे की गहराई** है। ```mermaid flowchart TB q1{"क्या कोड सुरक्षा से जुड़ा कुछ करता है?
(इनपुट, ऑथ, डेटा, सीक्रेट, बाहरी कॉल)"} q1 -->|नहीं| little["यहाँ SDH ज़्यादा कुछ नहीं जोड़ता।"] q1 -->|हाँ| q2{"SDH चलाएँ। क्या कोई अनुपालन मानक है,
या सुरक्षा का अलग विभाग?"} q2 -->|नहीं| baseline["SDH एक ठोस आधार है।"] q2 -->|हाँ| carrier["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: सिद्धांत, हूबहू 1. **डिफ़ॉल्ट रूप से सुरक्षित, आसान भाषा में, सबके लिए बराबर**: हर डिफ़ॉल्ट, संदेश और सुधार शुरू से ही सुरक्षित होना चाहिए और हर उपयोगकर्ता की समझ में आना चाहिए, चाहे वह डेवलपर हो या न हो। किसी उपयोगकर्ता वर्ग को दूसरे पर तरजीह नहीं मिलती। 2. **सामान्य सलाह की जगह संदर्भ की समझ**: हर चरण को detect चरण में पहचाने गए संदर्भ से शुरू करना चाहिए और सिस्टम असल में जो करता है उस पर काम करना चाहिए। सामान्य चेकलिस्ट के बजाय उस संदर्भ से जुड़े सुझावों को प्राथमिकता दें। सुरक्षा का ज्ञान स्पेक में और ज़रूरत पड़ने पर ही लोड होने वाली उसकी विशेषज्ञताओं में रहता है, और उपयोगकर्ता जो भी जानता है उसे आगे बढ़ाता है। 3. **कठोरता की जगह लचीलापन**: SDH प्रोजेक्ट और उपयोगकर्ता के हिसाब से ढलता है। सिद्धांत, ज़रूरतें और सुझाव शुरुआती बिंदु हैं, कोई तय अनुबंध नहीं। उपयोगकर्ता को किसी भी चीज़ को दोबारा लिखने, हटाने, जोड़ने या उसका दायरा छोटा करने दें। लचीलापन डिफ़ॉल्ट रूप से सुरक्षित आधार को कभी कमज़ोर नहीं करता, यह सिर्फ़ उपयोगकर्ता को यह तय करने देता है कि वह आधार कैसे लागू हो। 4. **सिर्फ़ जोड़ते न जाना, मौजूदा स्थिति से मिलाकर अपडेट करना**: आर्टिफ़ैक्ट जीवंत दस्तावेज़ हैं, लॉग नहीं। जब कोई चरण दोबारा चले, तो हर मौजूदा एंट्री को मौजूदा सच्चाई से मिलाकर अपडेट करें: जो अब भी सही है उसे रखें, जो बदला है उसे दोबारा लिखें, और जो अब लागू नहीं होता उसे हटाएँ। बंद करना उसी मिलान की आख़िरी मंज़िल है। 5. **केवल रक्षा के लिए**: SDH ऑडिट करता है, सुरक्षा मज़बूत करता है और पुष्टि करता है। यह कभी आक्रामक टूलिंग, बुरी नीयत से इस्तेमाल के लिए एक्सप्लॉइट, या नुक़सान पहुँचाने के लिए पकड़ से बचने की तकनीकें नहीं बनाता। दोहरे इस्तेमाल वाली सुरक्षा सामग्री सिर्फ़ साफ़ तौर पर रक्षात्मक और अधिकृत संदर्भ में ही स्वीकार्य है। 6. **स्पेक पहले, एजेंट से संचालित, सुरक्षा के लिए ढला हुआ**: वर्कफ़्लो को एक आज़माए हुए ढाँचे से बनाएँ: टेम्पलेट, कमांड, सभी चरणों को दिशा देने वाले सुरक्षा सिद्धांत, और चरणों को चलाने वाला एजेंट। उस ढाँचे को रक्षा के मक़सद से दोबारा बनाएँ। --- # Lagune शब्दावली: SDH, Charter, निष्कर्ष और नियंत्रण > Lagune और Security-Driven Hardening के हर शब्द की आसान भाषा में परिभाषा: SDH, charter, detect, निष्कर्ष, नियंत्रण, harden, verify, बंद करना, बंद हो पाना, विशेषज्ञता, श्रेणियाँ और कैटलॉग। कैनोनिकल: https://lagune.ai/hi-IN/docs/references/glossary भाषा: hi-IN मूल: https://lagune.ai/docs/references/glossary आख़िरी अपडेट: 2026-11-06 Lagune और Security-Driven Hardening पद्धति के हर अहम शब्द की परिभाषा, एक ही जगह, आसान भाषा में। ### Security-Driven Hardening (SDH) वह पद्धति जिसे Lagune लागू करता है: संदर्भ को समझने वाला, Blue Team का एक कन्वेंशन, जो सिस्टम के संदर्भ को पहचानता है, उस संदर्भ से जुड़े जोखिमों को प्राथमिकता के हिसाब से छाँटता है, और सुधारों में मार्गदर्शन करता है। सुरक्षा ज्ञान स्पेक और ज़रूरत पड़ने पर ही लोड होने वाली उसकी विशेषज्ञताओं में रहता है, इसलिए डेवलपर और गैर-डेवलपर, दोनों को एक ही फ़्लो से मदद मिलती है। ### Lagune SDH का रेफ़रेंस इम्प्लीमेंटेशन: नौ एजेंट कमांड, हर एक अपने भरे जाने वाले टेम्पलेट के साथ, जिन्हें AI एजेंट किसी कोडबेस की सुरक्षा मज़बूत करने के लिए चलाता है। हर एजेंट इन्हें अपने प्लगइन इंस्टॉलर से या [**skills.sh**](https://www.skills.sh/wellwelwel/lagune) से इंस्टॉल करता है, जैसा [इंस्टॉल पेज](https://lagune.ai/hi-IN/docs) पर बताया गया है, और ये कमांड हर नियतात्मक कदम के लिए Lagune का इंजन चलाती हैं। ### Charter (सुरक्षा सिद्धांत) Lagune की वह परत जो सभी चरणों को दिशा देती है: सुरक्षा को सबसे आगे रखने वाले सिद्धांतों का एक सेट, जिसका पालन बाद के हर चरण को करना होता है। इसे प्रोजेक्ट की सुरक्षा स्थिति के लिए कंपाइल-टाइम जाँच की तरह समझें। यह `.lagune/memory/charter.md` में रखा जाता है। ### डेवलपमेंट फ़्लो यूनिवर्सल कमांड `/lagune`, जो काम लिखे जाते समय ही उसकी सुरक्षा मज़बूत करती है। यह किसी भी पड़ाव पर कोई भी प्रॉम्प्ट लेती है, आपने जो माँगा वह बनाती है, और लौटाने से पहले उसे सुरक्षित डिफ़ॉल्ट के साथ मज़बूत करती है, और charter मौजूद हो तो उसी के मार्गदर्शन में। यह Lagune की ट्रैकिंग में कुछ नहीं लिखती, इसलिए इसका इकलौता नतीजा मज़बूत किया गया कोड है। charter (पहले) और Blue Team फ़्लो (बाद में) के साथ मिलकर, यही वह तरीक़ा है जिससे Lagune निर्माण के दौरान सुरक्षा देता है। ### Blue Team फ़्लो Lagune के मूल में पाँच चरणों वाला ऑडिट: charter, detect, plan, harden, verify। हर चरण पिछले चरण के काम को आगे बढ़ाता है। "Blue Team" रक्षकों की सुरक्षा परंपरा है, जो हमला करने वाली Red Team के उलट है। ### निष्कर्ष (Finding) पहचाना गया एक जोखिम। हर निष्कर्ष में यह होता है कि वह क्या है, क्यों मायने रखता है, और कोड में उसका सबूत क्या है। निष्कर्ष ट्रैकिंग की अकेली इकाई है, जिसे plan, harden और verify आगे ले जाते हैं, और हर आर्टिफ़ैक्ट में उसकी पहचान उसके नाम से होती है। ### सुरक्षा नियंत्रण (Control) किसी जोखिम को बंद करने के लिए लागू किया गया सुरक्षा उपाय। harden नियंत्रण लागू करता है, verify साबित करता है कि वे कारगर रहते हैं। Lagune किसी प्रॉम्प्ट को संतुष्ट करने के लिए कभी कोई नियंत्रण कमज़ोर नहीं करता। ### Detect वह चरण जो कोड पढ़ता है और खाका बनाता है कि सिस्टम क्या करता है और जोखिम कहाँ हैं। इसका मूल नियम है पहचानना, गढ़ना नहीं: यह सिर्फ़ वही दर्ज करता है जिसका कोड में आधार हो। ### Harden इकलौता चरण जो आपके कोड को छूता है। यह योजना के सुधार एक-एक करके लागू करता है और हर एक को Applied, Partial या Blocked के रूप में दर्ज करता है। Applied का मतलब यह नहीं कि वह साबित भी हो चुका है। ### Verify वह चरण जो कोड पढ़कर और उसका मिलान harden के दर्ज किए रिकॉर्ड से करके साबित करता है कि लागू किया गया हर सुधार कारगर रहता है। यह तीन में से एक फ़ैसला देता है: Risk closed, Risk not closed या Cannot tell from the code। ### बंद करना (Stand down) जब verify साबित कर देता है कि कोई जोखिम बंद हो गया है, तो उस निष्कर्ष को बंद कर दिया जाता है: आपकी पुष्टि के साथ उसे पूरी चेन से हटा दिया जाता है, ताकि उस पर दोबारा काम न हो। ### बंद हो पाना (Closability) यह गुण कि सुरक्षा के काम का एक अंत होता है। जो निष्कर्ष बंद साबित हो चुका है, उसे बंद कर दिया जाता है, इसलिए फ़्लो स्थिर हो सकता है, और सिर्फ़ कोड बदलने पर दोबारा खुलता है। SDH बंद हो सकने वाला है, कोई अंतहीन लूप नहीं। ### इंजन **npm** पर मौजूद `lagune` पैकेज, जिसे कमांड हर नियतात्मक कदम के लिए `npx` से चलाती हैं: हुक, कैटलॉग और श्रेणियाँ। ### विशेषज्ञता (Specialization) सुरक्षा ज्ञान का एक केंद्रित मॉड्यूल, जो किसी एक प्रोग्रामिंग भाषा से बंधा नहीं है और डिफ़ॉल्ट रूप से कभी नहीं, सिर्फ़ ज़रूरत पड़ने पर ही लोड होता है। विशेषज्ञता कमांड नहीं है। इंजन के `read catalog ` से किसी भी प्रॉम्प्ट में कोई विशेषज्ञता लोड करें, जैसे `npx lagune read catalog regex`। ### श्रेणी बिल्ट-इन विशेषज्ञताओं का एक नाम वाला समूह, `owasp` से लेकर `javascript`, `python`, `go` और `rust` जैसी भाषा-विशेष श्रेणियों तक। प्रोजेक्ट जिन श्रेणियों का इस्तेमाल करता है, वे `.lagune/configs.json` में दर्ज होती हैं और तय करती हैं कि कौन-सी बिल्ट-इन विशेषज्ञताएँ उसके कैटलॉग में शामिल होंगी। जब तक कोई श्रेणी दर्ज नहीं होती, प्रोजेक्ट सिर्फ़ `owasp` का इस्तेमाल करता है। ### कैटलॉग विशेषज्ञताओं का वह सेट जिसका प्रोजेक्ट इस्तेमाल करता है: उसकी श्रेणियों की बिल्ट-इन विशेषज्ञताएँ और `/lagune-specialize` से लिखी उसकी अपनी विशेषज्ञताएँ। इंजन का `read catalog` इसकी सूची दिखाता है, और चरण इसका मिलान कोड से करते हैं। ### प्रॉम्प्ट-ऑन-डिमांड (Prompt-on-demand) यह सिद्धांत कि हर जाँच डिफ़ॉल्ट रूप से चलाने के बजाय, प्रोजेक्ट असल में जैसा है, उसी के हिसाब से ज़रूरी सुरक्षा ज्ञान लाया जाता है। ### नाम से पहचान (Identity-by-name) Lagune का ट्रैकिंग मॉडल: हर निष्कर्ष का नाम, जो हर आर्टिफ़ैक्ट में सेक्शन के शीर्षक के रूप में बिल्कुल एक जैसा लिखा जाता है, पूरी चेन में उसकी पहचान है। ट्रैकिंग मैप (`.lagune/tracking.json`) में सिर्फ़ ट्रैकिंग रहती है, कभी कोई विवरण नहीं। ## अक्सर पूछे जाने वाले सवाल ### Security-Driven Hardening (SDH) क्या है? SDH संदर्भ को समझने वाली, Blue Team की एक सुरक्षा पद्धति है। यह सिस्टम के संदर्भ को पहचानती है, उस संदर्भ से जुड़े जोखिमों को प्राथमिकता के हिसाब से छाँटती है, और हर निष्कर्ष को आसान भाषा में रखते हुए सुधारों में मार्गदर्शन करती है। Lagune इसका रेफ़रेंस इम्प्लीमेंटेशन है। ### Lagune में charter क्या है? charter Lagune की वह परत है जो सभी चरणों को दिशा देती है, यानी सुरक्षा को सबसे आगे रखने वाले सिद्धांतों का एक सेट, जिसका पालन बाद के हर चरण को करना होता है। यह .lagune/memory/charter.md में रखा जाता है। ### किसी निष्कर्ष को बंद करने का क्या मतलब है? जब verify साबित कर देता है कि कोई जोखिम बंद हो गया है, तो उस निष्कर्ष को बंद कर दिया जाता है: आपकी पुष्टि के साथ उसे पूरी चेन से हटा दिया जाता है, ताकि उस पर दोबारा काम न हो। --- # कॉन्फ़िगरेशन स्कीमा > Lagune प्रोजेक्ट के कॉन्फ़िगरेशन का JSON Schema, जो आपके एडिटर में ऑटोकम्प्लीशन और वैलिडेशन देता है, और मौजूदा Lagune के साथ चलता है या किसी वर्शन पर तय किया जा सकता है। कैनोनिकल: https://lagune.ai/hi-IN/docs/references/configs-schema भाषा: hi-IN मूल: https://lagune.ai/docs/references/configs-schema आख़िरी अपडेट: 2026-11-06 `.lagune/configs.json` में दर्ज होता है कि प्रोजेक्ट किन [**श्रेणियों**](https://lagune.ai/hi-IN/docs/categories) का इस्तेमाल करता है, इसमें प्रोजेक्ट की अपनी [**विशेषज्ञताओं**](https://lagune.ai/hi-IN/docs/catalog) का इंडेक्स रहता है, और यही तय करता है कि [**चेकर**](https://lagune.ai/hi-IN/docs/hooks/configure) किन चीज़ों को छोड़ दें। इसके JSON Schema की मदद से, फ़ाइल एडिट करते समय आपका एडिटर हर फ़ील्ड को ऑटोकम्प्लीट करता है और कोई टाइपो या अनजानी श्रेणी पकड़ लेता है। ## मौजूदा स्कीमा जब भी **Lagune** यह फ़ाइल लिखता है और उसमें कोई `$schema` नहीं पाता, तो वह फ़ाइल को मौजूदा स्कीमा की ओर इशारा करवा देता है: ```json { "$schema": "https://lagune.ai/schemas/configs.json", "categories": ["owasp", "javascript"] } ``` यह पता हमेशा मौजूदा **Lagune** के साथ चलता है। **Lagune** 0.16.0 से पहले लिखी गई फ़ाइल को यह पता अपने अगले बदलाव पर मिलता है, और तब तक हर चरण इसकी ओर ध्यान दिलाता है। ## कोई वर्शन तय करें 0.16.0 और उसके बाद की हर **Lagune** रिलीज़ में स्कीमा वैसा ही रहता है जैसा वह उस वर्शन में था, जो **npm** पर प्रकाशित होता है और **jsDelivr** से मिलता है। कोई वर्शन तय करने के लिए, उसे `lagune@` के ठीक बाद लिखें, यानी `$schema` वाले पते में: ```json { "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json" } ``` वर्शन में कोई भी semver रेंज चल जाती है: | वर्शन | स्कीमा | | ------------------ | ------------------------------- | | `0.16.0` | 0.16.0 वाला स्कीमा | | `0.16.x` या `0.16` | सबसे नई 0.16 रिलीज़ वाला स्कीमा | | `0.x` या `0` | सबसे नई 0.x रिलीज़ वाला स्कीमा | | `latest` | सबसे नई रिलीज़ वाला स्कीमा | ## अक्सर पूछे जाने वाले सवाल ### क्या Lagune को स्कीमा की ज़रूरत है? नहीं। स्कीमा सिर्फ़ आपके एडिटर की मदद करता है, और Lagune फ़ाइल को $schema के साथ या उसके बिना, एक ही तरह से पढ़ता है। ### क्या Lagune तय किए गए स्कीमा को ओवरराइट कर देगा? नहीं। Lagune $schema सिर्फ़ तब लिखता है जब फ़ाइल में कोई न हो, और आपका सेट किया हुआ हर पता वैसा ही रखता है। ### मुझे वर्शन कब तय करना चाहिए? जब प्रोजेक्ट Lagune का कोई ख़ास वर्शन चलाता हो, ताकि आपका एडिटर फ़ाइल को उसी के हिसाब से जाँचे जो वह वर्शन स्वीकार करता है। --- # Lagune vs. Deepsec: AI-संचालित सुरक्षा के दो तरीक़े, आमने-सामने > Lagune और Vercel के Deepsec की तुलना करने वाला संदर्भ पेज: दोनों कैसे काम करते हैं, उनका जीवनचक्र, पहचान, लागत, निष्कर्ष और उन्हें बंद करना। कैनोनिकल: https://lagune.ai/hi-IN/docs/references/deepsec भाषा: hi-IN मूल: https://lagune.ai/docs/references/deepsec आख़िरी अपडेट: 2026-11-06 [Lagune](https://github.com/wellwelwel/lagune) और [Deepsec](https://github.com/vercel-labs/deepsec) (`v2.2.1`) एक ही समस्या के दो रक्षात्मक जवाब हैं: AI की मदद से डेवलपमेंट के दौर में सुरक्षा। दोनों का आधार, उनकी शुरुआत, बीच का हिस्सा और अंत, और उपयोगकर्ता के सामने वे ख़ुद को कैसे पेश करते हैं, ये सब सोच-समझकर अलग रखे गए हैं, भले ही उनका तंत्र कहीं-कहीं एक जैसा हो। **टिप** क्या Lagune, Deepsec से प्रेरित है? नहीं, Lagune पूरी तरह नए सिरे से लिखा गया है और Spec-Driven Development और Security Hardening से प्रेरित है। दोनों प्रोजेक्ट एक-दूसरे से स्वतंत्र रूप से बनाए गए हैं, और यह तुलना उपयोगकर्ताओं को उनके अंतर समझाने के लिए है। ## एक नज़र में | पहलू | Lagune | Deepsec | | ------------------ | ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | प्रकार | एक पद्धति (SDH), रेफ़रेंस इम्प्लीमेंटेशन के साथ | एक प्रोडक्ट: एजेंट से चलने वाला कमज़ोरी स्कैनर | | मूल आधार | सुरक्षा सिद्धांत और ज़रूरत पड़ने पर ही लोड होने वाला ज्ञान एजेंट को दिशा देते हैं, नियतात्मक हुक के सहारे | regex का चौड़ा जाल एक अनिवार्य AI जाँच तक पहुँचाता है | | यह क्या देता है | सुरक्षा मज़बूत किया गया कोड, प्रमाण, और निष्कर्षों की ट्रैक की गई चेन | गंभीरता के क्रम में लगी, ट्राइएज की गई निष्कर्षों की रिपोर्ट | | आपके कोड में बदलाव | हाँ: `harden` चरण आपका कोड बदलता है | नहीं: सिर्फ़ स्टैटिक एनालिसिस, निष्कर्ष और सुझाव का टेक्स्ट देता है | | रनटाइम | आपके पहले से चल रहे एजेंट और मॉडल पर चलता है, किसी भी टियर का | अपनी मॉडल पाइपलाइन चलाता है, डिफ़ॉल्ट रूप से फ़्रंटियर टियर | | शुरुआत | एक प्लगइन इंस्टॉल या `npx skills add`, फिर आसान भाषा में निर्देश दें, कोई नया टूल खड़ा करने की ज़रूरत नहीं | `.deepsec/` वर्कस्पेस खड़ा करें, डिपेंडेंसी इंस्टॉल करें, और मॉडल की कुंजी जोड़ें | ## यह कैसे काम करता है Lagune एजेंट-फ़र्स्ट है: एजेंट काम चलाता है, कोड जैसा है उसके हिसाब से ज़रूरत पड़ने पर ही ज्ञान लाता है, और तय किया जा सकने वाला हिस्सा नियतात्मक हुक को सौंप देता है। Deepsec नियतात्मकता-फ़र्स्ट है: एक चौड़ा स्कैन ऐसे उम्मीदवार पकड़ता है जो एक अनिवार्य मॉडल को बताते हैं कि किसकी जाँच करनी है और किस पर फ़ैसला देना है। | पहलू | Lagune | Deepsec | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | क्रम | सुरक्षा सिद्धांत और मेल खाता ज्ञान एजेंट को दिशा देते हैं, जो कुछ काम हुक को सौंपता है और बाक़ी पर ख़ुद फ़ैसला करता है | मैचर उम्मीदवार पकड़ते हैं, और मॉडल हर एक की जाँच करके फ़ैसला देता है | | नियतात्मक हिस्से की भूमिका | कई भाषाओं वाले हुक जो फ़ैसला लौटाते हैं या एजेंट को सही जगह दिखाते हैं, श्रेणी के ज्ञान के साथ मिलकर | मैचर जो अनिवार्य मॉडल के फ़ैसले के लिए उम्मीदवार पकड़ते हैं | | डेवलपमेंट फ़्लो | आपके कोड लिखते समय `/lagune` कमांड उसी जगह सुरक्षित ढंग से बनाती है | यह कोड रिव्यू करता है, लिखता नहीं | | ऑडिट फ़्लो | `charter` → `detect` → `plan` → `harden` → `verify` | `scan` → `process` → `triage` → `revalidate` → `report` | | AI का काम | ज्ञान के आधार पर तर्क करना, सुधार लागू करना, और साबित करना कि वह कारगर है | हर उम्मीदवार की जाँच करना और निष्कर्षों की रिपोर्ट देना | ## जीवनचक्र Lagune कोड लिखे जाने से पहले, उसके दौरान और उसके बाद काम करता है। Deepsec कोड मौजूद होने के बाद किसी रिपॉज़िटरी को रिव्यू करता है। | मौक़ा | Lagune | Deepsec | | ---------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | कोड बनने से पहले | `charter` चरण बताए गए इरादे से सुरक्षा नीति तैयार करता है | मौजूदा कोड से शुरू होता है: `init` कमांड को एक डायरेक्टरी चाहिए | | बनाते समय | `/lagune` कमांड उसी जगह डिफ़ॉल्ट रूप से सुरक्षित बनाती है, पीछे कोई आर्टिफ़ैक्ट नहीं छोड़ती | बनने के बाद रिव्यू करता है, बनते समय नहीं | | मौजूदा कोड पर | `detect` → `plan` → `harden` → `verify` | `scan` → `process`, मुख्य फ़्लो | | लगातार रिव्यू | हर दायरे के लिए चरण दोबारा चलाएँ, कोई तैयार CI गेट नहीं | इंक्रीमेंटल री-स्कैन, CI में exit गेट के रूप में `process --diff` | ## पहचान की परत दोनों की नियतात्मक परतें स्वभाव से उलटी हैं: एक फ़ैसला करती है, दूसरी बस पकड़ती है। | पहलू | Lagune | Deepsec | | --------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------------- | | समूह | हुक और विशेषज्ञताएँ, श्रेणियों में बँटी | हर पैटर्न या फ़्रेमवर्क के लिए मैचर | | आउटपुट | सीधा फ़ैसला (finding / review / advisory) और साथ में एक classify लेबल | बिना फ़ैसले वाला उम्मीदवार (slug, लाइनें, कोड का टुकड़ा, मेल खाया पैटर्न) | | ट्यूनिंग | सटीकता: टिप्पणियों को समझने वाला, प्लेसहोल्डर और विंडो गार्ड के साथ | रिकॉल: चौड़े जाल, फ़ॉल्स पॉज़िटिव बाद में AI छाँटता है | | गहराई | साझा वर्गों में ज़्यादा गहरा | ज़्यादा व्यापक, साझा वर्गों में कम गहरा | | फ़ॉल्स पॉज़िटिव | स्रोत पर ही कम रखे जाते हैं, फिर संदर्भ में परखे जाते हैं | जान-बूझकर ज़्यादा पैदा किए जाते हैं, फिर `revalidate` पास में घटाए जाते हैं | ## ज्ञान और फ़ैसला दोनों में सुरक्षा का वह ज्ञान है जो regex में नहीं समा सकता। फ़र्क़ इसमें है कि वह ज्ञान कहाँ रहता है और उसे कौन ढाल सकता है। | पहलू | Lagune | Deepsec | | ------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | रूप | बदले जा सकने वाले Markdown मॉड्यूल, जिनमें से कई के पीछे एक नियतात्मक हुक है | एक छोटा प्रॉम्प्ट और हर टेक के लिए ख़ास बिंदु, जो मॉडल के अपने ज्ञान पर टिके हैं | | चुनाव | कोड से मिलान होता है, और सिर्फ़ तब लोड होता है जब उसका संदर्भ मौजूद हो | हर AI बैच में डाला जाता है, साथ में पहचानी गई टेक के ख़ास बिंदु | | इसे कौन लिखता है | उपयोगकर्ता मॉड्यूल बदलता है और `specialize` कमांड से नए जोड़ता है | प्रॉम्प्ट मेंटेनर के हाथ में है, उपयोगकर्ता एक `INFO.md` फ़ाइल भरता है | | फ़ैसला कहाँ होता है | हुक अपनी न्यूनतम सीमा तय करते हैं, बाक़ी पर एजेंट ज्ञान के आधार पर फ़ैसला करता है | केंद्रीकृत: एक AI प्रोसेसर हर उम्मीदवार पर फ़ैसला देता है | | दोबारा इस्तेमाल | एक मॉड्यूल `detect` और `verify`, दोनों चरणों को राह दिखाता है | एक प्रॉम्प्ट इकलौते `process` चरण को चलाता है | ## निष्कर्ष और उन्हें बंद करना सबसे बड़ा फ़र्क़ इसमें है कि सुलझ जाने के बाद किसी निष्कर्ष का क्या होता है। | पहलू | Lagune | Deepsec | | ----------------- | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | गंभीरता | CVSS v4.0 स्कोर, एक्सपोज़र और दाँव के हिसाब से समायोजित | AI की दी हुई गंभीरता, साथ में एक्सप्लॉइट हो पाने की संभावना और असर के आधार पर P0 / P1 / P2 ट्राइएज | | फ़ैसले | Risk closed, Risk not closed, या Cannot tell from the code | true-positive, false-positive, fixed, uncertain, accepted-risk, duplicate | | सहेजना | कामकाजी चेन मौजूदा स्थिति से मिलाकर अपडेट होती है, बंद निष्कर्षों का सार इतिहास में जाता है | हर फ़ाइल के लिए सिर्फ़ जुड़ते जाने वाले रिकॉर्ड, कुछ भी हटाया नहीं जाता | | अंतिम स्थिति | बंद हो सकने वाला: साबित हुआ निष्कर्ष बंद होता है, और चेन स्थिर हो सकती है | हर निष्कर्ष हमेशा के लिए रखा जाता है, सुलझने पर व्यू से छिपा दिया जाता है | | इतिहास में ब्योरा | जोखिम क्या था, इसका छोटा सार | फ़ैसलों का पूरा सिलसिला, जिसमें यह भी कि उसे कैसे ठीक किया गया | ## लागत | पहलू | Lagune | Deepsec | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | नियतात्मक न्यूनतम आधार | मुफ़्त: हुक बिना AI और बिना कुंजी के चलते हैं, और तभी फ़ैसले दे देते हैं | मुफ़्त: `scan` कमांड बिना AI के चलती है, लेकिन अपने आप कोई फ़ैसला नहीं देती | | आम ख़र्च | आपके पहले से चल रहे एजेंट में ही शामिल: लोकल मॉडल पर $0 तक, आप जिस प्लान की क़ीमत पहले से चुका रहे हैं वही, या API आधारित इस्तेमाल में हर इटरेशन के हिसाब से | [100 से 2,000 फ़ाइलों के लिए हर रन पर लगभग $25 से $1,200, बड़े पैमाने पर और ज़्यादा](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) | | सबसे सस्ता रास्ता | कोई भी मॉडल, मुफ़्त लोकल मॉडल भी, चक्र पूरा कर देता है | सस्ते पेड टियर मौजूद हैं, लेकिन निष्कर्षों के लिए पेड AI चरण ज़रूरी है | ## विस्तार और गवर्नेंस हर एक वह परत खोलता है जिसे दूसरा बंद रखता है। | पहलू | Lagune | Deepsec | | ------------------ | ------------------------------------------------------------------- | ----------------------------------------- | | आप क्या बढ़ाते हैं | मॉड्यूल बदलें, या `specialize` कमांड से नए जोड़ें | मैचर, एजेंट, नोटिफ़ायर और ओनरशिप जोड़ें | | नीति की परत | सुरक्षा सिद्धांत हर चरण को दिशा देते हैं और उनका वर्ज़न रखा जाता है | कॉन्फ़िग कामकाजी है (मैचर, मॉडल, पाथ) | | नाम से ओवरराइड | सुधारा गया मॉड्यूल बिल्ट-इन की जगह लेता है | मैचर का slug टकराए, तो आपका मैचर जीतता है | ## इंटरफ़ेस Deepsec किसी सुरक्षा संगठन के लिए डिलीवरेबल तैयार करता है। Lagune उसे चलाने वाले व्यक्ति के लिए एक लाइव व्यू दिखाता है। | पहलू | Lagune | Deepsec | | --------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | लोगों के देखने का इंटरफ़ेस | पूरी चेन का लोकल लाइव डैशबोर्ड, आसान भाषा में | रिपोर्ट, एक्सपोर्ट, मेट्रिक्स और PR-कमेंट फ़ाइलें, साथ में एक डॉक्स साइट | | जवाबदेही | फ़ाइलें और लागू हुई विशेषज्ञताएँ सामने रखता है | ज़िम्मेदारी के लिए किसी का सुझाव देता है: ऑन-कॉल, मैनेजर या कमिट करने वाला | | दोहराया जा सकने वाला प्रमाण | `prove` कमांड चलाए जा सकने वाले टेस्ट और खुलासे के लिए सुरक्षा एडवाइज़री लिखती है | डिज़ाइन से स्टैटिक रहता है, लक्ष्य को कभी चलाता नहीं | | टूल की अपनी रक्षा | डैशबोर्ड पर लोकल राइट API की सुरक्षा मज़बूत करता है | अविश्वसनीय लक्ष्य कोड के ख़िलाफ़ अपने AI एक्ज़ीक्यूशन की सुरक्षा मज़बूत करता है | ## पैमाना और डिप्लॉयमेंट | पहलू | Lagune | Deepsec | | -------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------ | | इंस्टॉल | आपके एजेंट के प्लगइन या **skills** CLI से नौ कमांड, कुछ भी स्कैफ़ोल्ड नहीं होता | अपने पैकेज और डिपेंडेंसी वाला एक `.deepsec/` वर्कस्पेस | | पैमाने की दिशा | किसी भी हिस्से तक सिमट सकता है, एक संदर्भ या एक फ़ाइल से लेकर पूरे प्रोजेक्ट तक | पूरी रिपॉज़िटरी स्कैन करता है, बड़े मोनोरेपो तक | | वितरण | सिर्फ़ लोकल, इकलौता सर्वर लूपबैक से बँधा है | ज़रूरत हो तो काम को Vercel Sandbox वर्कर VM में बाँट सकता है | ## उपयोगकर्ता अनुभव हर टूल उसे चलाने वाले व्यक्ति से कैसे मिलता है: पहले रन के लिए क्या चाहिए, और चलाने वाला उसे किस ओर मोड़ता है। ### ऑनबोर्डिंग Lagune पहले से खुले एजेंट के ज़रिए चलता है। Deepsec पहले अपना वर्कस्पेस और मॉडल एक्सेस तैयार करता है। | पहलू | Lagune | Deepsec | | ------------------------ | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | पहली कमांड | प्लगइन इंस्टॉल या `npx skills add wellwelwel/lagune`, फिर एजेंट में `/lagune-*` | `npx deepsec init`, फिर `cd .deepsec`, `pnpm install`, `scan`, `process` | | चलाने के लिए क्रेडेंशियल | अलग कुंजी नहीं, यह आपका मौजूदा एजेंट इस्तेमाल करता है | मॉडल की कुंजी (जैसे AI Gateway, 12 घंटे वाला Vercel OIDC टोकन, या Anthropic टोकन) | ### इसे दिशा देना दोनों निर्देश लेते हैं। Lagune हर चरण में इनपुट का रूप पढ़ता है। Deepsec उन फ़ाइलों का दायरा छोटा करता है जिन पर वही जाँच चलती है। | पहलू | Lagune | Deepsec | | ------------------ | -------------------------------------------------------------------------------- | --------------------------------------------------------------- | | पूरा प्रोजेक्ट | बिना इनपुट वाला चरण पूरे दायरे को स्कैन करता है | `scan` और `process` कमांड रिपॉज़िटरी को स्कैन करती हैं | | एक हिस्सा | कोई भी चरण दी गई फ़ाइलों या डायरेक्टरी तक सिमट जाता है | `--files`, `--files-from` या `--diff` रन का दायरा छोटा करते हैं | | एक चिंता | चरण बताई गई चिंता तक सिमट जाता है | जाँच का प्रॉम्प्ट तय है | | प्राथमिकता का स्तर | `harden` और `verify` चरण क्रिटिकल, उच्च, मध्यम या निम्न तक सिमट जाते हैं | निष्कर्षों पर लेबल रन के बाद लगते हैं | | एक अकेली वैल्यू | हुक एक कोड के टुकड़े, पैटर्न या URL को सीधे स्कोर देता है (`--pattern`, `--url`) | काम की इकाई एक फ़ाइल है | ## अक्सर पूछे जाने वाले सवाल ### Lagune और Deepsec में क्या फ़र्क़ है? Lagune एजेंट-फ़र्स्ट है और कोड लिखे जाने से पहले, उसके दौरान और उसके बाद काम करता है: यह कोड से पहले नीति तय करता है, बनाते समय उसी जगह सुरक्षा मज़बूत करता है, और पहले से लिखे कोड का ऑडिट करता है, उसकी सुरक्षा मज़बूत करता है और पुष्टि करता है। Deepsec नियतात्मकता-फ़र्स्ट है: regex का चौड़ा स्कैन एक अनिवार्य फ़्रंटियर-मॉडल जाँच तक पहुँचाता है, जो मौजूदा कोड रिव्यू करती है और निष्कर्षों की रिपोर्ट देती है, कोड बदले बिना। ### क्या मैं इनमें से किसी को मुफ़्त में चला सकता हूँ? Lagune का पूरा फ़्लो मुफ़्त लोकल मॉडल पर $0 में चल सकता है, और इसके नियतात्मक हुक बिना किसी AI के फ़ैसले देते हैं। Deepsec का स्कैन मुफ़्त है, लेकिन कोई फ़ैसला नहीं देता, इसलिए किसी भी निष्कर्ष के लिए उसका पेड AI चरण ज़रूरी है। ### क्या इनमें से कोई मेरा कोड बदलता है? Lagune बदलता है: harden चरण आपके कोड में सुधार लागू करता है। Deepsec नहीं बदलता: यह सिर्फ़ स्टैटिक एनालिसिस करता है और निष्कर्ष व सुझाव का टेक्स्ट देता है, जिसे कोई व्यक्ति या एजेंट अलग से लागू करता है। --- # OWASP स्रोत > बिल्ट-इन OWASP विशेषज्ञताओं का ज्ञान कहाँ से आता है, OWASP के आधिकारिक अटैक और Cheat Sheet पेजों के साथ उसका पूरा खाका। कैनोनिकल: https://lagune.ai/hi-IN/docs/references/owasp-sources भाषा: hi-IN मूल: https://lagune.ai/docs/references/owasp-sources आख़िरी अपडेट: 2026-11-06 यह दस्तावेज़ OWASP के हर **अटैक** (`www-community`) और हर **Cheat Sheet** (`CheatSheetSeries`) को किसी सुरक्षा श्रेणी से जोड़ता है, और हर एक को उसके आधिकारिक सार्वजनिक पेज से लिंक करता है। एक श्रेणी के भीतर, बराबर के आइटम चेकलिस्ट की एक ही लाइन में आते हैं: एक ही जोखिम से जुड़े अटैक और Cheat Sheet कॉमा से अलग करके साथ-साथ लिखे जाते हैं। जिन आइटम का कोई सीधा जोड़ीदार नहीं है, वे अपनी अलग लाइन में हैं। - इसका श्रेय OWASP को जाता है। अटैक `https://owasp.org/www-community/attacks/` पर और Cheat Sheet `https://cheatsheetseries.owasp.org/cheatsheets/.html` पर मिलती हैं। --- ## 1. इंजेक्शन (सामान्य) - [x] [Code Injection](https://owasp.org/www-community/attacks/Code_Injection), [Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html), [Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_in_Java_Cheat_Sheet.html) (interpreter) - [x] [Direct Dynamic Code Evaluation (Eval Injection)](https://owasp.org/www-community/attacks/Direct_Dynamic_Code_Evaluation_Eval_Injection) (interpreter) - [x] [Function Injection](https://owasp.org/www-community/attacks/Function_Injection) (interpreter) - [x] [Resource Injection](https://owasp.org/www-community/attacks/Resource_Injection) (network) - [x] [Special Element Injection](https://owasp.org/www-community/attacks/Special_Element_Injection) (interpreter) - [x] [Custom Special Character Injection](https://owasp.org/www-community/attacks/Custom_Special_Character_Injection) (interpreter) - [x] [Comment Injection Attack](https://owasp.org/www-community/attacks/Comment_Injection_Attack) (interpreter) - [x] [Parameter Delimiter](https://owasp.org/www-community/attacks/Parameter_Delimiter) (interpreter) - [x] [Server-Side Includes (SSI) Injection](https://owasp.org/www-community/attacks/Server-Side_Includes_%28SSI%29_Injection) (interpreter) - [x] [Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), [Bean Validation](https://cheatsheetseries.owasp.org/cheatsheets/Bean_Validation_Cheat_Sheet.html) (interpreter) --- ## 2. SQL / डेटाबेस इंजेक्शन - [x] [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection), [SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), [Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) (sql) - [x] [Blind SQL Injection](https://owasp.org/www-community/attacks/Blind_SQL_Injection) (sql) - [x] [SQL Injection Bypassing WAF](https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF) (sql) - [x] [RSQL Injection](https://owasp.org/www-community/attacks/RSQL_Injection) (interpreter) - [x] [Database Security](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html) (sql) - [x] [NoSQL Security](https://cheatsheetseries.owasp.org/cheatsheets/NoSQL_Security_Cheat_Sheet.html) (interpreter) --- ## 3. OS / कमांड इंजेक्शन - [x] [Command Injection](https://owasp.org/www-community/attacks/Command_Injection), [OS Command Injection Defense](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html) (interpreter) --- ## 4. LDAP / XPath / XML इंजेक्शन - [x] [LDAP Injection](https://owasp.org/www-community/attacks/LDAP_Injection), [LDAP Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) (interpreter) - [x] [XPATH Injection](https://owasp.org/www-community/attacks/XPATH_Injection) (interpreter) - [x] [Blind XPath Injection](https://owasp.org/www-community/attacks/Blind_XPath_Injection) (interpreter) - [x] [XML External Entity (XXE) Prevention](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html), [XML Security](https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html) (xml) --- ## 5. क्रॉस-साइट स्क्रिप्टिंग (XSS) - [x] [Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/Cross-site-Scripting-%28XSS%29), [Cross Site Scripting Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), [XSS Filter Evasion](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) (browser) - [x] [DOM Based XSS](https://owasp.org/www-community/attacks/DOM_Based_XSS), [DOM based XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html), [DOM Clobbering Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) (browser) - [x] [Reflected DOM Injection](https://owasp.org/www-community/attacks/Reflected_DOM_Injection) (browser) - [x] [XSS in Converting File Content to Text](https://owasp.org/www-community/attacks/XSS_in_Converting_File_Content_to_Text) (browser) - [x] [XSS in subtitle](https://owasp.org/www-community/attacks/Xss_in_subtitle) (browser) - [x] [Cross Frame Scripting](https://owasp.org/www-community/attacks/Cross_Frame_Scripting) (browser) - [x] [Cross Site Tracing](https://owasp.org/www-community/attacks/Cross_Site_Tracing) (browser) - [x] [Content Security Policy](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) (browser) --- ## 6. क्रॉस-साइट रिक्वेस्ट फ़ोर्जरी (CSRF) और क्लिकजैकिंग - [x] [Cross Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/cross-site-request-forgery), [XSRF](https://owasp.org/www-community/attacks/XSRF), [Cross-Site Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) (http-request) - [x] [Clickjacking](https://owasp.org/www-community/attacks/Clickjacking), [Clickjacking Defense](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) (browser) - [x] [Cross Site History Manipulation (XSHM)](https://owasp.org/www-community/attacks/Cross_Site_History_Manipulation_%28XSHM%29) (browser) - [x] [Form action hijacking](https://owasp.org/www-community/attacks/Form_action_hijacking) (network) - [x] [Reverse Tabnabbing](https://owasp.org/www-community/attacks/Reverse_Tabnabbing) (browser) --- ## 7. रीडायरेक्ट और फ़ॉरवर्ड - [x] [Open Redirect](https://owasp.org/www-community/attacks/open_redirect), [Unvalidated Redirects and Forwards](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html) (network) - [x] [Execution After Redirect (EAR)](https://owasp.org/www-community/attacks/Execution_After_Redirect_%28EAR%29) (browser) --- ## 8. एक्सेस कंट्रोल और ऑथराइज़ेशन - [x] [Insecure Direct Object Reference (IDOR)](https://owasp.org/www-community/attacks/insecure_direct_object_reference), [Insecure Direct Object Reference Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html) (access-control) - [x] [Forced browsing](https://owasp.org/www-community/attacks/Forced_browsing) (access-control) - [x] [Web Parameter Tampering](https://owasp.org/www-community/attacks/Web_Parameter_Tampering) (access-control) - [x] [Setting Manipulation](https://owasp.org/www-community/attacks/Setting_Manipulation) (access-control) - [x] [Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) (access-control) - [x] [Transaction Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) (access-control) - [x] [Mass Assignment](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) (access-control) - [x] [Multi-Tenant Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) (access-control) --- ## 9. ऑथेंटिकेशन और क्रेडेंशियल - [x] [Brute Force Attack](https://owasp.org/www-community/attacks/Brute_force_attack), [Password Spraying Attack](https://owasp.org/www-community/attacks/Password_Spraying_Attack), [Bot Management and Anti-Automation](https://cheatsheetseries.owasp.org/cheatsheets/Bot_Management_and_Anti-Automation_Cheat_Sheet.html) (credential-endpoint) - [x] [Credential stuffing](https://owasp.org/www-community/attacks/Credential_stuffing), [Credential Stuffing Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) (credential-endpoint) - [x] [Qrljacking](https://owasp.org/www-community/attacks/Qrljacking) (federation) - [x] [Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html), [Multifactor Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) (access-control) - [x] [Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) (access-control) - [x] [Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html), [Choosing and Using Security Questions](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html) (access-control) - [x] [Email Validation and Verification in Identity Systems](https://cheatsheetseries.owasp.org/cheatsheets/Email_Validation_and_Verification_Cheat_Sheet.html) (access-control) --- ## 10. सेशन मैनेजमेंट - [x] [Session fixation](https://owasp.org/www-community/attacks/Session_fixation), [Session hijacking attack](https://owasp.org/www-community/attacks/Session_hijacking_attack), [Session Prediction](https://owasp.org/www-community/attacks/Session_Prediction), [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) (access-control) - [x] [Cookie Theft Mitigation](https://cheatsheetseries.owasp.org/cheatsheets/Cookie_Theft_Mitigation_Cheat_Sheet.html) (access-control) --- ## 11. आइडेंटिटी फ़ेडरेशन (OAuth / SAML / JWT) - [x] [OAuth 2.0 Protocol](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) (federation) - [x] [SAML Security](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html) (federation) - [x] [JSON Web Token for Java](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (federation) --- ## 12. क्रिप्टोग्राफ़ी और ट्रांसपोर्ट सुरक्षा - [x] [Cryptanalysis](https://owasp.org/www-community/attacks/Cryptanalysis), [Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html), [Key Management](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html) (crypto) - [x] [Manipulator-in-the-Middle (MITM)](https://owasp.org/www-community/attacks/Man-in-the-middle_attack), [Transport Layer Security](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) (transport) - [x] [HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) (transport) - [x] [Pinning](https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html) (transport) --- ## 13. सर्वर-साइड रिक्वेस्ट फ़ोर्जरी (SSRF) - [x] [Server Side Request Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery), [Server-Side Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) (network) --- ## 14. पाथ ट्रैवर्सल और फ़ाइल हैंडलिंग - [x] [Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) (path) - [x] [Binary Planting](https://owasp.org/www-community/attacks/Binary_planting) (path) - [x] [Windows ::DATA Alternate Data Stream](https://owasp.org/www-community/attacks/Windows_DATA_alternate_data_stream) (path) - [x] [Embedding Null Code](https://owasp.org/www-community/attacks/Embedding_Null_Code) (path) - [x] [File Upload](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) (upload) --- ## 15. HTTP प्रोटोकॉल का दुरुपयोग (हेडर, कैशिंग, स्प्लिटिंग) - [x] [HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting), [Cross-User Defacement](https://owasp.org/www-community/attacks/Cross-User_Defacement) (interpreter) - [x] [HTTP Security Response Headers](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) (browser, transport, http-request और access-control में बँटा हुआ) - [x] [Cache Poisoning](https://owasp.org/www-community/attacks/Cache_Poisoning) (interpreter) - [x] [IP Spoofing via HTTP Headers](https://owasp.org/www-community/attacks/ip_spoofing_via_http_headers) (http-request) --- ## 16. एन्कोडिंग और कंटेंट स्पूफ़िंग - [x] [Unicode Encoding](https://owasp.org/www-community/attacks/Unicode_Encoding) (interpreter) - [x] [Double Encoding](https://owasp.org/www-community/Double_Encoding) (interpreter) - [x] [Content Spoofing](https://owasp.org/www-community/attacks/Content_Spoofing) (browser) --- ## 17. CSV / स्प्रेडशीट इंजेक्शन - [x] [CSV Injection](https://owasp.org/www-community/attacks/CSV_Injection) (csv) --- ## 18. CORS (क्रॉस-ओरिजिन रिसोर्स शेयरिंग) - [x] [CORS OriginHeaderScrutiny](https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny) (http-request) - [x] [CORS RequestPreflightScrutiny](https://owasp.org/www-community/attacks/CORS_RequestPreflightScrutiny) (http-request) --- ## 19. डिनायल ऑफ़ सर्विस - [x] [Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (regex) --- ## 20. मेमोरी सेफ़्टी और नेटिव कोड - [x] [Buffer Overflow Attack](https://owasp.org/www-community/attacks/Buffer_overflow_attack), [Buffer Overflow via Environment Variables](https://owasp.org/www-community/attacks/Buffer_Overflow_via_Environment_Variables) (c-cpp) - [x] [Format string attack](https://owasp.org/www-community/attacks/Format_string_attack) (c-cpp) --- ## 21. मोबाइल कोड और अविश्वसनीय कोड का एक्ज़ीक्यूशन - [x] [Mobile code invoking untrusted mobile code](https://owasp.org/www-community/attacks/Mobile_code_invoking_untrusted_mobile_code) (interpreter) - [x] [Mobile code non-final public field](https://owasp.org/www-community/attacks/Mobile_code_non-final_public_field) (java) - [x] [Mobile code object hijack](https://owasp.org/www-community/attacks/Mobile_code_object_hijack) (java) --- ## 22. डीसीरियलाइज़ेशन - [x] [Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) (python, ruby, php, java और dotnet में बँटा हुआ) --- ## 23. मैलवेयर और क्लाइंट-साइड ख़तरे - [x] [Man-in-the-browser attack](https://owasp.org/www-community/attacks/Man-in-the-browser_attack), [Browser Extension Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Browser_Extension_Vulnerabilities_Cheat_Sheet.html) (browser) - [x] [Third Party JavaScript Management](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html) (browser) --- ## 24. लॉगिंग, रेप्युडिएशन और एरर हैंडलिंग - [x] [Log Injection](https://owasp.org/www-community/attacks/Log_Injection), [Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html), [Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html) (interpreter) - [x] [Repudiation Attack](https://owasp.org/www-community/attacks/Repudiation_Attack) (interpreter) --- ## 25. बिज़नेस लॉजिक और फ़ंक्शनैलिटी का दुरुपयोग बिज़नेस लॉजिक और फ़ंक्शनैलिटी के दुरुपयोग का कोड में कोई एक अटैक सरफ़ेस नहीं होता, जिसका बचाव किसी एक सरफ़ेस पर केंद्रित विशेषज्ञता कर सके: इसका बचाव ऐप्लिकेशन के हिसाब से किया गया डिज़ाइन है, यानी वही सोच जिसे प्रोजेक्ट की थ्रेट मॉडलिंग आगे बढ़ाती है। इसे "दायरे से बाहर" में ले जाया गया है। --- ## 26. AI / LLM / एजेंट सुरक्षा - [x] [Prompt Injection](https://owasp.org/www-community/attacks/prompt-injection), [LLM Prompt Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) (llm) - [x] [MCP Tool Poisoning](https://owasp.org/www-community/attacks/MCP_Tool_Poisoning), [MCP (Model Context Protocol) Security](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) (llm) - [x] [HITL Dialog Forging (Lies-in-the-Loop)](https://owasp.org/www-community/attacks/lies-in-the-loop) (llm) - [x] [AI Agent Security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html), [Secure Coding with AI](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html) (llm) - [x] [Retrieval-Augmented Generation (RAG) Security](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html) (llm) - [x] [Secure AI/ML Model Ops](https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html) (llm) - [x] [AML and Sanctions Compliance for AI Agent Payments](https://cheatsheetseries.owasp.org/cheatsheets/AML_Sanctions_AI_Agent_Payments_Cheat_Sheet.html) (llm) --- ## 27. प्रोटोटाइप पॉल्यूशन और क्रॉस-साइट लीक - [x] [Prototype Pollution Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html) (javascript) - [x] [Cross-site leaks (XS-Leaks)](https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html) (browser) --- ## 28. फ़्रेमवर्क और भाषा प्लेटफ़ॉर्म - [x] [Django Security](https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet.html), [Django REST Framework](https://cheatsheetseries.owasp.org/cheatsheets/Django_REST_Framework_Cheat_Sheet.html) (python) - [x] [Ruby on Rails](https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet.html) (ruby) - [x] [Laravel](https://cheatsheetseries.owasp.org/cheatsheets/Laravel_Cheat_Sheet.html) (php) - [x] [Symfony](https://cheatsheetseries.owasp.org/cheatsheets/Symfony_Cheat_Sheet.html) (php) - [x] [Java Security](https://cheatsheetseries.owasp.org/cheatsheets/Java_Security_Cheat_Sheet.html) (java) - [x] [DotNet Security](https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html) (dotnet) - [x] [NodeJS Security](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html) (javascript) - [x] [PHP Configuration](https://cheatsheetseries.owasp.org/cheatsheets/PHP_Configuration_Cheat_Sheet.html) (php) --- ## 29. वेब फ़्रंट-एंड और ब्राउज़र - [x] [HTML5 Security](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html) (browser) - [x] [AJAX Security](https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet.html) (browser) - [x] [Securing Cascading Style Sheets](https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.html) (access-control और browser में बँटा हुआ) --- ## 30. API और सर्विस - [x] [GraphQL](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html) (api-endpoint) - [x] [gRPC Security](https://cheatsheetseries.owasp.org/cheatsheets/gRPC_Security_Cheat_Sheet.html) (api-endpoint) - [x] [WebSocket Security](https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html) (api-endpoint) --- ## 31. क्लाउड, कंटेनर और इन्फ़्रास्ट्रक्चर कंटेनर और वर्कलोड का कॉन्फ़िगरेशन कोड के रूप में लिखा कॉन्फ़िगरेशन है, जिसे डेवलपर ऐप के साथ ही शिप करता है (`Dockerfile`, Compose, Pod का `securityContext`)। यह एक असली सरफ़ेस है, जिसे `harden` चरण ठीक करता है और `verify` चरण साबित करता है, इसलिए यह दायरे में है। क्लस्टर एडमिनिस्ट्रेशन (RBAC, etcd, API सर्वर, एडमिशन, नेटवर्क सेगमेंटेशन) ऑपरेटर का क्षेत्र है, और दायरे से बाहर रहता है। - [x] [Docker Security](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html), [Node.js Docker](https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker_Cheat_Sheet.html) (container) - [x] [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (container: वर्कलोड और Pod वाला हिस्सा। क्लस्टर एडमिनिस्ट्रेशन दायरे से बाहर रहता है) - [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless) --- ## 32. सप्लाई चेन और CI/CD - [x] [NPM Security](https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html) (interpreter) - [x] [Dependency Graph & SBOM Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html), [Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) (interpreter) --- ## 33. सीक्रेट और कॉन्फ़िगरेशन सीक्रेट मैनेजमेंट ऑपरेशन से जुड़ा काम है: वॉल्ट, CI/CD, क्लाउड कॉन्फ़िगरेशन, रोटेशन। इसका कोड से जुड़ा इकलौता पहलू (सोर्स कोड में हार्डकोड किया गया सीक्रेट) एक नियतात्मक स्कैन का काम है, जोखिम पर केंद्रित किसी विशेषज्ञता का नहीं। इसे "दायरे से बाहर" में ले जाया गया है। --- ## 34. प्रोसेस, डिज़ाइन और गवर्नेंस यूज़र की प्राइवेसी की सुरक्षा नीति और डिज़ाइन का मामला है (डेटा मिनिमाइज़ेशन, पारदर्शिता, डेटा रखने की अवधि), कोड का ऐसा कोई सरफ़ेस नहीं जिसका बचाव कोई विशेषज्ञता करे। इसे "दायरे से बाहर" में ले जाया गया है। --- ## 35. पेमेंट और कंप्लायंस - [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment) --- ## 36. एम्बेडेड / IoT / विशेष क्षेत्र ऑटोमोटिव और ड्रोन सुरक्षा एम्बेडेड सिस्टम के क्षेत्र हैं (CAN बस, OTA फ़र्मवेयर, सेंसर और रेडियो की अखंडता, फ़िज़िकल एक्सेस), न कि वेब या API ऐप्लिकेशन का वह सोर्स कोड जिसका Lagune ऑडिट करता है। इसे "दायरे से बाहर" में ले जाया गया है। --- ## दायरे से बाहर (कोड में कोई सरफ़ेस नहीं) ये विशेषज्ञताओं के क्षेत्र नहीं हैं, इसलिए इनके साथ कोई चेकबॉक्स नहीं है: ये गवर्नेंस, प्रोसेस, ऑपरेशन से जुड़ी हार्डनिंग या फ़्रेमवर्क के इस्तेमाल के मामले हैं, जिनका कोड में कोई एक सरफ़ेस नहीं होता जिसका बचाव किसी एक सरफ़ेस पर केंद्रित विशेषज्ञता कर सके। सुरक्षा के लिहाज़ से इनकी अहमियत असली है, लेकिन वह प्रोसेस और आर्किटेक्चर में है (या किसी फ़्रेमवर्क के मामले में, उस भाषा की अपनी स्किल में), उस रक्षा में नहीं जो यह कैटलॉग देता है। ये सिर्फ़ संदर्भ के लिए दिए गए हैं, करने वाले काम के रूप में नहीं। - [Authorization Regression Testing](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Regression_Testing_Cheat_Sheet.html), [Authorization Testing Automation](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html) - [JAAS](https://cheatsheetseries.owasp.org/cheatsheets/JAAS_Cheat_Sheet.html) - [Denial of Service](https://owasp.org/www-community/attacks/Denial_of_Service), [Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) - [HTTP/2 Reset Attack](https://owasp.org/www-community/attacks/HTTP2_Reset_Attack) - [Traffic flood](https://owasp.org/www-community/attacks/Traffic_flood) - [Web Service Amplification Attack](https://owasp.org/www-community/attacks/web_service_amplificaiton) (SOAP/WS-Addressing एम्प्लिफ़िकेशन, DoS का ऑपरेशन से जुड़ा एक रूप, जिसका कोड में कोई सरफ़ेस नहीं) - [Cash Overflow](https://owasp.org/www-community/attacks/Cash_Overflow) - [Spyware](https://owasp.org/www-community/attacks/Spyware), [Trojan Horse](https://owasp.org/www-community/attacks/Trojan_Horse) (एंड-यूज़र को निशाना बनाने वाला मैलवेयर, ऑडिट किए जा रहे प्रोजेक्ट के कोड का कोई सरफ़ेस नहीं। ब्राउज़र के अंदर पहुँचाए जाने वाला पहलू `browser` में है) - [REST Security](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html), [REST Assessment](https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html) - [Web Service Security](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html) - [Cloud Architecture Security](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html) (डिज़ाइन और उसके समझौते: IAM बनाम साइन किए गए URL, पब्लिक या प्राइवेट VPC, ट्रस्ट बाउंड्री, शेयर्ड रिस्पॉन्सिबिलिटी। `container` के उलट, इसमें कोई ठोस कॉन्फ़िगरेशन नहीं है जिसे कोई विशेषज्ञता जाँच सके) - [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) (नाम के बावजूद, यह IaC को _मैनेज करने_ के लिए SDLC प्रोसेस और टूलिंग के बारे में है: IDE प्लगइन, स्टैटिक एनालिसिस, इमेज स्कैनिंग, CI/CD, साइनिंग। यह Terraform या CloudFormation फ़ाइल में किसी असुरक्षित पैटर्न को सुरक्षित रूप में बदलने का तरीक़ा नहीं बताता) - [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (_सिर्फ़ क्लस्टर एडमिनिस्ट्रेशन वाला हिस्सा_: RBAC, etcd, API सर्वर, एडमिशन। वर्कलोड और Pod वाला हिस्सा `container` के तहत दायरे में है) - [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) (नेटवर्क आर्किटेक्चर और फ़ायरवॉल नीति) - [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) (DNS लाइफ़साइकिल और मॉनिटरिंग, कोड नहीं) - [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (वॉल्ट, CI/CD, रोटेशन। हार्डकोड किए गए सीक्रेट वाला पहलू एक नियतात्मक स्कैन का काम है, जोखिम पर केंद्रित किसी विशेषज्ञता का नहीं) - [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html) (कंपाइलर, लिंकर और बिल्ड फ़्लैग, जिनका सोर्स कोड में कोई सिंक नहीं) - [Microservices Security](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet.html), [Microservices based Security Arch Doc](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_based_Security_Arch_Doc_Cheat_Sheet.html) - [Zero Trust Architecture](https://cheatsheetseries.owasp.org/cheatsheets/Zero_Trust_Architecture_Cheat_Sheet.html) - [CI/CD Security](https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html), [GitHub Actions Security](https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html) - [Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) - [Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html), [Full Path Disclosure](https://owasp.org/www-community/attacks/Full_Path_Disclosure) (हर स्टैक के लिए ग्लोबल एरर-हैंडलर का कॉन्फ़िगरेशन। यह लीक वही जानकारी उजागर होना है जिसे एरर हैंडलिंग पहले से सँभालती है) - [Abuse of Functionality](https://owasp.org/www-community/attacks/Abuse_of_Functionality), [Business Logic Security](https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html), [Abuse Case (_ऐतिहासिक_)](https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html) (ऐप्लिकेशन के हिसाब से किया गया डिज़ाइन, कोड में कोई एक सिंक नहीं) - [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) (डेटा मिनिमाइज़ेशन, पारदर्शिता, डेटा रखने की नीति) - [Top 10 Automotive Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Automotive_Security_Cheat_Sheet.html), [Drone Security](https://cheatsheetseries.owasp.org/cheatsheets/Drone_Security_Cheat_Sheet.html) (एम्बेडेड सिस्टम के क्षेत्र: CAN बस, OTA फ़र्मवेयर, सेंसर और रेडियो की अखंडता, वेब या API का सोर्स कोड नहीं) - [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html) (Android और iOS प्लेटफ़ॉर्म की हार्डनिंग: स्टोरेज, बायोमेट्रिक्स, पिनिंग, PII। इसका कोड में कोई एक सरफ़ेस नहीं है, और अविश्वसनीय कोड लोड करने वाला पहलू `interpreter` में चला गया) - [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling (_कम्युनिटी पेज_)](https://owasp.org/www-community/Threat_Modeling) - [Attack Surface Analysis](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html) - [Secure Product Design](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) - [Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) - [Virtual Patching](https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html) - [Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) - [Legacy Application Management](https://cheatsheetseries.owasp.org/cheatsheets/Legacy_Application_Management_Cheat_Sheet.html) - [Security Terminology](https://cheatsheetseries.owasp.org/cheatsheets/Security_Terminology_Cheat_Sheet.html) --- # /lagune-repair: निष्कर्षों की टूटी ट्रैकिंग ठीक करें > जब किसी फ़ाइल का नाम बदलने या उसे दूसरी जगह ले जाने से Lagune की ट्रैकिंग उलझ जाए, तो चेन को ठीक करें। कैनोनिकल: https://lagune.ai/hi-IN/docs/commands/repair भाषा: hi-IN मूल: https://lagune.ai/docs/commands/repair आख़िरी अपडेट: 2026-11-06 🧰 जब किसी फ़ाइल का नाम बदलने या उसे दूसरी जगह ले जाने से चेन उलझ जाए, तो उसे ठीक करें। **अंदरूनी रखरखाव, सुरक्षा का कोई चरण नहीं** repair एक के बाद एक चलने वाले फ़्लो का छठा चरण नहीं है। इसका काम ट्रैकिंग को सुसंगत रखना है। ```prompt # यह कोई इनपुट नहीं लेता: यह हमेशा पूरी चेन ठीक करता है /lagune-repair ``` ## यह कैसे काम करता है detect चरण का हर निष्कर्ष एक ट्रैक किया गया आइटम है, जिसे plan, harden और verify चरण आगे ले जाते हैं: हर चरण उस पर काम करता है और उसे नाम से दोबारा रिपोर्ट करता है। वह नाम हर आर्टिफ़ैक्ट में सेक्शन के शीर्षक के रूप में बिल्कुल एक जैसा लिखा जाता है, और शुरू से आख़िर तक वही उस आइटम की पहचान है। ट्रैकिंग में बदल सकने वाली इकलौती चीज़ वे फ़ाइल पाथ हैं जिनकी ओर आइटम इशारा करता है। ये पाथ और कहीं नहीं रहते, इसलिए किसी फ़ाइल का नाम बदलने या उसे दूसरी जगह ले जाने से लिंक सिर्फ़ वहीं टूट सकता है, कभी दो ऐसी कॉपियों में नहीं जो आपस में बेमेल हो जाएँ। ऐसा होने पर repair मैप (`.lagune/tracking.json`) को ठीक करता है, ताकि नाम बदलने के बाद भी पहचान बनी रहे। यह आर्टिफ़ैक्ट और ट्रैकिंग मैप पढ़ता है, आपका सोर्स कोड सिर्फ़ यह जानने के लिए पढ़ता है कि नाम बदली गई फ़ाइल का नया पाथ क्या है, और सुरक्षा से जुड़ी कोई सामग्री ख़ुद कभी नहीं लिखता। इसी दौर में यह हर मेमोरी आर्टिफ़ैक्ट को उसके टेम्पलेट से मिलाकर जाँचता है, और जो कुछ उससे भटक गया है उसकी रिपोर्ट देता है, साथ ही हर गड़बड़ी के लिए वह चरण बताता है जो उसे ठीक करता है। **टिप** - यह न आपके कोड को छूता है, न लिखित आर्टिफ़ैक्ट को, सिर्फ़ ट्रैकिंग को। - इसे हाथ से चलाने की ज़रूरत शायद ही कभी पड़ती है। जब किसी चरण को पता चलता है कि चेन में तालमेल नहीं है, तो वह आपके लिए repair चलाता है और अपना काम जारी रखता है। - यह जिस ट्रैकिंग को सँभालता है, वह `.lagune/tracking.json` फ़ाइल में रहती है: यह अंदरूनी स्थिति है, जिसे आप कभी हाथ से एडिट नहीं करते। --- # Migrate: मैनिफ़ेस्ट पर आधारित Lagune प्रोजेक्ट को स्किल और प्लगइन पर ले जाएँ > मैनिफ़ेस्ट पर आधारित Lagune प्रोजेक्ट को स्किल पर आधारित Lagune पर ले जाएँ, और अपने सुरक्षा सिद्धांत, आर्टिफ़ैक्ट, ट्रैकिंग और अपनी विशेषज्ञताएँ बनाए रखें। कैनोनिकल: https://lagune.ai/hi-IN/docs/commands/migrate भाषा: hi-IN मूल: https://lagune.ai/docs/commands/migrate आख़िरी अपडेट: 2026-11-06 🔀 मैनिफ़ेस्ट पर आधारित **Lagune** प्रोजेक्ट को स्किल पर आधारित **Lagune** पर ले जाएँ, और आपने जो कुछ लिखा है वह सब बनाए रखें। **अप्रचलन की सूचना** मैनिफ़ेस्ट वाला प्रोजेक्ट `v1.x` तक जैसा है वैसा ही काम करता रहेगा: `npx lagune` कमांड `init`, `pull`, `update`, `add`, `remove`, `list` और डैशबोर्ड को `lagune@0.15.0` के हवाले कर देती है, जो मैनिफ़ेस्ट पर आधारित आख़िरी वर्ज़न है। ## प्रोजेक्ट ले जाएँ 1. पक्का करें कि आपका मौजूदा काम कमिट हो चुका है, फिर प्रोजेक्ट के रूट से migrate चलाएँ: ```bash npx lagune migrate ``` 2. सिर्फ़ वही कमिट करें जो migrate ने बदला है, ताकि यह पूरा बदलाव एक ही ऐसा बदलाव रहे जिसकी समीक्षा आसानी से हो सके। 3. [इंस्टॉल पेज](https://lagune.ai/hi-IN/docs) में बताए तरीक़े से अपने एजेंट के लिए कमांड इंस्टॉल करें। 4. अगर प्रोजेक्ट में पहले से detect, plan या harden का आर्टिफ़ैक्ट है, तो [`/lagune-repair`](https://lagune.ai/hi-IN/docs/commands/repair) कमांड से कहें कि वह उनमें और आपकी अपनी विशेषज्ञताओं में मौजूद पुराने रेफ़रेंस को मौजूदा स्थिति से मिलाकर अपडेट करे: ```prompt /lagune-repair `.lagune/memory/` के आर्टिफ़ैक्ट (`detect.md`, `plan.md` और `harden.md`) में लागू की गई विशेषज्ञताओं (जिन्हें पहले sub-skills कहा जाता था) को नए कैटलॉग में दिखने वाले नामों से मिलाकर अपडेट करो, और `.lagune/catalog/` में मेरी अपनी विशेषज्ञताएँ `.lagune/hooks/` के पुराने हुक को जो भी कॉल करती हैं, उन सबको `lagune_read` या `lagune_write` टूल की कॉल के रूप में दोबारा लिखो। ``` ## क्या बदलता है | पहले | बाद में | | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | `.lagune/templates/`, `.lagune/hooks/` और `.lagune/specializations.md` | हटा दिए गए: हर स्किल अपना टेम्पलेट साथ रखती है, और हुक इंजन चलाता है | | `.lagune/skills/` में बिल्ट-इन विशेषज्ञताओं की कॉपियाँ | हटा दी गईं: बिल्ट-इन विशेषज्ञताएँ इंजन देता है | | `.lagune/skills/` में आपकी अपनी विशेषज्ञताएँ | `.lagune/catalog/` में ले जाई गईं | | `.lagune/skills.json`, आपकी अपनी विशेषज्ञताओं का इंडेक्स | `.lagune/configs.json` में मिला दिया गया | | मैनिफ़ेस्ट की श्रेणियाँ | `.lagune/configs.json` में दर्ज | | पुरानी एजेंट कमांड, जैसे `/lagune.detect` | हटा दी गईं: [**Lagune** इंस्टॉल करने](https://lagune.ai/hi-IN/docs) पर नई कमांड आ जाती हैं, जैसे `/lagune-detect` | | `.gitignore` में **Lagune** का ब्लॉक | हटा दिया गया, और अगर फ़ाइल में और कुछ नहीं था, तो फ़ाइल भी | | `.lagune/proofs/`, जिसे वह ब्लॉक अनदेखा करता था | अपनी `.gitignore` फ़ाइल के ज़रिए कमिट से बाहर रहता है | | `.lagune/manifest.json` | सबसे आख़िर में डिलीट | आपका सुरक्षा का काम जैसा है वैसा ही रहता है: सुरक्षा सिद्धांत, हर चरण का बनाया आर्टिफ़ैक्ट, और वह ट्रैकिंग मैप जिसमें हर निष्कर्ष के पाथ दर्ज हैं। ## अक्सर पूछे जाने वाले सवाल ### क्या मुझे माइग्रेट करना ज़रूरी है? हाँ। मैनिफ़ेस्ट पर आधारित प्रोजेक्ट अप्रचलित हो चुके हैं और सिर्फ़ v1.x तक काम करते रहेंगे, इसलिए अपना प्रोजेक्ट ले जाने के लिए npx lagune migrate चलाएँ। ### migrate क्या-क्या बनाए रखता है? आपके सुरक्षा सिद्धांत, हर चरण का आर्टिफ़ैक्ट, ट्रैकिंग मैप, आपकी श्रेणियाँ और आपकी अपनी विशेषज्ञताएँ। विशेषज्ञताएँ .lagune/catalog/ में चली जाती हैं, और उनका इंडेक्स आपकी श्रेणियों के साथ .lagune/configs.json में पहुँच जाता है। ### नई कमांड कब इंस्टॉल करूँ? migrate के बाद, जैसा इंस्टॉल पेज पर आपके एजेंट के लिए बताया गया है। पहले इंस्टॉल करना भी ठीक है, क्योंकि migrate नए /lagune को बनाए रखता है। ### मेरी टीम का कोई साथी पहले ही माइग्रेट कर चुका है। मैं क्या चलाऊँ? माइग्रेशन वाले बदलाव पुल करें, फिर एक बार npx lagune migrate चलाएँ। यह आपके क्लोन से वे चीज़ें हटा देता है जो मैनिफ़ेस्ट पर आधारित Lagune ने छोड़ी थीं और जो वर्ज़न कंट्रोल में कभी थीं ही नहीं, और आपके प्रमाणों को कमिट से बाहर रखता है।