1. GİRİŞ

Yazılım tedarik zinciri saldırıları (supply chain attacks) son yıllarda siber güvenliğin en kritik sorunlarından biri haline geldi. SolarWinds, Codecov, PyPI/ npm paket zehirlenmeleri ve diğer örnekler, yazılımın doğrudan değil; tedarik zincirindeki bir zafiyetten dolayı tehlikeye girebileceğini gösterdi. Bu saldırılar sadece tek bir uygulamayı değil, o yazılıma bağımlı olan yüzlerce veya binlerce kurumu etkileyebilir. Bu nedenle tedarik zinciri güvenliği artık yalnızca güvenlik ekiplerinin değil, geliştiricilerin, DevOps ekiplerinin ve yöneticilerin de öncelikli konularından biridir.

Neden bugün önemli?

• Bulut‑native ve otomasyon temelli geliştirme süreçleri, tek bir kötü paket veya pipeline token sızıntısının geniş çapta etki yaratmasına yol açıyor.
• SaaS, açık kaynak ve üçüncü taraf bağımlılıkların yaygın kullanımı saldırı yüzeyini büyütüyor.
• Regülatörler ve büyük müşteriler artık SBOM (Software Bill of Materials) ve tedarik zinciri kanıtı talep ediyor; güvenlik yalnızca teknik değil, hukuki bir zorunluluk hâline geliyor.

Kimler için önemli?

• Geliştiriciler ve takım liderleri — güvenli bileşen seçimleri için
• DevOps ve SRE ekipleri — CI/CD ve artefakt üretim güvenliği için
• Güvenlik mühendisleri ve SOC — tespit, triage, remediation süreçleri için
• Üst yönetim ve uyumluluk ekipleri — risk yönetimi ve denetim için

2. KAVRAMSAL TEMELLER

2.1 Tedarik zinciri saldırısı nedir?

Tedarik zinciri saldırısı, hedef sistemin kendisine doğrudan değil, sistemin kullandığı yazılım, servis veya bileşenler üzerinden yapılan saldırıdır. Atak zinciri, malzeme (code, library, artifact), build pipeline, dağıtım altyapısı veya teslim edilen yazılımın doğrulanması eksikliğinden kaynaklanabilir. Temel amaç genellikle gizli kapı (backdoor), izinsiz veri erişimi veya distribütif kötü amaçlı yazılım dağıtımıdır.

2.2 Ana terminoloji

• Provenance: Bir artefaktın nerede, nasıl, hangi araçlarla üretildiğine dair kanıt.
• SBOM: Yazılım bileşenlerinin makine tarafından okunabilir listesi (CycloneDX, SPDX).
• In‑toto: Tedarik zinciri adımlarını doğrulamak için kullanılan metadatayı tanımlayan çerçeve.
• Sigstore / cosign: Artefakt imzalama, keyless signing ve provenance zinciri sağlama araçları/ekosistemleri.
• Dependency poisoning: Paket depo veya registry'e zararlı paket yükleyerek yapılan saldırı.
• Credential compromise: CI token, deploy keys veya publish credential'larının ele geçirilmesi.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE Saldırı Vektörleri

3.1 Saldırı vektörleri

• Repository poisoning: Açık kaynak repo'larına veya paket registry'lerine zararlı paketlerin yüklenmesi (typosquatting, trojanized packages).
• Build pipeline compromise: CI/CD ortamlarına sızma, token hırsızlığı veya kötü amaçlı step ekleme ile artefaktların veya container image'ların manipüle edilmesi.
• Dependency hijack: Transitive bağımlılıkların ele geçirilmesi veya konsolide edilmesi yoluyla saldırı gerçekleştirme.
• Developer machine compromise: Geliştirici makinesine yerleşen malware ile commit'lerin değiştirilmesi, CLAS veya signing key'lerin sızdırılması.
• Third‑party service compromise: CI sağlayıcısı, package registry veya diğer tedarikçi hizmetlerinin ihlali.

3.2 Tipik saldırı akışı — örnek bir senaryo

1. Saldırgan bir geliştirici token'ını veya CI secret'ını ele geçirir (phishing, leaked logs).
2. CI pipeline içine yeni bir build step veya malicious artifact eklenir; artefakt imzalanır ve registry'e aktarılır.
3. Registry'e gönderilen imaj veya paket, downstream tüketiciler tarafından pull edilir ve üretime ulaşır.
4. Zararlı kod aktivasyon koşuluna ulaştığında veri sızdırma, lateral movement veya persistent backdoor etkinleşir.

3.3 Tespit zorlukları

• Artefaktın orijinal kaynak koduna bakmak çoğu zaman yeterli olmaz; derleme adımları ve build metadata kritik olabilir.
• Transitif bağımlılıklar yüzünden saldırı kaynağını bulmak karmaşıktır.
• Provenance ve SBOM eksikliği, hangi artefaktın nereden geldiğini doğrulamayı zorlaştırır.

4. GERÇEK DÜNYA ÖRNEKLERİ

4.1 SolarWinds

SolarWinds saldırısı, yönetimsel ağlarda kullanılan bir yazılım güncelleme mekanizmasının manipülasyonu ile geniş çaplı izinsiz erişim sağlanmasının çarpıcı örneğidir. Zararlı güncellemeler tedarik zinciri aracılığıyla güvenilen müşterilere ulaştırıldı ve uzun süren gizli erişim sağlandı.

4.2 Codecov

Codecov örneğinde, bash uploader script'i üzerine yapılan değişiklik ile CI'de secret'ların sızdırılması ve birden fazla müşteride veri sızıntısı yaşanması mümkün oldu. Bu vaka, script'lerin integrity'sinin ve uploader'ların doğrulanmasının önemini gösterdi.

4.3 Paket zehirlenmeleri (npm/PyPI)

Typosquatting ve maintainer hesabı ele geçirilmesi örnekleri, package registry'lerin riskini gözler önüne serdi. Zararlı paketler, popüler paket isimlerine benzer adlarla yayılarak veya maintainer hesaplarına erişim sağlanarak dağıtıldı.

5. AVANTAJLAR VE SINIRLAMALAR (Savunma Perspektifi)

Avantajlar

• Tedarik zinciri güvenliği sağlayan pratikler uygulanırsa, risk geniş ölçüde azaltılabilir; immutability ve provenance ile geri dönüş zorlaştırılır.
• SBOM, imzalama ve doğrulama ile regülasyon uyumluluğu elde edilir; müşteri güveni artar.

Sınırlamalar

• Tam güvence imkânsızdır; karmaşık ekosistemlerde tüm bağımlılıkları kontrol etmek zordur.
• İmzalama ve provenance altyapısı kurulumu maliyet ve operasyonel yük getirir.
• Legacy sistemler ve üçüncü taraflar değişiklik yapmadan önce uyum sağlamakta zorlanabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 Build ve CI güvenliği

• CI runner'larını izole edin ve ephemeral runner kullanımı tercih edin.
• Secrets'ları asla düz metin tutmayın — secrets manager ve short‑lived credentials kullanın.
• Least privilege: publish tokenları, deploy keys, ve pipeline izinlerini minimal tutun; ServiceAccount ve role ayrıştırması yapın.
• Immutable build artefaktları üretin; image'ları digest ile referanslayın, "latest" kullanmayın.

7.2 Artefakt imzalama ve provenance

• cosign veya benzeri ile artefaktları ve SBOM'u imzalayın; imza doğrulamasını deploy sürecinde zorunlu kılın.
• in‑toto veya Sigstore ile pipeline adımlarının doğrulanmasını sağlayın; her adımın üretim kanıtı saklansın.
• SBOM üretimini otomatikleştirin ve merkezi olarak arşivleyin; SBOM'ları runtime ve incident response için erişilebilir kılın.

7.3 Registry ve dependency yönetimi

• Private registries ve caching proxy kullanın; third‑party registry pull'larını kontrol altına alın.
• Dependency pinning ile sürümlerin deterministic olmasını sağlayın; transitive bağımlılıkları izleyin.
• Package name quaranatine, publisher reputation scoring ve typosquatting detection uygulayın.

7.4 Organizasyonel ve yönetimsel adımlar

• Supplier risk programı kurun; tedarikçi denetimleri, SLA ve security questionnaire'leri zorunlu hâle getirin.
• Incident response playbook'larını tedarik zinciri ihlallerine göre güncelleyin; canary/rollback stratejileri tanımlayın.
• Geliştiricilere ve operasyon ekiplerine tedarik zinciri güvenliği eğitimi verin; en iyi uygulamaları sürekli paylaşın.

8. SIK YAPILAN HATALAR

• SBOM üretmeden artefaktları dağıtmak; hangi bileşenin nereden geldiğinin bilinmemesi.
• CI token'larını geniş yetkilerle bırakmak; rotate/short‑lived token politikalarının olmaması.
• Registry'e güvenip tarama yapmamak; publish ve pull aktivitelerini izlememek.
• Third‑party vendor'ları teknik olarak yeterince değerlendirmemek; SLA ve güvenlik taleplerini sözleşmeye koymamak.

9. GELECEK TRENDLER

9.1 Standardlaşma ve regülasyon

SBOM, sigstore ve in‑toto gibi standartların yaygınlaşması, regülatörlerin tedarik zinciri gereksinimlerini sertleştirmesi bekleniyor. Kamu sektörü ve kritikal altyapılarda SBOM zorunlulukları gündeme gelebilir.

9.2 AI destekli önceliklendirme

AI/ML, hangi tedarik zinciri bulgularının gerçek risk oluşturduğunu öngörmede, exploit likelihood scoring ve noisy alertleri filtrelemede kullanılacak. Bu, SOC ve DevSecOps ekiplerinin triage yükünü hafifletebilir.

9.3 Continuous provenance ve runtime doğrulama

Runtime'da artefakt doğrulaması, digest kontrolü ve imza doğrulama ile üretim ortamında da tedarik zinciri güvenliği sürekli kılınacak. eBPF tabanlı kontroller ve runtime integrity monitoring yaygınlaşacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. SBOM nedir ve neden gerekli?

   SBOM, yazılımınızın hangi bileşenleri içerdiğini gösterir. CVE takibi, lisans uyumluluğu ve incident response için kritik bir araçtır.

2. 2. Sigstore ne sağlar?

   Sigstore, artefakt imzalama ve public transparency log'lar aracılığıyla provenance kanıtı sağlar; bu sayede artefaktların kaynağı doğrulanabilir.

3. 3. CI token'larını nasıl güvenli yönetirim?

   Secrets manager, short‑lived credentials, ephemeral runners ve sık token rotate politikaları uygulayın; token'ları minimal scope ile verin.

4. 4. Typosquatting'e karşı ne yapmalıyım?

   Registry policy, package name monitoring, ve vendor reputation scoring ile kuşkulu paketleri tespit edin; bağımlılıkların kaynaklarını doğrulayın.

5. 5. Artefakt imzalama zorunlu mu?

   Zorunlu değil ama güçlü bir savunma katmanı sağlar. İmza doğrulama deploy sürecinde enforce edilirse compromise riski ciddi şekilde azalır.

6. 6. Üçüncü taraf risk değerlendirmesi nasıl yapılmalı?

   Tedarikçi güvenlik uygulamaları, SBOM sunumu, vulnerability history, SLA ve erişim kontrolleri değerlendirilerek yapılmalıdır.

7. 7. Registry güvenliği için başlıca önlemler nelerdir?

   Private registry, access controls, immutability, vulnerability scanning ve pull/push aktivitelerinin logging'i başlıca önlemlerdir.

8. 8. Küçük ekipler nereden başlamalı?

   SBOM üretimi, cosign ile basit imzalama, ve CI'de SCA/registry taraması ile başlayın; zamanla provenance ve in‑toto entegrasyonları ekleyin.

Anahtar Kavramlar

• SBOM: Yazılımın içerdiği bileşenleri listeler.
• Provenance: Artefaktın üretim geçmişi ve doğrulanabilir kanıtı.
• Sigstore / cosign: Artefakt imzalama ve imza doğrulama araçları.
• in‑toto: Tedarik zinciri adımlarının doğrulanmasında kullanılan çerçeve.
• Typosquatting: Paket adının çakma veya benzer isimlerle kötüye kullanılması.

Öğrenme Yol Haritası

1. 0–1 ay: Tedarik zinciri temel kavramları, package management, SBOM formatları ve temel CI/CD güvenliğini öğrenin.
2. 1–3 ay: cosign, sigstore, in‑toto deneyimleri, ve SBOM otomasyonu ile küçük bir pipeline güvenliği projesi yapın.
3. 3–6 ay: Runtime artefakt doğrulama, registry politika uygulamaları ve third‑party risk assessment süreçlerini uygulamaya alın.
4. 6–12 ay: Provenance integration, enterprise SBOM envanteri, AI‑based prioritization ve incident response playbook'ları üzerinde deneyim kazanın.