GitHub Actions में package manager तो है, लेकिन यह सबसे खराब हो सकता है

• GitHub Actions में workflow फ़ाइलों में uses: सिंटैक्स के ज़रिए पैकेज निर्भरता घोषित करके रन करने की संरचना है, और व्यवहार में यह वास्तव में एक package manager की भूमिका निभाती है
• लेकिन अन्य package manager की तरह मिलने वाले lockfile, integrity hash, transitive dependency pinning, dependency tree visibility जैसी बेसिक सुविधाएँ इसमें एकदम मौजूद नहीं हैं
• शोध में पाया गया कि अधिकांश GitHub Actions उपयोगकर्ता unverified बाहरी code रन करते हैं, और code injection vulnerability हजारों workflows में मिली
• GitHub ने कुछ mitigation उपाय (immutable release, SHA pinning policy आदि) लागू किए हैं, लेकिन transitive dependencies और reproducibility की समस्या अभी भी हल नहीं हुई है
• ये structural flaws software supply chain security पर व्यापक प्रभाव डालते हैं और GitHub Actions पर आधारित अन्य CI systems में भी यही समस्या फैलती है

---

GitHub Actions का पैकेज मैनेजमेंट स्ट्रक्चर और समस्याएँ

• uses: actions/checkout@v4 जैसी syntax एक dependency declaration है, जिसे GitHub interpret करके download और execute करता है
  • यह सामान्य package manager व्यवहार के समान है, लेकिन lockfile के बिना हर रन में अलग version चुना जा सकता है
• अन्य package manager (npm, Cargo, NuGet आदि) से तुलना करें तो, Actions में lockfile, transitive pinning, integrity verification, dependency tree visibility, resolution spec सभी missing हैं
• lockfile की गैर मौजूदगी मुख्य समस्या है, क्योंकि रन पर रन dependency resolution बदल सकता है और non-deterministic build पैदा होती है

सुरक्षा शोध के परिणाम और कमजोरियाँ

• USENIX Security 2022 अध्ययन के मुताबिक, 99.7% repositories बाहरी developers के Actions execute करते हैं, 97% unverified producer हैं, और 18% में security updates missing हैं
• follow-up अध्ययन में 2.7 मिलियन workflows में से 4,300 से अधिक में code injection vulnerability मिली
• GitHub Actions, CI/CD की ज़रूरी सुरक्षा properties जैसे admittance control, execution control, code control, secrets access control को पर्याप्त रूप से प्रदान नहीं करता

मुख्य तकनीकी दोष

• variable version issue: @v4 जैसी tag maintainer के द्वारा नए commit से re-tag की जा सकती है, जिससे code चुपचाप बदल सकता है
  • अगर lockfile हो, तो record किया जा सकता है कि उस tag को किस SHA में resolve किया गया था
• transitive dependency अस्पष्टता: Composite Action के अंदर अन्य Action को call करने के बावजूद वे दिखते नहीं हैं और control में नहीं आते
  • शोध में पाया गया कि JavaScript Actions में से 54% security weakness रखते हैं, और अधिकांश weakness indirect dependency से आती है
  • tj-actions/changed-files घटना में transitive dependency update के जरिए secret leak attack हुआ
• इंटीग्रिटी verification की कमी: npm या Cargo डाउनलोड को validate करने के लिए hash को रिकॉर्ड करते हैं, लेकिन Actions केवल SHA-based trust पर निर्भर करता है
• replay non-reproducibility: GitHub ने स्पष्ट कहा कि अगर version force push हो तो latest version fetch होता है, यानी उसी workflow में भी अलग code रन हो सकता है
• dependency tree की non-visibility: npm के npm ls या Cargo के cargo tree जैसी functionality नहीं है, इसलिए पूरी dependency structure देखने का कोई तरीका नहीं है
• resolution नियम गोपनीय: Actions की dependency resolution का कोई दस्तावेज़ नहीं है; ActionManager.cs में केवल एक simple recursive download logic मौजूद है

अतिरिक्त संरचनात्मक सीमाएँ

• central registry का अभाव: Actions Git repositories में रहते हैं, इसलिए कोई security scan, malware detection या typosquatting prevention नहीं होता
• shared environment issue: कई Action एक ही $PATH बदलते हैं, जिससे execution order बदलने पर परिणाम बदल सकता है
• offline रन संभव नहीं: हर बार GitHub से download करना पड़ता है और बिना network रन नहीं हो सकता
• namespace weakness: GitHub username ही namespace है, इसलिए account takeover या typo attack का जोखिम रहता है
  • यदि lockfile और integrity hash मौजूद हों, तो code बदलने पर build fail होकर detect हो सकता था

डिजाइन पृष्ठभूमि और प्रभाव

• Actions runner शुरुआत में Azure DevOps based था और इसे एक trusted internal environment को ध्यान में रखकर design किया गया था
  • GitHub ने इसे public marketplace के रूप में scale करते समय trust model को फिर से डिजाइन नहीं किया
