Ruff ve uv'nin arkasındaki Astral'ın açıkladığı açık kaynak güvenlik stratejisinin tüm ayrıntıları
(astral.sh)Astral, dünya çapında milyonlarca geliştiricinin dayandığı araçları (Ruff, uv, ty) geliştiriyor ve yakın zamanda yaşanan Trivy ile LiteLLM tedarik zinciri hack olaylarını vesile ederek kendi güvenlik uygulamalarını paylaştı. Hedef okur kitlesi üç gruptan oluşuyor: kullanıcılar, diğer açık kaynak maintainer'ları ve CI/CD sistemi geliştiricileri.
1. CI/CD güvenliği
GitHub Actions'ın güvenlik açısından varsayılan ayarları zayıf ve Ultralytics, tj-actions, Nx gibi ihlal vakalarının tamamı pull_request_target gibi riskli tetikleyicilerden kaynaklandı. Astral'ın yaklaşımı şöyle:
Riskli tetikleyicilerin tamamen yasaklanması
pull_request_target ve workflow_run gibi güvenli şekilde kullanılması neredeyse imkansız olan tetikleyiciler, organizasyon genelinde yasaklanıyor. Çoğu proje bu tetikleyicilere ihtiyaç duyduğunu düşünüyor, ancak gerçekte çoğu durumda daha düşük yetkili pull_request tetikleyicisi ya da basit workflow log'ları yeterli oluyor.
Action commit hash sabitleme (Hash Pinning)
Etiket veya branch (değiştirilebilir) yerine belirli bir commit SHA'ya sabitleniyor ve bu commit'in gerçekten yayınlanmış sürüm durumuyla eşleşip eşleşmediği çapraz doğrulanarak "sahtekar commit" riski önleniyor. zizmor ve GitHub'ın kendi politikaları birlikte kullanılıyor; dolaylı olarak çağrılan iç içe action'lar da dahil olmak üzere hepsine hash sabitleme uygulanıyor.
En az yetki ilkesi
Organizasyon seviyesinde varsayılan yetkiler salt okunur olacak şekilde ayarlanıyor ve tüm workflow'lar permissions: {} ile başlayıp yalnızca job bazında gerekli izinleri ekliyor. Secret'lar da organizasyon veya repository seviyesinde değil, dağıtım ortamına göre izole edilerek test job'larının release secret'larına erişmesi engelleniyor.
2. Repository ve organizasyon güvenliği
Yönetici ve yüksek yetkili hesapların sayısı en aza indiriliyor; organizasyon üyelerinin çoğu yalnızca ihtiyaç duydukları repository'ler için okuma ve yazma yetkisine sahip oluyor. 2FA için GitHub'ın varsayılanından (hangi yöntem olursa olsun) daha güçlü olan en az TOTP isteniyor ve ileride yalnızca WebAuthn ve passkey'e izin verecek şekilde daha da sıkılaştırılması planlanıyor.
main branch'i için force push yasak, pull request zorunlu; release tag'leri ise yalnızca dağıtım başarıyla tamamlandıktan sonra oluşturulabilecek şekilde koruma kuralları uygulanıyor. Özellikle repository yöneticilerinin bile bu kuralları atlayamaması için bunlar organizasyon seviyesinde zorunlu kılınıyor.
3. Otomasyon (GitHub App kullanımı)
Üçüncü taraf PR'lere yorum bırakmak gibi GitHub Actions içinde güvenli biçimde yapılamayan işler astral-sh-bot GitHub App'ine ayrılıyor. Ancak GitHub App'lerin de kusursuz olmadığı ve güvenilmeyen kodun çalıştırılması gereken durumlarda mutlaka pull_request tetikleyicisinin kullanılması gerektiği özellikle vurgulanıyor.
4. Release güvenliği
PyPI, crates.io ve NPM için uzun ömürlü kimlik bilgileri olmadan dağıtım yapmayı sağlayan Trusted Publishing kullanılıyor; binary'lere ve Docker image'larına ise Sigstore tabanlı doğrulama kayıtları (attestation) eklenerek release artifact'leri ile workflow arasında kriptografik bir bağ kuruluyor.
GitHub'ın immutable releases özelliği kullanılarak yayınlanan build'lerin sonradan değiştirilmesi engelleniyor; ayrıca release build sürecinde cache kullanımı yasaklanarak cache poisoning saldırıları önleniyor.
Release sürecinin kendisi de çift katmanlı korunuyor: release ortamının etkinleştirilmesi için organizasyon içindeki başka bir yetkili üyenin en az bir manuel onayı gerekiyor. Yani kötü niyetli bir release için, güçlü 2FA kullanan iki hesabın aynı anda ele geçirilmesi gerekiyor.
5. Bağımlılık güvenliği
Dependabot ve Renovate ile bağımlılık güncellemeleri ve bilinen zafiyet bildirimleri yönetilirken, yeni bir release'in hemen ardından anında güncelleme yapmayan bir "cooldown" politikası da birlikte uygulanıyor. Amaç, geçici olarak ele geçirilmiş bağımlılıkların etkisini en aza indirmek. Bu özellik uv içinde yerleşik olarak bulunuyor.
Python Packaging Authority (PyPA), Python Security Response Team gibi yakın projeler ve çalışma gruplarıyla sosyal bağlar korunarak, örneğin pip'e bildirilen bir sorunun uv'yi de etkilemesi gibi durumlarda bilgi paylaşımı sağlanıyor. Yeni bağımlılık eklerken temkinli davranılıyor, binary blob içeren bağımlılıklardan kaçınılıyor ve gereksiz özellikler devre dışı bırakılıyor.
Bağımlı olunan projelerin sürdürülebilirliği için OSS Fund üzerinden mali katkı da sürdürülüyor.
Temel önerilerin özeti
Astral'ın vurguladığı dört temel ilke şöyle: CI/CD'nin sınırlarını kabul edip güvenli şekilde yapılamayan işleri ya bırakmak ya da GitHub App'e ayırmak, uzun ömürlü kimlik bilgilerini mümkün olduğunca ortadan kaldırıp en dar kapsamda izole etmek, dağıtım ortamları, onaylar ve immutable tag'lerle release sürecini güçlendirmek, bağımlılık ağacının tamamının sağlık durumunu sürekli izlemek.
Çıkarımlar
PyPI ve tedarik zinciri güvenliğiyle derin biçimde ilgilenen biri açısından bakıldığında, bu yazı basit bir güvenlik rehberinin ötesinde, açık kaynak ekosisteminin tamamı için güven yapısının nasıl tasarlanacağına dair pratik bir örnek niteliği taşıyor. Özellikle Trusted Publishing, cooldown politikası ve çift onaylı release süreci, ölçekli açık kaynak projeleri için dikkate değer örnekler sunuyor.
Orijinal metin: Astral Blog, 2026.04.08
Henüz yorum yok.