Dependabot को बंद करें

 (words.filippo.io)
1 पॉइंट द्वारा GN⁺ 2026-02-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Dependabot की अत्यधिक सूचनाएँ वास्तविक सुरक्षा समस्याओं को हल करने की बजाय डेवलपर्स का समय बर्बाद करती हैं
  • Go ecosystem में हुई एक घटना की तरह, अप्रभावित repositories में भी हज़ारों PR और warnings बन जाती हैं, जिससे भ्रम पैदा होता है
  • govulncheck-आधारित GitHub Action का उपयोग करने पर केवल वास्तव में vulnerable code ही detect होता है, और अनावश्यक warnings हटाई जा सकती हैं
  • dependency updates को automated PR की बजाय नियमित testing और latest version verification के साथ manage करना अधिक सुरक्षित और अधिक प्रभावी है
  • यह तरीका alert fatigue को कम करने और open source maintainers पर पड़ने वाला बोझ हल्का करने में महत्वपूर्ण है

Dependabot की समस्याएँ

  • Dependabot बड़े पैमाने पर security alerts और automated PR बनाता है, जिससे डेवलपर्स के लिए वास्तव में महत्वपूर्ण समस्याओं की पहचान करना कठिन हो जाता है
    • Go package filippo.io/edwards25519 में एक मामूली बदलाव पर भी हज़ारों PR बन गए
    • अप्रभावित repositories (Wycheproof आदि) तक भी गलत security alerts पहुँच गए
  • इन alerts में गलत CVSS scores और कम compatibility indicators शामिल होते हैं, जो अनावश्यक चिंता पैदा करते हैं
  • ऐसी अत्यधिक सूचनाओं को security response की विश्वसनीयता और प्रभावशीलता घटाने वाला कारण माना गया है

govulncheck का उपयोग करते हुए विकल्प

  • Go Vulnerability Database version, package और symbol स्तर का सूक्ष्म metadata प्रदान करता है
    • उदाहरण के लिए GO-2026-4503 vulnerability केवल Point.MultiScalarMult symbol को प्रभावित करती है
  • govulncheck static analysis के माध्यम से केवल वास्तव में callable vulnerable code का पता लगाता है
    • go mod why के साथ उपयोग करने पर indirect dependency के प्रभाव का सटीक आकलन किया जा सकता है
    • जाँच के परिणाम में, vulnerability मौजूद होने पर भी यदि code उस symbol को call नहीं करता, तो warning नहीं दी जाती
  • इसे CLI (govulncheck -json) या Go API (golang.org/x/vuln/scan) के जरिए आसानी से integrate किया जा सकता है

GitHub Actions से प्रतिस्थापन

  • Dependabot की जगह govulncheck GitHub Action सेट करके रोज़ाना automated scans चलाए जा सकते हैं
    • केवल वास्तविक vulnerabilities मिलने पर ही notification भेजी जाती है
    • automated PR न बनने से डेवलपर्स महत्वपूर्ण security issues पर ध्यान केंद्रित कर सकते हैं
  • गलत warnings कम होने से security alert fatigue घटती है और response quality बेहतर होती है
  • open source maintainers को अनावश्यक PR भेजने की समस्या भी समाप्त हो जाती है

dependency updates को manage करने का तरीका

  • dependencies को हर project के development cycle के अनुसार एक साथ manage करना चाहिए
    • हर दिन latest versions पर testing की जाए, लेकिन वास्तविक updates केवल आवश्यकता होने पर किए जाएँ
    • Go में go get -u -t ./... और npm में npm update command से latest version testing की जा सकती है
  • यह तरीका security vulnerability response speed और stability दोनों सुनिश्चित करता है
    • latest version testing से compatibility issues पहले ही पकड़ में आ जाते हैं
    • malicious code वाली dependencies को तुरंत deploy होने से रोका जा सकता है
  • geomys/sandboxed-step का उपयोग करने पर CI environment में gVisor के साथ isolated execution संभव है

निष्कर्ष और समर्थन पृष्ठभूमि

  • Dependabot का automation कई बार security से ज़्यादा noise पैदा करता है
  • govulncheck और नियमित testing-आधारित approach अधिक सटीक और लंबे समय तक टिकाऊ security management तरीका है
  • लेख के लेखक का open source maintenance Geomys संगठन के माध्यम से Ava Labs, Teleport, Tailscale, Sentry आदि के समर्थन से जारी है
  • ऐसा मॉडल open source ecosystem के स्थिर रखरखाव और security quality में सुधार में योगदान देता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-02-21
