एंटरप्राइज में एजेंटिक सुरक्षाएडवांस्डपाठ 1536 मिनट का पाठ

कोडिंग एजेंट्स: सीक्रेट्स, पैकेज और पुल रिक्वेस्ट्स

कोडिंग एजेंट्स आपका कोड पढ़ते हैं, कमांड्स चलाते हैं और पुल रिक्वेस्ट्स खोलते हैं। उन्हें issues और dependencies में अविश्वसनीय (untrusted) टेक्स्ट मिलता है, और वे आपके सीक्रेट्स तक पहुँच सकते हैं। यहाँ बताया गया है कि उन्हें सुरक्षित रूप से कैसे इस्तेमाल करें।

✦ ट्यूटर से पूछें🧪 लैब · 35 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

कोडिंग एजेंट्स: सीक्रेट्स, पैकेज और पुल रिक्वेस्ट्स

कोडिंग एजेंट्स आपका कोड पढ़ते हैं, कमांड्स चलाते हैं और पुल रिक्वेस्ट्स खोलते हैं। उन्हें issues और dependencies में अविश्वसनीय (untrusted) टेक्स्ट मिलता है, और वे आपके सीक्रेट्स…

1/5
आसान शब्दों में
कोडिंग एजेंट आपकी वर्कशॉप में एक बहुत तेज़ नए ट्रेनी की तरह होता है। वे बेंच पर मौजूद हर टूल का इस्तेमाल कर सकते हैं। इसलिए आप अपनी तिजोरी खुली नहीं छोड़ते, उनके लाए गए पार्ट्स की जांच करते हैं, और किसी सीनियर व्यक्ति से उनका काम ग्राहकों तक जाने से पहले चेक करवाते हैं।
कोडिंग एजेंट्स एक रिपॉजिटरी को पढ़ सकते हैं, फ़ाइलों को एडिट कर सकते हैं, टर्मिनल कमांड्स चला सकते हैं, पैकेज इंस्टॉल कर सकते हैं और पुल रिक्वेस्ट्स खोल सकते हैं। अब कई डेवलपर्स रोज़ाना इनका इस्तेमाल करते हैं। वे डिफ़ॉल्ट रूप से लेथल ट्राइफ़ेक्टा (lethal trifecta) के तीनों हिस्सों को जोड़ते हैं: प्राइवेट डेटा (कोड और सीक्रेट्स), अविश्वसनीय कंटेंट (issues, READMEs, dependencies, वेब डॉक्स) और बाहर निकलने के रास्ते (नेटवर्क, git push, पैकेज इंस्टॉलेशन)।

चार जोखिम वाले क्षेत्र

क्षेत्रक्या गड़बड़ हो सकती हैमुख्य कंट्रोल
सीक्रेट्सएजेंट .env फ़ाइल या क्लाउड क्रेडेंशियल्स को पढ़ता है और उन्हें आउटपुट, लॉग्स या कमिट में प्रिंट कर देता हैएजेंट के एनवायरनमेंट में कोई असली सीक्रेट्स न हों; कमिट्स पर सीक्रेट स्कैनिंग हो
पैकेजएजेंट अपने मन से गढ़े गए किसी पैकेज का नाम इंस्टॉल करता है, या किसी असली पैकेज से मिलता-जुलता नाम; हमलावर ऐसे नामों को रजिस्टर कर लेते हैंमंज़ूर की गई रजिस्ट्रियाँ या प्रॉक्सी; लॉकफ़ाइलें; नई dependencies पर इंसानी जांच
इंजेक्ट किए गए निर्देशकोई issue, README, कोड कमेंट या dependency का डॉक एजेंट को कुछ नुकसानदेह करने को कहता हैरेपो के टेक्स्ट को अविश्वसनीय (untrusted) मानें; कमांड्स और नेटवर्क को सीमित करें
पाइपलाइनज़्यादा एक्सेस पाने या जांच से बचने के लिए एजेंट CI फ़ाइलों या वर्कफ़्लो को बदल देता हैप्रोटेक्टेड पाथ्स; कोड ओनर्स; कम-से-कम अधिकार (least-privilege) वाले CI टोकन
मनगढ़ंत-पैकेज की इस समस्या को कभी-कभी slopsquatting कहा जाता है: एक मॉडल ऐसे पैकेज का सुझाव देता है जो मौजूद ही नहीं है, और हमलावर उस नाम से एक नुकसानदेह पैकेज पब्लिश कर देता है। हमेशा जांचें कि नई dependency असली हो, मेंटेन की जा रही हो और वही हो जो आप चाहते थे।

