tedarik zinciri
Milyonlarca otomatik yazılım geliştirme süreci, derleme sürecine entegre edilmiş Trivy ve Checkmarx AST gibi güvenlik araçlarına dayanmaktadır. Son zamanlarda modern tarihin en büyük ve en tehlikeli tedarik zinciri saldırılarından birinin giriş noktası haline gelenler, tam da bu güvenilir çözümlerdi. Bu yazıda, otomatikleştirilmiş iş akışlarının denetlenmesi ve kurumsal bulut altyapısının güvenliğini sağlama konularını ele alıyoruz.
Saldırının zaman çizelgesi ve bilinen sonuçları
19 Mart’ta, CI/CD süreçlerinde yaygın olarak kullanılan açık kaynaklı bir güvenlik açığı tarama aracı olan Trivy aracılığıyla başarılı bir hedefli tedarik zinciri saldırısı gerçekleştirildi. TeamPCP olarak bilinen bir grup saldırgan, Trivy ile ilişkili resmi GitHub Actions iş akışlarına ve Docker görüntülerine kötü amaçlı yazılım yerleştirmeyi başardı. Sonuç olarak, gerçekleştirilen her otomatik süreç taraması, saldırıya uğramış sistemlerden SSH anahtarlarını, bulut erişim belirteçlerini, kripto para cüzdanlarını ve diğer değerli verileri çalan kötü amaçlı yazılımları tetikledi. Olayın kritik niteliği göz önüne alındığında, bu olaya CVE-2026-33634 kimlik numarası atandı ve CVSS4B puanı 9,4 olarak belirlendi; bu, maksimum puana çok yakın bir değer.
Aynı günün ilerleyen saatlerinde, Trivy ekibi saldırıyı tespit etti ve dağıtım kanallarından zararlı öğeleri kaldırarak saldırının bu aşamasını durdurdu. Ancak saldırganlar, çok sayıda Trivy kullanıcısının sistemlerine çoktan erişim sağlamıştı.
23 Mart’ta, başka bir uygulama güvenliği aracında da benzer bir durum tespit edildi: Checkmarx KICS için bir GitHub Action ve Checkmarx AST. Üç saat sonra, kötü amaçlı kod oradan da kaldırıldı. TeamPCP, Checkmarx tarafından desteklenen OpenVSX eklentilerini de ele geçirmeyi başardı: cx-dev-assist 1.7.0 ve ast-results. Olayın bu kısmının ne zaman çözüldüğüne dair haberler birbirinden farklı.
24 Mart’ta, Trivy’nin kod tarama özelliğini kullanan popüler bir proje olan LiteLLM yapay zeka ağ geçidi (çeşitli büyük dil modelleri sağlayıcılarına erişim sağlayan evrensel bir kütüphane) saldırıya uğradı. PyPI deposuna yüklenen 1.82.7 ve 1.82.8 sürümleri ele geçirildi. Bu sürümler yaklaşık beş saat boyunca herkesin erişimine açık kaldı.
Ancak saldırının sadece birkaç saat sürmüş olması, onu göz ardı etmek için bir neden değildir. Etkilenen projelerin popülerliği göz önüne alındığında, bu kötü amaçlı kod binlerce kez çalıştırılmış olabilir, hatta çok büyük şirketlerin altyapıları içinde bile.
Bu durum, saldırganların Kubernetes kümelerinde kalıcı arka kapılar kurmasına ve ayrıca JavaScript npm ekosisteminde kendi kendini çoğaltan CanisterWorm‘u yaymasına olanak sağladı.
Saldırganların kodunda, ele geçirilen sistemde Tahran saat dilimini veya ana dil olarak Farsça’yı tespit etmesi durumunda Kubernetes kümesini ve tüm düğümlerini silip yok eden yıkıcı özellikler bulunmaktadır. Diğer bölgelerde ise bu kötü amaçlı yazılım, CanisterWorm’u kullanarak verileri çalmaktadır.
Uzmanlara göre 20.000’den fazla depo, potansiyel olarak güvenlik açığına sahip olarak değerlendiriliyor. Saldırganlar, yüzlerce gigabaytlık veri ve yarım milyondan fazla hesap ele geçirdiklerini iddia ediyorlar.
Trivy Nasıl Saldırıya Uğradı?
Saldırganlar, Trivy’yi ele geçirmek için daha önceki bir olayda çalınan kimlik bilgilerini kullandılar. Şubat ayı sonlarında meydana gelen önceki Trivy saldırısı muhtemelen tam olarak önlenememişti ve saldırganlar (aynı TeamPCP grubu) yeni bir saldırıyla geri döndü. Trivy’nin geliştiricisi Aqua Security, önceki olayın ardından kimlik bilgilerinin kademeli olarak kullanımdan kaldırılmakta olması nedeniyle, saldırganların ele geçirilen eski erişim belirteçleri iptal edilmeden önce kendileri için yeni erişim belirteçleri oluşturabildiklerini tahmin ediyor.
Sonuç olarak, TeamPCP, CI/CD süreçlerinde kullanılan GitHub Actions’ı ele geçirmeyi başardı. Etiket yazma yetkisine sahip kimlik bilgilerini kullanan saldırganlar; aquasecurity/trivy-action üzerindeki 77 sürüm etiketinden 76’sını ve aquasecurity/setup-trivy üzerindeki yedi etiketin tamamını zorla değiştirerek, mevcut güvenilir sürümleri zararlı kod kayıtlarına yönlendirdi. Bu, Shai-Hulud 2.0 saldırı kampanyasında gözlemlenen taktiklere benziyor. Sonuç olarak, dağıtım sürecindeki iş akışları saldırganların kodunu çalıştırmaya başladı; ancak sürüm meta verilerinde gözle görülür bir değişiklik yoktu.
Aynı zamanda saldırganlar, GitHub Releases ve kapsayıcı kayıt defterleri dahil olmak üzere resmi dağıtım kanallarına virüs bulaşmış bir Trivy ikili dosyası (v0.69.4) yayınladılar.
LiteLLM Güvenlik İhlali
Popüler dil modeli erişim aracı LiteLLM’nin güvenliğinin ihlali, bu aracı kullanan projeler zincirinde büyük çaplı bir saldırı dalgasını tetikleyebilir. Saldırı, 24 Mart 2026 tarihinde TeamPCP’nin kütüphanenin kötü amaçlı sürümlerini (1.82.7 ve 1.82.8) PyPI’de doğrudan yayınlamasıyla gerçekleşti. 10:39 UTC ile 16:00 UTC arasında, bu güvenliği ihlal edilmiş paketler, kimlik bilgilerini çalan kötü amaçlı yazılımlar içeriyordu. Bu, proxy_server.py dosyasına yerleşik olarak bulunuyordu ve 1.82.8 sürümünde ayrıca zararlı bir litellm_init dosyası da bulunuyordu. Çalınan veriler, models.litellm[.]cloud sunucusuna aktarıldı.
Sıkı sürüm kilitleme uygulaması sayesinde LiteLLM Cloud veya resmi LiteLLM Proxy Docker görüntüsünü kullanan müşteriler bu durumdan etkilenmezken, belirtilen zaman aralığında pip aracılığıyla sabitlenmemiş sürümleri yükleyen geliştiriciler ve bunlardan yararlanan projeler tehlikeye maruz kaldı.
Üç saat içinde, kötü amaçlı paketler PyPI deposundan kaldırıldı; LiteLLM ekibi ise yeni sürümlerin yayınlanmasını askıya aldı, erişim bilgilerini yeniledi ve harici bir olay müdahale sürecini devreye soktu. Projelerinde LiteLLM kullanan ekiplerin, derhal litellm_init.pth güvenlik ihlali göstergesini kontrol etmeleri ve potansiyel olarak ele geçirilmiş olabilecek tüm gizli bilgileri düzenli aralıklarla değiştirmeleri tavsiye edilir.
TeamPCP Cloud Stealer kötü amaçlı yazılımının özellikleri
Saldırganlar, orijinal işlevselliği koruyarak GitHub Actions ve Trivy yürütülebilir dosyasına yeni kodlar eklediler. Trivy aracılığıyla yapılan güvenlik açığı taraması sonuçları normal görünüyordu, ancak aynı zamanda değerli veriler aranıyor ve çıkarılıyordu. Kötü amaçlı kod şu işlemleri gerçekleştiriyordu:
- Keşif yapmak (ağ verilerini ve ortam değişkenlerini toplamak);
- AWS ve GCP bulut ortamlarına erişmek için belirteçleri ve erişim anahtarlarını aramak;
- Runner.Worker ve Runner.Listener işlemlerinin belleğinde depolanan gizli bilgileri elde etmek için belleği tarama (/proc/*/mem);
- Kubernetes gizli bilgilerini çıkarma (/run/secrets/kubernetes.io/serviceaccount);
- Veri tabanı sunucularına (MySQL, PostgreSQL, MongoDB, Redis, Vault) bağlanmak için veri toplama;
- Ortam dosyaları ve CI/CD yapılandırma dosyalarından (.env, .json, .yml) diğer API anahtarlarını ve gizli bilgileri toplamak;
- Slack ve Discord kanalları için webhook’ları arama;
- Kripto cüzdanlarıyla ilgili verileri aramak (Solana blok zinciriyle ilgili değişkenlerin yanı sıra rpcuser ve rpcpassword verileri).
Toplanan veriler şifrelenerek, Trivy’nin geliştiricilerinin adıyla benzer bir ada sahip bir sunucuya (scan.aquasecurtiy[.]org) yüklendi. Bir yedekleme mekanizması olarak saldırganlar, docs-tpcp adlı bir depoya veri yüklemek için bir yöntem sağladılar.
CheckMarx ve LiteLLM’ye yönelik saldırıda, diğer yazım hatası içeren alan adlarında olduğu gibi benzer bir taktik kullanıldı: models.litellm[.]cloud ve checkmarx[.]zone.
Kötü amaçlı yazılımın ayrıntılı teknik analizi ve güvenlik ihlali göstergeleri, Securelist blogundaki uzmanımızın makalesinde bulunabilir.
CVE-2026-33634 için Müdahale ve Savunma Stratejileri
Kamu kayıt defterlerinde mevcut olan imza tabanlı kontroller ve bağımlılık taramaları artık yeterli değildir; zira kötü amaçlı kod, güvenilir ve imzalanmış eylemlerin içine doğrudan yerleştirilmiş ve davranışsal izleme uygulanana kadar tespit edilememiştir. CI/CD süreçleri, güvenliğin “yeni sınırı” haline gelmiştir.
Acil Önlemler. Tüm iş akışlarında güvenli sürümlerin kullanıldığından emin olun (Trivy ikili dosyası 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6).
CI/CD süreçleri yöneticileri ve güvenlik ekipleri, Checkmarx (kics-github-action, ast-github-action) ve Trivy (setup-trivy ve trivy-action) çözümlerine olan bağımlılıklarını derhal gözden geçirmelidir. İş akışları belirli bir SHA karma değeri yerine bir sürüm etiketine atıfta bulunuyorsa, aktif tedarik zinciri saldırısının sürdüğü süre boyunca iş akışı yürütme günlüklerinizi dikkatle inceleyin.
Ayrıca, ağ günlüklerinizi kontrol ederek scan.aquasecurtiy[.]org, checkmarx[.]zone ve models.litellm[.]cloud alan adlarına yönelik trafiği de kontrol etmelisiniz. Bu tür bir trafiğin varlığı, hassas verilerin başarıyla sızdırıldığını gösterir.
Kuruluşun GitHub’ında “docs-tpcp” adlı bir depo ortaya çıkmışsa, bu durum bir veri ihlalinin gerçekleştiğini de gösterebilir.
Ana bilgisayarları ve kümeleri güvenlik ihlali belirtileri açısından kontrol edin: ~/.config/sysmon/sysmon.py dosyalarının varlığı, Kubernetes’teki şüpheli pod’lar.
Önbelleği temizleyin ve PyPI modüllerinin bir envanterini çıkarın; zararlı modülleri kontrol edin ve temiz sürümlerine geri dönün.
Her halükarda, sistemlerin ele geçirildiği ve saldırganların etkilenen sistemler içinde hızla ilerlediği varsayımıyla, proaktif bir Tehdit Avcılığı gerçekleştirilmelidir.
Etkilenen ortamların, doğrulanmış yedeklemelerden geri yüklenmesi tavsiye edilir.
Bağımlılık sabitleme ve gizli bilgi yönetimi. Tüm süreçlerde ve Docker dosyalarında bağımlılık sürümlerinin kriptografik karma değerleri kullanılarak sabitlendiğinden emin olun. Bir gizli bilgi yönetimi aracı kullanarak uzun ömürlü belirteçlerden kısa ömürlü kimlik bilgilerine geçiş yapmanızı ve desteklenen durumlarda OIDC entegrasyonlarını hayata geçirmenizi öneririz. Çalışma zamanı ortamına gizli bilgilerin aktarılmasını en aza indirin ve bunu yalnızca kesinlikle gerekli olduğunda yapın. Gizli bilgilerin diskte veya geçici dosyalarda saklanmadığından ve farklı işlemler arasında yeniden kullanılmadığından emin olun.
Güvenliği ihlal edilmiş olabilecek tüm kimlik bilgilerini (API anahtarları, ortam değişkenleri, SSH anahtarları, Kubernetes hizmet hesabı belirteçleri ve diğer gizli bilgiler) düzenli aralıklarla değiştirin.
Diğer güvenlik önlemleri. Yalnızca kuruluş tarafından onaylanan listede yer alan GitHub Actions işlemlerine izin verin; yeni ve doğrulanmamış işlemleri engelleyin. GITHUB_TOKEN ve diğer erişim anahtarlarını en az ayrıcalık ilkesine uygun olarak yapılandırın. Kesinlikle gerekli olmadıkça yazma izni vermeyin.
GitHub Actions’ın güvenliğini artırmak için çeşitli açık kaynaklı araçlar mevcuttur:
- zizmor – GitHub Actions’da statik analiz ve yapılandırma hatalarının tespitine yönelik bir araç;
- gato ve Gato-X – yapısal açıdan zayıf süreçleri tespit etmeye yardımcı olan bir aracın iki sürümü;
- allstar – OpenSSF tarafından geliştirilen, GitHub kuruluşlarında ve depolarında güvenlik ilkelerini yapılandırmak ve uygulamak için kullanılan bir GitHub uygulaması.
Tedarik zinciri saldırıları hakkında daha fazla bilgi edinmek isterseniz, Tedarik Zinciri Reaksiyonu: Karşılıklı Bağımlılık Çağında Küresel Dijital Ekosistemin Güvenliği başlıklı analiz raporumuzu incelemenizi öneririz. Bu rapor, teknik uzmanların görüşlerine dayanmaktadır ve kuruluşların tedarik zinciri ve güvenilir ilişkilerle ilgili risklerle ne sıklıkla karşılaştıklarını, hangi alanlarda koruma eksiklikleri bulunduğunu ve bu tür tehditlere karşı dayanıklılığı artırmak için hangi stratejilerin uygulanması gerektiğini ortaya koymaktadır.
İpuçları