DevSecOps: Kod Güvenliğini CI/CD Pipeline’a Taşımak

Modern yazılım geliştirme ekipleri artık yalnızca daha iyi yazılım üretmeye değil, daha hızlı yazılım üretmeye de odaklanıyor.

Yeni özellikler daha kısa sürede geliştiriliyor.

Kod değişiklikleri gün içerisinde defalarca repository sistemlerine gönderiliyor.

CI/CD pipeline’ları sayesinde test, build ve deployment süreçleri otomatik hale geliyor.

Bu hız işletmelere büyük avantaj sağlıyor.

Ancak güvenlik tarafında önemli bir soru ortaya çıkıyor:

Yazılım geliştirme bu kadar hızlanırken güvenlik kontrolleri aynı hızda nasıl uygulanacak?

Geleneksel yöntemde güvenlik çoğu zaman yazılım geliştirme sürecinin sonunda devreye girerdi.

Uygulama geliştirilirdi.

Testler tamamlanırdı.

Release yaklaşırdı.

Son aşamada güvenlik ekibine gönderilirdi.

Pentest yapılırdı.

Kaynak kod analizi gerçekleştirilirdi.

Kritik bir açık bulunursa uygulama yeniden geliştirme ekibine dönerdi.

Bu model yavaş release yapılan dönemlerde uygulanabilir görünüyordu.

Ancak bugün günde onlarca deployment yapan bir organizasyonda aynı model sürdürülebilir değildir.

Her deployment öncesinde manuel güvenlik testi yapılamaz.

Her Pull Request güvenlik uzmanı tarafından tek tek incelenemez.

Her dependency güncellemesi manuel olarak değerlendirilemez.

Bu nedenle güvenlik kontrollerinin yazılım geliştirme sürecinin doğal bir parçası haline gelmesi gerekir.

Tam olarak burada DevSecOps yaklaşımı devreye girer.

DevSecOps’un amacı güvenliği geliştirme ekiplerinin karşısına son aşamada çıkan bir kontrol noktası olmaktan çıkarmaktır.

Güvenliği;

Planlama → Kodlama → Commit → Build → Test → Release → Deployment → Production

zincirinin tamamına entegre etmeyi hedefler.

Bu yaklaşımın en önemli prensiplerinden biri şudur:

Güvenlik geliştirmenin hızını durdurmamalıdır; güvenli geliştirmeyi otomatik hale getirmelidir.

1. DevSecOps Nedir?

DevSecOps, Development, Security ve Operations kavramlarının birleşiminden oluşur.

Temel amacı güvenliğin DevOps süreçlerine entegre edilmesidir.

Ancak DevSecOps’u yalnızca CI/CD pipeline’a birkaç güvenlik aracı eklemek olarak değerlendirmek eksik olur.

Gerçek DevSecOps yaklaşımı üç temel bileşenden oluşur:

İnsan

Süreç

Teknoloji

İnsan tarafında geliştiriciler, güvenlik uzmanları ve operasyon ekipleri birlikte çalışır.

Süreç tarafında güvenlik gereksinimleri ve politikaları yazılım geliştirme yaşam döngüsüne dahil edilir.

Teknoloji tarafında ise güvenlik kontrolleri mümkün olduğunca otomatik hale getirilir.

Bu nedenle DevSecOps bir ürün değildir.

Bir SAST lisansı satın almak da tek başına DevSecOps değildir.

DevSecOps daha geniş bir çalışma modelidir.

2. DevOps ile DevSecOps Arasındaki Fark Nedir?

DevOps’un temel amaçlarından biri geliştirme ve operasyon ekipleri arasındaki bariyerleri azaltmaktır.

Geliştirici kod yazar.

Pipeline otomatik test gerçekleştirir.

Build oluşturulur.

Uygulama otomatik olarak ilgili ortama alınır.

DevSecOps bu sürece güvenliği dahil eder.

Örneğin klasik DevOps pipeline’ı:

Commit

↓

Unit Test

↓

Build

↓

Deploy

şeklinde olabilir.

DevSecOps pipeline’ı ise:

Commit

↓

Secret Scanning

↓

SAST

↓

SCA

↓

Unit Test

↓

Build

↓

Container Scan

↓

Security Quality Gate

↓

Deploy

şeklinde genişletilebilir.

Aradaki temel fark güvenliğin otomatik geliştirme akışının bir parçası haline gelmesidir.

3. DevSecOps Neden Gereklidir?

Modern yazılım geliştirme hızında yalnızca manuel güvenlik süreçlerine güvenmek mümkün değildir.

Örneğin 100 geliştiricisi olan bir kurum düşünelim.

Her geliştirici günde ortalama birkaç commit yapıyor olabilir.

Bu yüzlerce kod değişikliği anlamına gelir.

Güvenlik ekibinin bütün değişiklikleri manuel olarak incelemesi gerçekçi değildir.

Dolayısıyla otomasyona ihtiyaç vardır.

DevSecOps güvenlik ekibinin her kod satırını manuel incelemesini değil;

güvenlik bilgisini otomatik kontrollere dönüştürmesini

hedefler.

4. Shift Left ve DevSecOps İlişkisi

DevSecOps’un temel kavramlarından biri Shift Left Security yaklaşımıdır.

Geleneksel yazılım geliştirme akışı soldan sağa düşünülür:

Planlama → Tasarım → Geliştirme → Test → Production

Güvenlik yalnızca sağ tarafta yapılırsa sorunlar geç tespit edilir.

Shift Left yaklaşımı güvenliği daha erken aşamalara taşır.

Örneğin:

Tasarım sırasında Threat Modeling.

Kodlama sırasında Secure Coding.

Commit sırasında Secret Scanning.

Pull Request sırasında SAST.

Build sırasında SCA.