Hacker News की राय
  • Dependabot कुछ हद तक काम का है
    लेकिन जो टूल सिर्फ version number और vulnerability DB की तुलना करते हैं, वे यह नहीं समझ पाते कि असली code वास्तव में उस vulnerability के संपर्क में है या नहीं, इसलिए noise बहुत होता है
    हाल में मुझे जो टूल प्रभावशाली लगा, वह CodeQL है। इसे GitHub Advanced Security में चलाया जा सकता है, और यह code के वास्तविक flow को ट्रैक करके दिखाता है कि input value किस तरह खतरनाक उपयोग तक पहुँचती है, यानी पूरा path विज़ुअली दिखाता है
    इससे ऐसी जानकारी मिलती है जिससे वास्तव में fix किया जा सके, और false positive भी कम होते हैं। हाँ, Python जैसी dynamic language में ऐसा code भी हो सकता है जो detection से बच निकले, लेकिन ज़्यादातर मामलों में यह काफ़ी उपयोगी है
    • पहले CodeQL project में मददगार था, लेकिन हाल में यह बहुत झुंझलाने वाला हो गया, इसलिए टीम ने इसे बंद कर दिया
      सिर्फ CodeQL की warning से बचने के लिए बेकार के intermediate variable जोड़ने जैसी टिप्पणियाँ आने लगीं। यह data पर overfit किए हुए tool जैसा लगता है
    • “false positive लगभग नहीं हैं” इस बात से सहमत होना मुश्किल है। Rice theorem के अनुसार ऐसा परफ़ेक्ट analysis संभव नहीं है
    • मेरे अनुभव में CodeQL में false positive काफ़ी हैं, और इसे local में आसानी से चलाने का तरीका नहीं है, इसलिए vendor lock-in पैदा होता है
    • Dependency version बढ़ाने से security बेहतर होगी, इसकी कोई गारंटी नहीं है। नया version नई vulnerabilities भी ला सकता है
  • NPM package में ReDoS warning बहुत ज़्यादा आती हैं। ज़्यादातर package सिर्फ client code में इस्तेमाल होते हैं, लेकिन backend से असंबंधित warning बहुत आती हैं। client-side ReDoS हमारे लिए मायने नहीं रखता
    • दरअसल मुझे लगता है DoS security vulnerability नहीं बल्कि availability issue है। यह security के CIA में से एक ज़रूर है, लेकिन व्यवहार में यह operational issue के ज़्यादा क़रीब है। DoS को security issue मानना बस एक ऐतिहासिक अवशेष है
    • मैं debug package maintain करता हूँ, और बेकार ReDoS रिपोर्ट बहुत आती हैं। कुछ मामलों में CVE भी register हो जाती है, इतना कि JS ecosystem छोड़ देने का मन करता है
    • AI code review tool में भी ऐसा ही problem देखा है। tool local में user permission के साथ चलता है, फिर भी input को बिना ज़रूरत sanitize करने को कहता है। आख़िर में यह सिर्फ समय की बर्बादी है
    • हम भी यही समस्या झेलते हैं। ख़ासकर Dev dependency से आने वाली ReDoS warnings अनावश्यक शोर बहुत पैदा करती हैं
    • ReDoS regex engine की bug है, लेकिन V8 जैसे engine आज भी सुरक्षित regex engine default रूप में नहीं देते
  • Govulncheck Go ecosystem की सबसे बेहतरीन सुविधाओं में से एक है
    अगर PR में vulnerable call जुड़ती है तो alert देने के लिए मैं GitHub Action बनाकर इस्तेमाल कर रहा हूँ।
    Dependabot auto-merge के साथ मिलाकर देखें तो JS codebase manage करने के लिए भी यह अच्छा combination है
    • Govulncheck भी परफ़ेक्ट नहीं है। इसमें false positive हैं, और CVE number के आधार पर किसी खास vulnerability को exclude करने का तरीका नहीं है
  • Dependabot उपयोगी है, लेकिन साथ ही यह हर दिन dependency को न्यूनतम रखने की अहमियत भी याद दिलाता है
    • मैं भी हर सुबह Dependabot PR निपटाते हुए दिन की शुरुआत करता हूँ।
      अगर tests काफ़ी हों तो नए version में bug भी पकड़ में आ जाते हैं, और उस प्रक्रिया से open source contribution तक हो जाती है। झंझट भरा है, लेकिन यह अच्छी आदत बना देता है
    • मैं भी सहमत हूँ। मेरे projects ज़्यादा नहीं हैं, लेकिन Dependabot काफ़ी काम का है
  • अच्छा होता अगर Dependabot को email की बजाय repository के अंदर tab की तरह manage किया जाता
    email notification परेशान करती हैं, और PR का ढेर लगना भी अच्छा नहीं लगता। मैं इन्हें सिर्फ किसी तय समय पर एक साथ निपटाना चाहता हूँ
    • dependabot.yml setting से run frequency और PR की संख्या नियंत्रित की जा सकती है
      official docs देखें
    • auto PR बंद करके, ज़रूरत पड़ने पर ही manually generate करना भी संभव है
      ख़ुद fix करते हुए issue की संख्या घटाने का तरीका भी अपनाया जा सकता है
    • Refined GitHub extension इस्तेमाल करें तो default view थोड़ा साफ़-सुथरा हो जाता है
      व्यक्तिगत रूप से मैं Renovate recommend करूँगा। यह ज़्यादा languages और auto-merge option support करता है
  • Go का govulncheck वाला तरीका (वास्तविक call path tracking) हर ecosystem में default होना चाहिए
    Dependabot की बुनियादी समस्या यह है कि वह dependency management को security problem समझ लेता है।
    जिस function को call ही नहीं किया जाता, उसकी vulnerability security issue नहीं बल्कि noise है
    Python में मुझे pip-audit --desc Dependabot से बेहतर लगता है।
    जब तक परफ़ेक्ट static analysis नहीं आता, तब तक हर quarter manual review करना शायद ज़्यादा सुरक्षित हो सकता है
    • लेकिन अगर ग्राहक ऐसे tool से code scan करते हैं, तो वे “हम उस function का इस्तेमाल नहीं करते” जैसी बात पर भरोसा नहीं करते
      यहीं असली security और security practice के बीच की खाई पैदा होती है
    • “अगर इस्तेमाल नहीं करते, तो वह function code में बचा ही क्यों है?” यह सवाल भी वाजिब है
  • समझ नहीं आता कि industry ने ऐसे सतही security scanner क्यों स्वीकार कर लिए
    ज़्यादातर CVE वास्तव में असर नहीं डालते, फिर भी कंपनियाँ container image में vulnerability count को 0 करने में लगी रहती हैं
    ऊपर से dependency update करने पर नई CVE आना लगभग तय है। क्योंकि ज़्यादातर software backport patch नहीं करते
    • “backport नहीं करते” वाली बात पिछले वाक्य से कैसे जुड़ती है, यह मुझे पूरी तरह स्पष्ट नहीं है
  • Dependabot या Renovate का फ़ायदा यह है कि वे language-agnostic तरीके से काम करते हैं
    repository ज़्यादा हों और languages भी विविध हों, तो हर जगह परफ़ेक्ट CI workflow जोड़ना अव्यावहारिक हो जाता है
    यह परफ़ेक्ट नहीं है, लेकिन कुछ भी न करने से तो कहीं बेहतर है
  • मुझे जिज्ञासा है कि Dependabot का CVSS score कहाँ से आता है
    क्या यह अपने आप CVE generate करता है?
    • CVSS worst case मानकर दिया गया score है, इसलिए यह वास्तविक risk level नहीं दिखाता
      GitHub का vulnerability DB quality से ज़्यादा quantity पर केंद्रित है, और Dependabot बिना दिमाग वाला spam notifier की तरह काम करता है
    • यह भी शक है कि वह bug वास्तव में vulnerability है भी या नहीं
      अगर समस्या सिर्फ function को ग़लत तरीके से call करने पर ही आती है, तो संभव है कि code पहले से ही सही तरह काम नहीं कर रहा था
  • हमारी कंपनी में भी ऐसा ही problem है
    GCP container image scan, Vanta पर CVE warnings की बाढ़ ला देता है, जिनमें ज़्यादातर या तो fix नहीं की जा सकतीं या ऐसे path से जुड़ी हैं जो वास्तव में इस्तेमाल ही नहीं होते
    क्या कोई ऐसा tool है जो इस तरह की context-based filtering कर सके?
    • हमारी कंपनी Aikido Code इस्तेमाल करती है। यह AI से vulnerability के वास्तविक impact को filter करने की कोशिश करता है
      नतीजे काफ़ी सकारात्मक रहे हैं, लेकिन codebase बड़ा हो और dependencies बहुत हों, तो CVE की संख्या कम करना अब भी मुश्किल है