- दुनिया भर के डेवलपर्स द्वारा इस्तेमाल किए जाने वाले Ruff, uv, ty जैसे टूल्स बनाने वाली Astral, अपने सभी प्रोडक्ट्स में सुरक्षा और विश्वसनीयता को मुख्य मूल्य के रूप में बनाए रखती है
- हाल में बढ़े supply chain attacks के जवाब में, कंपनी ने build, deploy और release की पूरी प्रक्रिया में सुरक्षा मजबूत करने के लिए अपनाई गई आंतरिक तकनीकों को सार्वजनिक किया है
- GitHub Actions-आधारित CI/CD में hash pinning, least privilege, secret isolation जैसी बहु-स्तरीय सुरक्षा व्यवस्था लागू की गई है
- release चरण में Trusted Publishing, Sigstore attestations, Immutable Releases आदि के जरिए deployment integrity सुनिश्चित की जाती है
- Astral का लक्ष्य इस दृष्टिकोण के माध्यम से पूरे open source ecosystem की सुरक्षा स्तर को बेहतर बनाना और टिकाऊ रक्षा तंत्र बनाना है
Astral का ओपन सोर्स सुरक्षा दृष्टिकोण
- Astral, Ruff, uv, ty जैसे टूल्स बनाती है जिन्हें दुनिया भर में लाखों डेवलपर्स इस्तेमाल करते हैं, और इन टूल्स की सुरक्षा और विश्वसनीयता को एक मुख्य मूल्य के रूप में बनाए रखती है
- हाल के Trivy और LiteLLM हैकिंग मामलों सहित supply chain attacks बढ़ने के साथ, Astral ने अपने टूल्स और build-deploy process की सुरक्षा सुनिश्चित करने के लिए उपयोग की जाने वाली आंतरिक सुरक्षा तकनीकों को साझा किया है
- कंपनी ने ऐसे security best practices भी साझा किए हैं जिन्हें उपयोगकर्ता, open source maintainers और CI/CD सिस्टम डेवलपर्स सभी संदर्भ के रूप में देख सकते हैं
CI/CD सुरक्षा
- Astral, GitHub Actions-आधारित व्यापक CI/CD workflows के जरिए development और deployment को automate करती है, और इसे सुरक्षा के एक मुख्य घटक के रूप में इस्तेमाल करती है
- इससे build और test स्थानीय environment के बजाय नियंत्रित और ऑब्ज़र्व किए जा सकने वाले environment में किए जाते हैं
- GitHub Actions की default security settings कमजोर हो सकती हैं, इसे ध्यान में रखते हुए कंपनी ने निम्नलिखित सख्ती लागू की है
pull_request_target, workflow_run जैसे खतरनाक triggers पर पूर्ण प्रतिबंध
- सभी actions को विशिष्ट commit hash (SHA) पर pin करना और impostor commit होने की cross-check verification करना
- zizmor के
unpinned-uses, impostor-commit audit tools और GitHub policies का साथ में उपयोग
- hash pinning संभव न होने वाले indirect dependency actions सहित पूरे dependency graph को hash pinning के तहत लाना
- केवल hash pinning पर्याप्त नहीं है, इसलिए manual review के जरिए immutability flaws का पता लगाया जाता है, और जरूरत पड़ने पर upstream projects के साथ मिलकर उन्हें ठीक किया जाता है
- उदाहरण: binary download URL और hash को map करके immutable state के रूप में embed करना
- workflow permissions को डिफ़ॉल्ट रूप से read-only तक सीमित रखा जाता है, और हर job को केवल आवश्यक minimum permissions ही दी जाती हैं
- GitHub Secrets को environment के अनुसार अलग किए गए deployment variables के रूप में मैनेज किया जाता है, ताकि test और lint jobs release secrets तक पहुंच न सकें
- सहायक टूल्स के रूप में zizmor (static analysis) और pinact (automatic hash pinning) का उपयोग किया जाता है
repository और organization सुरक्षा
- Astral organization के भीतर admin privilege accounts की संख्या न्यूनतम रखी जाती है, और अधिकांश सदस्यों को केवल आवश्यक repositories पर read-write access मिलता है
- सभी सदस्यों के लिए मजबूत 2FA अनिवार्य है, और कम से कम TOTP स्तर या उससे ऊपर की authentication method का उपयोग किया जाता है
- यदि GitHub केवल phishing-resistant methods (WebAuthn, Passkeys) की अनुमति देता है, तो कंपनी तुरंत उसी पर स्थानांतरित होने की योजना रखती है
- branch protection rules पूरे organization स्तर पर लागू हैं
main branch पर force push की अनुमति नहीं है, और सभी बदलाव केवल PR के जरिए किए जा सकते हैं
advisory-*, internal-* जैसे कुछ branch patterns बनाने पर रोक है
- tag protection rules के तहत release deployment सफल होने के बाद ही tag बनाया जा सकता है
- tag modification या deletion की अनुमति नहीं है, और release केवल
main branch से ही संभव है
- repository admins भी protection rules को bypass नहीं कर सकते, क्योंकि सभी सुरक्षा उपाय organization स्तर पर enforce किए जाते हैं
- Astral ने इन नियमों के सेट को gist के रूप में सार्वजनिक किया है ताकि दूसरे projects भी इसका संदर्भ ले सकें
automation
- GitHub Actions के जरिए third-party PRs पर comment करना जैसी कुछ tasks सुरक्षित रूप से करना संभव नहीं है
- इसके लिए Astral, astral-sh-bot GitHub App का उपयोग करती है, जो Actions के बाहर events को सुरक्षित तरीके से handle करता है
- GitHub App वही event data प्राप्त करता है, लेकिन code और data अलग-अलग environment में चलाए जाते हैं
- हालांकि, App भी sensitive credentials को अपने-आप हटाता नहीं है
- SQLi, prompt injection जैसी vulnerabilities मौजूद हो सकती हैं, इसलिए इसे सामान्य software के बराबर सुरक्षा मानक के साथ विकसित करना जरूरी है
- App का उपयोग अपने-आप untrusted code execution की सुरक्षा की गारंटी नहीं देता
- GitHub App का तरीका सुरक्षा के लिहाज से फायदेमंद है, लेकिन complexity बढ़ाता है
- App development और hosting की जरूरत होती है, इसलिए individual developers या छोटे projects के लिए यह बोझिल हो सकता है
- Python के लिए Gidgethub framework development को सरल बनाता है
- Astral की योजना astral-sh-bot को open source के रूप में जारी करने की है, और संदर्भ सामग्री के रूप में Mariatta का tutorial सुझाया गया है
release सुरक्षा
- Astral के टूल्स GitHub के अलावा PyPI, Homebrew, Docker images जैसे विभिन्न channels के जरिए भी वितरित किए जाते हैं
- supply chain attacks को रोकने के लिए निम्नलिखित कदम उठाए जाते हैं
- Trusted Publishing का उपयोग कर registry credentials हटाए जाते हैं
- Sigstore-आधारित attestations बनाकर build artifacts और workflows के बीच cryptographic linkage सुनिश्चित किया जाता है
- GitHub की Immutable Releases feature के जरिए publish होने के बाद modification रोका जाता है
- build cache का उपयोग न करके cache poisoning attacks रोके जाते हैं
- release process को dedicated deployment environment में isolate किया जाता है
- release environment activate करने के लिए दूसरे टीम सदस्य की approval आवश्यक होती है, ताकि एक account compromise होने पर malicious release न हो सके
release-gate environment और GitHub App-आधारित approval relay के जरिए multi-step approval बनाए रखी जाती है
- tags केवल release सफल होने के बाद ही बनाए जा सकते हैं
- standalone installer embedded checksums के जरिए binary integrity verify करता है
- release के बाद documentation, version manifest, pre-commit hooks update जैसे काम dedicated bot account और fine-grained PAT से किए जाते हैं
- भविष्य में macOS और Windows के लिए code signing जोड़ने की योजना है
dependency सुरक्षा
- Astral, Dependabot और Renovate का उपयोग dependency updates और vulnerability alerts को मैनेज करने के लिए करती है
- cooldown अवधि रखकर नई release के तुरंत बाद updates को delay किया जाता है, ताकि अस्थायी supply chain attack risk कम किया जा सके
- Renovate group-wise cooldown settings को support करता है, और अपनी dependencies के लिए छूट लागू की जाती है
- मुख्य upstream projects के साथ निरंतर सहयोग और security contributions जारी हैं
- Python Packaging Authority और Python Security Response Team जैसी संस्थाओं के साथ मिलकर security information साझा की जाती है
- नई dependencies जोड़ने से पहले सावधानीपूर्वक समीक्षा की जाती है, और अनावश्यक dependencies हटाने की कोशिश की जाती है
- खासकर binary blobs शामिल करने वाली dependencies से बचना, और अनावश्यक features disable करना
- OSS Fund के जरिए महत्वपूर्ण open source projects को वित्तीय सहायता दी जाती है
निष्कर्ष और मुख्य सीख
- open source security, तकनीकी और सामाजिक समस्याओं का संयुक्त स्वरूप है, और इसके लिए लगातार प्रतिक्रिया आवश्यक है
- Astral जिन प्रमुख सिद्धांतों पर जोर देती है
- CI/CD की सीमाओं को समझना, और आवश्यकता पड़ने पर GitHub App जैसे बाहरी isolation तरीकों का उपयोग करना
- दीर्घकालिक credentials को हटाना और न्यूनतम रखना, तथा Trusted Publishing और OIDC authentication का उपयोग करना
- release process को मजबूत बनाना, approval, tag, branch rules और Immutable Release लागू करना
- dependencies के प्रति सतर्क रहना, और tools व सहयोग के जरिए upstream projects की security भी मजबूत करना
- Astral इन तकनीकों का लगातार मूल्यांकन और सुधार करती रहेगी, और हमलावरों के व्यवहार में बदलाव के अनुसार अपने defense system को विकसित करेगी
notes सारांश
- PyPI का PEP 740 attestations upload की अनुमति देता है, लेकिन फिलहाल यह Astral के Trusted Publishing implementation के साथ compatible नहीं है, इसलिए इसका उपयोग अभी लंबित है
- install script में checksums,
curl ... | bash को सीधे चलाने पर सीमित प्रभाव रखते हैं, लेकिन CI/CD में vendoring के समय उपयोगी होते हैं
अभी कोई टिप्पणी नहीं है.