Bu sayede güvenlik problemi production’a ulaşmadan önce tespit edilebilir.

5. Shift Left Her Şeyi Sola Taşımak mıdır?

Hayır.

Shift Left bazen yanlış anlaşılır.

Amaç bütün güvenlik testlerini geliştirici bilgisayarına taşımak değildir.

Her güvenlik kontrolünün uygun olduğu aşama farklıdır.

Örneğin SAST erken aşamada çok değerlidir.

Ancak production ortamındaki gerçek WAF davranışı ancak runtime sırasında görülebilir.

Pentest de çalışan uygulama üzerinde değer üretir.

Bu nedenle ideal model:

Shift Left + Shift Right

yaklaşımıdır.

Güvenlik hem geliştirme aşamasında hem çalışma aşamasında devam eder.

6. CI Nedir?

CI, yani Continuous Integration, geliştiricilerin yaptığı kod değişikliklerinin merkezi repository’ye sık şekilde entegre edilmesini ifade eder.

Kod gönderildiğinde otomatik olarak:

• build,
• unit test,
• quality control

gibi işlemler çalışabilir.

Güvenlik kontrollerinin en önemli entegrasyon noktalarından biri CI sürecidir.

Çünkü güvenlik problemi daha ana branch’e alınmadan görülebilir.

7. CD Nedir?

CD iki farklı şekilde kullanılabilir:

Continuous Delivery

veya

Continuous Deployment

Continuous Delivery’de uygulama her zaman production’a alınabilir durumda tutulur ancak son deployment manuel onay gerektirebilir.

Continuous Deployment’da ise gerekli kontrolleri geçen kod otomatik olarak production’a alınabilir.

Her iki durumda da güvenlik kontrollerinin pipeline içinde olması kritik öneme sahiptir.

Çünkü otomatik deployment varsa güvenli olmayan kod da aynı hızla production’a gidebilir.

8. CI/CD Pipeline Nedir?

CI/CD pipeline, yazılım kodunun geliştiriciden production ortamına kadar geçtiği otomatik işlem zinciridir.

Örneğin:

Source

↓

Compile

↓

Test

↓

Build

↓

Package

↓

Deploy

şeklinde olabilir.

DevSecOps yaklaşımı bu zincire güvenlik kontrollerini ekler.

Pipeline böylece yalnızca yazılım üretmez.

Aynı zamanda yazılımın belirlenen güvenlik kriterlerini karşılayıp karşılamadığını da kontrol eder.

9. DevSecOps Pipeline Nerede Başlamalıdır?

İdeal güvenlik pipeline’ı geliştiricinin kodu remote repository’ye göndermesinden önce başlar.

Örneğin:

IDE

Kod yazılırken güvenlik uyarısı.

Pre-Commit

Secret Scanning.

Pull Request

SAST ve SCA.

Build

Full Security Scan.

Test Environment

DAST ve API Security.

Release

Security Quality Gate.

Production

Continuous Monitoring.

Bu yaklaşım güvenliği bir noktaya değil bütün yaşam döngüsüne dağıtır.

10. IDE Security Nedir?

Geliştiricinin kullandığı IDE içerisine güvenlik eklentileri entegre edilebilir.

Örneğin geliştirici güvensiz bir fonksiyon kullandığında IDE anında uyarı gösterebilir.

Bu yaklaşım son derece değerlidir.

Çünkü geliştirici güvenlik hatasını haftalar sonra raporda değil, kodu yazdığı anda görür.

Bu feedback loop ne kadar kısa olursa remediation o kadar kolaylaşır.

11. Developer Feedback Loop

DevSecOps’un en önemli hedeflerinden biri güvenlik geri bildirim süresini azaltmaktır.

Örneğin güvenlik açığı pentest sırasında iki ay sonra bulunursa geliştirici ilgili kodu unutmuş olabilir.

Aynı açık Pull Request aşamasında bulunursa kod hâlâ geliştiricinin zihnindedir.

Düzeltme çok daha hızlı yapılabilir.

Bu nedenle ideal güvenlik sistemi:

problemi mümkün olduğunca kodun oluşturulduğu ana yakın göstermelidir.

12. Pre-Commit Security

Pre-Commit Security, kod repository’ye gönderilmeden önce gerçekleştirilen güvenlik kontrolleridir.

En uygun kontrollerden biri Secret Scanning’dir.

Örneğin geliştirici yanlışlıkla production API key içeren dosyayı commit etmeye çalışır.

Pre-commit kontrolü secret’ı tespit eder.

Commit durdurulur.

Bu durumda bilgi remote repository geçmişine hiç girmez.

Bu, olay olduktan sonra credential rotation yapmaktan çok daha güçlü bir güvenlik yaklaşımıdır.

13. Pull Request Security

Pull Request veya Merge Request aşaması DevSecOps için en değerli kontrol noktalarından biridir.

Kod henüz ana branch’e alınmamıştır.

Geliştirici değişikliklerini tamamlamıştır.

Automated Security Scan çalıştırılabilir.

Örneğin:

• SAST
• SCA
• Secret Scanning
• IaC Security

kontrolleri otomatik olarak gerçekleştirilebilir.

Bulgu Pull Request ekranında geliştiriciye gösterilebilir.

14. Pull Request İçerisinde Security Review

Güvenlik bulgusunun ayrı bir PDF raporunda sunulması yerine geliştiricinin çalışma ortamına taşınması daha etkilidir.

Örneğin ilgili kod satırının yanında:

High – Potential SQL Injection

uyarısı gösterilebilir.

Altında:

• problemin açıklaması,
• CWE bilgisi,
• güvenli kod önerisi

bulunabilir.

Bu yaklaşım geliştirici deneyimini ciddi şekilde iyileştirir.

15. SAST Pipeline’a Nasıl Entegre Edilir?

