Software Supply Chain Attack Nedir? Tedarik Zinciri Nasıl Korunur?

Yazılım tedarik zinciri saldırısı, son kullanıcıya ulaşan uygulamayı doğrudan hedeflemek yerine uygulamanın üretildiği, paketlendiği, dağıtıldığı veya güncellendiği zincirdeki güven ilişkilerini kötüye kullanır. Saldırgan bir bağımlılığı, kaynak kod deposunu, CI/CD iş akışını, build sunucusunu, container registry'sini, imzalama anahtarını ya da güncelleme kanalını ele geçirerek meşru görünen zararlı bir artefakt üretmeye çalışabilir.

Bu saldırıları tehlikeli yapan nokta, zararlı değişikliğin güvenilen bir süreçten geçerek dağıtılabilmesidir. Uygulama kodunda açık aramak yerine geliştiricinin kullandığı pakete, build pipeline'ına veya yayın hesabına ulaşmak daha geniş etki yaratabilir. Bu nedenle korunma yaklaşımı yalnızca kaynak kod taramasına değil; bağımlılık seçimi, geliştirme ortamı, erişim yetkileri, build bütünlüğü, artefakt imzası, provenance ve güvenli güncelleme mekanizmasına birlikte bakmalıdır.

Yazılım tedarik zinciri hangi halkalardan oluşur?

Bir ürünün tedarik zinciri yalnızca açık kaynak paketlerden oluşmaz. Geliştirici cihazındaki IDE eklentileri, kod deposu, üçüncü taraf GitHub Actions iş akışları, build container'ı, container taban imajı, paket registry'si, cloud yetkilendirmesi, artefakt deposu ve otomatik güncelleme servisi de zincirin parçasıdır. OWASP Top 10:2025, Software Supply Chain Failures kategorisini bağımlılıkların ötesine taşıyarak yazılımın build, dağıtım ve güncelleme süreçlerindeki bozulmaları kapsayan A03 riski olarak tanımlar OWASP A03:2025 Software Supply Chain Failures.

Bir pipeline'ın çıktısı güvenilir kabul edilmeden önce yalnızca “build başarılı” bilgisi değil; hangi kaynaktan, hangi yetkili süreçle ve hangi bileşenlerle üretildiği de doğrulanmalıdır.

NIST Secure Software Development Framework; organizasyonu hazırlama, yazılımı yetkisiz değişikliklerden koruma, güvenli yazılım üretme ve kalan güvenlik açıklarına yanıt verme olmak üzere dört ana uygulama grubuna dayanır. Bu çerçeve, tedarik zinciri güvenliğinin tek bir ürün satın alarak değil, geliştirme yaşam döngüsüne entegre edilen risk temelli uygulamalarla kurulması gerektiğini gösterir NIST Secure Software Development Framework.

Tedarik zinciri saldırısı ile savunmasız bağımlılık aynı şey midir?

Hayır. Savunmasız bağımlılık, bir bileşende istemeden bulunan güvenlik açığının kullanılmasıdır. Tedarik zinciri saldırısında ise saldırgan çoğunlukla güvenilen üretim veya dağıtım mekanizmasını manipüle ederek zararlı kodu meşru yazılımın parçası haline getirmeye çalışır. İki durum kesişebilir; ancak müdahale biçimleri aynı değildir.

Bu ayrım olayın kapsamını belirler. Yalnızca paketi yükseltmek, build hesabı veya publish token'ı hâlâ saldırganın kontrolündeyse problemi çözmez. Buna karşılık paket sürümünde normal bir güvenlik açığı varsa tüm CI/CD sistemini ele geçirilmiş kabul etmek de gereksiz olabilir. Karar, kaynak, build ve dağıtım kanıtlarıyla verilmelidir.

En yaygın yazılım tedarik zinciri saldırı yolları

1. Bağımlılık ve paket registry saldırıları

Saldırgan popüler pakete benzeyen isimle zararlı paket yayımlayabilir, kurum içi paket adıyla public registry'de daha yüksek sürüm oluşturabilir veya meşru yayın hesabını ele geçirebilir. Paket yöneticisinin hangi registry'ye, hangi sürüm aralığıyla ve hangi öncelikle bağlandığı açıkça tanımlanmadığında build sistemi beklenmeyen kaynaktan kod indirebilir.

• Manifest ve lock dosyalarını birlikte kullanın.
• Kurumsal proxy veya özel registry üzerinden onaylı kaynaklara erişin.
• İç paket adlarının public registry'de çözülmesini engelleyin.
• Yeni ve beklenmeyen maintainer değişikliklerini inceleyin.
• Doğrudan ve transit bağımlılıkları yazılım geliştirme sürecinin parçası olarak envanterleyin.
• Güncellemeleri otomatik açılan pull request üzerinden test ve insan incelemesiyle birleştirin.

2. Kaynak kod deposu ve geliştirici hesabı saldırıları

Geliştirici hesabı, kişisel access token veya SSH anahtarı ele geçirildiğinde saldırgan workflow, release veya kritik kod değişikliği yapabilir. Koruma yalnızca parola politikasına bırakılmamalıdır. MFA, kısa ömürlü kimlik bilgileri, branch koruması, zorunlu review, CODEOWNERS ve kritik dosyalarda ayrılmış onay sorumluluğu birlikte uygulanmalıdır.

Tek kişinin kodu yazıp tüm kontrolleri aşarak üretime gönderebilmesi, zincirde görev ayrılığını zayıflatır. OWASP A03:2025, tek bir kişinin gözetimsiz biçimde kodu production'a kadar taşıyamamasını ve tedarik zincirinin her halkasında en az yetki uygulanmasını önerir OWASP A03:2025 Software Supply Chain Failures.

3. CI/CD workflow ve runner saldırıları

CI/CD, kaynak koduna, secret'lara, paket registry'sine ve production altyapısına aynı anda erişebildiği için yüksek değerli hedeftir. Üçüncü taraf bir workflow adımı ele geçirilirse repository token'ına, ortam değişkenlerine veya paylaşılan runner kaynaklarına erişmeye çalışabilir.

GitHub, üçüncü taraf Actions bileşenlerini tam uzunlukta commit SHA değerine sabitlemenin immutable kullanım için en güvenli yöntem olduğunu belirtir. Tag değeri sonradan farklı commit'e taşınabilirken belirli SHA incelenen kodu sabitler GitHub Actions Secure Use Reference.

• Üçüncü taraf action ve reusable workflow'ları tam commit SHA ile sabitleyin.
• Workflow dosyalarını CODEOWNERS ve zorunlu review kapsamına alın.
• Varsayılan token yetkilerini read-only seviyesine indirin; yalnız ihtiyaç duyulan job'a ek yetki verin.
• Uzun ömürlü cloud secret yerine desteklenen ortamlarda OIDC ve kısa süreli kimlik bilgileri kullanın.
• Güvenilmeyen pull request kodunu production secret bulunan runner'da çalıştırmayın.
• Self-hosted runner'ları kalıcı ve paylaşımlı sunucu yerine mümkünse tek kullanımlık ve izole tasarlayın.
• Build, publish ve deploy adımlarını ayrı job ve ayrı yetkilerle sınırlandırın.

4. Build sistemi ve araç zinciri manipülasyonu

Kaynak kod deposu temiz görünürken build sunucusu çıktıya farklı dosya ekleyebilir veya derleyici, plugin ve taban imaj beklenmedik sürüme dönebilir. Bu nedenle “source commit doğru” bilgisi tek başına yayın artefaktının doğru olduğunu kanıtlamaz. Build sürecinin hangi kaynak, parametre ve araçlarla çalıştığını gösteren provenance bilgisi gerekir.

SLSA, yazılım artefaktlarının bütünlüğünü korumak için kaynak, build, dependency ve provenance kontrollerini kademeli güvence seviyeleriyle ele alan vendor-neutral bir çerçevedir. İlk uygulanabilir adımlardan biri, build'in kaynağı ve üretim süreci hakkında doğrulanabilir provenance oluşturmaktır SLSA Framework.

5. Registry, container ve artefakt saldırıları

Container imajını yalnız latest etiketiyle dağıtmak, aynı tag'in zaman içinde farklı içeriği göstermesine neden olabilir. Üretim deployment'ında immutable digest kullanmak, beklenen artefaktın değişmediğini kontrol etmeyi kolaylaştırır. Registry'de publish, overwrite ve delete yetkileri sınırlanmalı; release artefaktları ayrı hesapla yazılmalı ve üretime alınmadan önce imza doğrulanmalıdır.

Sigstore; container imajı, binary, release dosyası ve SBOM gibi artefaktların imzalanması ve doğrulanması için açık kaynak araçlar sağlar. İmza, artefaktın kim tarafından üretildiği ve imzalandıktan sonra değiştirilip değiştirilmediği hakkında doğrulanabilir kanıt sunar Sigstore Overview.

6. Güncelleme ve dağıtım kanalı saldırıları

Güvenli build edilen yazılım, dağıtım sırasında imza kontrolü yapılmadan farklı dosyayla değiştirilebilir. Masaüstü uygulamaları, agent yazılımları, container deployment'ları ve otomatik plugin güncellemeleri yalnız HTTPS indirmeye güvenmemelidir. İstemci veya deployment katmanı, beklenen yayıncının imzasını ve uygun olduğunda provenance politikasını doğrulamalıdır.

Somut örnek: Zararlı değişiklik pipeline boyunca nasıl ilerleyebilir?

Aşağıdaki senaryo belirli bir şirket veya gerçek olay iddiası değildir; kontrol noktalarını göstermek için hazırlanmış genel bir teknik örnektir. Bir web uygulamasının container imajı Git tabanlı CI/CD ile oluşturuluyor ve production cluster'a otomatik dağıtılıyor olsun.

1. Workflow, üçüncü taraf bir build action'ını hareketli v2 etiketiyle çağırır.
2. Action deposu veya yayın yetkisi ele geçirilir ve v2 etiketi zararlı commit'e taşınır.
3. Yeni workflow çalışması zararlı action'ı indirir.
4. Job'ın registry write token'ı ve cloud deployment yetkisi vardır.
5. Action, uygulama çıktısına beklenmeyen dosya ekler ve yeni container imajı yayımlar.
6. Deployment yalnız latest tag'ini izlediği için digest ve imza doğrulamadan yeni imajı üretime alır.
7. Kaynak kod incelemesinde zararlı değişiklik görünmez; çünkü manipülasyon build sırasında yapılmıştır.

Bağımlılık ve paket güvenliği nasıl kurulmalıdır?

Bağımlılık yönetiminin amacı bütün güncellemeleri engellemek değildir. Sabitlenmiş ama yıllarca güncellenmeyen paketler de risk oluşturur. Sağlıklı süreç; hangi bileşenin kullanıldığını bilmek, güncellemeyi kontrollü almak, test etmek ve hızlı biçimde yayınlayabilmektir.

1. Doğrudan ve transit bağımlılıklar için SBOM üretin.
2. Manifest ile lock dosyasının CI içinde tutarlı olduğunu doğrulayın.
3. Paketleri yalnız onaylı registry ve kurumsal proxy üzerinden indirin.
4. Beklenmeyen package source veya namespace kullanımını build'i durduran politika haline getirin.
5. Güvenlik duyurularını ve kullanım dışı kalan paketleri sürekli izleyin.
6. Yeni major sürümleri otomatik production'a göndermek yerine test ve review sürecine alın.
7. Kullanılmayan paketleri kaldırarak saldırı yüzeyini azaltın.
8. Bakımı durmuş veya sahipliği belirsiz paketler için alternatif plan oluşturun.

SBOM, tek başına saldırıyı engellemez; ancak hangi ürünün hangi bileşeni kullandığını göstererek güvenlik olayı sırasında kapsamı belirlemeyi hızlandırır. Bu envanterin her release ile otomatik üretilmesi ve artefaktla ilişkilendirilmesi gerekir.

Repository ve CI/CD için minimum güvenlik tabanı

• Tüm geliştirici ve yönetici hesaplarında phishing dirençli MFA veya passkey kullanın.
• Production branch'lerinde doğrudan push'u kapatın.
• En az bir bağımsız review ve geçen güvenlik kontrolleri olmadan merge yapılmasını engelleyin.
• Workflow, dependency ve deployment dosyalarına özel CODEOWNERS tanımlayın.
• Repository, registry ve cloud audit loglarını merkezi olarak saklayın.
• Secret'ları repository içinde tutmayın; secret manager ve kısa ömürlü erişim kullanın.
• CI token'larının erişebileceği repository ve ortamları açık allowlist ile sınırlayın.
• Production deployment'ı build job'ından ayırın ve korunan environment onayı uygulayın.
• Runner imajlarını düzenli yenileyin; kalıcı erişim anahtarı bırakmayın.
• Fork ve harici katkı workflow'larının secret erişimini varsayılan olarak kapatın.

Bu taban kontroller, özel yazılım altyapısı planlanırken sonradan eklenecek güvenlik eklentileri değil, release mimarisinin başlangıç gereksinimleri olmalıdır.

Artefakt imzası, provenance ve SBOM birlikte nasıl kullanılır?

Üç artefakt farklı sorulara cevap verir:

Olgun yayın kapısı bu kanıtları birleştirir. Production sistemi; doğru digest'e sahip artefaktı, onaylı kimlik tarafından imzalanmışsa, beklenen builder provenance'ı taşıyorsa ve politika kontrollerini geçmişse kabul eder. İmza üretmek ama deployment sırasında doğrulamamak koruma sağlamaz.

Üçüncü taraf yazılım ve tedarikçi riski nasıl yönetilir?

Kuruluş yalnız kendi build hattından değil, satın aldığı yazılımların update ve destek kanallarından da etkilenir. Tedarikçi değerlendirmesi genel “güvenli miyiz?” sorusuyla sınırlı kalmamalıdır.

• SBOM sağlayabiliyor mu ve her sürümle güncelliyor mu?
• Güvenlik açığı bildirim ve koordineli açıklama süreci var mı?
• Release artefaktlarını imzalıyor mu?
• Build provenance veya üretim süreci hakkında kanıt sunabiliyor mu?
• Güncelleme kanalı imza doğruluyor mu?
• Kritik bağımlılık ve alt yüklenici değişikliklerini nasıl yönetiyor?
• Destek süresi bitişi ve güvenlik güncelleme takvimi açık mı?
• Olay durumunda müşteriye hangi süre ve kanalla bilgi verecek?

CISA'nın geliştirici ve tedarikçiler için hazırladığı yazılım tedarik zinciri rehberleri; kod, provenance ve artefakt bütünlüğünün korunmasını, güvenli geliştirme ortamı ve doğrulanabilir teslim süreçleriyle birlikte ele alır CISA Securing the Software Supply Chain for Suppliers.

Tedarik zinciri saldırısı şüphesinde nasıl müdahale edilmelidir?

1. Yayını durdurun: Şüpheli pipeline, registry publish ve otomatik update akışını geçici olarak kapatın.
2. Kimlik bilgilerini koruyun: Etkilenen token, signing key, deploy credential ve service account'ları iptal edin veya döndürün.
3. Kanıtları koruyun: Workflow logları, runner imajı, artefakt digest'leri, audit log ve registry geçmişini silmeden arşivleyin.
4. Kapsamı belirleyin: Hangi kaynak commit, build, paket ve müşterinin etkilendiğini SBOM ve provenance üzerinden araştırın.
5. Temiz ortam kurun: Ele geçirilme ihtimali olan build hostunu yeniden kullanmak yerine doğrulanmış ortamdan yeniden üretim yapın.
6. Artefaktları karşılaştırın: Kaynak, build parametresi, hash, imza ve dependency farklarını inceleyin.
7. Dağıtımı geri alın: Güvenilir önceki sürüme dönün veya etkilenen işlevi devre dışı bırakın.
8. Bildirim planını çalıştırın: Etkilenen müşteriler, tedarikçiler ve gerekli kurumlarla doğrulanmış bilgiyi paylaşın.
9. Kök nedeni düzeltin: Yalnız zararlı paketi silmek yerine hesabın, izin modelinin veya yayın sürecinin nasıl aşıldığını giderin.

Uygulanabilir tedarik zinciri güvenliği kontrol listesi

• Her ürün sürümü için SBOM ve artefakt digest'i üretiliyor mu?
• Bağımlılıklar yalnız onaylı registry'lerden mi indiriliyor?
• Manifest ve lock dosyası tutarlılığı CI'da doğrulanıyor mu?
• Third-party CI bileşenleri immutable SHA ile sabit mi?
• Workflow değişiklikleri zorunlu bağımsız review gerektiriyor mu?
• CI token'ları varsayılan olarak en az yetkili mi?
• Uzun ömürlü cloud credential yerine kısa süreli kimlik kullanılıyor mu?
• Runner'lar izole ve mümkünse tek kullanımlık mı?
• Build ile deploy farklı yetki ve onay sınırlarında mı?
• Artefaktlar imzalanıyor ve dağıtımdan önce imza gerçekten doğrulanıyor mu?
• Build provenance üretiliyor ve deployment politikası tarafından kontrol ediliyor mu?
• Container deployment'ları hareketli tag yerine digest'e bağlanıyor mu?
• Registry publish, overwrite ve delete yetkileri ayrılmış mı?
• Tedarikçi yazılımları için SBOM, güncelleme ve olay bildirim şartları tanımlı mı?
• Şüpheli build'i durdurma ve güvenilir sürüme dönme prosedürü test edildi mi?

Sonuç: Güven yalnızca koda değil üretim zincirine dayanmalıdır

Software supply chain attack, bir uygulamanın bağımlılık, kaynak, build, CI/CD, registry veya güncelleme halkalarından birini ele geçirerek güvenilir görünen zararlı yazılım dağıtmayı hedefler. Bu nedenle klasik kod güvenliği kontrolleri tek başına yeterli değildir. Ekip, yazılımın hangi bileşenlerden oluştuğunu, kim tarafından hangi ortamda üretildiğini ve dağıtılan artefaktın doğrulanmış sürümle aynı olduğunu kanıtlayabilmelidir.

Sağlam yaklaşım; bağımlılık envanteri, en az yetkili CI/CD, izole build, immutable referans, SBOM, imza, provenance, doğrulamalı deployment ve hızlı olay müdahalesini tek bir release sistemi içinde birleştirir. Bu kontroller bir kerelik denetim değil, her build ve her yayınla tekrar çalışan güvenlik mekanizmaları olmalıdır. Düzenli yazılım bakım süreci, paket ve pipeline güvenliğinin zaman içinde korunması için gereklidir.