Güvenlik dünyasında son yılların en çarpıcı olaylarından biri, çok kısa bir süre önce, Mart 2026’da yaşandı. Aqua Security’nin açık kaynak güvenlik tarayıcısı Trivy, sofistike bir tedarik zinciri saldırısının hedefi oldu. Olayın dikkat çekici yanı şuydu: saldırganlar kaynak koda tek bir satır bile dokunmadı. Bunun yerine build pipeline’ını — yani yazılımın derleme ve dağıtım sürecini — ele geçirerek çok daha sinsi bir yol izledi.
Ne Oldu?
Şubat 2026’nın sonlarına doğru saldırganlar, Trivy’nin GitHub Actions ortamındaki bir yanlış yapılandırmayı keşfetti. Ekim 2025’ten beri var olan bu yapılandırma hatası, harici pull request’lerin tetiklediği iş akışlarının depo gizli anahtarlarına (repository secrets) erişmesine olanak tanıyordu. Saldırganlar bu açıktan faydalanarak ayrıcalıklı bir erişim token’ı elde etti ve depo otomasyon süreçlerinde bir dayanak noktası oluşturdu.
1 Mart’ta Trivy ekibi durumu fark etti ve kimlik bilgilerini sıfırlamaya çalıştı. Ancak burada kritik bir hata yapıldı: kimlik bilgisi rotasyonu atomik şekilde gerçekleştirilmedi. Tüm anahtarlar eş zamanlı olarak iptal edilmek yerine aşamalı bir süreçte değiştirildi. Bu birkaç günlük pencere, saldırganlara yeni oluşturulan anahtarları da çalmak için yeterli zamanı verdi.
19 Mart 2026’da asıl darbe geldi. Saldırganlar ele geçirdikleri kimlik bilgilerini kullanarak üç eşzamanlı hamle yaptı:
Birincisi, `aquasecurity/trivy-action` deposundaki 77 sürüm etiketinden 76’sını force-push ile değiştirerek zararlı yazılım içeren commit’lere yönlendirdi. İkincisi, `aquasecurity/setup-trivy` deposundaki 7 etiketin tamamını kötü amaçlı commit’lerle değiştirdi. Üçüncüsü, ele geçirilen `aqua-bot` hizmet hesabı üzerinden release otomasyonunu tetikleyerek zararlı Trivy v0.69.4 sürümünü yayınladı.
Saldırganların yöntemindeki inceliğe dikkat edin: git tag repointing. Yani mevcut sürüm etiketlerini geriye dönük olarak zehirleyerek, güvenilir referansları kötü amaçlı commit’lere yönlendirdiler. CI/CD pipeline’larında `trivy-action@v1` gibi etiket bazlı referans kullanan herkes, farkında olmadan zararlı kodu çalıştırmaya başladı.
Zararlı Yazılım Ne Yapıyordu?
Burada işler gerçekten ürkütücü bir hal alıyor. Zararlı kod, meşru Trivy taramasından önce çalışıyor ve sistemdeki ortam değişkenlerini, kimlik bilgilerini tarayarak şifreliyordu. Hedeflenen veriler arasında AWS, GCP ve Azure bulut kimlik bilgileri, SSH anahtarları, Kubernetes token’ları, Docker yapılandırma dosyaları ve Git kimlik bilgileri yer alıyordu. Toplanan tüm bu hassas bilgiler, saldırganların kontrol ettiği `scan.aquasecurtiy[.]org` adresine HTTP POST isteğiyle gönderiliyordu. Alan adındaki yazım hatasına dikkat edin — “aquasecurity” yerine “aquasecurtiy” kullanılmış; klasik bir typosquatting taktiği.
İşin en kötü tarafı şuydu: zararlı kod çalıştıktan sonra meşru Trivy taraması da normal şekilde tamamlanıyordu. Yani pipeline çıktılarına bakan bir mühendis, her şeyin yolunda gittiğini düşünüyordu. Sessiz, görünmez ve son derece etkili bir saldırıydı bu.
22 Mart’ta saldırı genişledi. Docker Hub’da zararlı v0.69.5 ve v0.69.6 imajları yayınlandı. Çalınan kimlik bilgileri kullanılarak düzinelerce npm paketi ele geçirildi ve CanisterWorm adlı kendi kendine yayılan bir solucan dağıtıldı.
Olay CVE-2026-33634 tanımlayıcısıyla izleniyor ve CVSS skoru 9.4 — yani kritik seviyede.
Kaynak Koda Dokunmadan Nasıl Bu Kadar Hasar Verildi?
Bu saldırının bize öğrettiği en önemli ders şu: modern yazılım tedarik zincirinde kaynak kod, buz dağının sadece görünen kısmı. Build pipeline’ları, CI/CD iş akışları, release otomasyonu, paket kayıt defteri kimlik bilgileri — bunların hepsi saldırı yüzeyinin bir parçası.
Kaynak kodu inceleyen biri hiçbir anormallik göremezdi. Kodun kendisi temizdi. Sorun, kodun nasıl derlenip dağıtıldığındaydı. Bu durum, geleneksel kod inceleme süreçlerinin tek başına yeterli olmadığını acı bir şekilde ortaya koyuyor.
Düşünün: binlerce organizasyon Trivy’yi CI/CD pipeline’larında güvenlik tarayıcısı olarak kullanıyordu. Güvenlik tarayıcısının kendisi bir silaha dönüştü. Güvenlik aracınıza güveniyorsunuz, ama o güvenlik aracının build süreci ele geçirilmiş. Bu, bir nevi itfaiyecinin kundakçı olması gibi bir şey.
Chainguard Müşterileri Neden Etkilenmedi?
Şimdi gelelim kritik soruya. ENC Teknoloji olarak Chainguard müşterilerimiz bu saldırıdan neden etkilenmedi?
Cevap, Chainguard’ın yazılımı nasıl inşa ettiğiyle doğrudan ilgili. Chainguard Factory, Trivy’yi doğrudan uygulama kaynak kodundan derliyor. Upstream’den önceden derlenmiş artifact’ler tüketmiyor. Trivy’nin kaynak kodu ele geçirilmediği için — sadece build ve release iş akışı ele geçirildiği için — Chainguard’ın bağımsız build pipeline’ı temiz bir imaj üretti.
Bu yaklaşımın altında yatan felsefe basit ama güçlü: upstream projenin dağıttığı binary’ye, Docker imajına veya GitHub Action’a güvenmek yerine, kaynak kodu alıp kendi kontrollü ortamınızda sıfırdan derleyin. Böylece derleme süreci boyunca ne olduğunu bilirsiniz.
Chainguard Factory 2.0 ve DriftlessAF altyapısı bu prensibi daha da ileri taşıyor. Her imaj, her gece kaynak koddan yeniden derleniyor. Yapay zeka destekli reconciliation bot’ları, bağımlılık güncellemelerini ve güvenlik açığı bazlı yeniden derlemeleri otomatik olarak tetikliyor. Her imaj imzalanıyor, provenance attestation’ları ve SBOM’larla birlikte sunuluyor.
Bir de şöyle düşünelim: Trivy saldırısında saldırganlar Docker Hub’daki imajları ve GitHub’daki Action etiketlerini zehirledi. Upstream artifact’leri doğrudan kullanan herkes etkilendi. Ama Chainguard müşterileri zaten bu artifact’leri kullanmıyordu. Kendi bağımsız build süreçlerinden geçmiş, imzalanmış ve doğrulanmış imajları kullanıyorlardı.
Buradan Çıkarılacak Dersler
Bu olay, yazılım tedarik zinciri güvenliğinde birkaç kritik noktayı bir kez daha gözler önüne serdi.
İlk olarak, GitHub Actions iş akışlarınızdaki izin modelini sıkılaştırın. Harici pull request’lerin tetiklediği iş akışlarının depo gizli anahtarlarına erişimi olmamalı. Trivy’deki bu yapılandırma hatası aylar boyunca fark edilmedi.
İkinci olarak, kimlik bilgisi rotasyonunu atomik yapın. Trivy ekibinin yaptığı en büyük hata, rotasyonu aşamalı gerçekleştirmesiydi. Tüm kimlik bilgileri eş zamanlı olarak geçersiz kılınmalı ve yenileriyle değiştirilmeliydi.
Üçüncü olarak, etiket bazlı referanslar yerine SHA bazlı sabitleme kullanın. `trivy-action@v1` yerine `trivy-action@abc123def` gibi belirli bir commit hash’ine bağlanmak, tag repointing saldırılarına karşı koruma sağlar.
Ve son olarak, belki de en önemlisi: upstream binary’lere körü körüne güvenmeyin. Kaynak koddan derleme yapabilen, her adımı doğrulanabilir ve tekrarlanabilir bir build pipeline’ına sahip olmak, bu tür saldırılara karşı en etkili savunma hattıdır. Chainguard’ın yaklaşımının bu saldırıda işe yaramasının nedeni tam olarak budur.
Trivy olayı, açık kaynak ekosisteminin ne kadar birbirine bağlı olduğunu ve bir noktadaki kırılganlığın nasıl domino etkisi yarattığını gösteriyor. Güvenlik tarayıcınız bile güvenli olmayabilir — önemli olan, yazılımınızın tüm yaşam döngüsünü kontrol edebilmeniz ve her aşamada doğrulama yapabilmenizdir.
ENC Teknoloji olarak; Chainguard kullanan müşterilerimize bu güvenceyi sunabilmenin haklı gururunu yaşıyoruz. Tedarik zinciri güvenliğinizi bir üst seviyeye taşımak istiyorsanız, bizimle iletişime geçin.
Chainguard
kurulum, göç ve danışmanlığı
Deneyimli ekibimizle Chainguard çözümleri kurulum, göç ve danışmanlık hizmetlerimizle sizlerin yanındayız.
Chainguard çözümlerinden abonelik ve kurumsal destek almak mı istiyorsunuz?