SAST genellikle kod checkout edildikten sonra çalıştırılabilir.

Örnek:

Git Checkout

↓

SAST Scan

↓

Result Analysis

↓

Quality Gate

↓

Build

SAST sonucunda yeni Critical veya High bulgu varsa pipeline politika gereği durdurulabilir.

Ancak bütün bulgular nedeniyle build durdurulmamalıdır.

Risk bazlı yaklaşım gereklidir.

16. Incremental SAST Neden Önemlidir?

Büyük uygulamalarda full SAST analizi uzun sürebilir.

Her Pull Request’te 45 dakika süren tarama geliştirici deneyimini kötüleştirebilir.

Bu nedenle incremental scan kullanılabilir.

Yalnızca değişen kod ve ilişkili veri akışları analiz edilir.

Örneğin:

Pull Request → Incremental Scan

Nightly Build → Full Scan

modeli kullanılabilir.

Bu sayede hız ve güvenlik arasında denge sağlanır.

17. SCA Pipeline Entegrasyonu

SCA, dependency dosyalarını veya build çıktısını analiz etmek için pipeline içerisinde çalıştırılabilir.

Örneğin:

package-lock.json

pom.xml

requirements.txt

dosyaları kontrol edilebilir.

Kritik CVE bulunan dependency tespit edilirse geliştiriciye uyarı verilebilir.

Fixed version önerilebilir.

18. SCA Quality Gate Nasıl Olmalı?

Bütün CVE’lerde build engellenmemelidir.

Örneğin risk modeli şu kriterleri birlikte kullanabilir:

• Critical severity
• Reachable
• Public exploit
• Internet-facing application

Bu şartları karşılayan bir dependency vulnerability build’i durdurabilir.

Düşük riskli bulgular backlog’a alınabilir.

Bu, geliştiricinin yüzlerce gereksiz güvenlik uyarısıyla karşılaşmasını engeller.

19. Secret Scanning Pipeline Entegrasyonu

Secret Scanning mümkün olduğunca erken çalışmalıdır.

Ancak CI/CD pipeline içerisinde de ikinci kontrol olarak kullanılabilir.

Örneğin geliştirici pre-commit kontrolünü bypass etmiş olabilir.

Pipeline secret tespit ederse build durdurulabilir.

Özellikle:

• production API key,
• private key,
• cloud credential

bulguları otomatik bloklama için uygun olabilir.

20. Active Secret Tespit Edilirse Ne Olmalı?

Pipeline yalnızca:

“Secret bulundu.”

demekle kalmamalıdır.

Eğer aktif production credential repository’ye girdiyse olay güvenlik olayı haline gelebilir.

Bu durumda süreç:

Block

↓

Revoke

↓

Rotate

↓

Investigate

şeklinde ilerlemelidir.

Çünkü secret Git geçmişine girdiyse sadece koddan silmek yeterli değildir.

21. IaC Security Nedir?

Modern DevOps ekipleri altyapıyı da kod olarak yönetir.

Terraform, Kubernetes YAML ve benzeri Infrastructure as Code yapılandırmaları kullanılabilir.

Bu dosyalarda güvenlik yanlış yapılandırmaları bulunabilir.

Örneğin:

• public storage,
• açık firewall rule,
• privileged container,
• excessive IAM permission

gibi problemler IaC scanning araçlarıyla erken aşamada tespit edilebilir.

22. Infrastructure as Code Neden Shift Left İçin Önemlidir?

Cloud ortamında güvenlik problemi production’a çıktıktan sonra tespit edilebilir.

Ancak aynı hata Terraform dosyasında daha deployment yapılmadan bulunabilir.

Örneğin storage bucket’ın public olması IaC içerisinde görülebilir.

Pipeline deployment’ı durdurabilir.

Bu, cloud misconfiguration’ın production’a hiç ulaşmamasını sağlar.

23. Container Security Pipeline’a Nasıl Eklenir?

Container kullanan uygulamalarda build sonrasında image scanning yapılabilir.

Örneğin pipeline:

Code

↓

SAST

↓

SCA

↓

Docker Build

↓

Container Scan

↓

Sign Image

↓

Deploy

şeklinde ilerleyebilir.

Container scan sırasında hem application dependency hem de OS package açıkları tespit edilebilir.

24. Base Image Politikası

Geliştiricilerin rastgele container base image kullanması supply chain riskini artırabilir.

Kurumsal politika ile yalnızca onaylı base image’ların kullanılmasına izin verilebilir.

Örneğin internal registry içerisinde:

Approved Base Images

tutulabilir.

Image’lar düzenli olarak patch edilir.

Geliştiriciler doğrudan public registry’den bilinmeyen image çekmez.

25. Container Image Signing

Build tamamlandıktan sonra image dijital olarak imzalanabilir.

Deployment sistemi yalnızca güvenilir CI/CD pipeline tarafından imzalanmış image’ları kabul edebilir.

Bu şu saldırıyı önlemeye yardımcı olur:

Saldırgan registry’ye zararlı image yükler.

Kubernetes bu image’ı çalıştırmaya çalışır.

Signature policy:

Trusted signature yok → Deployment reddedildi.

Bu supply chain güvenliğinde güçlü bir kontroldür.

26. Security Quality Gate Nedir?

Security Quality Gate, yazılımın pipeline’ın bir sonraki aşamasına geçmesi için karşılaması gereken güvenlik kriteridir.

Örneğin politika şöyle olabilir:

• Yeni Critical SAST bulgusu yok.
• Reachable Critical dependency yok.
• Active secret yok.
• Container’da kritik exploit edilebilir CVE yok.

Bu şartlardan biri karşılanmazsa pipeline durdurulabilir.

27. Quality Gate’in Amacı Nedir?

Amaç geliştiricinin işini zorlaştırmak değildir.

