💻 computer science

SCAFFOLD-CEGIS: Preventing Latent Security Degradation in LLM-Driven Iterative Code Refinement

यह शोध पत्र एक "सुप्त सुरक्षा क्षरण" (latent security degradation) विरोधाभास की पहचान करता है जहाँ विनिर्देश विचलन (specification drift) और अप्रभावी स्थैतिक विश्लेषण के कारण पुनरावृत्तिपूर्ण LLM कोड परिशोधन कमजोरियों को बढ़ा देता है, और SCAFFOLD-CEGIS फ्रेमवर्क का प्रस्ताव करता है—जो 100% सुरक्षा एकरूपता (safety monotonicity) प्राप्त करने और क्षरण दर को घटाकर 2.1% करने के लिए काउंटर-एग्जांपल-गाइडेड इंडक्टिव सिंथेसिस और स्पष्ट सत्यापन योग्य बाधाओं का उपयोग करने वाला एक मल्टी-एजेंट सिस्टम है।

मूल लेखक: Yi Chen, Yun Bian, Haiquan Wang, Shihao Li, Zhe Cui

प्रकाशित 2026-03-10

📖 5 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Yi Chen, Yun Bian, Haiquan Wang, Shihao Li, Zhe Cui

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आपके पास एक बहुत ही प्रतिभाशाली, लेकिन थोड़ी भुलक्कड़ सहायक है जिसका नाम "द एआई" (The AI) है। आप इस सहायक से एक सॉफ्टवेयर कोड लिखने के लिए कहते हैं। शुरुआत में, कोड सुरक्षित और सुदृढ़ है, जैसे कि मजबूत तालों, अलार्मों और दरवाजे पर एक गार्ड वाला एक घर।

लेकिन आप कोड को सिर्फ एक बार नहीं चाहते; आप एआई से इसे बेहतर बनाने के लिए बार-बार कहना चाहते हैं। आप कहते हैं, "इसे तेज़ बनाओ।" आप कहते हैं, "इसे पढ़ने में आसान बनाओ।" आप अनुरोध करते हैं, "यह नया फीचर जोड़ो।"

समस्या: "रिनोवेशन पैराडॉक्स" (नवीनीकरण का विरोधाभास)
शोध एक अजीब समस्या की खोज करता है: हर बार जब एआई किसी एक तरीके से कोड को बेहतर (जैसे तेज़ या साफ) बनाने की कोशिश करता है, तो वह अनजाने में दूसरे तरीके से कोड को खराब (कम सुरक्षित) बना देता है।

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

शोधकर्ताओं ने पाया कि लगभग 10 चरणों के इन "नवीनीकरणों" के बाद, लगभग आधे कोड श्रृंखलाओं में शुरुआत की तुलना में अधिक सुरक्षा खामियां थीं। एआई गति या सरलता के लिए अनुकूलन करने में इतना व्यस्त था कि वह "तालों" को रखना भूल गया।

विफल समाधान: "मेटल डिटेक्टर" गेट
आप सोच सकते हैं, "ठीक है, चलिए बाहर निकलने के लिए एक मेटल डिटेक्टर लगा देते हैं। यदि कोड में कोई ज्ञात वायरस (एक विशिष्ट सुरक्षा बग) है, तो हम उसे रोक देंगे।" इसे स्टैटिक एनालिसिस (SAST) कहा जाता है।

यह शोध दिखाता है कि यह अच्छी तरह से काम नहीं करता है। क्यों? क्योंकि एआई केवल "वायरस" जोड़ नहीं रहा है; वह वास्तव में सुरक्षात्मक उपायों को हटा रहा है।

उपमा: कल्पना कीजिए कि मेटल डिटेक्टर केवल यह जाँचता है कि आपके पास कोई हथियार है या नहीं। लेकिन ठेकेदार कोई हथियार नहीं लाया; उसने तो बस गार्ड की बंदूक छीन ली और गार्ड को बेसमेंट में बंद कर दिया। मेटल डिटेक्टर को कुछ भी गलत नहीं दिखता क्योंकि कोई नया हथियार नहीं जोड़ा गया। घर अब असुरक्षित है, लेकिन डिटेक्टर कहता है, "सब ठीक है!"

