Bölüm 33

Secure Deployment & CI/CD

15 dk okuma3.055 kelimePHP 8.1+

Ön koşul

Bölüm 3 (Secure SDLC), Bölüm 25 (CI sırları, Codecov), Bölüm 29 (IaC/container), Bölüm 30 (tedarik zinciri, SBOM, imzalama), Bölüm 31 (izleme). İleri referans: Bölüm 34 (backdoor).

Bu bölümün kazanımı

Dağıtım hattının (CI/CD pipeline) neden güçlü bir saldırı yüzeyi olduğunu; build sisteminin ele geçirilmesinin (SolarWinds) meşru imzalı bir artefakta kötü kod enjekte edebildiğini; ve savunmaları (en az yetkili/izole CI, build bütünlüğü/provenance, sır koruma) öğreneceksiniz.

1. Giriş

Uygulamanızı ne kadar güvenli yazarsanız yazın, onu inşa eden ve dağıtan hat (CI/CD pipeline) ele geçirilirse, bu güvenliğin hiçbir anlamı kalmaz. Modern yazılım, kaynaktan (source) üretime giden otomatik bir boru hattından geçer: derleme (build), test, artefakt üretimi, dağıtım (deploy). Bu hattın her adımı — ve onu çalıştıran sistemler — güçlü ayrıcalıklara sahiptir: dağıtım kimlik bilgileri, bulut erişimi, imzalama anahtarları, üretim sırları. Bir CI/CD sistemini ele geçirmek, üretimi ele geçirmektir.

Bunun en çarpıcı ve endişe verici örneği SolarWinds SUNBURST saldırısıdır (Bölüm 11): saldırganlar, SolarWinds'in build sistemini ele geçirip Orion yazılımının derleme sürecine kötü kod enjekte ettiler. Bu kod, SolarWinds'in geçerli sertifikasıyla imzalanıp meşru güncelleme kanalları üzerinden 18.000'den fazla kuruma dağıtıldı. Kullanıcılar imzalı, "güvenilir" bir güncelleme kurduklarını sanıyordu — oysa içinde bir arka kapı vardı. Bu vaka bir ilkeyi kanıtladı: "Doğrulama olmadan güven anlamsızdır" — ve imzalamanın tek başına yetmediğini, çünkü build sistemi ele geçirilmişse imza da kötü kodu meşru kılar.

Bu bölüm, dağıtımı ve CI/CD hattını güvence altına almayı ele alır. Kısım VII'nin operasyonel temasını sürdürür: uygulama kodu (Kısım I-V) ve altyapı (Kısım VI) güvenli olsa bile, onları üreten ve dağıtan süreç de güvenli olmalıdır.

2. Temel Teori

Dağıtım hattı = saldırı yüzeyi. Tipik CI/CD akışı: kaynak → build → test → artefakt → deploy → üretim. Her adım bir hedeftir ve pipeline'ı çalıştıran sistemler güçlü erişime sahiptir:

Varlık	Neden değerli
Dağıtım kimlik bilgileri	Üretime doğrudan erişim
Bulut anahtarları	Altyapı kontrolü (Bölüm 21, 25)
İmzalama anahtarları	Kötü artefaktı "meşru" gösterme
Üretim sırları	DB/API erişimi (Bölüm 25)
Build sistemi	Kaynağa/artefakta kod enjeksiyonu (SolarWinds)

Başlıca tehditler: - Build sistemi ele geçirme (SolarWinds): Saldırgan build sürecine kötü kod enjekte eder; artefakt meşru imzayla çıkar. - CI sır hırsızlığı (Codecov, Bölüm 25): Ele geçirilmiş bir CI aracı, ortam değişkenlerindeki sırları sızdırır. - Zehirlenmiş pipeline yürütme (Poisoned Pipeline Execution): Saldırgan, pipeline yapılandırmasını (pipeline-as-code) değiştirerek kötü adımlar ekler. - Tahrif edilmiş artefakt: Build ile deploy arasında artefakt değiştirilir. - Kötü IaC: Terraform/Dockerfile/manifest'lere kötü/yanlış yapılandırma (Bölüm 29).

Kritik ders — imzalama gerekli ama yeterli değil. SolarWinds, artefaktın imzalı olmasının onu güvenilir kılmadığını gösterdi: build sistemi ele geçirilmişse, imza da kötü kodu "meşru" gösterir. Bu yüzden savunma, imzalamanın yanında build sürecinin kendisini korumayı gerektirir: build bütünlüğü, provenance (kaynak-kanıtı), izole/ephemeral build ortamları.