Amaç kabul edilemez güvenlik riskinin production’a ulaşmasını engellemektir.

Quality Gate şu soruya cevap verir:

“Bu release kurumun kabul ettiği minimum güvenlik seviyesini karşılıyor mu?”

Bu sınır kurumun risk iştahına göre belirlenir.

28. Her Güvenlik Bulgusu Build’i Durdurmalı mı?

Hayır.

Bu DevSecOps projelerinde yapılan en büyük hatalardan biridir.

Örneğin SAST 500 Low bulgu üretiyorsa hepsi build’i durdurmamalıdır.

Aksi halde geliştiriciler güvenlik aracını devre dışı bırakmaya çalışabilir.

Quality Gate şu şekilde olabilir:

Critical → Block

High → Risk ve uygulama kritikliğine göre

Medium → Ticket

Low → Backlog

Bu yalnızca örnektir.

Kurumsal risk modeline göre özelleştirilmelidir.

29. New Vulnerability ile Existing Vulnerability Ayrımı

Legacy uygulamalarda binlerce geçmiş güvenlik bulgusu olabilir.

DevSecOps ilk devreye alındığında bunların tamamında pipeline durursa geliştirme yapılamaz hale gelebilir.

Bu nedenle New Code Policy kullanılabilir.

Temel prensip:

Yeni güvenlik açığı üretme.

Existing Security Debt ayrı backlog’da yönetilir.

Yeni kod daha sıkı güvenlik politikasına tabi tutulur.

30. Security Debt DevSecOps İçerisinde Nasıl Yönetilir?

Geçmiş güvenlik problemleri risk bazlı şekilde sınıflandırılabilir.

Örneğin:

Critical

Acil remediation.

High

Planlı sprint.

Medium

Backlog.

Yeni kodda ise farklı politika uygulanabilir:

Yeni Critical / High → Merge yok.

Bu model güvenliği iyileştirirken geliştirme sürecinin tamamen durmasını engeller.

31. Build Breaker Nedir?

Build Breaker, belirli güvenlik kriterleri sağlanmadığında CI/CD sürecini otomatik durduran mekanizmadır.

Örneğin:

SAST Critical Found

↓

Build Failed

Ancak Build Breaker dikkatli kullanılmalıdır.

Yanlış Positive nedeniyle sürekli build duruyorsa güvenlik sistemi güven kaybeder.

Bu nedenle yalnızca yüksek doğruluklu güvenlik kontrollerinde uygulanmalıdır.

32. False Positive DevSecOps’u Nasıl Etkiler?

SAST veya diğer güvenlik araçları çok fazla False Positive üretirse geliştirici ekipleri sürekli yanlış uyarılarla uğraşır.

Bu durum:

Security Alert Fatigue

oluşturabilir.

Bir süre sonra gerçek kritik bulgular da göz ardı edilebilir.

Bu nedenle DevSecOps otomasyonunun başarısı yalnızca araç sayısıyla ölçülmemelidir.

Signal-to-Noise Ratio

yani gerçek değerli bulgu oranı kritik öneme sahiptir.

33. Security Triage Otomatik Olabilir mi?

Bazı triage adımları otomatikleştirilebilir.

Örneğin:

• duplicate detection,
• reachability,
• asset criticality,
• exploit intelligence

otomatik olarak bulguya eklenebilir.

Ancak kritik durumlarda insan doğrulaması hâlâ önemlidir.

İdeal yaklaşım:

Automation First, Human Where Needed

şeklinde olabilir.

34. Developer Exception Süreci

Bazı durumlarda güvenlik bulgusu bilerek kabul edilebilir.

Örneğin geliştirici:

“Bu vulnerability bizim kullanım senaryomuzda reachable değil.”

diyebilir.

Bu durumda exception süreci bulunmalıdır.

Exception:

• gerekçeli,
• süreli,
• owner atanmış,
• audit edilebilir

olmalıdır.

Süresiz ve kontrolsüz suppress mekanizması güvenlik politikasını etkisiz hale getirebilir.

35. False Positive Suppression Nasıl Yönetilmeli?

Bir bulgu gerçekten False Positive ise sistemde suppress edilebilir.

Ancak şu bilgiler tutulmalıdır:

• kim suppress etti,
• neden,
• ne zaman,
• hangi scope için,
• expiration tarihi.

Böylece güvenlik kararı izlenebilir hale gelir.

36. Security as Code Nedir?

DevSecOps’un ileri kavramlarından biri Security as Code yaklaşımıdır.

Güvenlik politikalarının manuel doküman olmaktan çıkarılıp makine tarafından uygulanabilir kurallara dönüştürülmesini ifade eder.

Örneğin:

Production container root çalışamaz.

kuralı dokümanda yazmak yerine pipeline policy olarak uygulanabilir.

Deployment bu koşulu karşılamazsa otomatik engellenebilir.

37. Policy as Code Nedir?

Policy as Code güvenlik ve uyum politikalarının kod şeklinde yönetilmesidir.

Örneğin cloud deployment sırasında:

• public IP yasak,
• encryption zorunlu,
• privileged container yasak,
• belirli region dışında deployment yasak

gibi politikalar otomatik uygulanabilir.

Bu yaklaşım güvenlik politikasının manuel kontrol ihtiyacını azaltır.

38. Security Policy Git’te Tutulabilir mi?

Evet.

Policy as Code kuralları version control içerisinde tutulabilir.

Bu önemli avantajlar sağlar.

Kim değiştirdi?

Ne zaman değiştirdi?

Hangi kural kaldırıldı?

Pull Request review yapıldı mı?

hepsi görülebilir.

Böylece güvenlik politikası da yazılım kodu gibi yönetilebilir.

39. DevSecOps’ta Threat Modeling Nerede Yer Alır?

