Astral'ın açık kaynak güvenlik stratejisi

 (astral.sh)
1 puan yazan GN⁺ 19 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Dünya genelinde geliştiricilerin kullandığı Ruff, uv, ty gibi araçları geliştiren Astral, tüm ürünlerinde güvenlik ve güvenilirliği temel değer olarak koruyor
  • Son dönemde artan tedarik zinciri saldırılarına karşı, derleme, dağıtım ve sürüm çıkarma süreçlerinin tamamında güvenliği güçlendirmeye yönelik iç yöntemlerini paylaştı
  • GitHub Actions tabanlı CI/CD içinde hash sabitleme, en az ayrıcalık, gizli bilgilerin ayrıştırılması gibi çok katmanlı koruma mekanizmaları uyguluyor
  • Sürüm aşamasında Trusted Publishing, Sigstore attestations, Immutable Releases gibi yöntemlerle dağıtım bütünlüğünü güvence altına alıyor
  • Astral, bu yaklaşımla açık kaynak ekosisteminin genel güvenlik seviyesini yükseltmeyi ve sürdürülebilir bir savunma yapısı kurmayı hedefliyor

Astral'ın açık kaynak güvenlik yaklaşımı

  • Astral, dünya çapında milyonlarca geliştiricinin kullandığı Ruff, uv, ty gibi araçları geliştiriyor ve bu araçların güvenliği ile güvenilirliğini temel değer olarak koruyor
  • Trivy ve LiteLLM saldırı örnekleri gibi tedarik zinciri saldırılarının artmasıyla birlikte, Astral kendi araçlarıyla derleme ve dağıtım süreçlerinin güvenliğini sağlamak için kullandığı iç güvenlik yöntemlerini paylaştı
  • Kullanıcıların, açık kaynak bakımcılarının ve CI/CD sistemi geliştiricilerinin yararlanabileceği güvenlik en iyi uygulamalarını aktarıyor

CI/CD güvenliği

  • Astral, GitHub Actions tabanlı geniş kapsamlı CI/CD iş akışları ile geliştirme ve dağıtımı otomatikleştiriyor; bunu güvenliğin temel bileşenlerinden biri olarak kullanıyor
    • Derleme ve testlerin yerel ortam yerine kontrol edilen ve gözlemlenebilir bir ortamda çalışmasını sağlıyor
  • GitHub Actions'ın varsayılan güvenlik ayarlarının zayıf olduğunu kabul ederek şu sıkılaştırma önlemlerini uyguluyor
    • pull_request_target, workflow_run gibi tehlikeli tetikleyicileri tamamen yasaklama
    • Tüm action'ları belirli bir commit hash'ine (SHA) sabitleme ve impostor commit olup olmadığını çapraz doğrulama
    • zizmor'un unpinned-uses, impostor-commit denetim araçlarını GitHub politikalarıyla birlikte kullanma
    • Hash sabitlemenin mümkün olmadığı dolaylı bağımlılık action'ları da dahil olmak üzere tüm bağımlılık grafiğini hash'e sabitleme
  • Yalnızca hash sabitlemenin yeterli olmadığını kabul ederek, elle inceleme yoluyla değişmezlik kusurlarını tespit ediyor ve gerektiğinde üst projelerle iş birliği içinde düzeltiyor
    • Örnek: İkili dosya indirme URL'leri ile hash'leri eşleştirip değişmez biçimde gömme
  • İş akışı izinleri varsayılan olarak yalnızca okuma ile sınırlandırılıyor ve her job için yalnızca gerekli en düşük yetkiler veriliyor
  • GitHub Secrets, ortama göre ayrılmış dağıtım ortam değişkenleri olarak yönetiliyor; böylece test ve lint işleri sürüm gizli bilgilerine erişemiyor
  • Yardımcı araç olarak zizmor (statik analiz) ve pinact (otomatik hash sabitleme) kullanılıyor

Depo ve organizasyon güvenliği

  • Astral organizasyonunda yönetici yetkili hesapların sayısı en aza indiriliyor ve üyelerin çoğu yalnızca gerekli depolarda okuma-yazma yetkisine sahip
  • Tüm üyeler için güçlü iki aşamalı kimlik doğrulama (2FA) zorunlu; en az TOTP düzeyinde bir yöntem kullanılıyor
    • GitHub yalnızca oltalamaya dayanıklı yöntemlere (WebAuthn, Passkeys) izin vermeye başlarsa hemen geçiş yapılacak
  • Branch koruma kuralları organizasyon genelinde uygulanıyor
    • main branch'ine force push yapılamıyor, tüm değişiklikler yalnızca PR üzerinden yapılabiliyor
    • advisory-*, internal-* gibi belirli branch desenlerinin oluşturulması yasak
  • Tag koruma kuralları sayesinde etiketler yalnızca sürüm dağıtımı başarıyla tamamlandıktan sonra oluşturulabiliyor
    • Tag değiştirme ve silme yasak; sürüm yalnızca main branch'inden çıkarılabiliyor
  • Depo yöneticileri bile koruma kurallarını atlayamıyor; tüm korumalar organizasyon düzeyinde zorunlu tutuluyor
  • Astral, bu kural setini diğer projelerin referans alabilmesi için gist olarak yayımladı

