- 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 का भरोसा हासिल करना असंभव है
अभी कोई टिप्पणी नहीं है.