Her güvenlik kontrolü otomatik değildir.

Threat Modeling daha çok tasarım aşamasında yapılır.

Yeni sistem tasarlanırken:

• trust boundary,
• authentication,
• data flow,
• external integration,
• high-value asset

analiz edilir.

Buradan çıkan güvenlik gereksinimleri daha sonra pipeline kontrollerine dönüştürülebilir.

Örneğin threat model:

Bu servis yalnızca internal network’ten erişilebilir olmalı.

diyorsa IaC policy bunu otomatik enforce edebilir.

40. Security Requirement as Code

Güvenlik gereksinimleri mümkün olduğunca test edilebilir hale getirilebilir.

Örneğin gereksinim:

Bütün API endpoint’lerinde authentication zorunlu.

Bu bazı framework’lerde automated rule ile kontrol edilebilir.

Böylece security requirement dokümanda unutulmaz.

CI/CD içerisinde sürekli doğrulanır.

41. Security Champion DevSecOps’ta Neden Önemlidir?

Güvenlik ekibi bütün geliştirme ekiplerine tek başına yetişemez.

Bu nedenle ekip içerisindeki geliştiricilerden bazıları Security Champion rolü üstlenebilir.

Security Champion:

• güvenlik bulgularını anlamaya,
• geliştiricilere yardımcı olmaya,
• Secure Coding standardını yaymaya,
• AppSec ekibiyle iletişim kurmaya

yardımcı olur.

Bu model DevSecOps kültürünü güçlendirir.

42. Security Champion Güvenlik Uzmanı mıdır?

Şart değildir.

Genellikle ana rolü yazılım geliştiricidir.

Ancak güvenlik konusunda daha fazla eğitim ve sorumluluk alır.

Amaç her ekibe tam zamanlı security engineer yerleştirmek değil;

güvenlik bilgisini ekiplerin içerisine yaymaktır.

43. DevSecOps Geliştiricinin Sorumluluğunu Artırır mı?

Evet, ancak güvenliğin tamamını geliştiriciye yüklememelidir.

Geliştiricinin:

• Secure Coding prensiplerini bilmesi,
• güvenlik uyarılarını değerlendirmesi,
• doğru remediation uygulaması

beklenebilir.

Ancak AppSec ekibinin de:

• araçları yönetmesi,
• politikaları oluşturması,
• kritik bulguları doğrulaması,
• eğitim sağlaması

gerekir.

Güvenlik ortak sorumluluktur.

44. “You Build It, You Secure It”

DevSecOps kültüründe bazen:

“You build it, you run it.”

prensibine güvenlik de eklenir.

Yani:

“You build it, you secure it.”

Ancak bu ifade güvenlik ekibinin sorumluluğunu ortadan kaldırmaz.

Amaç geliştiricinin güvenliğin yalnızca başka bir departmanın işi olmadığını anlamasıdır.

45. Developer Security Training

DevSecOps otomasyonu eğitim olmadan eksik kalır.

Araç geliştiriciye:

CWE-89

uyarısı veriyorsa geliştiricinin bunun ne anlama geldiğini anlayabilmesi gerekir.

Secure Coding eğitimleri teknoloji stack’e göre özelleştirilebilir.

Örneğin:

Java geliştiricileri,

.NET geliştiricileri,

frontend ekipleri

farklı güvenlik örnekleriyle eğitilebilir.

46. Just-in-Time Security Training

Yıllık genel Secure Coding eğitimine ek olarak bulgu anında kısa eğitim verilebilir.

Örneğin geliştirici SQL Injection bulgusu aldığında:

“Parameterized Query nasıl kullanılır?”

şeklinde kısa rehber gösterilebilir.

Bu yöntem Just-in-Time Security Training olarak düşünülebilir.

Bilgi ihtiyaç anında verildiği için daha etkili olabilir.

47. Secure Code Snippet

İyi AppSec araçları yalnızca hatayı göstermekle kalmamalıdır.

Güvenli alternatif de sunmalıdır.

Örneğin:

Unsafe

String concatenation SQL.

Secure

Parameterized query.

Bu yaklaşım geliştiricinin remediation süresini azaltır.

48. Security Ticket Automation

Doğrulanmış bulgular otomatik olarak iş takip sistemine aktarılabilir.

Örneğin:

SAST bulgusu

↓

Jira ticket

↓

Application Owner

↓

SLA

↓

Remediation

↓

Retest

Bu sayede güvenlik bulgusu PDF içerisinde kaybolmaz.

49. AppSec Orchestration

Çok sayıda security scanner kullanıldığında sonuçların merkezi yönetimi zorlaşabilir.

SAST farklı sistemde.

SCA başka platformda.

DAST ayrı konsolda.

Container security farklı yerde.

Bu noktada AppSec Orchestration veya Application Security Posture Management yaklaşımları kullanılabilir.

Amaç bütün bulguları tek risk görünümünde toplamak ve önceliklendirmektir.

50. Duplicate Finding Problemi

Aynı güvenlik açığı birden fazla araç tarafından bulunabilir.

Örneğin SQL Injection:

SAST,

DAST,

Pentest

tarafından ayrı ayrı raporlanabilir.

Merkezi platform bu bulguları tek issue altında birleştirebilir.

Bu security backlog’un şişmesini engeller.

51. Asset Context Neden Önemlidir?

Aynı güvenlik açığı farklı uygulamalarda aynı riski taşımaz.

Örneğin:

Critical vulnerability

internal demo uygulamasında olabilir.

Aynı vulnerability

internet-facing ödeme sisteminde olabilir.

Risk farklıdır.

Bu nedenle DevSecOps bulgularına application context eklenmelidir.

52. Application Criticality

Her uygulamaya iş kritikliği atanabilir.

Örneğin:

Tier 1 – Kritik

Tier 2 – Yüksek