Otomasyon

  • GitHub Actions ile üçüncü taraf PR'lere yorum bırakma gibi bazı işler güvenli biçimde yapılamıyor
  • Astral bu amaçla, Actions dışında olayları güvenli şekilde işlemek için astral-sh-bot GitHub App kullanıyor
    • GitHub App aynı olay verilerini alıyor, ancak kod ve verinin ayrıldığı bir ortamda çalışıyor
  • Ancak App kullanımı da hassas kimlik bilgilerini ortadan kaldırmıyor
    • SQLi, prompt injection gibi açıklar bulunabileceği için normal yazılımla aynı güvenlik düzeyinde geliştirilmesi gerekiyor
    • App kullanmak, güvenilmeyen kod çalıştırmanın güvenli olduğunu garanti etmiyor
  • GitHub App yaklaşımı güvenlik açısından avantajlı olsa da karmaşıklığı artırıyor
    • App geliştirme ve barındırma gerektiriyor; bu da bireysel geliştiriciler veya küçük projeler için yük oluşturabiliyor
    • Python için Gidgethub çerçevesi geliştirmeyi basitleştiriyor
  • Astral, astral-sh-bot'u açık kaynak olarak yayımlamayı planlıyor ve kaynak olarak Mariatta'nın eğitimini öneriyor

Sürüm güvenliği

  • Astral araçları GitHub'ın yanı sıra PyPI, Homebrew, Docker image'ları gibi çeşitli kanallardan dağıtılıyor
  • Tedarik zinciri saldırılarını önlemek için şu önlemler uygulanıyor
    • Trusted Publishing kullanılarak registry kimlik bilgileri ortadan kaldırılıyor

    • Sigstore tabanlı attestations üretilerek derleme çıktıları ile iş akışları arasında kriptografik bağ kuruluyor

      • GitHub'ın Immutable Releases özelliği ile yayımlandıktan sonra değişiklik yapılması engelleniyor
      • Build cache kullanılmayarak cache kirletme saldırıları önleniyor
      • Sürüm süreci özel bir deployment environment içinde izole ediliyor
      • Sürüm ortamı etkinleştirilirken başka ekip üyelerinin onayı gerekiyor; böylece tek bir hesabın ele geçirilmesiyle kötü niyetli sürüm çıkarılması önleniyor
      • release-gate ortamı ve GitHub App tabanlı onay aktarımı ile çok aşamalı onay korunuyor
      • Tag'ler yalnızca sürüm başarıyla tamamlandıktan sonra oluşturulabiliyor
      • Bağımsız kurucu (standalone installer), yerleşik checksum'larla ikili dosya bütünlüğünü doğruluyor
      • Sürüm sonrası dokümantasyon, sürüm manifestleri ve pre-commit hook güncellemeleri özel bot hesapları ve ayrıntılı PAT'ler ile yapılıyor
      • İleride macOS ve Windows için kod imzalama eklenmesi planlanıyor

Bağımlılık güvenliği

  • Astral, Dependabot ve Renovate ile bağımlılık güncellemelerini ve güvenlik açığı bildirimlerini yönetiyor
  • Yeni sürümlerin hemen ardından güncellemeleri geciktirmek için cooldown süresi uygulanıyor; böylece geçici tedarik zinciri saldırısı riski azaltılıyor
    • Renovate, grup bazlı cooldown ayarlarını destekliyor; kendi bağımlılıklarında da bu hafifletme uygulanıyor
  • Başlıca üst projelerle sürekli iş birliği ve güvenlik katkısı yürütülüyor
  • Python Packaging Authority ve Python Security Response Team gibi yapılarla iş birliği içinde güvenlik bilgisi paylaşılıyor
  • Yeni bağımlılıkların eklenmesi dikkatle değerlendiriliyor ve gereksiz bağımlılıkların kaldırılması hedefleniyor
    • Özellikle ikili blob içeren bağımlılıklardan kaçınılıyor ve gereksiz özellikler devre dışı bırakılıyor
  • OSS Fund üzerinden kritik açık kaynak projelerine maddi destek veriliyor

