Astral की ओपन सोर्स सुरक्षा रणनीति

 (astral.sh)
1 पॉइंट द्वारा GN⁺ 22 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • दुनिया भर के डेवलपर्स द्वारा इस्तेमाल किए जाने वाले 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 जारी हैं
    • उदाहरण: apache/opendal-reqsign में CI/CD सुरक्षा मजबूत करने में योगदान
  • 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 के समय उपयोगी होते हैं

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

1 टिप्पणियां

 
GN⁺ 22 일 전
Hacker News की राय

  • GitHub के CI को सुरक्षित तरीके से इस्तेमाल करने के लिए बहुत ज़्यादा चरणों से गुजरना पड़ता है
    ऐसी संरचना में सुरक्षा की दृष्टि से सुरक्षित संचालन करना असंभव लगता है
    ऐसा महसूस होता है कि जिन सिस्टमों में अधिकार-विभाजन या isolation जैसे बुनियादी सिद्धांत भी नहीं माने जाते, उन पर supply chain security खड़ी करना मुश्किल है

    • मेरी भी लगभग यही राय है। हाल ही में मैंने GitHub Actions में agent द्वारा लिखे गए कोड को सुरक्षित रूप से चलाने का तरीका खोजा, और sandbox-action से कुछ हद तक सफलता मिली
      लेकिन इसकी सेटिंग इतनी बारीक है कि यह scalable approach नहीं लगती। अगर defaults थोड़े अधिक सुरक्षित हो जाएँ, तो स्थिति काफी बेहतर हो सकती है
    • क्या आपने इस जटिल GitHub CI के बदले कोई वैकल्पिक build system देखा है जो उपयोगी हो?
      पूरा लेख पढ़ने के बाद लगा कि शायद यह जटिलता इस क्षेत्र की मूलभूत समस्या ही हो सकती है
    • असल में यह package registry के पूरे इकोसिस्टम की समस्या से अलग नहीं है
      ज़्यादातर immutable release को support नहीं करते, और support करने पर भी नए version अपने-आप खींच लेने की संरचना होती है, इसलिए वे हमलों के प्रति कमज़ोर हैं
      सचमुच सुरक्षित रहने के लिए verified dependencies को fixed versions के साथ अपनी registry में मैनेज करना चाहिए, लेकिन वह शायद Google जैसी कंपनियाँ ही कर सकती हैं

  • हमारी टीम द्वारा बनाए गए stagex के uv binary दुनिया में इकलौते हैं जो पूर्ण source bootstrap और multi-signed deterministic artifacts के साथ build किए गए हैं
    इसमें 25 साल पुराने web of trust और 5000 से अधिक keys से जुड़े smartcard-आधारित signing system का उपयोग होता है
    फिर भी यह खीझ पैदा करता है कि ऐसी supply chain security पर volunteers ज़्यादा मेहनत कर रहे हैं

    • बाज़ार पहले ही जवाब दे चुका है। लोग सुरक्षा से ज़्यादा सुविधा चाहते हैं
      OpenClaw जैसे tools keys और secrets लीक करा दें, तब भी लोग उन्हें इस्तेमाल करते रहते हैं
      आप attack surface घटाना चाहते हैं, लेकिन बाज़ार उसे और बढ़ा रहा है
    • सच कहें तो इसमें झुंझलाने जैसी बात नहीं है। आप reproducible Linux distribution बना रहे हैं, और उसी के आधार पर पार्टनर support services बेचते हैं
      volunteers के बिना Debian जैसे प्रोजेक्ट भी मौजूद नहीं होते। शिकायत करने से बेहतर है कि बेहतर नतीजे देकर प्रतिस्पर्धा की जाए
    • (मैं TFA का लेखक हूँ) keys की संख्या या उनकी उम्र trust का पैमाना नहीं है
      आखिरकार अगर आप third-party द्वारा बनाए गए artifacts दे रहे हैं, तो threat model क्या है, यह स्पष्ट नहीं है
      uv की सभी builds locked resolution से आती हैं, और signed artifacts दिए जाते हैं। किसी दूसरी identity set से signed commits का मूल्य स्पष्ट नहीं है
    • open source license की प्रकृति ही ऐसी है कि कंपनियाँ उसे मुफ्त में इस्तेमाल कर सकें
      OpenAI के पास supply chain security को मज़बूत करने के लिए अलग से पैसा खर्च करने का कोई खास कारण नहीं है
    • acquisition हुए अभी कुछ ही हफ्ते हुए हैं, इसलिए अगर OpenAI ने build process बदल दिया होता तो वही ज़्यादा अजीब लगता
      तकनीकी आलोचना समझ में आती है, लेकिन इस समय OpenAI को सीधे ज़िम्मेदार ठहराना उचित नहीं लगता

  • जानकारी के लिए, PyPI का Trusted Publishing William Woodruff और Trail of Bits टीम ने मिलकर लागू किया था

  • मैं Astral टीम से पूछना चाहता हूँ कि इतनी मेहनत के बावजूद GitHub पर इतनी अधिक निर्भरता को वे कैसे मैनेज करते हैं
    अगर GitHub hack हो जाए या किसी bug की वजह से settings बदल जाएँ, तो आप क्या करेंगे?

    • हम भी GitHub के साथ सीधे संवाद करते हैं। क्योंकि वे core infrastructure हैं, इसलिए platform changes को हम ध्यान से monitor करते हैं
    • GitHub में सच में बहुत bugs हैं। workflow का अपने ही repository की branch clone करते समय fail हो जाना भी आम है

  • open source ecosystem काफ़ी resilient है, लेकिन 3rd-party code sandboxing अब भी कमज़ोर है
    हर बार uv का इस्तेमाल करते हुए यह सुविधा ज़रूर उभरकर आती है कि कई Python versions को आसानी से मैनेज किया जा सकता है, लेकिन इसका मतलब यह भी है कि वह host machine पर बिना isolation के चलता है, जो असहज करता है

    • मैं uv को हमेशा Docker के अंदर इस्तेमाल करता हूँ। उस स्थिति में यह काफी सुविधाजनक है

  • मौजूदा supply chain की बड़ी समस्या यह है कि बहुत से tools और dependencies origin verification के बिना download हो जाते हैं
    इसलिए मैं open source और multisig file verification solution asfaload पर काम कर रहा हूँ
    यह axios जैसी घटनाओं को रोक सकने वाली संरचना है

    • क्या वही release attestations का उद्देश्य नहीं है? संबंधित दस्तावेज़ देखें
    • दिशा सही लगती है। लेकिन code या product अभी सार्वजनिक नहीं है, इसलिए आकलन करना मुश्किल है
    • मेरा मानना है कि किसी खास author verification से ज़्यादा बेहतर यह होगा कि automated code auditing tools से सभी code की जाँच की जाए

  • GitHub Actions को commit SHA पर pin करने के बाद भी, अगर वह action दूसरी dependencies खींच लाता है तो जोखिम बना रहता है
    असली समाधान है CI pipeline में कोड पर सीधा स्वामित्व या fork करने के बाद उसका स्वयं रखरखाव

    • लेख में भी यही बात है। हम defense in depth approach अपनाते हैं
      सभी actions का audit करते हैं, और जहाँ mutable dependencies हों उन्हें patch या replace करते हैं (मैं Astral से हूँ)
    • security हमेशा एक trade-off है
      पूरे stack को खुद मैनेज करना सबसे सुरक्षित है, लेकिन व्यावहारिक नहीं
      hash pinning लगभग मुफ्त में मिलने वाला security improvement है
      अंततः यह स्पष्ट समझना ज़रूरी है कि आप कहाँ तक trust कर रहे हैं
    • वैसे भी 3rd-party actions का उपयोग करते समय code को खुद पढ़कर verify करना पड़ता है। सिर्फ fork कर लेने से समस्या हल नहीं होती

  • हाल के Trivy और litellm मामलों को देखें तो release process security guide की सचमुच ज़रूरत है
    इस लेख की सलाह व्यावहारिक है और तुरंत लागू की जा सकती है
    supply chain security का मूल इस बात पर निर्भर करता है कि जिन platforms पर हम निर्भर हैं, उनके defaults कितने सुरक्षित हैं

  • यह एक शानदार overview है। लगता है कि यह दूसरे open source projects के लिए भी उपयोगी reference material बन सकता है

  • मैं repomatic का maintainer हूँ, जो एक Python CLI और reusable workflow tool है
    इसमें इस लेख की ज़्यादातर security practices पहले से default के रूप में शामिल हैं
    लक्ष्य है security को default बनाने वाला environment तैयार करना
    यह लेख पढ़ने के बाद मैंने fork PR approval policy check भी जोड़ दिया है
    अधिक जानकारी के लिए GitHub repository देखें