Tier 3 – Standart

Tier 4 – Düşük

Security Quality Gate buna göre farklı olabilir.

Kritik finans uygulamasında daha sıkı politika uygulanırken internal düşük riskli araçta daha esnek politika kullanılabilir.

53. Risk-Based DevSecOps

Olgun DevSecOps yaklaşımı bütün uygulamalara aynı güvenlik yükünü uygulamaz.

Risk bazlı çalışır.

Örneğin Tier 1 uygulamada:

• SAST
• SCA
• Secret Scan
• DAST
• Pentest
• Threat Modeling

zorunlu olabilir.

Tier 4 uygulamada ise:

• SAST
• SCA
• Secret Scan

yeterli görülebilir.

Bu güvenlik kaynaklarının doğru kullanılmasını sağlar.

54. DevSecOps ve API Security

API’ler modern uygulamaların ana saldırı yüzeylerinden biridir.

DevSecOps pipeline içerisinde:

• API schema validation,
• SAST,
• API DAST,
• secret scanning

uygulanabilir.

Release öncesinde manuel API pentest de gerçekleştirilebilir.

Özellikle authorization problemleri otomasyonla tamamen çözülemez.

55. DevSecOps ve Microservices

Mikroservis mimarisinde yüzlerce repository ve bağımsız deployment olabilir.

Manuel güvenlik yaklaşımı burada daha da zorlaşır.

DevSecOps sayesinde her mikroservis standart güvenlik pipeline’ından geçebilir.

Örneğin shared template kullanılabilir:

SAST

SCA

Container Scan

Sign

Deploy

Bu standardizasyon büyük ölçekli kurumlarda çok değerlidir.

56. Golden Pipeline Nedir?

Golden Pipeline, kurum tarafından onaylanmış standart CI/CD pipeline şablonudur.

Geliştirme ekipleri sıfırdan pipeline oluşturmak yerine güvenli template kullanır.

Örneğin Golden Pipeline içerisinde varsayılan olarak:

• SAST,
• SCA,
• Secret Scanning,
• container scanning,
• signing

bulunabilir.

Bu yaklaşım güvenliği “optional” olmaktan çıkarır.

57. Paved Road Yaklaşımı

Platform Engineering dünyasında kullanılan Paved Road yaklaşımı geliştiriciye güvenli ve kolay yol sunmayı hedefler.

Geliştiriciye:

“Şunları yapman zorunlu.”

demek yerine,

güvenli pipeline,

güvenli base image,

onaylı library,

hazır authentication component

sunulur.

Güvenli yol aynı zamanda en kolay yol haline gelir.

Bu başarılı DevSecOps kültürünün güçlü prensiplerinden biridir.

58. Güvenliği Kolaylaştırmak

Eğer güvenli yöntem geliştirici için çok zor ise zaman baskısı altında bypass edilme ihtimali artar.

Bu nedenle güvenlik kontrolleri mümkün olduğunca geliştirici dostu olmalıdır.

Örneğin:

Parolayı koda yazma.

yerine:

Tek satırla Secrets Manager’dan çek.

çözümü sunulmalıdır.

Güvenli yöntem kolaylaştıkça uyum artar.

59. Developer Experience ile Security Dengesi

Başarılı DevSecOps programında iki hedef dengelenmelidir:

Security

ve

Developer Velocity

Güvenlik ekibi her şeyi engellerse yazılım geliştirme yavaşlar.

Her şeyi serbest bırakırsa risk artar.

Risk bazlı automation bu dengeyi sağlar.

60. Pipeline Security’nin Kendisi Güvenli mi?

Bu kritik bir sorudur.

CI/CD pipeline’a güvenlik araçları eklemek yeterli değildir.

Pipeline’ın kendisinin de korunması gerekir.

Çünkü CI/CD sistemi genellikle:

• source code,
• production credential,
• container registry,
• cloud infrastructure

erişimine sahiptir.

Saldırgan pipeline’ı ele geçirirse bütün yazılım tedarik zincirini etkileyebilir.

61. CI/CD Access Control

CI/CD yönetim yetkileri minimum tutulmalıdır.

Örneğin her geliştirici:

• production secret,
• pipeline configuration,
• deployment approval

değiştirememelidir.

Least Privilege ve separation of duties uygulanabilir.

62. Branch Protection

Kritik branch’lerde doğrudan push yasaklanabilir.

Örneğin main branch için:

• Pull Request zorunlu,
• iki reviewer,
• security checks successful,
• signed commit

şartları uygulanabilir.

Böylece tek kullanıcının doğrudan production kodunu değiştirmesi zorlaştırılır.

63. Code Owner Nedir?

CODEOWNERS veya benzeri mekanizmalar belirli dosya ve modüller için zorunlu reviewer belirleyebilir.

Örneğin:

authentication kodundaki değişiklikler Security Champion onayı gerektirebilir.

CI/CD configuration değişiklikleri DevOps owner onayı gerektirebilir.

Bu riskli kod bölgelerinde ek kontrol sağlar.

64. Production Deployment Approval

Kritik uygulamalarda Continuous Deployment yerine approval gate kullanılabilir.

Örneğin:

Bütün otomatik kontroller başarılı.

↓

Release Manager Onayı.

↓

Production Deployment.

Bu özellikle regüle ve kritik sistemlerde faydalı olabilir.

65. Separation of Duties

Aynı kişinin:

kod yazması,

review etmesi,

production’a deploy etmesi

her ortamda istenmeyebilir.

Separation of Duties belirli kritik işlemlerde ikinci onay mekanizması sağlar.

DevSecOps otomasyon ile bu gereksinimi kolaylaştırabilir.

66. CI/CD Secrets Nasıl Yönetilmeli?

Pipeline içinde production credential açık metin tutulmamalıdır.