इसे एक बॉक्स में चलाएं

  1. 1

    कंटेनर या VM

    एजेंट एक dev container या वर्चुअल मशीन में काम करता है, सीधे क्रेडेंशियल्स से भरे लैपटॉप पर नहीं।
  2. 2

    कोई प्रोडक्शन सीक्रेट्स नहीं

    टेस्ट क्रेडेंशियल्स का इस्तेमाल करें या बिल्कुल न करें। असली सीक्रेट्स CI सिस्टम और सीक्रेट्स मैनेजर में ही रहते हैं।
  3. 3

    नेटवर्क सीमाएं

    पैकेज रजिस्ट्री (या आपके इंटरनल मिरर) और कोड होस्ट को अनुमति दें। जहाँ हो सके बाकी सब ब्लॉक कर दें।
  4. 4

    कमांड सीमाएं

    कई कोडिंग एजेंट्स कमांड चलाने से पहले पूछ सकते हैं या सिर्फ लिस्ट की गई कमांड्स की अनुमति दे सकते हैं। ख़तरनाक कमांड्स (डिलीट करना, पुश करना, डिप्लॉय करना) के लिए मंज़ूरी ज़रूर रखें।

पुल रिक्वेस्ट्स चेकपॉइंट हैं

पूरी छूट वाला एजेंट
  • सीधे main ब्रांच पर पुश करता है
  • CI वर्कफ़्लो और सुरक्षा कॉन्फ़िगरेशन को एडिट कर सकता है
  • CI टोकन रेपो में लिख सकता है और पैकेज पब्लिश कर सकता है
  • मर्ज कर दिया गया क्योंकि "टेस्ट्स पास हो गए"
सुरक्षा घेरे (guardrails) के अंदर काम करने वाला एजेंट
  • अपनी अलग ब्रांच पर काम करता है; ब्रांच प्रोटेक्शन सीधे पुश होने से रोकती है
  • CI, auth और dependency फ़ाइलों में बदलाव के लिए कोड ओनर के रिव्यू की ज़रूरत होती है
  • CI डिफ़ॉल्ट रूप से केवल पढ़ने वाले (read-only) टोकन के साथ चलता है; पब्लिश करने के अधिकार सिर्फ सुरक्षित रिलीज़ जॉब्स में होते हैं
  • एक इंसान हर एजेंट पुल रिक्वेस्ट को किसी नए साथी के काम की तरह रिव्यू करता है
Least-privilege CI token (GitHub Actions example)yaml
# At the top of a workflow file: default to read-only
permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci        # installs exactly what the lockfile says
      - run: npm test
नोट
अन्य CI सिस्टम्स में भी इसी तरह की सेटिंग्स होती हैं। मुख्य विचार एक ही है: पाइपलाइन जॉब्स को दिया जाने वाला ऑटोमैटिक टोकन केवल पढ़ने के लिए (read-only) होना चाहिए, जब तक कि किसी खास काम के लिए ज़्यादा की ज़रूरत न हो।

रिव्यूअर्स को एजेंट पुल रिक्वेस्ट्स में क्या देखना चाहिए

  • नई dependencies: क्या वे सच में मौजूद हैं, क्या वे जानी-मानी हैं, क्या उनकी वाकई ज़रूरत है?
  • CI, बिल्ड स्क्रिप्ट्स, परमिशन, auth या सुरक्षा जांचों में बदलाव, भले ही वे छोटे हों।
  • हटाए गए या कमज़ोर किए गए टेस्ट्स, या "बिल्ड को पास कराने" के लिए बंद की गई चेकिंग।
  • हार्ड-कोड की गई कीज़ (keys), अनजान सर्वर्स के URLs, या बाहर जाने वाले नए नेटवर्क कॉल्स।
  • ऐसा कोड जो दिए गए काम से ज़्यादा कुछ करता है।
सावधान रहें
टेस्ट पास होने का मतलब यह नहीं कि कोड सुरक्षित है। एक एजेंट ऐसा कोड और टेस्ट लिख सकता है जो आपस में तो मेल खाते हों, लेकिन फिर भी गलत या असुरक्षित हों। रिव्यू और सुरक्षा स्कैनिंग अभी भी ज़रूरी हैं।
यह करके देखें। जिस रिपॉजिटरी पर आप काम करते हैं, उसे जांचें: क्या कोई भी (या कोई भी बॉट) सीधे main ब्रांच पर पुश कर सकता है? किन फ़ाइलों के लिए आप चाहेंगे कि कोड ओनर उन्हें मंज़ूरी दे?

