Astral ऐसे टूल्स (Ruff, uv, ty) बनाती है जिन पर दुनिया भर के लाखों डेवलपर निर्भर हैं, और हाल में Trivy और LiteLLM supply chain hacking घटनाओं के बाद उसने अपनी सुरक्षा प्रथाओं को सार्वजनिक किया है। इसका लक्षित पाठक वर्ग तीन तरह का है: उपयोगकर्ता, दूसरे open source maintainers, और CI/CD सिस्टम डेवलपर।
1. CI/CD सुरक्षा
GitHub Actions के security defaults कमज़ोर हैं, और Ultralytics·tj-actions·Nx जैसी सभी breach घटनाएँ pull_request_target जैसे ख़तरनाक triggers से शुरू हुईं। Astral का जवाब इस प्रकार है:
ख़तरनाक triggers पर पूरी रोक
pull_request_target और workflow_run जैसे ऐसे triggers, जिन्हें सुरक्षित रूप से इस्तेमाल करना लगभग असंभव है, संगठन-स्तर पर प्रतिबंधित किए जाते हैं। ज़्यादातर प्रोजेक्ट्स को लगता है कि उन्हें इन triggers की ज़रूरत है, लेकिन व्यवहार में अधिकतर मामलों में कम-privilege वाला pull_request trigger या साधारण workflow logs ही काफ़ी होते हैं।
Action commit hash pinning
टैग या branch (जो बदले जा सकते हैं) की जगह किसी खास commit SHA पर pin किया जाता है, और यह cross-verify भी किया जाता है कि वह commit वास्तव में release state से मेल खाता है, ताकि "imposter commit" से बचा जा सके। इसके लिए zizmor और GitHub की अपनी policies दोनों का साथ में उपयोग होता है, और परोक्ष रूप से call होने वाले nested actions तक पर भी hash pinning लागू होती है।
least privilege सिद्धांत
संगठन स्तर पर default permissions को read-only रखा जाता है, और सभी workflows permissions: {} से शुरू होते हैं, फिर केवल job स्तर पर ज़रूरत के हिसाब से permissions जोड़ी जाती हैं। Secrets भी organization या repository स्तर पर रखने के बजाय deployment environment के हिसाब से अलग किए जाते हैं, ताकि test jobs release secrets तक पहुँच न सकें।
2. Repository और organization सुरक्षा
Admin और high-privilege accounts की संख्या न्यूनतम रखी जाती है, और संगठन के अधिकांश members के पास केवल ज़रूरी repositories के लिए read/write access होता है। 2FA के लिए GitHub के default (कोई भी तरीका) से अधिक मज़बूत TOTP या उससे ऊपर की शर्त रखी जाती है, और आगे चलकर केवल WebAuthn·passkeys की अनुमति देने की योजना है।
main branch पर force push की मनाही है और pull request अनिवार्य है; release tags को भी केवल deployment सफल होने के बाद ही बनाया जा सके, इसके लिए protection rules लागू हैं। खास बात यह है कि repository admins भी इन rules को bypass नहीं कर सकते, क्योंकि इन्हें organization स्तर पर enforce किया जाता है।
3. Automation (GitHub App का उपयोग)
ऐसे काम जिन्हें GitHub Actions में सुरक्षित रूप से करना संभव नहीं है, जैसे third-party PR पर comment छोड़ना, उन्हें astral-sh-bot GitHub App में अलग किया जाता है। हालांकि, Astral यह भी ज़ोर देकर कहती है कि GitHub App भी पूरी तरह vulnerabilities से मुक्त नहीं हैं; अगर untrusted code execution की ज़रूरत हो, तो अनिवार्य रूप से pull_request trigger का ही उपयोग करना चाहिए।
4. Release सुरक्षा
PyPI·crates.io·NPM पर बिना long-term credentials के publish करने के लिए Trusted Publishing का उपयोग किया जाता है, और binaries·Docker images के साथ Sigstore-आधारित attestation जोड़ी जाती है, ताकि release artifacts और workflow के बीच cryptographic link मिल सके।
GitHub की immutable releases सुविधा का उपयोग करके public build में बाद की छेड़छाड़ को रोका जाता है, और release builds के दौरान cache का उपयोग प्रतिबंधित किया जाता है ताकि cache poisoning हमले रोके जा सकें।
Release process खुद भी दोहरे स्तर पर सुरक्षित है: release environment को सक्रिय करने के लिए संगठन के भीतर किसी दूसरे अधिकृत member की कम-से-कम 1 manual approval ज़रूरी होती है। यानी किसी malicious release के लिए मज़बूत 2FA वाले दो accounts को एक साथ compromise करना पड़ेगा।
5. Dependency सुरक्षा
Dependabot·Renovate के जरिए dependency updates और ज्ञात vulnerabilities alerts को मैनेज किया जाता है, लेकिन इसके साथ एक "cooldown" policy भी चलाई जाती है, जिसमें नई release के तुरंत बाद update नहीं किया जाता। इसका मकसद अस्थायी रूप से compromise हुई dependencies के असर को कम करना है। uv में यह फीचर built-in है।
Python Packaging Authority (PyPA)·Python Security Response Team जैसे पड़ोसी projects और working groups के साथ सामाजिक संपर्क बनाए रखे जाते हैं, ताकि pip को report हुई कोई issue अगर uv को भी प्रभावित करती हो, तो जानकारी साझा की जा सके। नई dependencies जोड़ने में conservative रुख अपनाया जाता है, binary blobs वाली dependencies से बचा जाता है, और गैर-ज़रूरी features को disable रखा जाता है।
जिन projects पर यह निर्भर है, उनकी sustainability के लिए OSS Fund के माध्यम से आर्थिक योगदान भी जारी है।
मुख्य सिफारिशों का सार
Astral जिन चार मुख्य सिद्धांतों पर ज़ोर देती है, वे हैं: CI/CD की सीमाओं को पहचानें और जो काम सुरक्षित रूप से नहीं किए जा सकते उन्हें या तो छोड़ दें या GitHub App में अलग कर दें; long-term credentials को जहाँ तक संभव हो हटाएँ और उन्हें न्यूनतम दायरे में isolate करें; deployment environments, approvals और immutable tags के ज़रिए release process को मज़बूत करें; और पूरी dependency tree की सेहत पर लगातार नज़र रखें।
निहितार्थ
PyPI और supply chain security में गहरी दिलचस्पी रखने वालों के नज़रिए से देखें तो यह लेख सिर्फ़ एक security guide नहीं, बल्कि पूरे open source ecosystem की trust structure को कैसे डिज़ाइन किया जाए इसका एक व्यावहारिक उदाहरण है। खासकर Trusted Publishing, cooldown policy, और dual-approval release process ऐसे बिंदु हैं जिनसे बड़े open source projects को सीख लेनी चाहिए।
मूल लेख: Astral Blog, 2026.04.08
अभी कोई टिप्पणी नहीं है.