Merkezi secret store kullanılabilir.

Pipeline yalnızca çalıştığı anda gerekli secret’a erişir.

Mümkünse short-lived identity tercih edilmelidir.

Örneğin static cloud key yerine workload identity kullanılabilir.

67. Short-Lived Credentials

Kısa ömürlü credential DevSecOps güvenliğini ciddi şekilde artırabilir.

Örneğin CI/CD pipeline cloud’a deployment yapmak için 1 yıllık access key kullanmak yerine 15 dakikalık temporary token alabilir.

Token çalınsa bile saldırganın kullanım süresi sınırlı olur.

68. Build Reproducibility

Güvenli supply chain için aynı kaynak koddan aynı build sonucunun üretilebilmesi değerlidir.

Bu reproducible build yaklaşımı supply chain manipülasyonlarını tespit etmeye yardımcı olabilir.

Build ortamı mümkün olduğunca kontrollü ve deterministik olmalıdır.

69. Immutable Artifact

Build tamamlandıktan sonra artifact değiştirilmemelidir.

Örneğin:

Build Once → Promote Same Artifact

yaklaşımı kullanılabilir.

Test ortamında onaylanan image başka şekilde yeniden build edilmeden production’a taşınır.

Böylece test edilen artifact ile production artifact aynı olur.

70. SBOM Pipeline’a Nasıl Eklenir?

Build sırasında otomatik SBOM üretilebilir.

Örneğin:

Build

↓

SCA

↓

SBOM Generation

↓

Artifact Signing

↓

Release

Her release ile SBOM saklanabilir.

Bu ileride yeni CVE çıktığında hızlı etki analizi sağlar.

71. Provenance Nedir?

Software provenance bir artifact’ın nasıl üretildiği hakkında bilgi sağlar.

Örneğin:

• hangi repository,
• hangi commit,
• hangi pipeline,
• hangi build environment

kullanıldığı kaydedilebilir.

Bu supply chain güvenliğinde önemlidir.

Çünkü production’daki artifact’ın kaynağı doğrulanabilir.

72. DevSecOps Metrikleri

DevSecOps programının başarılı olup olmadığını ölçmek gerekir.

Örneğin şu metrikler takip edilebilir:

• Pull Request başına güvenlik bulgusu
• Critical vulnerability sayısı
• Mean Time to Remediate
• Security Gate failure oranı
• SAST kapsamındaki repository oranı
• SCA kapsamındaki uygulama oranı
• Secret leak sayısı
• Production sonrası bulunan açık sayısı

Bu metrikler AppSec olgunluğunu ölçmeye yardımcı olur.

73. Mean Time to Remediate

MTTR, güvenlik bulgusunun tespit edilmesinden kapanmasına kadar geçen ortalama süreyi ifade eder.

DevSecOps’un önemli hedeflerinden biri MTTR değerini azaltmaktır.

Çünkü bulgu geliştiriciye hızlı ulaştığında remediation daha hızlı olur.

74. Mean Time to Detect

Bir başka önemli metrik problemin ne kadar hızlı tespit edildiğidir.

Geleneksel modelde güvenlik açığı aylar sonra pentestte bulunabilir.

DevSecOps modelinde Pull Request sırasında birkaç dakika içerisinde bulunabilir.

Bu ciddi bir güvenlik avantajıdır.

75. Vulnerability Escape Rate

Bir güvenlik açığının geliştirme ve test kontrollerinden kaçıp production’a ulaşması ölçülebilir.

Amaç zaman içerisinde bu oranı azaltmaktır.

Bu metrik AppSec kontrollerinin ne kadar etkili olduğunu gösterebilir.

76. Security Coverage

Kaç repository SAST kapsamında?

Kaç uygulama SCA kullanıyor?

Kaç pipeline Secret Scanning uyguluyor?

Kaç uygulamanın SBOM’u var?

Bu oranlar güvenlik programının kapsama seviyesini gösterir.

77. Finding Count Tek Başına İyi Bir Metrik midir?

Hayır.

“Bu ay 5.000 güvenlik açığı bulduk.”

tek başına başarı göstergesi değildir.

Hatta kötü süreç göstergesi olabilir.

Daha anlamlı sorular:

• Kaçı gerçekti?
• Kaçı tekrar eden problemdi?
• Kaçı production’a ulaştı?
• Ne kadar sürede düzeltildi?
• Aynı CWE yeniden oluşuyor mu?

olmalıdır.

78. DevSecOps Olgunluk Yolculuğu

DevSecOps tek seferlik proje değildir.

Aşamalı olarak geliştirilebilir.

Seviye 1

Manuel pentest.

Seviye 2

SAST ve SCA.

Seviye 3

CI/CD automation.

Seviye 4

Security Quality Gate.

Seviye 5

Threat Modeling + Security Champions.

Seviye 6

Risk-based Continuous AppSec.

Bu yapı kurumdan kuruma farklılık gösterebilir.

79. Her Kurum Aynı DevSecOps Modelini Kullanmalı mı?

Hayır.

Küçük yazılım ekibi ile yüzlerce geliştiricisi olan finans kuruluşunun ihtiyaçları aynı değildir.

DevSecOps mimarisi:

• ekip büyüklüğü,
• teknoloji stack,
• regülasyon,
• release sıklığı,
• uygulama kritikliği

doğrultusunda tasarlanmalıdır.

Ama temel prensip aynıdır:

Güvenliği yazılım geliştirme yaşam döngüsüne entegre etmek.

80. DevSecOps Araç Projesi Değildir

DevSecOps başarısızlıklarının temel nedenlerinden biri yalnızca araç satın alınmasına odaklanmaktır.

SAST ürünü alınır.

SCA ürünü alınır.

DAST alınır.

Ama geliştirici sürece dahil edilmez.

