1. GİRİŞ

Günümüz yazılım geliştirme ortamlarında Continuous Integration (CI) ve Continuous Delivery/Deployment (CD) süreçleri, uygulamaların hızlı ve güvenilir şekilde üretime taşınmasını sağlar. Ancak hızla büyüyen dağıtım frekansları ve karmaşık tedarik zincirleri, güvenlik risklerini de beraberinde getirir. Secure CI/CD, güvenliğin pipeline'ın her aşamasına gömülmesi; build, test, release ve runtime safhalarında otomasyonla güvenlik kontrollerinin uygulanması anlamına gelir. Bu yazıda CI/CD güvenliğinin neden kritik olduğunu, hangi bileşenlerden oluştuğunu, nasıl çalıştığını ve gerçek dünya uygulamalarını mühendis perspektifiyle öğreneceksiniz.

Bu neden bugün önemli?

• Sürekli dağıtım döngüleri ile bir zafiyetin üretime hızlıca ulaşma riski artıyor.
• Tedarik zinciri saldırıları (dependabot saldırıları, imaj poisoning) yazılımın güvenilirliğini tehdit ediyor.
• Regülasyon ve uyumluluk gereksinimleri (PCI, HIPAA, GDPR) dağıtım hattının güvenliğini belgelemeyi istiyor.

Kimler için önemli?

Yazılım mühendisleri, DevOps ekipleri, güvenlik mühendisleri, SRE'ler ve teknik yöneticiler; pipeline güvenliği hem teknik hem organizasyonel kararlar gerektirdiğinden tüm paydaşlar için kritiktir.

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

• CI/CD: Kaynak koddan üretime kadar otomatik derleme, test ve dağıtım süreçleri.
• Artifact: Build çıktısı; binary, container image, paket veya manifest dosyaları.
• SBOM: Software Bill of Materials; bir artefaktın içerdiği tüm bileşenlerin listesi.
• Policy as Code: Güvenlik ve operasyon kurallarının kodla ifade edilmesi ve otomatik doğrulanması.
• Signing: Artifact imzalama; imzanın doğrulanması deploy öncesi güven sağlar.

2.2 Mimari bileşenler

• Source Control (Git)
• CI Server (Jenkins, GitHub Actions, GitLab CI, Azure DevOps)
• Artifact Repository (Docker Registry, Nexus, Artifactory)
• Secrets Manager (Vault, AWS Secrets Manager, Azure Key Vault)
• Policy Engine (OPA, Rego, Sentinel)
• Monitoring & SIEM/SOAR

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE VERİ AKIŞI

3.1 Pipeline aşamaları ve güvenlik kontrolleri

1. Commit/Pre‑merge: Pre‑commit hook'ları, linters ve hızlı SAST (static analysis) ile erken geri bildirim.
2. Build: İzole build agent'ları, reproducible build, dependency pinning ve SBOM üretimi.
3. Test: Unit, integration, SCA (Software Composition Analysis), SAST/DAST entegre testler.
4. Sign & Publish: Artifact signing, immutability (digest based tags), push to private registry.
5. Pre‑deploy gating: Policy as code kontrolleri, vulnerability gating, license compliance checks.
6. Deploy: Canary/blue‑green deployments, admission controller ve runtime policy enforcement.
7. Runtime: Telemetry, monitoring, EDR/NDR ile detection ve SOAR ile otomatik remediasyon.

3.2 Örnek veri akışı

Bir geliştirici pull request açtığında pre‑merge SAST ve linters çalışır. CI pipeline tetiklenir; bağımlılıklar sabitlenir, SBOM üretilir ve image inşa edilir. Image imzalanır ve registry'e gönderilir. Policy engine imzanın doğruluğunu ve tarama sonuçlarını kontrol eder; eğer kriterler sağlanıyorsa otomatik olarak canary'e deploy edilir. Canary'de telemetry toplanır; anormallik tespit edilirse SOAR playbook'ı tetiklenerek rollback veya izolasyon yapılır.