यह एक "नकली सुरक्षा" प्रभाव पैदा करता है। कोड परीक्षण पास कर लेता है, लेकिन वास्तव में वह पहले से अधिक खतरनाक होता है।

समाधान: SCAFFOLD-CEGIS (एक "स्मार्ट ब्लूप्रिंट" प्रणाली)
इसे ठीक करने के लिए, लेखकों ने SCAFFOLD-CEGIS नामक एक नई प्रणाली बनाई। यह विशेषज्ञ वास्तुकारों और निरीक्षकों की एक टीम की तरह काम करती है जो केवल "बुरी चीजों" को नहीं देखते, बल्कि सक्रिय रूप से "अच्छी चीजों" की रक्षा करते हैं।

यहाँ निर्माण की उपमा का उपयोग करते हुए यह टीम कैसे काम करती है:

सुरक्षा वास्तुकार (द "एंकर" मेकर):
काम शुरू करने से पहले, यह एजेंट मूल कोड को देखता है और कहता है, "ये एंकर (Anchors) हैं।"

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

निर्माता (द एआई):
एआई अनुरोधित सुधार (तेज़, साफ) करने की कोशिश करता है लेकिन "एंकर" को हटाने या कमजोर करने से सख्ती से वर्जित है।
गेटकीपर (4-स्तरीय निरीक्षक):
किसी भी बदलाव को स्वीकार करने से पहले, एक गेटकीपर चार स्तरों के माध्यम से इसकी जांच करता है:

क्या यह काम करता है? (शुद्धता/Correctness)
क्या हमने कोई सुरक्षा खो दी है? (सुरक्षा एकरूपता/Safety Monotonicity)
क्या परिवर्तन बहुत बड़ा है? (डिफ बजट/Diff Budget - बड़े जोखिम भरे ओवरहाल को रोकने के लिए)
क्या हमने एंकर को तोड़ दिया? (एंकर अखंडता/Anchor Integrity)
उपमा: यदि निर्माता कमरे को बड़ा करने के लिए स्टील का बीम हटाने की कोशिश करता है, तो गेटकीपर तुरंत दरवाजा बंद कर देता है।

शिक्षार्थी (द "अनुभव" संग्राहक):
यदि निर्माता विफल हो जाता है और उसे अस्वीकार कर दिया जाता है, तो यह एजेंट केवल "नहीं" नहीं कहता। यह लिखता है कि वह क्यों विफल हुआ।

उपमा: "ओह, निर्माता ने फिर से validate फंक्शन को हटाने की कोशिश की। अगली बार, निर्माता को बताएं: 'जिस नाम में 'validate' है, उन फंक्शन्स को कभी न हटाएं।'"
यह एआई को अपनी गलतियों से सीखने में मदद करता है ताकि वह एक ही सुरक्षा त्रुटि दोबारा न करे।

परिणाम
जब शोधकर्ताओं ने इस नई प्रणाली का परीक्षण किया:

पुराना तरीका (केवल एआई से पूछना): सुरक्षा समय के साथ खराब होती गई।
मध्यम तरीका (केवल मेटल डिटेक्टर का उपयोग करना): सुरक्षा ठीक दिखती थी, लेकिन वास्तव में खराब हो गई क्योंकि डिटेक्टर "हटाए गए बचावों" को पकड़ नहीं पाया।
नया तरीका (SCAFFOLD-CEGIS): इस प्रणाली ने सुरक्षा गिरावट को सफलतापूर्वक रोका। इसने "छिपे हुए सुरक्षा नुकसान" की दर को लगभग 20% से घटाकर केवल 2% कर दिया।

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

तकनीकी सारांश: SCAFFOLD-CEGIS

1. समस्या विवरण: पुनरावृत्ति परिशोधन विरोधाभास (The Iterative Refinement Paradox)

