Google, geliştirme altyapısını kod yazma, test etme, bir ürünü birleştirme ve dağıtma aşamasında gerçekleştirilen saldırılara karşı koruma konusunda mevcut deneyimi özetleyen SLSA (Yazılım Yapıları için Tedarik Zinciri Düzeyleri) çerçevesini tanıttı.
Geliştirme süreçleri giderek daha karmaşık hale geliyor ve üçüncü taraf araçlara bağımlı hale geliyor; bu da nihai üründeki güvenlik açıklarının belirlenmesi ve kullanılmasıyla değil, geliştirme sürecinin kendisinden ödün verilmesiyle ilgili saldırıların ilerlemesi için uygun koşullar yaratıyor (tedarik zinciri saldırıları, genellikle kod yazma sürecinde kötü niyetli değişiklikler yapılması, dağıtılmış bileşenlerin ve bağımlılıkların değiştirilmesi).
Çerçeve, ürünün kod geliştirme, birleştirme, test etme ve dağıtma aşamasında kötü niyetli değişiklik yapma tehdidiyle ilgili 8 tür saldırıyı dikkate alır.
- A. Kaynak kodunda, güvenlik açıklarına yol açan arka kapılar veya gizli hatalar içeren değişiklikler dahil.
Saldırı örneği: “Hypocrite Commits” - güvenlik açıkları içeren yamaları Linux çekirdeğine tanıtma girişimi.
Önerilen güvenlik yöntemi: her değişikliğin iki geliştirici tarafından bağımsız olarak incelenmesi.
- B. Kaynak kodu kontrol platformunun tehlikeye atılması.
Saldırı örneği: geliştirici şifreleri sızdırıldıktan sonra bir PHP projesinin Git deposuna arka kapıyla kötü niyetli taahhütlerin enjekte edilmesi.
Önerilen koruma yöntemi: Kod yönetimi platformunun artan güvenliği (PHP durumunda, saldırı, az kullanılan bir HTTPS arayüzü üzerinden gerçekleştirildi; bu, SSH anahtarını kontrol etmeden şifre kullanarak giriş yaparken değişikliklerin gönderilmesine izin verdi. güvenilmez MD5'in şifreleri karıştırmak için kullanıldığı gerçeği).
- C. Kodun build veya sürekli entegrasyon sistemine aktarılması aşamasında değişiklik yapılması (depodaki kodla eşleşmeyen kod build edilir).
Saldırı örneği: Yapı altyapısında değişiklikler yaparak Webmin'e bir arka kapı enjekte edilmesi, bunun sonucunda depodaki dosyalardan farklı kod dosyalarının kullanılması.
Önerilen koruma yöntemi: Bütünlüğün kontrol edilmesi ve derleme sunucusundaki kodun kaynağının belirlenmesi.
- D. Montaj platformunun tehlikeye atılması.
Saldırı örneği: SolarWinds Orion ürününe montaj aşamasında bir arka kapı kurulumunun sağlandığı SolarWinds saldırısı.
Önerilen koruma yöntemi: montaj platformu için gelişmiş güvenlik önlemlerinin uygulanması.
- E. Düşük kaliteli bağımlılıklar yoluyla kötü amaçlı kodun teşvik edilmesi.
Bir saldırı örneği: zararsız bir bağımlılık ekleyerek ve ardından bu bağımlılığın güncellemelerinden birine kötü amaçlı kod ekleyerek popüler olay akışı kitaplığına bir arka kapının sokulması (kötü amaçlı değişiklik git deposuna yansıtılmadı, ancak yalnızca tamamlanmış MNP paketinde mevcuttur).
Önerilen koruma yöntemi: SLSA gerekliliklerini tüm bağımlılıklara yinelemeli olarak uygulayın (olay akışı durumunda kontrol, ana Git deposunun içeriğine karşılık gelmeyen kod derlemesini ortaya çıkaracaktır).
- F. CI/CD sisteminde oluşturulmayan yapıtların yüklenmesi.
Saldırı örneği: CodeCov betiğine, saldırganların müşterinin sürekli entegrasyon sistemi ortamlarında depolanan bilgileri çıkarmasına olanak tanıyan kötü amaçlı kod eklenmesi.
Önerilen koruma yöntemi: eserlerin kaynağı ve bütünlüğü üzerinde kontrol (CodeCov durumunda, codecov.io web sitesinden gönderilen Bash Uploader komut dosyasının proje deposundaki kodla eşleşmediği ortaya çıkabilir).
- G. Paket deposunun tehlikeye atılması.
Saldırı örneği: Araştırmacılar, kötü amaçlı paketleri dağıtmak için bazı popüler paket depolarının aynalarını dağıtmayı başardılar.
Önerilen koruma yöntemi: Dağıtılmış yapıtların bildirilen kaynak kodlarından derlendiğinin doğrulanması.
- H. Yanlış paketi kurarak kullanıcının kafasını karıştırmak.
Saldırı örneği: yazım açısından popüler uygulamalara benzer paketleri depolara yerleştirmek için yazım hatası (NPM, RubyGems, PyPI) kullanmak (örneğin, kahve betiği yerine kahve betiği).
İşaretlenen tehditleri engellemek için SLSA, denetim meta verilerinin oluşturulmasını otomatikleştirmeye yönelik araçların yanı sıra bir dizi öneri sunar. SLSA, yaygın saldırı yöntemlerini özetlemekte ve güvenlik katmanları kavramını tanıtmaktadır. Her seviye, geliştirmede kullanılan yapıtların bütünlüğünü sağlamak için belirli altyapı gereksinimleri getirir. Desteklenen SLSA düzeyi ne kadar yüksek olursa, o kadar fazla koruma uygulanır ve altyapı yaygın saldırılara karşı o kadar iyi korunur.
- SLSA 1, derleme sürecinin tamamen otomatik olmasını ve kaynaklar, bağımlılıklar ve derleme süreci hakkındaki bilgiler de dahil olmak üzere yapıtların nasıl oluşturulduğuna ilişkin meta veriler ("kaynak") oluşturmasını gerektirir (denetim için örnek bir meta veri oluşturucu GitHub Eylemleri için sağlanmıştır). SLSA 1, kötü niyetli değişikliklere karşı koruma öğeleri içermez; bunun yerine yalnızca kodu tanımlar ve güvenlik açığı yönetimi ve risk analizi için meta veriler sağlar.
- SLSA 2 - kimliği doğrulanmış meta veriler üreten sürüm kontrolü ve derleme hizmetlerinin kullanımını gerektirerek birinci düzeyi genişletir. SLSA 2'nin kullanılması, kodun kökenini izlemenize olanak tanır ve güvenilir derleme hizmetlerinde kodda yetkisiz değişiklik yapılmasını önler.
- SLSA 3 - kaynak kodun ve derleme platformunun, kodu denetleme ve sağlanan meta verilerin bütünlüğünü sağlama yeteneğini garanti eden standartların gereksinimlerini karşıladığını doğrular. Denetçilerin platformları standartların gerekliliklerine göre sertifikalandırabilecekleri varsayılmaktadır.
- SLSA 4, önceki seviyeleri aşağıdaki gereksinimlerle tamamlayan en yüksek seviyedir:
- Tüm değişikliklerin iki farklı geliştirici tarafından zorunlu olarak incelenmesi.
- Tüm derleme adımları, kodlar ve bağımlılıklar tam olarak bildirilmeli, tüm bağımlılıklar ayrı ayrı çıkarılıp doğrulanmalı ve derleme işlemi çevrimdışı gerçekleştirilmelidir.
- Tekrarlanabilir bir derleme süreci kullanmak, derleme sürecini kendiniz tekrarlamanıza ve yürütülebilir dosyanın sağlanan kaynak koddan oluşturulduğundan emin olmanıza olanak tanır.
Kaynak: opennet.ru