Sonuç ve temel dersler

  • Açık kaynak güvenliği, teknik ve toplumsal sorunların birleşiminden oluşuyor ve sürekli müdahale gerektiriyor
  • Astral'ın vurguladığı başlıca ilkeler
    • CI/CD'nin sınırlarını kabul etmek ve kaçınılmaz durumlarda GitHub App gibi dış izolasyon yöntemleri kullanmak
    • Uzun ömürlü kimlik bilgilerini kaldırmak ve en aza indirmek, Trusted Publishing ve OIDC kimlik doğrulamasından yararlanmak
    • Sürüm sürecini güçlendirmek, onay, tag, branch kuralları ve Immutable Release uygulamak
    • Bağımlılık farkındalığını sürdürmek, araçlar ve iş birlikleriyle üst projelerin güvenliğini de güçlendirmek
  • Astral, bu teknikleri sürekli değerlendirip iyileştirecek ve saldırgan davranışlarındaki değişime göre savunma yapısını geliştirmeyi sürdürecek

Dipnot özeti

  • PyPI'deki PEP 740 attestations yüklemeye izin veriyor; ancak şu anda Astral'ın Trusted Publishing uygulamasıyla uyumlu olmadığı için beklemede
  • Kurulum betiğindeki checksum'lar, curl ... | bash doğrudan çalıştırıldığında sınırlı etkiye sahip olsa da CI/CD içinde vendor etme durumunda yararlı

İlgili okumalar