3.3 İzolasyon ve least privilege

Build agent'ları ve runner'lar izole network ve minimal izinlerle çalışmalıdır. CI hesabı ve deploy token'ları kısa ömürlü olmalı, least privilege prensibine uygun IAM rolleri ile sınırlandırılmalıdır. Anahtarlar ve credential'lar secrets manager'da tutulmalı, pipeline içinde env olarak değil, runtime injection ile erişilmelidir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix, Google ve büyük teknoloji uygulamaları

Büyük firmalar pipeline güvenliğini otomasyon ve policy merkezli yaklaşımla uygular. Örneğin, artefakt imzalama ve provenance takibi; SBOM ile zafiyet yönetimi; canary ve chaos engineering ile güvenlik testleri üretim benzeri koşullarda yürütülür.

4.2 Finans ve regülatör sektörler

Finans kurumları için deploy süreçleri sıkı onay ve audit izleri gerektirir. Birçok kurum pipeline'da approval gate'leri, immutable logs ve ayrıntılı SBOM kayıtları ile compliance'i sağlar.

4.3 KOBİ ve startup yaklaşımları

Küçük ekipler için managed CI (GitHub Actions, GitLab), cloud KMS ve managed registries hızlı başlangıç sağlar. Temel kontroller: SCA, secret management, image signing ve basic policy as code ile başlayıp olgunlaştıkça genişletilmelidir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Güvenliğin erken bulunması maliyeti düşürür ve üretim riskini azaltır.
• Otomasyon ile tekrarlanabilir ve izlenebilir süreçler kurulur.
• Artifact provenance ve imza doğrulama ile tedarik zinciri riski azalır.

Sınırlamalar

• CI/CD araç zinciri karmaşıklığı ve entegrasyon maliyeti.
• Yanlış yapılandırılmış otomasyonlar yanlış güven hissi verebilir; tuning ve sürekli gözlem gerekir.
• Tooling arasındaki veri standardı eksikliği SBOM ve provenance entegrasyonunu zorlaştırabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 CI ortamı ve build güvenliği

• İzolasyon: Build runner'ları container veya VM'de, ephemeral ve stateless olmalı.
• Reproducible builds: deterministic build süreçleri, kaynak ve araç zincirinin versiyon kilitlenmesi.
• SBOM üretimi: her build için SBOM oluşturup archive edin.

7.2 Secrets yönetimi

• Secrets manager kullanın; CI pipeline içinde secrets injection ile erişim verin.
• Never store secrets in repo; rotate tokens per job and use short‑lived credentials.
• Audit access and use of secrets; monitor for anomalous access patterns.

7.3 Artifact güvenliği

• Artifact signing (cosign, GPG), immutability ve digest‑based deployments kullanın.
• Vulnerability scanning: image/binary scanning at build and registry time.
• License compliance: third‑party license checks integrated with gating rules.

7.4 Policy as Code ve otomasyon

• Define policies in Rego/Sentinel and enforce in CI, IaC, and deploy phases.
• Run policy checks as early as possible; fail fast to reduce wasted cycles.
• Integrate policy violations into developer workflow with actionable feedback.

7.5 Runtime monitoring ve response

• Canary deployments with health and security probes.
• Collect telemetry (logs, metrics, traces) and correlate with CI events.
• SOAR playbooks for common remediation: revoke credentials, rollback, isolate IPs.

8. SIK YAPILAN HATALAR

• Secrets'ları repository içinde saklamak veya pipeline konfigürasyonunda plain text bırakmak.
• Build agent'larını public/shared runner olarak kullanmak ve izole etmemek.
• Artifact imzası ve SBOM üretimini atlamak — provenance eksikliği.
• Geliştirici deneyimini göz ardı edip aşırı katı gating politikaları koymak; bu, kuralları atlatmaya veya bypass etmeye yol açar.