Bulgular yönetilmez.

Quality Gate tanımlanmaz.

False Positive temizlenmez.

Bu durumda araçlar security noise üretir.

Gerçek DevSecOps:

People + Process + Technology

üçlüsünü birlikte yönetir.

SecureSys DevSecOps ve CI/CD Güvenliği Yaklaşımı

SecureSys olarak DevSecOps’u yalnızca CI/CD pipeline içerisine güvenlik tarama araçları eklemek şeklinde değerlendirmiyoruz.

Amaç güvenliği geliştirme sürecinin sonunda uygulanan bir kontrol olmaktan çıkarıp yazılım yaşam döngüsünün doğal bir parçası haline getirmektir.

Proje kapsamına göre;

Secure Coding, SAST, SCA, Secret Scanning, IaC Security, Container Security, DAST, API Security ve Pentest

kontrollerinin CI/CD süreçleriyle birlikte değerlendirilmesi mümkündür.

Ancak teknik entegrasyon kadar önemli başka bir konu daha vardır:

Doğru güvenlik kontrolünü doğru noktada çalıştırmak.

Her commit sonrasında uzun süren full scan çalıştırılması geliştirici deneyimini bozabilir.

Her Low severity bulguda pipeline durdurulması sürdürülebilir değildir.

Her güvenlik kararının manuel onay gerektirmesi DevOps hızını ortadan kaldırabilir.

Bu nedenle güçlü DevSecOps modeli:

hız + otomasyon + risk bazlı güvenlik

dengesini kurmalıdır.

Örneğin:

Developer aşamasında hızlı güvenlik geri bildirimi,

Pull Request sırasında incremental SAST,

Build sırasında SCA ve Secret Scanning,

Release öncesinde Security Quality Gate,

kritik uygulamalarda manuel pentest,

production ortamında sürekli güvenlik izleme

birlikte değerlendirilebilir.

Sonuçta DevSecOps’un gerçek başarısı:

kaç güvenlik aracı kurulduğuyla değil, güvenlik problemlerinin production’a ulaşmadan ne kadar erken engellenebildiğiyle ölçülmelidir.

Sık Sorulan Sorular

DevSecOps nedir?

DevSecOps, güvenlik kontrollerinin DevOps ve yazılım geliştirme yaşam döngüsüne entegre edilmesi yaklaşımıdır.

DevOps ile DevSecOps arasındaki fark nedir?

DevSecOps, DevOps süreçlerine güvenliği tasarım, geliştirme, build, test ve deployment aşamalarında dahil eder.

CI/CD pipeline nedir?

Kaynak kodun test edilmesi, build edilmesi ve ilgili ortama deploy edilmesi gibi işlemlerin otomatik olarak yürütüldüğü süreçtir.

SAST CI/CD pipeline’a entegre edilebilir mi?

Evet. SAST Pull Request, Merge Request veya build aşamasında otomatik çalıştırılabilir.

SCA CI/CD içerisinde kullanılabilir mi?

Evet. Dependency dosyaları ve build bileşenleri otomatik olarak bilinen güvenlik açıkları açısından taranabilir.

Security Quality Gate nedir?

Yazılımın pipeline’ın sonraki aşamasına geçebilmesi için karşılaması gereken minimum güvenlik kriteridir.

Her güvenlik bulgusu build’i durdurmalı mı?

Hayır. Risk bazlı politika uygulanmalıdır. Aksi halde güvenlik kontrolleri geliştirme sürecini gereksiz şekilde yavaşlatabilir.

Secret Scanning ne zaman çalıştırılmalıdır?

Mümkün olduğunca pre-commit aşamasından başlayarak Pull Request ve CI/CD pipeline içerisinde de çalıştırılması faydalıdır.

DevSecOps pentestin yerine geçer mi?

Hayır. DevSecOps sürekli otomatik güvenlik kontrolleri sağlarken pentest gerçek saldırgan perspektifinden derin manuel değerlendirme sağlar.

DevSecOps için mutlaka çok sayıda araç gerekir mi?

Hayır. Araç sayısından daha önemli olan doğru kontrollerin doğru aşamalarda entegre edilmesi ve bulguların sürdürülebilir biçimde yönetilmesidir.

Sonuç: Güvenlik Pipeline’ın Sonunda Değil, İçinde Olmalıdır

Modern yazılım geliştirme dünyasında güvenliğin release öncesindeki son kontrol noktası olarak kalması artık yeterli değildir.

Çünkü yazılım çok hızlı değişmektedir.

Yeni kod yazılır.

Yeni dependency eklenir.

Yeni container oluşturulur.

Yeni API yayınlanır.

Yeni cloud kaynağı devreye alınır.

Bütün bunlar birkaç saat içerisinde gerçekleşebilir.

Güvenlik bu hızın gerisinde kalırsa risk production ortamına taşınır.

DevSecOps bu nedenle güvenliği hızlandırmaya çalışır.

Güvenlik kontrolünü geliştiriciye yaklaştırır.

Manuel yapılan işlemleri otomatikleştirir.

Politikaları kod haline getirir.

SAST, SCA ve Secret Scanning gibi teknolojileri CI/CD’ye taşır.

Kritik riskleri release öncesinde durdurur.

Ve güvenlik uzmanının zamanını binlerce rutin kontrolden çıkararak gerçekten karmaşık risklere ayırmasını sağlar.

Başarılı DevSecOps’un temel prensibi şudur:

Güvenlik yazılım geliştirme hızının önünde duran bir kapı olmamalıdır.

Güvenliğin kendisi o yolun bir parçası olmalıdır.

Çünkü en güçlü güvenlik kontrolü production’da saldırıyı engelleyen kontrol değildir.

Daha güçlü olan:

güvensiz kodun production’a hiç ulaşmamasını sağlayan kontroldür.