TeamPCP Vakası: Açık Kaynak Tedarik Zincirinde Güven Nasıl Kırılıyor

Ne Oldu?

Avustralya Federal Polisi (AFP), 26 Ağustos 2026'da TeamPCP adlı siber suç örgütüyle bağlantılı oldukları iddia edilen iki Batı Avustralyalı hakkında toplam 14 suçlama yöneltti. Her iki şüpheli de ertesi gün Perth Sulh Mahkemesi'ne çıkarıldı. AFP'nin resmi açıklamasında isimleri paylaşılmayan şüpheliler, 21 yaşındaki bir Cottesloe sakini ve 23 yaşındaki bir Mandurah sakini olarak tanımlandı.

AFP ve Batı Avustralya Polis Teşkilatı, Cottesloe, Hamilton Hill ve Mandurah'taki adreslerde arama yaptı ve adli inceleme için elektronik cihazlara el koydu. Polis, iki şüphelinin örgütün faaliyetlerinde önemli roller üstlendiğini ve bunun karşılığında kripto para ile ödeme aldığını ileri sürüyor. Ödeme tutarına ilişkin inceleme devam ediyor.

21 yaşındaki şüpheli hakkında sekiz, 23 yaşındaki şüpheli hakkında ise altı suçlama bulunuyor. Her iki şüpheliye de bilgisayar suçu işlemek amacıyla veri bulundurma, ciddi bir suç işlemek amacıyla verileri yetkisiz biçimde değiştirme ve bilgisayar suçunda kullanılmak üzere veri sağlama suçlamaları yöneltildi. Bunlar için öngörülen azami hapis cezaları üç ile beş yıl arasında değişiyor.

21 yaşındaki şüpheli ayrıca Crimes Act 1914 kapsamındaki bir 3LA emrine uymamak ve değeri 100.000 Avustralya doları veya üzerinde olan suç geliriyle işlem yapmakla suçlandı. Bu suçlamalar için öngörülen azami hapis cezaları sırasıyla 10 ve 20 yıl. Dolayısıyla kanuni ceza üst sınırı bakımından en ağır suçlama, suç geliriyle işlem yapma iddiası. AFP açıklamasında suçlamalar Trivy, Checkmarx KICS veya LiteLLM gibi belirli projelerle ayrı ayrı eşleştirilmiyor. Yargılama devam ettiği için bütün suçlamalar bu aşamada iddia niteliğinde.

Saldırı Nasıl İşledi?

TeamPCP kampanyası, saldırganların tek tek kurumların dış sistemlerini hedeflemesi yerine, binlerce geliştirme sürecinde güvenilerek kullanılan yazılım bileşenlerine yönelmesiyle büyüdü. Zararlı kod GitHub Actions, Docker Hub, npm, PyPI ve OpenVSX gibi meşru dağıtım kanalları üzerinden yayıldı. Böylece saldırganlar, ele geçirdikleri projenin kullanıcılarına doğrudan saldırmak zorunda kalmadan, ilgili bileşeni kullanan CI/CD süreçlerinde kod çalıştırabildi.

Zincirin ilk önemli halkası Trivy oldu. Aqua Security'nin olay açıklamasına göre saldırganlar, Şubat ayı sonunda Trivy'nin GitHub Actions ortamındaki bir yapılandırma hatasından yararlanarak yetkili bir erişim token'ı elde etti. Olayın ardından yapılan kimlik bilgisi rotasyonunun bütün erişim yollarını kapatmaması, saldırganların geçerli kimlik bilgileriyle yeniden erişim sağlamasına imkan tanıdı. 19 Mart'ta Trivy'ye ait çok sayıda sürüm etiketi zararlı kodu gösterecek biçimde değiştirildi ve resmi yayın süreçleri üzerinden zararlı çıktılar yayımlandı.

Sonraki aşamada Checkmarx KICS ve AST GitHub Actions iş akışları ile bazı OpenVSX eklentileri hedef alındı. Checkmarx'ın açıklamasına göre saldırganlar resmi dağıtım kanallarına zararlı sürümler yerleştirdi. Unit 42, bu aşamada çalınmış GitHub erişim token'larının kullanıldığını belirtiyor.

24 Mart'ta bu kez LiteLLM'in 1.82.7 ve 1.82.8 sürümleri PyPI üzerinde yetkisiz biçimde yayımlandı. LiteLLM, farklı büyük dil modeli sağlayıcılarına gönderilen istekleri yöneten açık kaynak bir yapay zeka ağ geçididir. Bu nedenle çalıştığı ortamlarda model sağlayıcılarına ait API anahtarları, bulut erişim bilgileri ve başka kritik kimlik bilgileri bulunabilir.