9. GELECEK TRENDLER

9.1 AI destekli güvenlik otomasyonu

AI, vulnerability prioritization, exploit prediction ve otomatik remediation tavsiyeleri sağlayacak. Pipeline içinde anomaly detection ile potansiyel supply chain saldırıları erken tespit edilebilecek.

9.2 Standardizasyon ve SBOM yaygınlığı

SBOM üretimi ve tüketimi standartlaşacak; regülatörler SBOM gereksinimleri ile şirketleri zorlayabilir. Sigstore ve cosign gibi açık standartlar daha geniş kabul görecek.

9.3 Policy as Code'un kurumsallaşması

Merkezi policy layer ile IaC, pipeline, Kubernetes ve runtime politikaları tutarlı şekilde yönetilecek; bu, compliance otomasyonunu kolaylaştıracak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. CI pipeline'ında secrets'ları nasıl güvenli tutarım?

   Secrets manager kullanın; pipeline job'larında ephemeral credentials ile erişim sağlayın ve erişimleri audit edin. Repo veya pipeline konfigürasyonunda kesinlikle plain text saklamayın.

2. 2. SBOM neden önemli?

   SBOM, artefaktların içinde hangi bileşenlerin olduğunu gösterir; tedarik zinciri risklerini, lisans uyumluluğunu ve CVE takibini kolaylaştırır.

3. 3. Artifact signing ne sağlar?

   Signing, artefaktın kaynağını ve bütünlüğünü doğrular; deploy öncesi imzanın doğrulanması provenance sağlar ve imaj poisoning riskini azaltır.

4. 4. Build runner'ları nasıl izole etmeliyim?

   Ephemeral runner'lar, network segmentation, egress kontrol ve minimal izinlerle çalıştırılmalı; shared public runner'lar dikkatle yönetilmelidir.

5. 5. Hangi araçlarla başlayabilirim?

   Trivy/Dependabot (SCA), SonarQube/CodeQL (SAST), OWASP ZAP (DAST), cosign (signing), CycloneDX/CycloneDX (SBOM) başlangıç için uygun araçlardır.

6. 6. Policy as Code'u nasıl entegre ederim?

   OPA/Gatekeeper veya Sentinel ile IaC ve manifestler için Rego/Sentinel policy'leri geliştirip CI aşamasında doğrulayın; ihlal varsa pipeline'ı durdurun.

7. 7. Canary ve blue‑green deployment güvenliği için öneriler?

   Canary'de güvenlik telemetrisini yoğunlaştırın, canary beslemelerini limitli tutun, ve anomalilerde otomatik rollback playbook'ları kurun.

8. 8. Küçük ekipler için ilk 3 adım nedir?

   1) Secrets manager ve kısa ömürlü kredensiyeller, 2) Dependency scanning (SCA) ve basic SAST, 3) Artifact signing ve private registry ile başlayın.

Anahtar Kavramlar

• SBOM: Yazılım bileşenleri listesi—tedarik zinciri görünürlüğü sağlar.
• Artifact signing: Build çıktılarının imzalanması ve doğrulanması.
• Policy as Code: Güvenlik kurallarının otomatik denetimi için kodlanması.
• SOAR: Güvenlik operasyon otomasyonu ve orkestrasyonu.
• Reproducible builds: Aynı kaynakla aynı artefaktın üretilebilmesi.

Öğrenme Yol Haritası

1. 0–1 ay: Temel CI/CD kavramları, Git workflow ve temel güvenlik prensiplerini öğrenin.
2. 1–3 ay: SAST/SCA araçlarını entegre edin, secrets manager kurulumunu deneyin ve SBOM kavramlarını uygulayın.
3. 3–6 ay: Artifact signing, policy as code ve vulnerability gating uygulamalarını hayata geçirin.
4. 6–12 ay: SOAR entegrasyonu, runtime detection, canary güvenlik testleri ve supply chain assurance projelerinde deneyim kazanın.