Savunmalar (özet): 1. En az yetkili CI/CD (Bölüm 1, 25): Kapsamlı, kısa-ömürlü kimlik bilgileri; "god-mode" değil. Her pipeline yalnızca gerekene erişsin. 2. İzole/ephemeral build: Temiz, geçici, kalıcı sır barındırmayan build ortamları. 3. Build bütünlüğü + provenance (SLSA): Artefaktın nereden/nasıl üretildiğini kanıtla; tekrarlanabilir build. 4. Artefakt imzalama + doğrulama — ama build sürecini de koru (SolarWinds dersi). 5. İmzalama anahtarlarını koru (HSM, Bölüm 25). 6. Ortam ayrımı: dev/staging/prod izole; gereksiz üretim sırrı CI'da tutulmaz. 7. Güvenli IaC (Bölüm 29): Terraform/Dockerfile tarama. 8. Pipeline config değişikliklerini incele: pipeline-as-code de koddur (inceleme + commit imzalama, Bölüm 30). 9. SBOM + provenance (Bölüm 30): Neyin, nereden geldiğini izle. 10. Pipeline'ı izle (Bölüm 31): Anormal build/deploy davranışı. 11. Kaynağı koru: Branch koruması, 2FA, imzalı commit (Bölüm 30).

3. Mimarisel Bakış

 GÜVENSİZ (SolarWinds kalıbı):
   Saldırgan → BUILD sistemini ele geçir → derleme sürecine kod enjekte
        ↓  artefakt GEÇERLİ sertifikayla imzalanır (imza kötüyü meşru gösterir)
   Meşru güncelleme kanalı → 18.000+ kuruma dağıtım
        ↓  kullanıcı "imzalı/güvenilir" güncelleme kurar → arka kapı
        ✗ imzalama TEK BAŞINA yetmedi; build korunmalıydı

 GÜVENLİ:
   Kaynak (branch koruması + imzalı commit — Böl.30)
        ↓  [ İzole/ephemeral build + en-az-yetkili CI (Böl.25) ]
        ↓  [ build bütünlüğü + provenance (SLSA) + tekrarlanabilir ]
   Artefakt → imzala (HSM) + provenance ekle
        ↓  [ deploy'da imza + provenance DOĞRULA ]
   Üretim (ortam ayrımı; sır vault'tan deploy anında — Böl.25)
        ↓  [ pipeline izleme (Böl.31) + SBOM ]

 TEHDİTLER: build ele geçirme · CI sır hırsızlığı (Codecov) ·
            pipeline zehirlenmesi · artefakt tahrifi · kötü IaC

Kritik gözlem: güven, kaynaktan üretime her adımda doğrulanmalıdır; build sürecinin kendisi korunmadıkça imzalama yeterli değildir.

4. Güvensiz Kod

Gerçekçi (güvensiz) CI/CD yapılandırması:

# ⚠️ GÜVENSİZ pipeline (ör. GitHub Actions / GitLab CI)
deploy:
  script:
    # 1) God-mode kimlik: tüm buluta tam erişimli, uzun-ömürlü anahtar
    - export AWS_ACCESS_KEY_ID=$PROD_ADMIN_KEY   # her şeye yetkili, statik
    # 2) Sırlar ortamda, her adıma miras (Codecov riski — Bölüm 25)
    - ./third_party_uploader.sh                  # ele geçirilirse env sırları sızar
    # 3) Build ve deploy izole değil; kalıcı runner, temizlenmiyor
    - ./build.sh && ./deploy.sh
    # 4) Artefakt doğrulaması/provenance yok
    # 5) IaC taranmıyor; pipeline config incelenmiyor (pipeline-as-code)

5. Açığın Analizi

God-mode, uzun-ömürlü kimlik — Pipeline'a tüm buluta tam erişimli, statik bir anahtar veriliyor. Pipeline (veya bir adımı) ele geçirilirse, saldırgan tüm altyapıyı ele geçirir. CI kimlikleri kapsamlı ve kısa-ömürlü (OIDC/federated, geçici) olmalı; yalnızca gerekene erişmeli (Bölüm 1, 25).

Sırlar ortamda, her adıma miras — Codecov (Bölüm 25) dersi: ortam değişkenlerindeki sırlar, pipeline'daki her adıma (üçüncü taraf araçlar dahil) mirastır. Ele geçirilmiş bir araç (third_party_uploader.sh) bu sırları sızdırır. Sırlar adım-bazlı ve minimal olmalı; üçüncü taraf araçlara gereksiz sır verilmemeli.

İzole olmayan, kalıcı build — Build ve deploy aynı, temizlenmeyen kalıcı runner'da çalışıyor. Bir build'de bırakılan kötü kod/sır, sonraki build'lere sızabilir; ortam kirlidir. Build ortamları ephemeral (her seferinde temiz) ve izole olmalı.

Artefakt doğrulaması/provenance yok — Üretilen artefaktın nereden/nasıl geldiği kanıtlanmıyor; build ile deploy arasında tahrif edilse fark edilmez. Provenance (SLSA) ve imza doğrulaması gerekir.

IaC taranmıyor, pipeline config incelenmiyor — Terraform/Dockerfile'lardaki kötü yapılandırma (Bölüm 29) ve pipeline-as-code değişiklikleri denetlenmiyor; saldırgan pipeline'a kötü adım ekleyebilir (poisoned pipeline). IaC taranmalı; pipeline config kod gibi incelenmeli (Bölüm 30).

Kök sorun: CI aşırı yetkili, sırlar korunmasız, build izole değil, artefakt doğrulanmıyor ve pipeline/IaC denetlenmiyor. Çözüm: en az yetki + izole build + provenance/imza + sır koruma + denetim.

6. Hacker Bakış Açısı

Saldırgan CI/CD'yi neden ve nasıl hedefler?

Yüksek kaldıraç arar. Pipeline, "tek nokta, çok erişim" sunar: bir pipeline üretime, buluta, imzalama anahtarlarına ve sırlara erişir. SolarWinds gibi, bir build sistemini ele geçirmek tüm downstream kullanıcılara ulaşmayı sağlar — devasa kaldıraç.

Build'e kod enjekte eder. SolarWinds kalıbı: build sürecine, meşru koda benzeyen (geliştirici denetiminden kaçan) kötü kod enjekte eder; artefakt geçerli imzayla çıkar. Bu, imzalamanın neden tek başına yetmediğini gösterir.

CI sırlarını çalar. Codecov (Bölüm 25) kalıbı: pipeline'da çalışan bir aracı ele geçirip ortam değişkenlerindeki sırları (bulut, DB, imzalama) sızdırır. Sonra bu sırlarla daha geniş erişim kazanır.

Pipeline'ı zehirler. Pipeline yapılandırmasını (pipeline-as-code) veya bir bağımlılığını değiştirerek kötü adımlar ekler (poisoned pipeline execution) — ör. bir test adımına sır sızdıran kod.

Kaynağı ve kimlikleri hedefler. Zayıf branch koruması, 2FA eksikliği veya çalınan geliştirici/CI token'ıyla kaynağa erişir; oradan pipeline'a veya doğrudan üretime ulaşır.

Savunmacı dersi: Saldırgan için CI/CD, uygulamayı atlayıp doğrudan üretime giden bir arka kapıdır. En az yetki, izole build, provenance/doğrulama ve sır koruma, bu kaldıracı ortadan kaldırır.

7. Exploit Mantığı

Bu bölüm saldırı tekniği içermez. CI/CD güvenliğinin neden kritik olduğu kavramsaldır:

Pipeline = üretime köprü. CI/CD, kaynaktan üretime giden güçlü ve otomatik yoldur; onu ele geçirmek, uygulama savunmalarını atlayıp doğrudan üretimi ele geçirmektir.
İmzalama gerekli ama yeterli değil. SolarWinds, build ele geçirilmişse imzanın kötü kodu meşru kıldığını gösterdi. Güven, artefaktın imzasında değil, nasıl üretildiğinin doğrulanmasında (provenance) yatar.
Tek ele geçirme, çok kurban. SolarWinds'te bir build sistemi, 18.000+ kuruma ulaştı — tedarik zinciri kaldıracı (Bölüm 30) ile aynı asimetri.
Sır sızıntısı zincirler. CI sırları (Codecov, Bölüm 25) sızınca, saldırgan bulut/DB/imzalama erişimiyle çok daha geniş bir ihlale tırmanır.

Savunmacının çerçevesi: (a) CI kimlikleri en-az-yetkili/kısa-ömürlü mü, (b) build izole/ephemeral mi, (c) artefakt provenance'ı doğrulanıyor mu, (d) sırlar korunuyor mu (Codecov), (e) pipeline/IaC denetleniyor mu. Savunma beşini de sağlar.

8. Güvenli Kod

Sertleştirilmiş CI/CD yapılandırması:

# ✅ GÜVENLİ pipeline
deploy:
  # 1) En az yetkili, KISA-ÖMÜRLÜ kimlik (OIDC/federated — statik anahtar yok)
  id-tokens: write            # OIDC ile geçici, kapsamlı bulut kimliği (Bölüm 25)
  environment: production     # ortam ayrımı + onay kapısı

  script:
    # 2) İzole/ephemeral runner; her build temiz başlar
    # 3) Sırlar adım-bazlı ve minimal; üçüncü taraf araca gereksiz sır YOK (Codecov)
    - ./build.sh                                  # sır gerektirmeyen build
    # 4) Artefakt imzala + PROVENANCE üret (SLSA)
    - cosign sign --key $SIGN_KEY artifact        # imzalama anahtarı HSM/KMS'te
    - slsa-provenance generate artifact           # nereden/nasıl üretildi
    # 5) SBOM üret (Bölüm 30)
    - syft artifact -o spdx-json > sbom.json

verify-and-deploy:
  script:
    # 6) Deploy ÖNCESİ imza + provenance DOĞRULA (SolarWinds dersi)
    - cosign verify --key $PUB_KEY artifact
    - slsa-verifier verify artifact               # provenance doğrula
    # 7) Sır vault'tan DEPLOY ANINDA çekilir (kalıcı değil — Bölüm 25)
    - ./deploy.sh

Ek katmanlar (kod dışı ama kritik):

- Kaynak koruması: branch koruması + zorunlu inceleme + imzalı commit (Bölüm 30) + 2FA
- Pipeline-as-code inceleme: pipeline config değişiklikleri kod gibi incelenir
- IaC tarama (Bölüm 29): Terraform/Dockerfile/manifest güvenlik denetimi (Checkov/Trivy)
- İmzalama anahtarları HSM/KMS'te (Bölüm 25); build ortamında kalıcı sır yok
- Pipeline izleme (Bölüm 31): anormal build/deploy, beklenmedik ağ, sır erişimi
- Ortam ayrımı: dev/staging/prod izole; en az yetki her ortamda

Öne çıkan modern pratikler: - En az yetkili, kısa-ömürlü CI kimlikleri (Bölüm 1, 25): OIDC/federated; statik god-mode anahtar yok. - İzole/ephemeral build: Her build temiz, geçici ortamda; kalıcı sır yok. - Build bütünlüğü + provenance (SLSA) + tekrarlanabilir build: Artefaktın nereden/nasıl geldiğini kanıtla. - Artefakt imzala + deploy'da doğrula — ama build'i de koru: SolarWinds dersi; imza tek başına yetmez. - İmzalama anahtarları HSM/KMS'te (Bölüm 25). - Sır koruma (Codecov dersi): Adım-bazlı minimal sır; üçüncü taraf araca gereksiz sır yok; sır deploy anında vault'tan. - Ortam ayrımı + IaC tarama (Bölüm 29) + pipeline-as-code inceleme. - Kaynak koruması (Bölüm 30): Branch koruması, imzalı commit, 2FA. - SBOM + provenance (Bölüm 30) + pipeline izleme (Bölüm 31).

9. Patch Analizi

Neden işe yarar? En az yetkili/kısa-ömürlü CI kimlikleri, bir pipeline ele geçirilse bile erişimi sınırlar. İzole/ephemeral build, kirlenmeyi ve kalıcı sır sızıntısını önler. Build bütünlüğü + provenance (SLSA), artefaktın nasıl üretildiğini doğrular — SolarWinds'in imza-tek-başına yetmezliğini kapatır. Sır koruma (Codecov dersi) CI sır hırsızlığını, ortam ayrımı gereksiz üretim erişimini engeller. Kaynak koruması + pipeline/IaC incelemesi, zehirlenmeyi önler. Bunlar birlikte, pipeline'ı uygulama savunmalarını atlayan bir arka kapı olmaktan çıkarır.

Neden imzalama yeterli değil (SolarWinds):

Savunma	Neyi kapatır	Boşluğu
Artefakt imzalama	Tahrif (deploy'da)	Build ele geçirilirse imza kötüyü meşru gösterir
+ Build bütünlüğü/provenance	Build enjeksiyonu	Nereden/nasıl üretildiğini kanıtlar
+ İzole/en-az-yetkili build	Build sistemi ele geçirme	Yüzeyi ve etkiyi daraltır

SolarWinds'in dersi tam bu satırdadır: imzalama gerekli ama build sürecinin kendisi korunmadıkça yetersizdir. Provenance ve izole build, bu boşluğu kapatır.

Performans: İmzalama/doğrulama ve provenance üretimi build'e küçük bir süre ekler; en az yetki ve izole build'in performans etkisi yoktur. Güvenlik kazancı (üretim devrini engelleme) çok büyüktür.

10. Gerçek Hayat Senaryosu

Kurgu — bir SaaS'ın dağıtım hattı. Pipeline, kolaylık için tüm buluta yetkili statik bir anahtar kullanıyor ve üçüncü taraf bir kapsama (coverage) aracını çalıştırıyor. O araç ele geçirilince (Codecov kalıbı, Bölüm 25), ortam değişkenlerindeki tüm sırları — bulut anahtarı, DB, imzalama — dışarı sızdırıyor. Saldırgan bu sırlarla build sistemine erişip, sonraki sürüme meşru koda benzeyen bir arka kapı enjekte ediyor (SolarWinds kalıbı); artefakt şirketin geçerli sertifikasıyla imzalanıp müşterilere dağıtılıyor. Doğru mimariyle: en-az-yetkili/kısa-ömürlü kimlik (god-mode sır yok) + üçüncü taraf araca sır vermeme + provenance doğrulama → hem sır hırsızlığı hem build enjeksiyonu engellenirdi. Dersler: (1) CI sırları minimal ve korunmalı (Codecov); (2) build süreci korunmalı, imza tek başına yetmez (SolarWinds); (3) provenance/doğrulama, "nasıl üretildi" sorusunu yanıtlar.

11. Gerçek Vaka Analizi — SolarWinds SUNBURST (2020)

ReversingLabs/Mandiant(FireEye)/Microsoft analizleri, CISA Acil Direktifi 21-01, MITRE ATT&CK T1195.002 ile doğrulanmıştır. Build hattı ele geçirmenin ders kitabı vakasıdır.

Özet. Aralık 2020'de, IT izleme yazılımı SolarWinds Orion'a sofistike bir tedarik zinciri saldırısı (SUNBURST/Solorigate) açıklandı. Saldırganlar (bir devlet destekli grup), Orion'un build sürecine kötü kod enjekte etti; bu kod, SolarWinds'in geçerli sertifikasıyla imzalanıp Mart–Haziran 2020 arasında meşru güncellemeler (Orion 2019.4–2020.2.1) yoluyla dağıtıldı. 18.000'den fazla müşteri kötü güncellemeyi kurdu (yaklaşık 100'ünde derin takip-ihlali görüldü; 9 federal ajans + ~100 özel şirket).

Teknik neden — build sistemi ele geçirme + imzanın yanıltıcılığı. Zaman çizelgesi öğreticidir: saldırganlar Eylül 2019'da SolarWinds ağına girdi, Ekim 2019'da kod enjeksiyonunu test etti, ve Şubat 2020'de SUNBURST'ü Orion build'ine yerleştirdi. ReversingLabs ve Microsoft'un analizine göre saldırganların üç adımlı planı vardı: (1) build sistemini ele geçir, (2) kendi kodunu enjekte et, (3) imzalı paketlerin istemci tarafında beklendiği gibi görüneceğini doğrula. Kötü kod (SolarWinds.Orion.Core.BusinessLayer.dll içinde), meşru Orion koduna benzeyecek şekilde yazıldı ki geliştirici denetiminden ve derlemeden sorunsuz geçsin. Derlenip SolarWinds'in geçerli imzalama altyapısıyla imzalandı — yani imza sistemi, güvenilmeyen kodu imzalamaya zorlandı.

Bu, bu bölümün merkezî dersinin kanıtıdır: artefaktın imzalı olması onu güvenilir yapmaz; build sistemi ele geçirilmişse imza da kötü kodu meşru gösterir. Kullanıcılar, geçerli imzalı bir SolarWinds güncellemesi kurduklarını — yani "güvenilir" bir şey — sanıyordu. Güven, imzada değil, build sürecinin bütünlüğünde olmalıydı. SUNBURST ayrıca sofistike kaçınma kullandı: ~2 hafta uykuda kaldı (IR zaman çizelgelerini aşmak için), swdev/solarwinds/sandbox/vmware gibi host adlarında çıkış yaptı (analiz ortamlarından kaçınma), ve DGA ile gizli C2 kurdu.

Etki. Küresel casusluk kampanyası; devlet ajansları ve büyük şirketler. Brad Smith (Microsoft) bunu "kitlesel, ayrım gözetmeyen küresel saldırı" olarak niteledi. Saldırı, yazılım güven zincirlerinin ne kadar kırılgan olduğunu gösterdi ve doğrudan yanıt olarak SLSA, SBOM ve provenance çerçeveleri, DevSecOps pipeline sertleştirmesi ve Zero Trust yaklaşımları yaygınlaştı.

Çıkarılacak dersler: 1. Build sistemi birinci sınıf bir hedeftir. Onu koru: en az yetki, izole/ephemeral build, erişim kontrolü, izleme. 2. İmzalama tek başına yetmez. Build ele geçirilmişse imza kötüyü meşru kılar; provenance (SLSA) ve build bütünlüğü şart. "Doğrulama olmadan güven anlamsızdır." 3. Build kimliklerini/sırlarını koru. Build sürecindeki kimlik yeniden kullanımı bir faktördü; en az yetki ve sır koruma (Bölüm 25) gerekir. 4. Provenance + SBOM (Bölüm 30). Artefaktın nereden/nasıl geldiğini izle; "trust is the new attack surface".

12. Detection

Pipeline yapılandırması incelemede:

grep -rniE 'ADMIN_KEY|_TOKEN|SECRET|PASSWORD' .github/ .gitlab-ci.yml   # god-mode/statik sır?
grep -rn 'id-tokens\|OIDC\|permissions' .github/workflows/              # en az yetki/OIDC?
grep -rn 'cosign\|slsa\|provenance\|sbom' .                             # imzalama/provenance var mı?
# IaC tarama ve pipeline-as-code inceleme durumunu kontrol et

Kontroller: CI kimlikleri en-az-yetkili/kısa-ömürlü mü? Build izole mi? Artefakt imzalanıp doğrulanıyor mu (provenance)? Sırlar korunuyor mu (Codecov)? IaC/pipeline denetleniyor mu?

SAST/pipeline tarama: CI/CD güvenlik denetimi (örn. pipeline yanlış yapılandırma, aşırı yetki, gömülü sır — Bölüm 25); IaC tarama (Checkov/Trivy — Bölüm 29).

Provenance/imza doğrulama: SLSA seviyesi; artefakt imza + provenance doğrulaması deploy öncesi zorunlu mu?

Runtime/SIEM (Bölüm 31): Pipeline'dan anormal davranış — beklenmedik giden bağlantılar (build sırasında C2), olağandışı sır erişimi (Codecov kalıbı), build çıktısında beklenmedik değişiklik, imzalama anahtarına anormal erişim. SUNBURST kaçınma göstergeleri (uzun uyku, host-adı kontrolleri) build ortamı izlemesiyle yakalanabilirdi.

13. Prevention

En az yetkili, kısa-ömürlü CI kimlikleri (Bölüm 1, 25): OIDC/federated; god-mode statik anahtar yok.
İzole/ephemeral build: Temiz, geçici ortam; kalıcı sır yok.
Build bütünlüğü + provenance (SLSA) + tekrarlanabilir build.
Artefakt imzala + deploy'da doğrula — build'i de koru (SolarWinds).
İmzalama anahtarları HSM/KMS'te (Bölüm 25).
Sır koruma (Codecov): Adım-bazlı minimal sır; üçüncü taraf araca gereksiz sır yok; sır deploy anında vault'tan.
Ortam ayrımı + IaC tarama (Bölüm 29) + pipeline-as-code inceleme (Bölüm 30).
Kaynak koruması (Bölüm 30): Branch koruması, imzalı commit, 2FA.
SBOM + provenance + pipeline izleme (Bölüm 31).

14. Mitigation

Acil: God-mode/statik CI kimliklerini kapsamlı/kısa-ömürlüye (OIDC) çevir; üçüncü taraf araçlardan gereksiz sırları kaldır (Codecov); imzalama anahtarlarını HSM/KMS'e al.
Geçici: Build sistemi ele geçirilmişse artefaktları provenance ile doğrula/yeniden inşa et; sızmış sırları döndür (Bölüm 25); pipeline izlerini adli analizle incele (Bölüm 32).
Kalıcı: İzole/ephemeral build + provenance (SLSA) + imza doğrulama + sır koruma standardını kur; IaC/pipeline taramasını ve izlemeyi (Bölüm 31) ekle; SBOM üret.

15. Checklist

[ ] CI/CD kimlikleri en-az-yetkili ve kısa-ömürlü mü (OIDC/federated, god-mode statik anahtar yok)?
[ ] Build ortamları izole/ephemeral mi (kalıcı sır yok)?
[ ] Artefaktlar imzalanıyor ve deploy öncesi imza + provenance doğrulanıyor mu?
[ ] Build bütünlüğü/provenance (SLSA) sağlanıyor mu (imza tek başına değil — SolarWinds)?
[ ] İmzalama anahtarları HSM/KMS'te mi (Bölüm 25)?
[ ] CI sırları adım-bazlı minimal mi; üçüncü taraf araca gereksiz sır verilmiyor mu (Codecov)?
[ ] Ortamlar (dev/staging/prod) ayrık ve en-az-yetkili mi?
[ ] IaC taranıyor (Bölüm 29) ve pipeline-as-code inceleniyor mu (Bölüm 30)?
[ ] Kaynak korunuyor mu (branch koruması, imzalı commit, 2FA)?
[ ] SBOM üretiliyor ve pipeline izleniyor mu (Bölüm 31)?

16. Laboratuvar

Lab 33.1 — En az yetkili CI. İzole bir pipeline'da god-mode statik anahtar yerine kapsamlı/kısa-ömürlü (OIDC benzeri) bir kimlik kur; erişimin nasıl daraldığını gözlemle.

Lab 33.2 — Artefakt imzalama + doğrulama. Bir artefaktı imzala (cosign) ve deploy öncesi doğrula; imzasız/tahrif edilmiş artefaktın reddedildiğini gör. Sonra "build ele geçirilirse imza neden yetmez"i (SolarWinds) tartış.

Lab 33.3 — Provenance. Bir build için provenance (SLSA) üret ve doğrula; artefaktın "nereden/nasıl üretildiği"nin nasıl kanıtlandığını gözlemle.

Lab 33.4 — CI sır sızıntısı (Codecov). Bir pipeline'da ortam sırlarının her adıma miras olduğunu göster; üçüncü taraf bir adımın bunları nasıl sızdırabileceğini modelle. Adım-bazlı minimal sırla düzelt.

17. Quiz

Dağıtım hattı (CI/CD) neden güçlü bir saldırı yüzeyidir?
SolarWinds'te saldırganlar neyi ele geçirdi ve kod nereye enjekte edildi?
"İmzalama gerekli ama yeterli değil" ne demektir (SolarWinds)?
Build bütünlüğü/provenance (SLSA) imzanın hangi boşluğunu kapatır?
Codecov (Bölüm 25) türü CI sır hırsızlığı nasıl çalışır ve nasıl önlenir?
En az yetkili, kısa-ömürlü CI kimlikleri (OIDC) neden önemlidir?
İzole/ephemeral build ortamı neyi önler?
"Poisoned pipeline execution" nedir ve inceleme onu nasıl azaltır?
SolarWinds'in üç adımlı saldırgan planı neydi?
SUNBURST hangi kaçınma tekniklerini kullandı (uyku, host-adı kontrolü)?
İmzalama anahtarları neden HSM/KMS'te olmalıdır (Bölüm 25)?
"Doğrulama olmadan güven anlamsızdır" ilkesini SolarWinds nasıl kanıtlar?

18. Kaynakça

MITRE ATT&CK, T1195.002 Supply Chain Compromise: Compromise Software Supply Chain; CISA Emergency Directive 21-01.
ReversingLabs, SUNBURST: the next level of stealth; Mandiant/FireEye, Highly Evasive Attacker Leverages SolarWinds Supply Chain; Microsoft, Deep Dive into Solorigate.
SLSA (Supply-chain Levels for Software Artifacts) çerçevesi; in-toto/Sigstore(cosign) dokümantasyonu; NIST SP 800-161r1 ve SP 800-218 (SSDF).
OWASP, CI/CD Security Cheat Sheet; Top 10 CI/CD Security Risks.
MITRE, CWE-1357 (Reliance on Insufficiently Trustworthy Component); CWE-506 (Embedded Malicious Code).