LiteLLM'in olay açıklaması, saldırının CI/CD güvenlik taramasında kullanılan Trivy bağımlılığıyla bağlantılı olabileceğini belirtiyor. CloudSEK ve Unit 42 de Trivy'den LiteLLM'e uzanan bu ilişkiyi destekliyor. Bununla birlikte hangi CI/CD çalıştırıcısının zararlı Trivy sürümünü çalıştırdığı, hangi yayın bilgisinin ele geçirildiği ve aynı bilginin PyPI yüklemesinde nasıl kullanıldığına ilişkin tüm adli kayıtlar kamuya açıklanmış değil. Bu nedenle saldırı zincirinin genel yönü güçlü bulgularla desteklense de her teknik adımı kesinleşmiş bir olay dizisi gibi sunmamak gerekiyor.

Etki Büyüklüğü Ne Kadar?

AFP, zararlı kodun dünya genelinde 1.000'den fazla kuruluşu potansiyel olarak etkilediğini, 500.000'den fazla kimlik bilgisinin çalınmasını mümkün kıldığını ve en az 300 GB verinin dışarı çıkarıldığını açıkladı. Bu rakamlar kampanyanın muhtemel toplam etkisine ilişkin kolluk kuvveti değerlendirmesini yansıtıyor. Her kuruluşta aynı düzeyde bir ihlal yaşandığını veya açıklanan bütün verilerin bağımsız olarak doğrulandığını göstermiyor.

Unit 42, Mart ayında aynı büyüklükteki rakamları aktarırken saldırganın bu miktarda veri ve kimlik bilgisi sızdırmış olabileceğini belirten daha ihtiyatlı bir dil kullanmıştı. Mart ayı sonu itibarıyla TeamPCP'nin bağlantılı olduğu sızıntı sitesinde en az 16 kuruluş yer alıyordu. Bu sayı da kampanyanın bağımsız olarak doğrulanmış toplam mağdur sayısı olarak değerlendirilmemeli.

Ağustos ayında yayımlanan araştırmalar, olayın ölçeğine ilişkin farklı veri kümeleri ortaya koydu. CloudSEK, yeniden yapılandırdığı maruziyet verisinde 2.500'den fazla kuruluş ve yaklaşık 434.000 CI/CD hattı bulunduğunu açıkladı. CloudSEK bu sayıların her kuruluşta zararlı kodun çalıştığını, bütün kimlik bilgilerinin çalındığını veya başarılı bir ihlal gerçekleştiğini kanıtlamadığını özellikle belirtiyor.

StepSecurity, CloudSEK verisinin kendi analizinde 2.186 kuruluşla bağlantılı 78.330 farklı sır tespit edildiğini bildirdi. Hudson Rock ise saldırganlarla ilişkilendirilen 153 GB büyüklüğündeki arşivde, 2.488 kurumsal alan adına ait 118.829 CI/CD çalıştırıcı kaydı belirlediğini açıkladı. Rakamlar arasındaki fark, araştırmacıların farklı veri kümeleri ve sayım yöntemleri kullanmasından kaynaklanıyor. Bu nedenle bu sayıları tek bir doğrulanmış mağdur toplamı gibi bir araya getirmek doğru değil.

Bu rakamlar StepSecurity'nin CloudSEK verisi üzerindeki analizine dayanıyor. Bazı kuruluşlar birden fazla platform kullandığı için satırlar toplanarak benzersiz kuruluş sayısına ulaşılamaz. Veriler ayrıca her kuruluşta başarılı bir ihlal gerçekleştiğini tek başına kanıtlamaz.

Oligo Security, Ağustos 2026 tarihli araştırmasında TeamPCP ile daha önce TA-NATALSTATUS ve IronErn adlarıyla takip edilen faaliyetler arasında altyapı, zararlı yazılım dağıtım yolları ve operasyon yöntemleri bakımından bağlantı kurdu. Araştırmacılar, ilişkili faaliyetlerin 2020'ye kadar uzandığını ve aynı saldırganlar, yakın çalışan gruplar veya ortak kullanılan altyapı arasında operasyonel devamlılığa işaret ettiğini değerlendiriyor.

Önce Mevcut Maruziyeti Araştırın

Bu kampanyadan etkilenmiş olma ihtimali bulunan bir kurum için ilk adım, yalnızca zararlı paketi kaldırmak olmamalı. FBI'ın 2 Temmuz 2026 tarihli FLASH-20260702-01 danışmanlığı, dışarı çıkarılan verilerin ve kimlik bilgilerinin ilk olaydan uzun süre sonra da kullanılabileceği konusunda uyarıyor. Bu nedenle maruziyet döneminde CI/CD ortamından erişilebilen sırların, yayın token'larının ve bulut kimlik bilgilerinin döndürülmesi gerekiyor.

