क्या AI सुरक्षा परीक्षण SAST, DAST और पेनिटेस्ट की जगह ले सकता है?

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

एजेंट समीक्षा एक दुभाषिया है, नई टेस्ट श्रेणी नहीं

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

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

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

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

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

SAST अब भी दोहराई जा सकने वाली स्रोत कवरेज का मालिक है

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

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

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

NIST SP 800-218 यहां व्यावहारिक सलाह देता है: कोड विश्लेषण जल्दी करें और सुरक्षा सुविधाओं व बचावों को मैन्युअल रूप से सत्यापित करें। मूल्य इनके मेल में है। स्थिर नियम हर कमिट पर ज्ञात दोष आकार पकड़ते हैं, एजेंट अपवादों की जांच करता है, केंद्रित रिग्रेशन टेस्ट लिखता है और वही पैटर्न लौटने पर नियम ट्यून करने में मदद करता है। एजेंट ने कुछ चतुर बग खोजे इसलिए SAST हटाना, मापी जा सकने वाली व्यापकता को प्रभावशाली किस्सों के बदले छोड़ना है।

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

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

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

DAST उस व्यवहार का प्रमाण देता है जो रिपॉजिटरी नहीं दिखा सकता

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

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

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

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

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

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

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

प्राधिकरण टेस्ट को पहचानें और निषिद्ध नतीजे चाहिए

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

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

छोटा निष्पादन योग्य मैट्रिक्स «IDOR टेस्ट करें» जैसे अस्पष्ट निर्देश से अधिक बताता है। नीचे दिया शेल अंश डिस्पोजेबल वातावरण, दो बेयरर टोकन और उपयोगकर्ता A के स्वामित्व वाले दस्तावेज़ को मानता है। यह स्टेटस और B के जवाब में A के गुप्त मार्कर की अनुपस्थिति, दोनों जांचता है:

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

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

अब एक बार में एक आयाम बदलें: रीड बनाम अपडेट, सीधी ID बनाम सर्च, सक्रिय बनाम निरस्त सदस्यता, सामान्य रूट बनाम एक्सपोर्ट और यूज़र टोकन बनाम सर्विस टोकन। एजेंट इन केस को कुशलता से बना और चला सकता है। इंसान को जांचना होगा कि मैट्रिक्स नीति से मेल खाता है या नहीं, और 404, 403, खाली नतीजा या संपादित ऑब्जेक्ट में से कौन सा नतीजा इरादे के अनुकूल है। वरना एजेंट उस व्यवहार का जश्न मना सकता है जिसे व्यवसाय उल्लंघन मानता है।

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

सेशन के दौरान नीति बदलाव भी टेस्ट करें। उपयोगकर्ता को प्रोजेक्ट से हटाएं, स्वामित्व ट्रांसफर करें, अकाउंट निष्क्रिय करें या सर्विस भूमिका सीमित करें, फिर पुराने टोकन और कनेक्शन दोबारा इस्तेमाल करें। अपेक्षित रिवोकेशन समय प्रोडक्ट नीति से आना चाहिए। «कभी न कभी» टेस्ट नहीं हो सकता और तुरंत रिवोकेशन जरूरी नहीं भी हो सकता, लेकिन टीम को सीमा चुनकर API रिक्वेस्ट, क्यू किए काम, डाउनलोड और लाइव सब्सक्रिप्शन में उसकी पुष्टि करनी चाहिए।

टेनेंट आइसोलेशन स्पष्ट रिक्वेस्ट पथ के बाहर टूटता है

टेनेंट आइसोलेशन को स्टोरेज, कैश, क्यू, सर्च, फाइल, एनालिटिक्स और प्रशासनिक सीमाओं में टेस्ट चाहिए। आम विफलता मुख्य लिस्ट एंडपॉइंट में tenant_id का न होना नहीं है। वह द्वितीयक पथ है जो टेनेंट संदर्भ साथ लिए बिना डेटा कॉपी, इंडेक्स, कैश या एक्सपोर्ट करता है।

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

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

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

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

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

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

बिजनेस लॉजिक के लिए दुरुपयोग की कहानी चाहिए

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

OWASP Web Security Testing Guide टेस्टर से छूटे वर्कफ्लो स्टेप, दोहराए गए फंक्शन, नकली रिक्वेस्ट, टाइमिंग बदलाव और वैध सुविधाओं के दुरुपयोग को आजमाने को कहता है। इसका पुराना बिजनेस-लॉजिक परिचय साफ कहता है कि स्कैनर ऑटोमेशन ऐप-विशिष्ट ज्ञान या रचनात्मकता नहीं दे सकता। आधुनिक एजेंट ऑटोमेशन बेहतर बनाते हैं, ज्ञान की कमी नहीं हटाते। मॉडल सुझाव दे सकता है कि कूपन दोबारा इस्तेमाल हो सकता है, लेकिन जब तक कोई नियम न बताए, वह नहीं जान सकता कि दोबारा इस्तेमाल प्रमोशन है या धोखाधड़ी।

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

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

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

डिपेंडेंसी जोखिम कमजोर वर्जन से अधिक है

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

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

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

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

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

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

गलत सकारात्मक नतीजे प्रमाण डिजाइन की समस्या हैं

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

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

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

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

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

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

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

मानवीय पेनिटेस्ट टेस्ट के आसपास की धारणाएं जांचता है

कुशल पेनिट्रेशन टेस्टर ऐप के ब्रीफ के विपरीत होने पर योजना बदलता है। यही वह हिस्सा है जिसे एजेंट ने नहीं बदला। व्यक्ति ओनर से बात करता है, अस्पष्ट नियम साफ करता है, ऑपरेशनल शॉर्टकट देखता है, दूसरी पहचान मांगता है और तय करता है कि अजीब व्यवहार पर प्रयोगों की लंबी श्रृंखला करनी चाहिए या नहीं।

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

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

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

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

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

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

कई प्रकार के प्रमाण से एक गेट बनाएं

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

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

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

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

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

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