1 yorum

 
GN⁺ 19 일 전
Hacker News yorumları

  • GitHub CI'yi güvenli kullanmak için fazla çok adımdan geçmek gerekiyormuş gibi geliyor
    Böyle bir yapıda güvenli şekilde işletmek bence imkansız
    Yetki ayrımı veya izolasyon gibi temel ilkelerin bile korunmadığı bir sistemin üstüne tedarik zinciri güvenliği inşa etmek pek mümkün görünmüyor

    • Ben de benzer düşünüyorum. Kısa süre önce GitHub Actions'ta ajan tarafından yazılmış kodu güvenli biçimde çalıştırmanın yolunu araştırdım ve sandbox-action ile bir ölçüde başarılı oldum
      Ama yapılandırma o kadar hassas ki ölçeklenebilir bir yaklaşım gibi görünmüyor. Varsayılanlar biraz daha güvenli hale gelse çok daha iyi olurdu
    • Bu karmaşık GitHub CI yerine kullanılabilecek alternatif bir build sistemi görüp görmediğinizi merak ediyorum
      Yazının tamamını okuyunca, bu karmaşıklığın bu alanın doğasında olan bir sorun olabileceğini düşündüm
    • Aslında bu, paket registry'leri genelindeki sorundan farklı değil
      Çoğu değiştirilemez release desteklemiyor; desteklese bile yeni sürümleri otomatik çekme yapısı yüzünden saldırılara açık oluyor
      Gerçekten güvenli olmak için doğrulanmış bağımlılıkları sabit sürümlerle kendi registry'nizde yönetmeniz gerekir, ama bunu ancak Google gibi şirketler yapabilir

  • Ekibimizin geliştirdiği stagex içindeki uv binary'si, dünyada tam kaynak bootstrap ve çoklu imzalı deterministik artifact'lerle build edilen tek örnek
    25 yıllık bir trust web'i ve 5000'den fazla anahtarla bağlı akıllı kart tabanlı bir imza sistemi kullanıyor
    Buna rağmen gönüllülerin bu tür tedarik zinciri güvenliğini daha ciddiye alıyor olması sinir bozucu

    • Piyasa aslında cevabı çoktan vermiş durumda. İnsanlar güvenlikten çok kullanım kolaylığı istiyor
      OpenClaw gibi araçlar anahtarları ve sırları sızdırsa bile kullanıcılar yine de onları kullanıyor
      Siz saldırı yüzeyini azaltmaya çalışıyorsunuz, ama piyasa tam tersine onu genişletiyor
    • Aslında kızılacak bir durum değil. Siz yeniden üretilebilir bir Linux dağıtımı yapıyorsunuz ve partnerleriniz bunun üzerinden destek hizmeti satıyor
      Gönüllüler olmadan Debian gibi projeler de var olamazdı. Şikayet etmek yerine daha iyi sonuçlarla rekabet etmek gerekir
    • (TFA yazarıyım) Anahtarların sayısı ya da yaşı güven ölçüsü değildir
      Sonuçta üçüncü tarafça build edilmiş çıktılar sunuluyorsa, tehdit modelinin ne olduğu net değil
      uv'nin tüm build'leri kilitlenmiş çözümlemeden geliyor ve imzalı artifact'ler sunuyor. Farklı bir kimlik kümesiyle imzalanmış commit'lerin değeri belirsiz
    • Open source lisanslarının kendisi zaten şirketlerin ücretsiz kullanabilmesi için tasarlanmış
      OpenAI'ın özellikle para harcayıp tedarik zinciri güvenliğini güçlendirmesi için bir nedeni yok
    • Daha satın alınalı birkaç hafta oldu; OpenAI build sürecini değiştirseydi bu daha da garip olurdu
      Teknik eleştiriyi anlıyorum ama zamanlama açısından bunu OpenAI'ın sorumluluğu gibi göstermek zor

  • Bilgi olarak, PyPI'daki Trusted Publishing özelliği William Woodruff ile Trail of Bits ekibi tarafından birlikte geliştirildi

  • Astral ekibine sormak istiyorum. Bu kadar çaba gösterirken GitHub'ın kendisine bu kadar bağımlı olmayı nasıl yönetiyorsunuz?
    GitHub hack'lenirse ya da bir bug yüzünden ayarlar değişirse ne yaparsınız?

    • Biz de GitHub ile doğrudan iletişim halindeyiz. Onlar kritik altyapı olduğu için platformdaki değişiklikleri yakından izliyoruz
    • GitHub gerçekten bug dolu. Workflow'nun kendi repository'sindeki branch'i clone ederken bile başarısız olması sık görülen bir şey

  • Open source ekosistemi dayanıklı ama 3rd-party kod sandboxing hâlâ yetersiz
    uv kullanılırken birden fazla Python sürümünü kolayca yönetebilmek öne çıkarılıyor, ama bu aynı zamanda onun host makinede izolasyon olmadan çalıştığı anlamına geliyor ve bu tedirgin edici

    • Ben uv'yi her zaman Docker içinde kullanıyorum. O zaman oldukça kullanışlı oluyor

  • Mevcut tedarik zincirindeki büyük sorunlardan biri, birçok araç ve bağımlılığın kaynak doğrulaması olmadan indirilmesi
    Bu yüzden ben, open source bir multisig dosya doğrulama çözümü olan asfaload üzerinde çalışıyorum
    axios benzeri olayları önleyebilecek bir yapı

    • Bu zaten release attestations'ın amacı değil mi? İlgili belge bakılabilir
    • Yaklaşım doğru gibi görünüyor. Ama kod ya da ürün henüz açık olmadığı için değerlendirmek zor
    • Belirli bir yazarı doğrulamaktansa tüm kodu otomatik kod denetim araçlarıyla incelemek daha iyi olabilir diye düşünüyorum

  • GitHub Actions'ı commit SHA'ya sabitleseniz bile, o action başka bağımlılıkları çekiyorsa hâlâ risk var
    Gerçek çözüm, CI pipeline'ında koda doğrudan sahip olmak ya da fork edip kendiniz bakımını yapmak

    • Makalede de geçiyor. Biz defense in depth yaklaşımı benimsiyoruz
      Tüm action'ları denetliyor, değişken bağımlılık varsa düzeltiyor ya da değiştiriyoruz (Astral'danım)
    • Güvenlik her zaman bir trade-off meselesi
      Tüm stack'i kendiniz yönetmek en güvenlisi ama pratik değil
      Hash sabitleme, neredeyse bedavaya elde edilen güçlü bir güvenlik iyileştirmesi
      Sonuçta önemli olan, neye kadar güvendiğinizi açık biçimde bilmek
    • Zaten 3rd-party action kullanırken kodu doğrudan okuyup doğrulamak gerekir. Sadece fork etmek sorunu çözmez

  • Son Trivy ve litellm olaylarına bakınca, release süreci güvenlik rehberi gerçekten gerekli görünüyor
    Bu yazının tavsiyeleri pratik ve hemen uygulanabilir
    Tedarik zinciri güvenliğinin özü, bağımlı olduğumuz platformların varsayılan ayarlarının ne kadar güvenli olduğuna bağlı

  • Harika bir genel bakış. Diğer open source projeleri için de faydalı bir başvuru kaynağı olabilir

  • Ben, Python CLI ve yeniden kullanılabilir workflow aracı olan repomatic'in bakımını yapıyorum
    Bu yazıdaki güvenlik uygulamalarının çoğunu varsayılan olarak içeriyor
    Amaç, güvenliğin varsayılan olduğu bir ortam oluşturmak
    Yazıyı okuduktan sonra fork PR onay politikası kontrolünü ekledim
    Ayrıntılar için GitHub deposuna bakabilirsiniz