Rotasyon tek başına yeterli değil. Eski kimlik bilgilerinin olay tarihinden sonra kullanılıp kullanılmadığı erişim kayıtlarından araştırılmalı. Etkilenen CI/CD çalıştırıcıları, oluşturulan yazılım çıktıları ve bu çıktılardan kurulan sistemler olay müdahalesi kapsamında incelenmeli. Gerekirse çalıştırıcılar güvenilir bir kaynaktan yeniden oluşturulmalı.

FBI ayrıca saldırganların çalınan kimlik bilgileriyle oluşturduğu tpcp-docs ve docs-tpcp adlı depoların GitHub organizasyonlarında aranmasını öneriyor. Tek başına bu depo adlarının bulunması kesin ihlal kanıtı sayılmasa da derhal araştırılması gereken güçlü bir gösterge niteliğinde.

• GitHub Actions iş akışlarını değişken etiketler veya dal referansları yerine doğrulanmış commit SHA değerlerine sabitlemek, ele geçirilen bir sürüm etiketinin otomatik olarak kullanılmasını önlemeye yardımcı olur
• npm ve PyPI gibi paket ekosistemlerinde kilit dosyaları, bütünlük hash'leri, paket imzaları ve erişimi kontrollü yazılım depoları kullanılmalıdır
• Derleme hatlarında kullanılan tarayıcı, linter ve test araçlarını da yazılım bağımlılığı olarak yönetmek, bu bileşenlere sürüm doğrulama, bütünlük kontrolü ve asgari yetki ilkelerinin uygulanmasını sağlar
• Yayın token'larının erişim kapsamını depo ve paket bazında en aza indirmek ve düzenli olarak döndürmek, tek bir sızmanın zincirleme etkiye dönüşme olasılığını azaltır

Tedarik Zinciri Güvenliği Açısından Çıkarımlar

TeamPCP vakası, tedarikçi riskinin yalnızca ticari yazılım ve SaaS sağlayıcılarından ibaret olmadığını gösteriyor. Açık kaynak bir güvenlik tarayıcısı, GitHub Action, paket veya IDE eklentisi de kurumun yazılım tedarik zincirinde güvenilen bir tedarikçi gibi çalışıyor. Bu bileşenlerden biri ele geçirildiğinde kurumun kendi kodundaki güvenlik kontrolleri saldırıyı durdurmaya yetmeyebilir.

Buradaki temel sorun yalnızca zararlı bir paketin indirilmesi değil. CI/CD süreçleri kod depolarına, bulut ortamlarına, paket kayıt sistemlerine ve üretim sistemlerine erişebilen güçlü kimlik bilgileri taşıyor. Bu nedenle geliştirme ve dağıtım ortamları da üretim sistemleriyle aynı ciddiyette korunmalı.

Tedarik zinciri güvenliği yazımızda ele aldığımız SBOM (Software Bill of Materials), bu noktada önemli bir görünürlük katmanı sağlıyor. Güncel ve sorgulanabilir bir SBOM, etkilenen bileşenlerin ve sürümlerin hangi sistemlerde kullanıldığını manuel incelemeye kıyasla çok daha hızlı belirlemeye yardımcı olabilir. Ancak SBOM'un yalnızca oluşturulması yeterli değil. Envanterin güncel tutulması, bilinen zararlı sürümler ve güvenlik duyurularıyla düzenli olarak karşılaştırılması gerekiyor.

Kalıcı Olarak Ne Yapılmalı?

• Derleme ve CI/CD hatlarında kullanılan tüm açık kaynak araçların sürüm sabitleme durumunu gözden geçirin
• Kritik bağımlılıklarınız için SBOM görünürlüğü oluşturun, SBOM'u güncel tutun ve bilinen zararlı sürümlerle düzenli olarak karşılaştırın
• CI/CD servis hesaplarında ve yayın token'larında asgari yetki uygulayın, token'ları depo ve paket bazında sınırlandırın
• Kod deposu ve paket kayıt sistemi hesaplarında kimlik avına dayanıklı çok faktörlü kimlik doğrulama kullanın
• CI/CD süreçlerinden çıkan ağ bağlantılarını izleyin ve yalnızca gerekli hedeflere erişime izin verin
• Yazılım çıktıları yayımlanmadan veya dağıtılmadan önce hash ve imza doğrulaması yapın, güvenilir ve erişimi kontrollü yazılım depoları kullanın
• CI/CD kimlik doğrulama, yapılandırma ve yazılım çıktısı işlem kayıtlarını merkezi olarak tutun
• Maruziyet ihtimali varsa yalnızca token rotasyonuyla yetinmeyin, ilgili CI/CD çalıştırıcılarını ve sistemleri olay müdahalesi kapsamında inceleyin
• Kritik kod depoları ve yayın çıktıları için çevrimdışı veya değiştirilemez yedek bulundurun
• FBI danışmanlığında listelenen tpcp-docs ve docs-tpcp depo adlarını kendi ortamınızda arayın

Sıkça Sorulan Sorular