• इसलिए lockfile, integrity verification, transitive pinning, dependency visibility जैसी बेसिक फीचर missing रह गईं
• OIDC-based package auto distribution बढ़ने के साथ, Actions की security flaws का असर पूरे package registry supply chain security पर पड़ता है
• GitLab CI ने integrity keyword जोड़कर hash verification दिया, जबकि GitHub ने यही request “नो प्लान” कहकर बंद कर दी
• Forgejo Actions जैसे GitHub-compatible CI systems को भी यही structure maintain करनी पड़ती है, इसलिए यह flaw पूरी ecosystem में फैलता है

सुधार प्रस्ताव और स्थिति

• community ने lockfile support (issue #2195) की मांग की, लेकिन GitHub ने 2022 में इसे “नो प्लान” कहकर बंद कर दिया
• Palo Alto research ने साबित किया कि सिर्फ SHA pinning से transitive dependencies protect नहीं की जा सकतीं
• कुछ टीमों ने Dependabot updates, अपने repository का vendoring, और zizmor security scanner जैसी चीज़ों से इसे patch करने की कोशिश की है
• वास्तविक समाधान है सभी Action और उनकी transitive dependencies के SHA और integrity hash को record करने वाला lockfile लागू करना
• जब तक GitHub इसे adopt नहीं करता, CI/CD supply chain का भरोसा हासिल करना असंभव है

[holywork]

शायद इन्हें तब समझ आएगा जब इनका सिस्टम हैक हो जाएगा।

[GN⁺]

Hacker News राय

• मैं GHA(GitHub Actions) का बचाव नहीं करना चाहता, लेकिन दस्तावेज़ों में स्थिरता और सुरक्षा के लिए commit SHA pinning की सिफारिश स्पष्ट रूप से की गई है
  इसे सीधे lock file की तरह लागू किया जा सकता है, लेकिन transitive dependency को नियंत्रित नहीं किया जा सकता, इसलिए यह पूर्ण समाधान नहीं है
  आखिरकार security patch को track करने और hash अपडेट करने का बोझ आता है, और शायद इसी वजह से hash-आधारित pinning व्यापक रूप से इस्तेमाल नहीं होती

  • GitHub को Actions जारी होने के तुरंत बाद से ही इस समस्या का पता था, फिर भी उसने version pinning feature को व्यवहारिक रूप से बेहतर नहीं बनाया
    ज़्यादातर उपयोगकर्ता इस समस्या को पहचानते ही नहीं, और जो पहचानते हैं वे भी शायद ही कभी SHA का उपयोग करते हैं
    मुझे व्यक्तिगत रूप से Actions पसंद हैं और मैं कुछ का रखरखाव भी करता हूँ, लेकिन सार्वजनिक repositories को देखें तो 90% @v1, 9% @v1.2, और सिर्फ़ 1% commit SHA का उपयोग करती हैं
    GitHub थोड़ा सा निवेश करके भी lock file solution बना सकता था
  • दस्तावेज़ों में दी गई रणनीति transitive dependency समस्या को हल नहीं करती, इसलिए वास्तव में यह मूलभूत समाधान नहीं है
  • यह कहना कि commit SHA pinning स्थिर है, व्यवहारिक रूप से ग़लत है
    यह अक्सर किसी विशेष Node version या API version पर निर्भर करता है, इसलिए कई बार @main का उपयोग करना ही बेहतर अनुभव रहा है
  • मुझे लगता है कि SHA का उपयोग करना उल्टा एक anti-pattern है
    ऐसा भ्रम होता है कि आपको “fixed version” मिल रहा है, जबकि वास्तव में ऐसा नहीं है
    दो बार समस्या झेलने के बाद मुझे समझ आया — या तो lock file है, या नहीं है

• GitHub अपने ही Actions का लगभग रखरखाव नहीं करता, और हालत यह है कि बुनियादी functionality के लिए भी unofficial forks पर निर्भर होना पड़ता है
  पूरा ecosystem जैसे अस्थायी जुगाड़ पर चल रहा हो

  • लगता नहीं कि यह स्थिति जल्दी सुधरेगी
    क्योंकि GitHub ने घोषणा की है कि feature development से ज़्यादा प्राथमिकता Azure migration को दी जाएगी
    संबंधित लेख
  • दिलचस्प बात यह है कि GitHub काफ़ी महँगी service है
    हमारी छोटी कंपनी भी हर महीने 200 डॉलर से ज़्यादा चुकाती है
    ऐसा लगता है कि इसे Windows से भी ज़्यादा महत्वपूर्ण नई revenue stream माना जा रहा है
  • setup- actions* की गुणवत्ता स्पष्ट रूप से गिर गई है, और अजीब फैसले बढ़ गए हैं
    शायद मूल लेखक अब कंपनी छोड़ चुके हैं
  • यह बात मैं पहली बार सुन रहा हूँ, क्या इसके कुछ ठोस उदाहरण हैं?
  • क्या GitHub ने हाल में यह घोषणा नहीं की थी कि वह AI development पर फ़ोकस करने के लिए सामान्य feature development की गति धीमी करेगा?

• क्या किसी ने ArgoCD को CI pipeline की तरह इस्तेमाल किया है, यह जानने की जिज्ञासा है

• मुझे लगता है GHA ‘less is more’ दर्शन की विफलता का उदाहरण है
  इसका industry standard बन जाना ही सबसे बड़ी समस्या है
  थोड़ा सा निवेश करके इससे कहीं बेहतर CI बनाया जा सकता था, लेकिन ऐसा लगता है MS ने IE6 युग की गलती दोहरा दी
  अब युवा engineers की वह पीढ़ी, जिसके पास तुलना का अनुभव नहीं है, उसकी सीमाओं को पहचान ही नहीं पाती

  • सब लोग इस बात से सहमत लगते हैं कि GHA सच में बहुत ख़राब है, लेकिन free computing resources मिलने की वजह से लोग इसका इस्तेमाल करते रहते हैं
    मैं एक रिटायर हो चुके laptop को Woodpecker server की तरह चलाने का सोच रहा हूँ। देखना चाहता हूँ कि ऐसा CI कैसा होता है जिससे लोग नफ़रत नहीं करते
  • मैं उस पीढ़ी से हूँ जिसे पहले VSS इस्तेमाल करना पड़ता था, इसलिए आज का GitHub भी उस समय से कहीं बेहतर माहौल लगता है
  • मैं ज़्यादातर काम local में सीधे करता हूँ
    उसके मुकाबले GHA कोई ख़ास value देता हुआ नहीं लगता

• जब कंपनी Jenkins/Ansible से GHA पर जाने की कोशिश कर रही थी, तब मैंने विरोध किया था, और अब लगता है वह सही फ़ैसला था
  CI हमेशा maintenance burden लेकर आता है, और ख़ासकर Mac environment आज भी संभालना मुश्किल है

• “क्या आप भरोसा करते हैं कि GitHub सही SHA code देता है?” इस सवाल पर,
  जब ज़्यादातर लोग GitHub-hosted runners इस्तेमाल करते हैं, तो अगर उस पर भरोसा नहीं है, तो समस्या पहले से ही उससे बड़ी है

• कभी-कभी सोचता हूँ, अगर GitHub Actions local-first संरचना के साथ आता और Nix-आधारित locking को support करता, तो कैसा होता
  cachix/cloud.devenv.sh

  • विडंबना यह है कि वह code भी GitHub पर host किया गया है

• बहुत से third-party Actions अपने दस्तावेज़ों या उदाहरणों में सीधे master branch को refer करते हैं
  एक malicious push से असंख्य repositories में data exfiltration संभव हो सकता है
  tag का उपयोग भी पूर्ण सुरक्षा नहीं देता, क्योंकि tags को भी move किया जा सकता है

• शोधकर्ताओं द्वारा बताए गए CI/CD के चार मुख्य security properties (authentication, execution, code, secret access) को देखकर एक सवाल उठता है
  क्या CI/CD को सच में secrets तक पहुँच की ज़रूरत होती है?
  मुझे लगता है सिर्फ़ API call की permission होना काफ़ी होना चाहिए
  आदर्श system सीधे secrets को संभालने के बजाय secure enclave जैसे adapter के माध्यम से अप्रत्यक्ष रूप से काम करे

  • “अच्छे CI को secrets support नहीं करना चाहिए” कहना अंततः जटिल secret management का प्रस्ताव देने जैसा है
    व्यवहारिक रूप से ज़्यादातर ग्राहकों को अब भी secrets की ज़रूरत होती है
  • सिद्धांत रूप से यह सही है, लेकिन व्यवहार में लोग CI/CD में secrets डालने को मजबूर होते हैं
    platform को कम से कम सुरक्षित secret management mechanism तो देना ही चाहिए
    खासकर open source projects CI से सीधे deployment करना चाहते हैं
  • हमारी कंपनी QNX compiler या Coverity जैसे commercial tools इस्तेमाल करती है, और इन्हें license server तक पहुँच के लिए secrets चाहिए होते हैं
    यह “secure enclave वाला तरीका” ठोस रूप से कैसे अलग होगा, यह जानना चाहूँगा
  • अगर CI/CD पूरी तरह infrastructure के साथ integrated हो, तो secrets के बिना भी deployment संभव हो सकता है, लेकिन
    व्यवहार में हर environment अलग होता है और implementation cost बहुत ज़्यादा होती है, इसलिए ज़्यादातर लोग container + environment variable मॉडल पर टिक जाते हैं
  • कई cloud DBs के साथ compatibility test करने के लिए हर DB तक पहुँचने वाली credentials चाहिए होती हैं
    ऐसे tests को automate करने के लिए secrets अपरिहार्य हैं

• अगर lock file को repository में commit करना है, तो उसके शुरुआती निर्माण के समय bootstrapping problem आती है
  इसे हल करने के लिए Actions को local में चलाने की क्षमता चाहिए
  nektos/act जैसे tools हैं, लेकिन वे मुख्यतः debugging के लिए हैं
  शायद static analysis-आधारित अलग mechanism की ज़रूरत होगी