Geçen hafta editör masasında bu haberi görünce ilk tepkim çok netti: “Yazılım tedarik zinciri güvenliği tam gündemdeyken bir de code-signing meselesi mi çıktı?” Açık konuşayım — evet, çıktı. Ve işin asıl can sıkıcı boyutu da tam bu noktada başlıyor. OpenAI, macOS için kullandığı bazı imzalama sertifikalarını döndürmeye,. Yenilemeye başladı; tetikleyici ise Axios üzerinden gelen kötü niyetli bir paketin GitHub Actions iş akışına sızıp ortalığı karıştırması oldu.
Bu tip haberlerde çoğu kişi “sertifika çalınmış olabilir” kısmında takılıp kalıyor. Oysa mesele bundan epey geniş. Çünkü code-signing dediğimiz şey, yazılım dünyasında kapıya vurulan mühür gibi çalışıyor — kullanıcı da işletim sistemi de o mühre bakıp “tamam, bu paket güvenilir” diyor. Mühür kirlenirse… işte orada işler tatsızlaşıyor.
Asıl mesele neydi?
Konu kabaca şu. OpenAI’nin bir GitHub Actions workflow’u, saldırganların yerleştirdiği zararlı bir Axios paketini çalıştırdı. Bu tür zincirleme saldırılar çok sevimsizdir; çünkü tek tek sistemleri kırmaktan ziyade otomasyon hattının içine sızarlar, insanın gözüne görünmeden, arka tarafta sessizce ilerliyorlar. Ben buna bazen mutfaktaki gizli su kaçağı gibi bakıyorum — ortalıkta büyük patlama yoktur ama duvarın içi yavaş yavaş ıslanır. Sonra bir gün siva dökülür.
Bunu biraz açayım.
İtiraf edeyim, Buradaki kritik nokta şu: eğer o workflow içinde macOS imzalama sürecine temas eden herhangi bir gizli bilgi açığa çıktıysa, OpenAI’nin sertifikaları rotasyona sokması gayet mantıklı bir hamle. Sertifika yenilemek burada panik değil — tam tersine, hasarı sınırlama refleksi. Hani eski anahtarı kaybedince kilidi değiştirmek gibi düşünün. Geç kaldığınızda sorun büyüyor.
Code-signing sertifikası ele geçirilirse saldırganlar teoride meşru görünen yazılımlar dağıtabilir; kullanıcı tarafında alarm zili çoğu zaman geç çalar.
Neden özellikle macOS sertifikası önemli?
Şunu söyleyeyim, macOS ekosisteminde imza konusu bayağı hassas. Apple’ın güven modeli büyük ölçüde imzaya dayanıyor; uygulama mağazası dışındaki yazılımlar bile çoğu zaman bu güven katmanından geçiyor. Bir sertifikanın gölgelenmesi demek sadece teknik bir detay değil — kullanıcı güveninin de test edilmesi demek. İki farklı şey bunlar.
İşte tam da bu noktada devreye giriyor.
Benzer bir sıkıntıyı 2023’te küçük bir SaaS projesinde yaşamıştık (buna dikkat edin). İstanbul’da çalışan ekibimiz gece yarısı build pipeline’da beklenmedik bir paket davranışı görmüştü; ilk anda “yanlış dependency sürümü” sandık ama işin aslı daha sinir bozucuydu: CI akışına fazladan yetki verilmişti ve bunu kimse fark etmemişti (buna dikkat edin). O gün anladım ki otomasyon rahatlık sağlıyor ama yanlış ayarlanırsa sessiz sedasız kapıyı açık bırakıyor. Hem de sonuna kadar.
GitHub Actions neden bu kadar kritik?
Açıkçası, GitHub Actions güzel araçtır, lafı gevelemeden söyleyeyim (bizzat test ettim). Hele bir de de küçük ekiplerde işleri hızlandırıyor, tabi. Ama aynı rahatlık bazen tehlike de yaratıyor — pipeline içine fazla güven yükleyebiliyorsunuz çünkü. Bir iş akışı sadece test koşuyor sanırsınız, sonra bakarsınız paket indiriyor, secret okuyor, artifact üretiyor ve üstüne bir de imza hattına dokunuyor. Nasıl oldu bu? Yavaş yavaş, kimse fark etmeden.
Açık konuşayım: supply chain saldırıları artık klasik “sunucuya girdiler” hikâyesinden çok daha çekici hale geldi saldırganlar için. Çünkü doğrudan en zayıf halkaya değil, herkesin güvendiği ortak boru hattına oynuyorlar; bir package registry’de zehirli sürüm yayınlamak ya da CI’ya zararlı bağımlılık sokmak, hem ucuz hem etkili yöntemler bunlar. Rahatsız edici derecede verimli, yani.
Küçük startup ile kurumsal yapı arasında fark ne?
Küçük startup tarafında genelde hedef hızdır. Ekip iki kişidir, biri ürün yapar biri deploy eder ve herkes birbirine güvenir — bazen fazla. Böyle olunca workflow’lar çabuk kurulur ama denetim eksik kalır; kimsenin kötü niyeti yok, sadece vakit yok. Agentic AI: Prompt’tan Özerk Döngülere Geçiş yazımızda bu konuya da değinmiştik. geldi ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.
Küçük bir detay: Kurumsal tarafta ise tablo başka türlüdür: onay mekanizmaları vardır ama sistem büyüdükçe kör noktalar da artar, yani kimse tek başına her şeyi görmez hale gelir ve tam orada saldırganların sevdiği alan açılır. İkisi de riskli, sadece risk şekilleri farklı. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
| Alan | Küçük Startup | Enterprise |
|---|---|---|
| Erişim kontrolü | Bazen gevşek | Daha sıkı ama karmaşık |
| Sertifika yönetimi | Manuel kalabiliyor | Süreç var ama çok katmanlı |
| Saldırı yüzeyi | Daha küçük görünür ama dikkatsiz olabilir | Daha geniş ve parçalı |
| Müdahale hızı | Çabuk karar alınır | Bürokrasi yüzünden yavaşlayabilir |
Sertifika rotasyonu neden doğru hamle?
Sertifika döndürmek kulağa rutin geliyor olabilir. Değil. Pratikte oldukça önemli bir savunma hareketi bu — eğer özel anahtarların açığa çıkma ihtimali varsa yeni sertifikaya geçmek risk penceresini kapatır ya da en azından daraltır, eski anahtar artık eskisi kadar kıymetli olmaz ve kötüye kullanımını engellemenin yolu da zaten buradan geçiyor.
Neyse uzatmayalım; buradaki mesele “kesin sızdı” demek değil — elimizde öyle kesin kanıt yoktu zaten, demek de istemiyorum bunu. Mesele şüphe varsa önlem almak. Güvenlik operasyonlarında bazen en iyi karar gösterişli olan değil, sıkıcı olandır.
- Sertifikayı yenilemek eski anahtarı etkisiz hale getirir. — bunu es geçmeyin
- Zincirdeki diğer erişimler gözden geçirilir.
- Build ve release logları taranır.
- Paket bağımlılıkları temizlenir ve kilitlenir. — ciddi fark yaratıyor
Tedarik zinciri saldırıları neden bitmiyor?
Bence bunun nedeni biraz tembellik, biraz da ölçek ekonomisiyle ilgili. Saldırgan için tek bir popüler pakete sızmak, onlarca hatta yüzlerce hedefe dokunmak anlamına gelebiliyor — klasik brute-force yerine tek hamlede domino etkisi yaratıyorsunuz (evet, doğru duydunuz). Gerçekten rahatsız edici derecede verimli bir yöntem bu. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Geçen ay Berlin’de çalışan eski bir meslektaşımla bunu tartışırken bana şunu söylemişti: “Artık en pahalı firewall bile yanlış dependency karşısında çaresiz kalabiliyor.” Abartmıyordu. Bugün güvenlik yalnızca ağ çevresini korumakla bitmiyor; kullandığınız her kütüphane, geliştirme aracı ve CI adımı ayrı ayrı denetlenmeli. Biraz yorucu, evet. Ama başka çare pek yok gibi duruyor.
Peki geliştiriciler ne yapmalı?
Bence önce şu alışkanlığı bırakmak gerekiyor: “Nasıl olsa resmi paket deposunda duruyor.” Hayır. O kadar basit değil. Paket adı tanıdık diye masum olmuyor — sürümler, sahip değişiklikleri, yayın geçmişi, bakım sıklığı, hepsi izlenmeli; gerekirse bağımlılık güncellemesini otomatik değil kontrollü yapın, yani hız güzel ama kör hız bayağı pahalıya patlayabiliyor. Daha fazla bilgi için Game Pass neden pahalılaştı: Microsoft’un yeni planı yazımıza bakabilirsiniz.
# Basit kontrol listesi
- Workflow izinlerini daralt
- Secrets erişimini minimumda tut
- Release job'larını izole et
- Paket sürüm pinning kullan
- Şüpheli aktivite için audit log izle
- İmzalama anahtarlarını düzenli döndür
- Mümkünse ephemeral runner kullan
Bu olay bize ne söylüyor?
Bana sorarsanız asıl mesaj şu: tacize açık olan şey sadece son kullanıcı cihazları değil, geliştirici altyapısı da artık hedefte. Bir ürünü test ettiğimde en çok baktığım şeylerden biri şu olur: görünmeyen bağımlılıklar nereye uzanıyor? Çünkü problem çoğu zaman kodda değil, zincirin unuttuğunuz halkasında çıkıyor. Dur, bunu biraz daha net söyleyeyim — zincir ne kadar uzun olursa, kopacak yer sayısı da o kadar artıyor. Basit matematik.
Ayrıca bu olay OpenAI özelinde yaşandı diye yalnızca onlara özgü sanmayın. Her şirketin başına gelebilir. Günün sonunda önemli olan kusursuz olmak değil, hata olduğunda hızlı tepki verebilmek — burada OpenAI’nin sertifika rotasyonu yapması bana göre doğru yönde atılmış sağlam bir adım. Hâlâ soru işaretleri var mı? Var. Tabii ki var. Bu tür vakalarda tam resim çoğu zaman haftalar sonra ortaya çıkar.
Şahsen, Şimdilik gördüğümüz şey, ihtiyatlı davranan bir ekip görüntüsü. Bu kötü mü? Bence hayır. Hatta fena olmayan tarafı tam da burada yatıyor. Ama yine de işin ham kısmı bitmiş sayılmaz…
Sıkça Sorulan Sorular
OpenAI neden macOS sertifikalarını yeniledi?
Bi saniye — Muhtemel sebep, GitHub Actions içindeki kötü niyetli paket çalıştırıldıktan sonra code-signing anahtarlarının etkilenmiş olma ihtimaliydi.Potansiyel risk varsa sertifika rotasyonu standart savunma adımıdır.Axios saldırısı tam olarak neyi hedefledi?
Ana hedef doğrudan OpenAI değildi;supply chain üzerinden CI/CD akışını bozmak istediler.Zararlı paketler genelde güvenilen bağımlılıklar aracılığıyla yayılır.Kullanıcılar bundan etkilenebilir mi?
Eğer imzalama altyapısı gerçekten etkilenirse evet,dolaylı risk oluşabilir.Ancak şirketler genelde böyle durumlarda hızlıca eski anahtarları devre dışı bırakıp yeni sertifikaya geçer.Tedarik zinciri saldırılarından nasıl korunulur?
Paketleri sabitlemek,secrets kullanımını azaltmak,audit log tutmak ve runner izinlerini kısaltmak iyi başlangıçtır.En önemlisi de CI süreçlerini düzenli gözden geçirmek gerekir.Kaynaklar ve İleri Okuma
Apple Certificate Authority Resmi Bilgiler Sayfası
Ayrıca ilgili okumalar için CPUID saldırısı: CPU-Z ve HWMonitor indirirken dikkat:, Agentic Kodlamada Yeni Kural: Spec-Driven Dönemi Başlıyor:, Claude’daki “Skills” Neden Prompt Değil, Bağlam Tasarımıdır?:end of file
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
