Google Threat Intelligence, yazılım tedarik zinciri güvenliğine ilişkin rehberinde savunmanın yalnızca kaynak kodu ve paket taramasına dayandırılmaması gerektiğini vurguluyor. Kaynağa göre saldırganlar, geliştirme ve derleme süreçlerinde yüksek yetkilerle çalışan güvenilir araçları hedef alıyor; etkili koruma ise geliştirici uç noktalarından üretim ortamına kadar uzanan sürekli denetim ve yalıtım gerektiriyor.
Google’ın değerlendirmesinde güvenlik tarayıcıları, yardımcı kütüphaneler ve yapay zekâ destekli geliştirici araçları, mühendislik yaşam döngüsüne erişim sağlayabilecek hedefler arasında bulunuyor. Rehber, bu araçlara verilen yetkilerin saldırganlar açısından önemine dikkat çekiyor. Önerilen yaklaşım, geliştirme sürecindeki her bileşeni ayrı ayrı korumakla yetinmek yerine, bileşenler arasındaki güven ilişkilerini ve erişim yollarını birlikte ele almak.
Saldırı odağı: Kimlik bilgilerinden derleme sürecine
Google’ın dikkat çektiği teknikler
Google Threat Intelligence’a göre saldırı teknikleri, çalınmış statik kimlik bilgilerinin kullanılmasının ötesine geçiyor. Rehberde GitHub Actions önbelleğinin zehirlenmesi, OpenID Connect (OIDC) belirteçlerinin ele geçirilmesi ve değiştirilebilir action etiketlerinin kötüye kullanılması örnek gösteriliyor. Kaynak, bu yöntemleri derleme hattının kendisine müdahale edilmesi bağlamında değerlendiriyor.
Google, söz konusu müdahalelerin meşru kriptografik köken bilgisi taşımaya devam eden, ancak içeriği saldırgan tarafından değiştirilmiş paketlerin yayımlanmasına yol açabildiğini belirtiyor. Bu nedenle rehberde köken doğrulaması tek başına bir güvenlik çözümü olarak sunulmuyor; kimlik, bağımlılık, çalıştırma ortamı ve yayınlama denetimleriyle birlikte ele alınıyor.
Google’ın savunma yaklaşımında temel hedef, bir ihlalin geliştirme yaşam döngüsü boyunca yayılmasını önlemek. Kaynak, yalnızca belirli anlarda yapılan güvenlik taramalarını ve geleneksel erişim kontrollerini yetersiz buluyor; ilk kod değişikliğinden üretime dağıtıma kadar otomatik doğrulama ve politika uygulamasını öne çıkarıyor.
Geliştirici cihazları ve kimlik yaşam döngüsü
Google’a göre geliştirici iş istasyonları; kod depolarına, derleme hatlarına ve bulut ortamlarına ayrıcalıklı erişim taşıdıkları için yüksek değerli hedefler. Kaynak, entegre geliştirme ortamları üzerinden kişisel erişim belirteçlerinin (PAT), SSH anahtarlarının ve kuruma ait kodun toplanmasına dikkat çekiyor. Uç nokta algılama ve müdahale (EDR) araçlarının güvenilir geliştirme uygulamalarının süreç ağaçlarını izlemesi; olağandışı dosya erişimini, beklenmedik süreç başlatılmasını ve yetkisiz dış ağ bağlantılarını takip etmesi öneriliyor.
Rehber, geliştirme faaliyetlerinin mümkün olduğunda konteyner tabanlı ortamlara veya ayrılmış sanal makinelere taşınmasını öneriyor. Google’ın burada amaçladığı koruma, kötü amaçlı kurulum sonrası betiklerin ve zehirlenmiş bağımlılıkların ana sistem üzerindeki etkisini sınırlamak. Hassas ana makine dizinlerinin çalışma konteynerlerine bağlanmasının kısıtlanması, sanal makinelerin merkezi olarak sertleştirilmiş temel imajlardan oluşturulması ve canlı üretim ağlarından ayrılması da bu yaklaşımın parçaları. Kaynak ayrıca bu ortamlardaki çalıştırma ve ağ etkinliklerinin merkezi kurumsal günlüklere aktarılmasını tavsiye ediyor.
Kimlik tarafında Google, erişim verilmeden önce cihazın güvenlik durumunu değerlendiren koşullu erişim politikaları ile kullanıcı API etkinliğinin izlenmesini öneriyor. Kimlik bilgilerinin otomatik yenilenmesi, ihtiyaç anında temin edilmesi ve belirteçlerin geçerlilik süresinin sınırlandırılması da rehberde yer alıyor. Geliştirici erişimi için kaynak, yerel sistemde saklanan statik parolalara benzettiği PAT kullanımından uzaklaşılarak donanım destekli güvenlik anahtarlarıyla korunan SSH tabanlı kimlik doğrulamaya geçilmesini tavsiye ediyor.
Bağımlılıklar: Yeni sürümü hemen almak yerine denetlemek
Google Threat Intelligence, internetten indirilen betiklerin incelenmeden doğrudan kabukta çalıştırıldığı “curl to bash” uygulamalarının engellenmesini öneriyor. Bunun yerine açık SHA-256 özetleriyle belirtilen üretici konteynerlerinin kullanılması tavsiye ediliyor. Rehber ayrıca Yazılım Bileşen Analizi (SCA) sonuçlarının, savunmasız kodun uygulamanın yürütme yolunda gerçekten kullanılıp kullanılmadığını değerlendiren erişilebilirlik analiziyle birlikte ele alınmasını istiyor. Derlemelerde yazılım malzeme listesi (SBOM) oluşturulması ve SLSA Seviye 2 veya üzeri köken denetimlerinin uygulanması da öneriler arasında.
Rehberin somut önerilerinden biri, kamuya açık paketlerin yeni sürümleri kurulabilir hâle gelmeden önce en az yedi gün bekletilmesi. Google, kötü amaçlı açık kaynak paketlerin yayımlandıktan kısa süre sonra topluluk tarafından tespit edilip kaldırılabildiğini belirterek bu aralığı bir risk azaltma önlemi olarak sunuyor. Kaynağa göre bekleme politikası merkezi paket depolarında veya yerel yapılandırmalarda uygulanabilir; amaç, zehirlenmiş sürümlerin kurum içi derlemelere hemen ulaşmasını engellemek.
Google, konteyner imajları ve üçüncü taraf bağımlılıklarının hem kayıt deposu katmanında hem çalışma zamanında otomatik taranmasını, saklanan yazılım çıktılarının da yeni açıklar ortaya çıktıkça yeniden değerlendirilmesini öneriyor. Bulguların önceliklendirilmesinde erişilebilirlik analizinin yanı sıra CISA’nın Bilinen İstismar Edilen Güvenlik Açıkları (KEV) kataloğu gibi gerçek dünyadaki istismar sinyallerine başvurulması tavsiye ediliyor. Kaynak, uygulanabilir olmayan bulguların ayıklanması ve uyarı yükünün azaltılması için VEX bildirimlerinin kullanılmasını da öneriyor.
Derleme altyapısında kalıcılığı ve yayınlama yetkisini sınırlamak
Google’a göre CI/CD altyapısında temel savunma hedeflerinden biri, saldırganın iş çalıştırıcılarında kalıcı erişim elde etmesini önlemek. Rehber, her görevin yeni ve yalıtılmış bir ortamda yürütüldüğü, tamamlandığında ortamın otomatik olarak yok edildiği geçici, tek kullanımlık runner mimarisini öneriyor. Kaynak, bu yaklaşımı görevler arasında bulaşmayı ve kalıcı tutunma noktalarını sınırlayan bir önlem olarak değerlendiriyor.
Kurumun kendi yönettiği çalıştırıcılarda Google, yalıtımın ağ katmanına da taşınmasını tavsiye ediyor. Dışarı yönlü trafiğin önceden onaylanmış paket depoları ve kod deposu API’leriyle sınırlandırılması, veri sızdırma riskini azaltmak için öneriliyor. Rehber ayrıca Poisoned Pipeline Execution (PPE) riskine karşı, incelenmemiş pull request kodunun gizli bilgilere erişiminin engellenmesini vurguluyor.
Yayınlama aşamasında Google, uzun ömürlü paket deposu belirteçlerini tedarik zinciri olaylarında tekrar eden bir risk kaynağı olarak tanımlıyor: Çalınan bir belirteç, güvenilir bir ad altında zehirlenmiş sürüm yayımlamak için kullanılabiliyor. Kaynak, mümkün olan yerlerde bu statik belirteçlerin, yayın anında belirli bir derleme iş akışına verilen kısa ömürlü ve kimliğe bağlı belirteçlerle değiştirilmesini öneriyor.
Çalışma zamanı koruması da savunmanın parçası
Google’ın yaklaşımı derlemenin tamamlanmasıyla bitmiyor. Rehber, çalışan uygulamalar ve konteynerler üzerinde yürütme alanını sınırlayan korumalar öneriyor; SQL enjeksiyonu gibi girişimler için Runtime Application Self-Protection (RASP), yapay zekâ iş yüklerinde istem enjeksiyonu ve güvenlik kısıtlarını aşma girişimleri için çalışma zamanı koruyucularını örnek veriyor. Uygulama katmanı trafiğini inceleyen web uygulaması güvenlik duvarları (WAF) da kötü amaçlı istekleri arka uç hizmetlerine ulaşmadan süzmek amacıyla önerilen kontroller arasında.
Kaynaklar ve doğrulama
- Google Threat Intelligenceprimary