और देखें और पढ़ें

लैब

एक सुरक्षित और मज़बूत CI वर्कफ़्लो, ब्रांच प्रोटेक्शन प्लान और एजेंट पुल रिक्वेस्ट रिव्यू चेकलिस्ट।

~35 min

समस्या

अपनी किसी प्रैक्टिस रिपॉजिटरी पर काम करें, या कागज़ पर करें।

  1. शुरुआती CI वर्कफ़्लो को ठीक करें ताकि यह कम-से-कम अधिकार (least privilege) के नियम का पालन करे: डिफ़ॉल्ट रूप से केवल पढ़ने की अनुमति (read-only), टेस्ट जॉब में कोई सीक्रेट्स न हों, और लॉकफ़ाइल से इंस्टॉलेशन हो।
  2. एक ब्रांच प्रोटेक्शन प्लान लिखें: main पर कौन पुश कर सकता है, कितने रिव्यू चाहिए, और किन पाथ्स के लिए कोड ओनर की ज़रूरत है (CI फ़ाइलें, auth कोड, dependency फ़ाइलें)।
  3. कोडिंग एजेंट्स द्वारा खोली गई पुल रिक्वेस्ट्स के लिए 6–8 बिंदुओं की एक रिव्यू चेकलिस्ट लिखें।
  4. एजेंट के लिए सैंडबॉक्स सेटिंग्स लिखें: यह कहाँ चलता है, यह किस नेटवर्क तक पहुँच सकता है, किन कमांड्स के लिए मंज़ूरी की ज़रूरत है।
शुरुआती कोडyaml
# Practice workflow with problems to fix
permissions: write-all

jobs:
  test:
    runs-on: ubuntu-latest
    env:
      PROD_DB_PASSWORD: "hunter2-example-not-real"
    steps:
      - uses: actions/checkout@v4
      - run: npm install        # installs latest versions, ignores lockfile
      - run: npm test
      - run: npm publish        # publishing from a test job

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1एजेंट को ऐसे टेस्ट चलाने हैं जिनके लिए डेटाबेस की ज़रूरत है। आप उसे प्रोडक्शन क्रेडेंशियल्स देने से कैसे बचेंगे?दिखाएं

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

Q2किसी पब्लिक रिपॉजिटरी का issue ट्रैकर कोडिंग एजेंट्स के लिए एक खास जोखिम क्यों है?दिखाएं

इंटरनेट पर कोई भी व्यक्ति वहाँ लिख सकता है, इसलिए यह पूरी तरह से अविश्वसनीय (untrusted) सामग्री है। ऐसा एजेंट जो issues पढ़ता है और जिसके पास सीक्रेट्स या लिखने का एक्सेस भी है, वह लेथल ट्राइफ़ेक्टा (lethal trifecta) बन जाता है। पब्लिक issues के लिए कम अधिकारों वाले एक अलग एजेंट का इस्तेमाल करें, जिसके पास कोई सीक्रेट्स न हों और न ही पुश या पब्लिश करने के अधिकार हों, और उसके द्वारा सुझाए गए हर काम का इंसानों से रिव्यू करवाएं।

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

अगर सारे टेस्ट पास हो जाएं, तो क्या हम एजेंट को अपनी पुल रिक्वेस्ट्स खुद मर्ज करने दे सकते हैं?

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

कोडिंग एजेंट्स के ज़रिए सीक्रेट्स कैसे लीक होते हैं?

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

Issues के ज़रिए होने वाले इंजेक्शन के बारे में क्या?

अगर किसी एजेंट को "issue 42 फिक्स करने" को कहा जाता है, तो उस issue का टेक्स्ट उसके संदर्भ (context) में चला जाता है। कोई भी व्यक्ति जो issues लिख सकता है (पब्लिक रेपो पर कोई भी), वह वहाँ निर्देश डाल सकता है। पब्लिक रेपो पर एजेंट क्या कर सकता है इसे सीमित करें, और ऐसे एजेंट को कभी भी सीक्रेट्स या पब्लिश करने के अधिकार न दें।

क्या एजेंट्स को dependencies जोड़ने की अनुमति होनी चाहिए?

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

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें