1. Supply Chain Saldırıları Nedir?
Supply chain saldırıları; sizin sisteminize doğrudan saldırmak yerine, kullandığınız tedarik bileşenlerini hedef alır: paket depoları, dependency’ler, build araçları, container registry ve deployment süreçleri. Bu saldırıların en tehlikeli yanı; “normal güncelleme” gibi görünmesidir.
Supply chain saldırıları nedir, web projelerini nasıl etkiler?
Supply chain saldırıları; NPM/PyPI gibi paket ekosistemlerine, dependency isimlendirmelerine (typo-squatting), özel paket adlarına (dependency confusion) veya container imaj kaynaklarına sızarak sizin uygulamanıza arka kapı taşımayı hedefler. Web projelerinde bu; veri sızıntısı, ödeme/rezervasyon akışına müdahale veya API anahtarlarının ifşası gibi kritik sonuçlar doğurabilir.
Neden “günlük iş” içinde daha kolay kaçırılır?
- •Paket güncellemesi rutin bir işlem gibi görünür
- •Dependency zinciri çok uzundur
- •Imajlar sık rebuild edilir ve kaynak takibi zayıflar
- •CI/CD’de “policy gate” yoksa risk prod’a kadar ilerler
☑ Mini Check : Supply chain risk sinyalleri
- •Projede çok sayıda 3rd party paket var mı?
- •Lockfile kullanımı zorunlu mu?
- •Paket kaynağı (registry) politikası var mı?
- •Container imajları hangi registry’den geliyor, denetleniyor mu?
- •CI’de tarama/policy ile build engeli var mı?
Ne yapmalıyım?
- • Paket ve imaj kaynaklarını “izinli liste”ye indir.
- • Lockfile’ı zorunlu kıl; drift’i azalt.
- • Internal registry ile kaynak kontrolü kur.
- • Build pipeline’da policy gate ekle (tarama + onay).
2. Paket Depoları ve Güvenilir Kaynak Seçimi
İlk savunma hattı “nereden indiriyorum?” sorusudur. NPM/PyPI/OS depolarında kötü niyetli paketler, sahte isimler ve compromised maintainer vakaları görülebilir. Bu nedenle hedef; güvenilir kaynak seçimi ve kaynak politikasını netleştirmektir.
Güvenilir kaynak politikası (prensip)
- •Resmî/kurumsal onaylı registry’ler
- •Paket adı ve scope kuralları
- •İmzalı/artifact doğrulaması (mümkünse)
- •“Yeni paket ekleme” için review süreci
Typo-squatting ve dependency confusion riskleri
- •Typo-squatting: popüler paketin benzer isimlisi
- •Dependency confusion: internal paket adının public registry’den çekilmesi
Bu iki risk, kaynak politikanız zayıfsa kolay çalışır.
☑ Mini Check : Kaynak kontrolü
- •Hangi registry’lerden çekileceği tanımlı mı?
- •Yeni paket eklemek için code review şart mı?
- •Internal paket isimleri korunuyor mu?
- •Paket sürümleri rastgele mi, yoksa planlı mı?
- •Paket ekleme/güncelleme loglanıyor mu?
Ne yapmalıyım?
- • Registry politikasını yaz ve build pipeline’a uygula.
- • Yeni dependency eklemeyi PR + review şartına bağla.
- • Internal paket isimlendirmesiyle confusion riskini azalt.
- • Kritik modüllerde bağımlılık minimizasyonu yap (Internal link: /tr/yazilim/web-sitesi-gelistirme).
3. Dependency Yönetimi ve Kilitleme (Lockfile)
Lockfile, supply chain güvenliğinin “temel emniyet kemeri”dir: aynı bağımlılık ağacını tekrar üretmenizi sağlar, sürpriz güncellemeleri azaltır. Ayrıca patch/vulnerability yönetimini daha kontrollü hale getirir.
Kütüphane/dependency güvenliğini nasıl sağlarım?
Lockfile ile bağımlılık sürümlerini sabitleyin, güncellemeleri planlı PR’larla yönetin ve tarama sonuçlarını (CVE) risk bazlı önceliklendirin. Kritik paketlerde minimum bağımlılık ve güvenilir kaynak politikası uygulayın; güncelleme sonrası test ve rollback planı oluşturun.
Lockfile + policy birlikte çalışmalı
Lockfile tek başına yetmez; lockfile’ın güncellenmesi de kontrol altında olmalı:
- •Dependabot/benzeri otomasyon varsa review zorunlu
- •“Bir anda büyük güncelleme” yerine kademeli
- •Kritik modüllerde “minimum dependency” prensibi
Otel ve B2B örneği
- •Otel ödeme/rezervasyon modülü: 3rd party bağımlılık sayısı minimize edilmeli
- •B2B entegrasyon SDK’ları: sürüm pinleme + test + roll-forward/rollback planı
☑ Mini Check : Lock stratejisi
- •Lockfile repo’da zorunlu mu?
- •Lockfile değişikliği review ediliyor mu?
- •Kritik paketler için pinleme stratejisi var mı?
- •Vulnerability bulguları ticket’a dönüşüyor mu?
- •Güncelleme sonrası test/rollback akışı var mı?
Ne yapmalıyım?
- • Lockfile’ı zorunlu kıl; CI’da kontrol et.
- • Dependency update’lerini PR bazında ve kademeli yönet.
- • Vulnerability bulgularını risk bazlı önceliklendir.
- • Kritik modüllerde bağımlılıkları azalt.
4. Container İmaj Kaynakları
Container dünyasında supply chain, “hangi base image?” ve “hangi registry?” sorularında yoğunlaşır. Resmî ve minimal base image’ler, güvenilir registry’ler ve imajların “provenance” (kaynak geçmişi) kontrolü kritik hale gelir.
Image registry güvenliği
- •Registry erişim yetkileri (RBAC)
- •İmaj taraması ve politika (kritik CVE’de blok)
- •Signed images/provenance (mümkünse)
- •Eski imajların yaşam döngüsü ve cleanup
Base image seçimi
- •Resmî/onaylı base image listesi
- •Minimal katmanlar
- •Düzenli rebuild ve patch
“Build→Image→Deploy” zincirini güvenli yapmak
Supply chain katmanlarının birbirine bağlandığı yer burasıdır: build çıktısı güvenilir mi, image içine secret girmiyor mu, deploy pipeline policy gate ile korunuyor mu?
☑ Mini Check : Image kaynak kontrolü
- •Approved base image listesi var mı?
- •Registry erişimleri rol bazlı mı?
- •İmaj taraması CI/registry tarafında zorunlu mu?
- •Critical CVE’de deploy bloklanıyor mu?
- •Rebuild/rollout rutini var mı?
Ne yapmalıyım?
- • Base image’i standardize et (approved list).
- • Registry’yi RBAC ile sıkılaştır; public push yok.
- • İmaj taramasını policy gate yap.
- • Eski imaj riskini azaltmak için düzenli rebuild/rollout planla.
5. Otel ve B2B İçin Supply Chain Risk Senaryoları
Teoriyi operasyonla bağlamak için tipik senaryoları ele alalım: otelde ödeme/rezervasyon; B2B’de entegrasyon SDK’ları ve worker’lar.
Otel senaryosu — rezervasyon/ödeme modülünde 3rd party paket
- •Risk: ödeme akışına müdahale, token sızıntısı
- •Kontrol: minimal dependency + lockfile + kaynak policy + code review
- •İzleme: anomali istek, beklenmeyen outbound bağlantı
B2B senaryosu — entegrasyon SDK’sı ve dependency confusion
- •Risk: internal paket ismi public registry’den çözülür
- •Kontrol: internal registry + scope/prefix standardı + lockfile
- •Süreç: güncelleme PR’ları + test + rollback
Otel ve B2B projelerinde supply chain riskini azaltmak için hangi adımları atmalıyım?
Güvenilir registry ve onaylı paket/imaj listesi kullanın, dependency’leri lockfile ile sabitleyin, internal registry ile kaynakları kontrol edin ve CI/CD’de tarama + policy gate ile riskli güncellemeleri prod’a sokmayın. Kritik modüllerde bağımlılık minimizasyonu ve düzenli rebuild/rollout rutini uygulayın.
Fark yaratan mini bölüm (Competitor Gap): “Haber” değil “günlük rutin”
TR’de supply chain çoğunlukla haber seviyesinde konuşuluyor; asıl fark, bunu günlük rutine bağlamaktır: lockfile disiplinini CI’ya koymak, internal registry, policy gate, approved list ve periyodik gözden geçirme.
☑ Mini Check : Sürdürülebilir supply chain programı
- •Approved dependency + base image listesi var
- •Lockfile + internal registry standardı var
- •CI’da tarama ve policy gate var
- •Critical modüllerde bağımlılık minimizasyonu yapıldı
- •365 günlük periyotta politika gözden geçiriliyor
Ne yapmalıyım?
- • “Onaylı kaynaklar” listesini yayınla (paket + imaj).
- • Lockfile ve internal registry’yi standart yap.
- • CI policy gate ile riskli update’leri blokla.
- • Web geliştirme ve sunucu güvenlik süreçleriyle entegre et (Internal link: /tr/yazilim/web-sitesi-gelistirme, /tr/yazilim/sunucu-guvenlik).
6. İçerik içi tablo (Dependency kontrol ve lock stratejileri)
| Katman | Kontrol | Amaç | Kanıt/Çıktı |
|---|---|---|---|
| Paket kaynağı | Güvenilir registry + allowlist | Kötü paket riskini azalt | Registry policy dokümanı |
| Dependency | Lockfile zorunlu | Sürpriz güncellemeyi azalt | CI lockfile check |
| Internal paket | Internal registry | Confusion riskini azalt | Scope/prefix standardı |
| Image | Approved base image | Saldırı yüzeyini azalt | Base image listesi |
| Build | Tarama + policy gate | Riskliyi prod’a sokma | CI raporu + blok kayıtları |
| Deploy | Rebuild/rollout rutini | Eski zafiyetleri azalt | Release takvimi |
7. Dependency & Registry Supply Chain Güvenlik Checklist Şablonunu İndir
Dependency & Registry Supply Chain Güvenlik Checklist Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu asset; paket/dependency ve container imaj kaynaklarını “güvenilir ve denetlenebilir” hale getirmek için hazırlanmıştır. Lockfile, internal registry ve approved base image standardını kurar; CI policy gate ile riskli güncellemeleri prod’a sokmamayı hedefler. Amaç; supply chain saldırı yüzeyini küçültmektir.
Kim Kullanır?
Backend/DevOps, platform mühendisliği, otel/B2B yazılım ekipleri.
Nasıl Kullanılır?
- Registry ve dependency kaynak politikasını doldur.
- Lockfile ve internal registry adımlarını CI gate’e bağla.
- Image tarama ve deploy policy’leriyle döngüyü kapat.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Onaylı registry listesi var (NPM/PyPI/OS)
- ▢ ✅ Lockfile zorunlu ve CI’da kontrol ediliyor
- ▢ ✅ New dependency ekleme PR+review şart
- ▢ ✅ Internal registry (paket) kullanım planı var
- ▢ ✅ Internal paket isimlendirme standardı var
- ▢ ✅ Approved base image listesi var
- ▢ ✅ Image taraması CI/registry’de zorunlu
- ▢ ✅ Critical CVE’de build/deploy bloklanıyor
- ▢ ✅ Rebuild/rollout rutini var
- ▢ ✅ 365 gün gözden geçirme takvimi var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables listesi
- •Registry policy + allowlist
- •Lockfile + CI gate
- •Internal registry planı
- •Approved base image listesi
- •Scan + policy gate raporu
Bir Sonraki Adım
Dependency ve imaj kaynaklarını kontrol altına alıp typo-squatting/registry risklerini azaltmak isteyen otel ve B2B yazılım ekipleri için.
Sık Sorulan Sorular
Supply chain saldırıları nedir, web projelerini nasıl etkiler?▾
Kütüphane/dependency güvenliğini nasıl sağlarım?▾
Internal registry ve lockfile kullanmak ne işe yarar?▾
Otel ve B2B projelerinde supply chain riskini azaltmak için hangi adımları atmalıyım?▾
npm/paket güncellerken güvenlikten nasıl emin olurum?▾
İlgili İçerikler
İlgili Yazılar