यह शोध पत्र लार्ज लैंग्वेज मॉडल (LLM)-संचालित सॉफ्टवेयर इंजीनियरिंग में एक महत्वपूर्ण, कम खोजे गए जोखिम की पहचान करता है: पुनरावृत्ति कोड परिशोधन (iterative code refinement) के दौरान अंतर्निहित सुरक्षा क्षरण (latent security degradation)। जबकि GitHub Copilot जैसे उपकरण कार्यक्षमता और प्रदर्शन को सुधारने के लिए मल्टी-टर्न इंटरैक्शन की सुविधा प्रदान करते हैं, लेखक तर्क देते हैं कि यह प्रक्रिया अक्सर अनजाने में सुरक्षा को कम कर देती है।

मुख्य मुद्दा मल्टी-ऑब्जेक्टिव ऑप्टिमाइज़ेशन में विशिष्टीकरण विचलन (specification drift) है। जब LLMs सुरक्षा के साथ-साथ प्रतिस्पर्धी लक्ष्यों (कार्यक्षमता, प्रदर्शन, रखरखाव) के लिए अनुकूलन करते हैं, और सुरक्षा बाधाएं केवल "सॉफ्ट प्रॉम्प्ट्स" के रूप में प्रदान की जाती हैं, तो अनुकूलन प्रक्षेपवक्र (optimization trajectory) इच्छित सुरक्षा विशिष्टता से धीरे-धीरे अलग हो जाता है। इससे रक्षात्मक तर्क (defensive logic) का हटाना, अपवाद हैंडलिंग (exception handling) का कमजोर होना, या अनुमति जाँच (permission checks) को बायपास करना जैसी स्थितियाँ उत्पन्न होती हैं।

महत्वपूर्ण रूप से, शोध पत्र दर्शाता है कि स्टैटिक एप्लिकेशन सिक्योरिटी टेस्टिंग (SAST) गेटिंग पर्याप्त नहीं है। SAST उपकरण ज्ञात भेद्यता पैटर्न पर निर्भर करते हैं और उन संरचनात्मक क्षरणों का पता लगाने में विफल रहते हैं जहाँ सुरक्षा-महत्वपूर्ण तत्वों को बिना किसी नए, नियम-ट्रिगर करने वाले पैटर्न को पेश किए, बस हटा दिया जाता है या कमजोर कर दिया जाता है। वास्तव में, लेखक एक "छद्म-सुरक्षा प्रभाव" (pseudo-security effect) देखते हैं जहाँ केवल SAST पर भरोसा करने से अंतर्निहित सुरक्षा क्षरण दर (उनके प्रयोगों में 12.5% से 20.8% तक) बढ़ सकती है, क्योंकि मॉडल SAST कवरेज से बाहर के बड़े, जोखिम भरे रिफैक्टर करने को एक संकेत के रूप में व्याख्या कर सकते हैं।

2. कार्यप्रणाली: SCAFFOLD-CEGIS फ्रेमवर्क

इन सीमाओं को संबोधित करने के लिए, लेखक SCAFFOLD-CEGIS प्रस्तावित करते हैं, जो काउंटरएग्जांपल-गाइडेड इंडक्टिव सिंथेसिस (CEGIS) प्रतिमान से प्रेरित एक मल्टी-एजेंट फ्रेमवर्क है। यह फ्रेमवर्क सुरक्षा बाधाओं को अंतर्निहित निर्देशों से स्पष्ट, सत्यापन योग्य हार्ड बाधाओं (hard constraints) में बदल देता है।

मुख्य आर्किटेक्चर

सिस्टम चार सहयोगी एजेंटों के माध्यम से एक क्लोज्ड लूप में संचालित होता है:

SecurityArchitectAgent: कोडबेस से सिमेंटिक एंकर्स (Semantic Anchors) निकालता है। ये एंकर सुरक्षा-महत्वपूर्ण तत्वों (फंक्शन्स, पैटर्न, इनवेरिएंट्स) का प्रतिनिधित्व करते हैं और उन्हें एक विशिष्टता सेट $\Phi$ $Φ$ में औपचारिक रूप दिया जाता है।
- फंक्शन-स्तर: रेगुलर एक्सप्रेशन (regex) और AST पार्सिंग के माध्यम से वैलिडेशन, सैनिटाइजेशन और ऑथेंटिकेशन फंक्शन्स की पहचान करता है।
- पैटर्न-स्तर: रक्षात्मक तर्क पैटर्न (जैसे, पैरामीटराइज्ड क्वेरीज़, विशिष्ट अपवाद हैंडलिंग) से मेल खाता है।
- इनवेरिएंट-स्तर: वैश्विक नियमों को लागू करता है (जैसे, "सभी SQL क्वेरीज़ पैरामीटराइज्ड होनी चाहिए")।
ImplementerAgent: परिभाषित हार्ड बाधाओं का पालन करते हुए रिफाइनमेंट कार्य को पूरा करने के लिए कैंडिडेट कोड ( $P'$ ) उत्पन्न करता है।
GatekeeperAgent: स्वीकृति से पहले प्रत्येक कैंडिडेट पर चार-स्तरीय गेटेड सत्यापन (four-layer gated verification) करता है:
- सटीकता (Correctness): सुनिश्चित करता है कि कोड टेस्ट सुइट को पास करता है।
- सेफ्टी मोनोटोनिसिटी (Safety Monotonicity): सत्यापित करता है कि भेद्यता की संख्या (SAST के माध्यम से) नहीं बढ़ती है ( $\Delta V \le 0$ )।
- डिफ़ (Diff) बजट: बड़े, जोखिम भरे रिफैक्टर को रोकने के लिए परिवर्तनों के पैमाने को सीमित करता है।
- एंकर अखंडता (Anchor Integrity): सुनिश्चित करता है कि कोई भी हार्ड-लेवल सिमेंटिक एंकर (जैसे, महत्वपूर्ण वैलिडेशन फंक्शन्स) हटाया या बदला नहीं गया है।
AssimilatorAgent: अस्वीकृत कैंडिडेट का विश्लेषण करने के लिए संरचित सबक (काउंटरएग्जम्पल्स) निकालता है। यह भविष्य के जेनरेशन को निर्देशित करने के लिए एक फेलियर नॉलेज बेस को अपडेट करता है, जिससे विशिष्ट संरचनात्मक त्रुटियों की पुनरावृत्ति को रोका जा सके।

सैद्धांतिक गारंटी

फ्रेमवर्क सेफ्टी मोनोटोनिसिटी को लागू करता है, जिसे सभी इटरेशन $i$ के लिए $V(P_{i+1}) \le V(P_i)$ के रूप में परिभाषित किया गया है, जहाँ $V$ भेद्यता की संख्या है। टॉलरेंस थ्रेशोल्ड $\delta_{max} = 0$ सेट करके, सिस्टम यह गारंटी देता है कि कोई भी इटरेशन नई SAST-डिटेक्टेबल भेद्यताएं पेश नहीं करता है या एंकर किए गए सुरक्षा तत्वों को हटाता नहीं है।

3. प्रमुख योगदान

विरोधाभास का अनुभवजन्य सत्यापन: GPT-4o का उपयोग करके 96 इटरेशन चेन्स पर नियंत्रित प्रयोगों के माध्यम से, लेखक प्रकट करते हैं कि दस इटरेशन के बाद 43.7% चेन्स बेसलाइन की तुलना में अधिक भेद्यताएं प्रदर्शित करती हैं। क्रॉस-मॉडल और क्रॉस-लैंग्वेज प्रयोग पुष्टि करते हैं कि यह घटना व्यापक है, न कि केवल एक मॉडल तक सीमित।
SAST ब्लाइंड स्पॉट्स की पहचान: शोध पत्र विशिष्ट "लेटेंट" क्षरण मामलों (जैसे, इनपुट वैलिडेशन फंक्शन्स को हटाना, अपवादों को निगलना, अनुमति जाँच को बायपास करना) का दस्तावेजीकरण करता है जो SAST जाँच को पास करते हैं लेकिन सुरक्षा से समझौता करते हैं।
SCAFFOLD-CEGIS फ्रेमवर्क: एक नया आर्किटेक्चर जो सिमेंटिक एंकरिंग, मल्टी-लेयर गेटिंग और फेलियर एसिमिलेशन को सुरक्षा मोनोटोनिसिटी को लागू करने के लिए एकीकृत करता है।
मात्रात्मक सुधार: फ्रेमवर्क अंतर्निहित सुरक्षा क्षरण दर को (अनप्रोटेक्टेड बेसलाइन्स में) 20.8% से घटाकर 2.1% कर देता है, जबकि 100% सेफ्टी मोनोटोनिसिटी प्राप्त करता है।

4. प्रयोगात्मक परिणाम

लेखकों ने पायथन और जावा में 24 प्रोग्रामिंग कार्यों के माध्यम से तीन रिसर्च क्वेश्चन (RQs) के लिए फ्रेमवर्क का मूल्यांकन किया, जिसमें छह सुरक्षा परिदृश्य (SQL इंजेक्शन, इनपुट हैंडलिंग, ऑथेंटिकेशन, आदि) शामिल थे।

RQ1 (बाहरी वैधता): GPT-5-Nano, Claude Sonnet 4.5, और DeepSeek-V3 के माध्यम से प्रयोगों ने पुष्टि की कि इटरेटिव रिफाइनमेंट विभिन्न मॉडलों और भाषाओं में सुरक्षा को कम करता है। विशेष रूप से, स्टैटिक एनालिसिस (SAST) मेट्रिक्स अक्सर कम क्षरण दर (जैसे, 4.2%–10.5%) दिखाते हैं, जबकि LLM-आधारित सिमेंटिक रिव्यू बहुत अधिक विश्वसनीयता और लेटेंट सुरक्षा क्षरण (42.5%–52.5%) प्रकट करता है, जो डिटेक्शन कवरेज में अंतर को उजागर करता है।
RQ2 (डिफेंस तुलना): छह बेसलाइन्स (जिसमें प्रॉम्प्ट-आधारित सुरक्षा, सेल्फ-रिफाइन, पोस्ट-हॉक SAST, और हाइब्रिड गार्ड शामिल हैं) के मुकाबले, SCAFFOLD-CEGIS एकमात्र ऐसा तरीका था जिसने 0% SAST क्षरण दर और 2.1% लेटेंट सुरक्षा क्षरण दर दोनों प्राप्त की।
- मुख्य निष्कर्ष: पोस्ट-हॉक SAST अकेले अनप्रोटेक्टेड बेसलाइन (12.5%) की तुलना में उच्च लेटेंट क्षरण दर (20.8%) का परिणाम था, जो "छद्म-सुरक्षा" जोखिम की पुष्टि करता है।
RQ3 (एब्लेशन स्टडी):
- गेटेड वेरिफिकेशन को 100% सेफ्टी मोनोटोनिसिटी प्राप्त करने के प्राथमिक चालक के रूप में पहचाना गया।
- सिमेंटिक एंकरिंग SAST नियमों से परे कवरेज का विस्तार करने के लिए आवश्यक थी ताकि संरचनात्मक विलोपन को पकड़ा जा सके।
- फेलियर एसिमिलेशन ने टास्क कंप्लीशन रेट (TCR) को ~66% (एसिमिलेशन के बिना) से बढ़ाकर 77.14% कर दिया, जो दर्शाता है कि विफलताओं से सीखना सिस्टम को सख्त सुरक्षा बाधाओं के तहत भी कोड विकास क्षमताओं को बनाए रखने की अनुमति देता है।

5. महत्व और दावे

शोध पत्र का दावा है कि LLM-संचालित इटरेटिव कोड रिफाइनमेंट में सुरक्षा क्षरण का एक अंतर्निहित जोखिम है जिसे सॉफ्ट प्रॉम्प्टिंग या SAST गेटिंग जैसे वर्तमान मानक अभ्यासों द्वारा कम नहीं किया जा सकता है।

इस कार्य का महत्व यहाँ है:

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

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