Modern yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda h\u0131z ve \u00e7eviklik vazge\u00e7ilmez bir hal al\u0131rken, g\u00fcvenlik genellikle g\u00f6z ard\u0131 edilen ya da sonraya b\u0131rak\u0131lan bir konu olabiliyor. Peki, s\u00fcrekli entegrasyon ve s\u00fcrekli da\u011f\u0131t\u0131m (CI\/CD) boru hatlar\u0131m\u0131zda g\u00fcvenli\u011fi ba\u015f\u0131ndan itibaren otomatize ederek, hem h\u0131z\u0131 koruyup hem de potansiyel g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 minimuma indirmek m\u00fcmk\u00fcn m\u00fc? “100 G\u00fcn DevOps” yolculu\u011fumuzun 78. g\u00fcn\u00fcnde, bu kritik sorunun cevab\u0131n\u0131 DevSecOps felsefesiyle arayacak, CI\/CD s\u00fcre\u00e7lerinize g\u00fcvenli\u011fi nas\u0131l entegre edebilece\u011finizi ad\u0131m ad\u0131m inceleyece\u011fiz.<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn rekabet\u00e7i i\u015f d\u00fcnyas\u0131nda, \u015firketler yaz\u0131l\u0131mlar\u0131n\u0131 m\u00fcmk\u00fcn olan en k\u0131sa s\u00fcrede piyasaya s\u00fcrmek istiyor. Bu durum, DevOps felsefesinin temelini olu\u015fturan h\u0131zl\u0131 ve otomatik CI\/CD s\u00fcre\u00e7lerini do\u011furdu. Ancak bu h\u0131z\u0131n getirdi\u011fi bir bedel de var: G\u00fcvenlik. Geleneksel g\u00fcvenlik yakla\u015f\u0131mlar\u0131 genellikle geli\u015ftirme ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn son a\u015famalar\u0131nda, yani yaz\u0131l\u0131m neredeyse tamamland\u0131\u011f\u0131nda devreye girer. Bu “son dakika” g\u00fcvenlik kontrolleri, ke\u015ffedilen g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131n d\u00fczeltilmesini hem maliyetli hem de zaman al\u0131c\u0131 hale getirir. D\u00fc\u015f\u00fcnsenize, bir binan\u0131n temelini att\u0131ktan sonra ta\u015f\u0131y\u0131c\u0131 kolonlarda bir problem oldu\u011funu fark etmek gibi bir durum bu.<\/p>\n
\u0130\u015fte tam bu noktada DevSecOps devreye giriyor. DevSecOps, g\u00fcvenlik k\u00fclt\u00fcr\u00fcn\u00fc, s\u00fcre\u00e7lerini ve ara\u00e7lar\u0131n\u0131 geli\u015ftirme, operasyonlar ve hatta i\u015f birli\u011fi ad\u0131mlar\u0131n\u0131n her a\u015famas\u0131na entegre etmeyi hedefleyen bir yakla\u015f\u0131md\u0131r. Ama\u00e7, g\u00fcvenli\u011fi bir “engelleyici” olmaktan \u00e7\u0131kar\u0131p, t\u00fcm ekibin ortak sorumlulu\u011fu haline getirmektir. Bu, “g\u00fcvenli\u011fi sola kayd\u0131rma” (shift-left) prensibiyle \u00f6zetlenebilir; yani g\u00fcvenlik kontrollerini, geli\u015ftirme ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn m\u00fcmk\u00fcn oldu\u011funca erken a\u015famalar\u0131na ta\u015f\u0131mak. Kod yaz\u0131lmaya ba\u015fland\u0131\u011f\u0131 andan itibaren, g\u00fcvenlik endi\u015feleri g\u00f6z \u00f6n\u00fcnde bulundurulur. B\u00f6ylelikle, zafiyetler \u00e7ok daha erken tespit edilir ve d\u00fczeltilmesi \u00e7ok daha kolay ve ucuz olur. \u00d6rne\u011fin, bir geli\u015ftiricinin yanl\u0131\u015fl\u0131kla hassas bir API anahtar\u0131n\u0131 koda g\u00f6mmesini d\u00fc\u015f\u00fcn\u00fcn. Geleneksel yakla\u015f\u0131mda bu, ancak \u00fcretim ortam\u0131na da\u011f\u0131t\u0131m yap\u0131ld\u0131ktan sonra ortaya \u00e7\u0131kabilirken, DevSecOps ile kod incelemesi veya otomatik tarama s\u0131ras\u0131nda h\u0131zla yakalan\u0131r.<\/p>\n
DevSecOps’un benimsenmesi, sadece g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 azaltmakla kalmaz, ayn\u0131 zamanda ekipler aras\u0131ndaki i\u015fbirli\u011fini de g\u00fc\u00e7lendirir. Geli\u015ftiriciler, g\u00fcvenlik uzmanlar\u0131 ve operasyon ekipleri, ortak bir hedef do\u011frultusunda birlikte \u00e7al\u0131\u015f\u0131r. Bu, “herkesin g\u00fcvenli\u011fe katk\u0131da bulundu\u011fu” bir k\u00fclt\u00fcr\u00fc te\u015fvik eder. Sonu\u00e7 olarak, DevSecOps sadece bir dizi ara\u00e7 ve teknikten ibaret de\u011fildir; ayn\u0131 zamanda bir zihniyet de\u011fi\u015fikli\u011fidir. Yaz\u0131l\u0131m\u0131n kalitesini art\u0131r\u0131rken, potansiyel siber sald\u0131r\u0131 risklerini minimize etme konusunda kritik bir rol oynar. Dolay\u0131s\u0131yla, h\u0131zl\u0131 geli\u015ftirme ortamlar\u0131nda g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 \u00f6nlemek sadece m\u00fcmk\u00fcn de\u011fil, DevSecOps yakla\u015f\u0131m\u0131yla art\u0131k bir zorunluluk haline gelmi\u015ftir.<\/p>\n
DevSecOps’un temelinde yatan birka\u00e7 kilit prensip bulunmaktad\u0131r. Bunlar\u0131 anlamak, yakla\u015f\u0131m\u0131n neden bu kadar etkili oldu\u011funu kavramam\u0131z\u0131 sa\u011flar:<\/p>\n
Bu prensiplerin uygulanmas\u0131, DevSecOps’a bir\u00e7ok avantaj kazand\u0131r\u0131r. \u0130lk olarak, g\u00fcvenlik a\u00e7\u0131klar\u0131 daha erken ve daha ucuza tespit edilir.<\/strong> Bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131n\u0131 geli\u015ftirme a\u015famas\u0131nda d\u00fczeltmek, \u00fcretim a\u015famas\u0131nda d\u00fczeltmekten on kat daha ucuz olabilir. \u0130kinci olarak, da\u011f\u0131t\u0131m s\u00fcre\u00e7leri h\u0131zlan\u0131r.<\/strong> G\u00fcvenlik kontrollerinin otomatikle\u015fmesi sayesinde, manuel bekleme s\u00fcreleri ortadan kalkar ve yaz\u0131l\u0131m daha h\u0131zl\u0131 bir \u015fekilde \u00fcretime al\u0131nabilir. \u00dc\u00e7\u00fcnc\u00fc olarak, mevzuata uyumluluk daha kolay hale gelir.<\/strong> Otomatik kontroller ve denetim izleri, PCI DSS, GDPR gibi d\u00fczenlemelere uyumu kolayla\u015ft\u0131r\u0131r. D\u00f6rd\u00fcnc\u00fc olarak, g\u00fcvenlik k\u00fclt\u00fcr\u00fc geli\u015fir.<\/strong> T\u00fcm ekibin g\u00fcvenli\u011fe dahil olmas\u0131, herkesin bu konuda daha bilin\u00e7li ve sorumlu davranmas\u0131n\u0131 sa\u011flar. Son olarak, riskler azal\u0131r.<\/strong> S\u00fcrekli ve otomatik g\u00fcvenlik kontrolleri, potansiyel siber sald\u0131r\u0131 y\u00fczeyini daralt\u0131r ve organizasyonun genel g\u00fcvenlik duru\u015funu g\u00fc\u00e7lendirir. Bu avantajlar, DevSecOps’u modern yaz\u0131l\u0131m geli\u015ftirmenin vazge\u00e7ilmez bir par\u00e7as\u0131 haline getirmektedir.<\/p>\n CI\/CD boru hatt\u0131na g\u00fcvenli\u011fi entegre etmek, sadece birka\u00e7 ara\u00e7 eklemekten ibaret de\u011fildir; bu, s\u00fcrecin her a\u015famas\u0131n\u0131 dikkatlice planlamay\u0131 ve otomatikle\u015ftirmeyi gerektiren kapsaml\u0131 bir yakla\u015f\u0131md\u0131r. Bu b\u00f6l\u00fcmde, geli\u015ftiricinin kod yaz\u0131m\u0131ndan ba\u015flay\u0131p, \u00fcretim ortam\u0131na da\u011f\u0131t\u0131ma kadar uzanan bir dizi g\u00fcvenlik ad\u0131m\u0131n\u0131 nas\u0131l uygulayabilece\u011finizi ad\u0131m ad\u0131m inceleyece\u011fiz. Bu entegrasyon, zafiyetleri erken yakalamak ve g\u00fcvenlik risklerini minimuma indirmek i\u00e7in hayati \u00f6neme sahiptir.<\/p>\n \u0130lk ad\u0131m, geli\u015ftirme a\u015famas\u0131nda ba\u015flar. Geli\u015ftiriciler kod yazarken, IDE’lerine entegre g\u00fcvenlik eklentileri veya kod analizi ara\u00e7lar\u0131 kullanarak anl\u0131k geri bildirimler alabilirler. Bu, hen\u00fcz kod repoya g\u00f6nderilmeden hatalar\u0131n d\u00fczeltilmesine olanak tan\u0131r. Git hook’lar\u0131 da bu a\u015famada devreye girebilir; \u00f6rne\u011fin, bir geli\u015ftirici hassas bilgileri (\u015fifreler, API anahtarlar\u0131) commit etmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131nda hook, commit’i engeller. Bu t\u00fcr \u00f6nleyici tedbirler, g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131n boru hatt\u0131na girmesini ba\u015ftan engeller.<\/p>\n CI\/CD boru hatt\u0131n\u0131n ilk a\u015famalar\u0131ndan biri olan kod derleme ve test a\u015famas\u0131nda, Statik Uygulama G\u00fcvenlik Testi (SAST) ara\u00e7lar\u0131 devreye girer. SAST ara\u00e7lar\u0131, yaz\u0131lan kodun kaynak kodunu, derlenmi\u015f kodu veya ikili dosyalar\u0131n\u0131 analiz ederek potansiyel g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 tespit eder. Bu taramalar, kodun \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131na gerek kalmadan ger\u00e7ekle\u015fir ve SQL enjeksiyonu, XSS, Buffer Overflow gibi yayg\u0131n zafiyetleri bulmada etkilidir. SAST, CI\/CD s\u00fcrecine otomatik bir ad\u0131m olarak entegre edildi\u011finde, her kod commit’i veya pull request ile birlikte g\u00fcvenlik analizi de tetiklenir ve sonu\u00e7lar geli\u015ftiricilere an\u0131nda bildirilir. Bu, hatalar\u0131n taze ve hen\u00fcz k\u00fc\u00e7\u00fckken d\u00fczeltilmesini sa\u011flar.<\/p>\n SAST’in ard\u0131ndan, Ba\u011f\u0131ml\u0131l\u0131k Taramas\u0131 (Dependency Scanning) gelir. Modern uygulamalar genellikle a\u00e7\u0131k kaynak k\u00fct\u00fcphaneler ve \u00fc\u00e7\u00fcnc\u00fc taraf ba\u011f\u0131ml\u0131l\u0131klar \u00fczerine kuruludur. Bu ba\u011f\u0131ml\u0131l\u0131klar\u0131n kendi g\u00fcvenlik a\u00e7\u0131klar\u0131 olabilir. Ba\u011f\u0131ml\u0131l\u0131k taray\u0131c\u0131lar\u0131, projenizin kulland\u0131\u011f\u0131 t\u00fcm k\u00fct\u00fcphaneleri tarar ve bilinen zafiyet veritabanlar\u0131yla kar\u015f\u0131la\u015ft\u0131r\u0131r. E\u011fer bir zafiyet bulunursa, geli\u015ftiricilere uyar\u0131 verilir ve g\u00fcncel, g\u00fcvenli bir s\u00fcr\u00fcme ge\u00e7meleri \u00f6nerilir. Bu ad\u0131m, tedarik zinciri sald\u0131r\u0131lar\u0131na kar\u015f\u0131 korunmada kritik bir rol oynar.<\/p>\n Uygulama derlenip ba\u011f\u0131ml\u0131l\u0131klar\u0131 taranm\u0131\u015f ve g\u00fcvenlik kontrollerinden ge\u00e7mi\u015fse, s\u0131rada Dinamik Uygulama G\u00fcvenlik Testi (DAST) ve Konteyner G\u00fcvenli\u011fi bulunur. E\u011fer uygulaman\u0131z konteynerle\u015ftirilmi\u015fse (Docker, Kubernetes), konteyner imajlar\u0131n\u0131n taranmas\u0131 olmazsa olmazd\u0131r. Konteyner imaj taray\u0131c\u0131lar\u0131 (\u00f6rne\u011fin Clair, Trivy), imajdaki i\u015fletim sistemi katmanlar\u0131n\u0131, uygulamalar\u0131 ve ba\u011f\u0131ml\u0131l\u0131klar\u0131 tarayarak bilinen zafiyetleri tespit eder. Bu, da\u011f\u0131t\u0131lacak imaj\u0131n g\u00fcvenli oldu\u011fundan emin olman\u0131z\u0131 sa\u011flar. DAST ise uygulaman\u0131n \u00e7al\u0131\u015f\u0131r haldeki versiyonunu, bir sald\u0131rgan gibi d\u0131\u015far\u0131dan test eder. Web uygulamalar\u0131ndaki zafiyetleri (\u00f6rne\u011fin OWASP Top 10) bulmak i\u00e7in s\u0131zma testlerine benzer otomatik taramalar yapar. DAST, SAST’in ka\u00e7\u0131rabilece\u011fi runtime sorunlar\u0131n\u0131 ortaya \u00e7\u0131kar\u0131r.<\/p>\n Son olarak, da\u011f\u0131t\u0131m a\u015famas\u0131nda g\u00fcvenlik politikalar\u0131n\u0131n uygulanmas\u0131 ve \u00fcretim ortam\u0131nda s\u00fcrekli izleme devreye girer. Politika Olarak Kod (Policy as Code) ara\u00e7lar\u0131 (\u00f6rne\u011fin Open Policy Agent – OPA), Kubernetes ortam\u0131nda kaynaklar\u0131n do\u011fru konfig\u00fcre edildi\u011finden, g\u00fcvenlik standartlar\u0131na uygun oldu\u011fundan emin olmak i\u00e7in kullan\u0131l\u0131r. \u00dcretim ortam\u0131nda ise G\u00fcvenlik Bilgisi ve Olay Y\u00f6netimi (SIEM) sistemleri, tehdit alg\u0131lama ve yan\u0131t (Detection and Response) mekanizmalar\u0131 s\u00fcrekli \u00e7al\u0131\u015f\u0131r. Bu ad\u0131mlar, yaln\u0131zca boru hatt\u0131ndaki g\u00fcvenli\u011fi sa\u011flamakla kalmaz, ayn\u0131 zamanda da\u011f\u0131t\u0131m sonras\u0131 da uygulaman\u0131n ve altyap\u0131n\u0131n g\u00fcvende kalmas\u0131na yard\u0131mc\u0131 olur. Bu entegre yakla\u015f\u0131m, DevSecOps felsefesinin kalbini olu\u015fturur ve g\u00fcn\u00fcm\u00fcz\u00fcn dinamik tehdit ortam\u0131nda hayati bir koruma katman\u0131 sa\u011flar.<\/p>\n Statik Uygulama G\u00fcvenlik Testi (SAST), CI\/CD boru hatt\u0131na entegre edilen ilk ve en \u00f6nemli g\u00fcvenlik katmanlar\u0131ndan biridir. SAST ara\u00e7lar\u0131, kodunuzu \u00e7al\u0131\u015ft\u0131rmadan analiz eder, potansiyel g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 ve zafiyetleri bulur. Bu ara\u00e7lar, geli\u015ftirme s\u00fcrecinin erken a\u015famalar\u0131nda devreye girerek, “shift-left” prensibini en iyi \u015fekilde uygulamam\u0131z\u0131 sa\u011flar. Peki, SAST ara\u00e7lar\u0131n\u0131 CI\/CD’ye nas\u0131l entegre ederiz? \u0130\u015fte ad\u0131m ad\u0131m bir rehber:<\/p>\n 1. Do\u011fru SAST Arac\u0131n\u0131 Se\u00e7mek:<\/strong> Piyasada bir\u00e7ok SAST arac\u0131 bulunmaktad\u0131r (SonarQube, Checkmarx, Fortify, Bandit, ESLint vb.). Se\u00e7im yaparken, projenizin kulland\u0131\u011f\u0131 programlama dillerini destekleyip desteklemedi\u011fini, CI\/CD platformunuzla entegrasyon kolayl\u0131\u011f\u0131n\u0131, raporlama \u00f6zelliklerini ve lisanslama modelini g\u00f6z \u00f6n\u00fcnde bulundurmal\u0131s\u0131n\u0131z. A\u00e7\u0131k kaynak projeler i\u00e7in Python i\u00e7in Bandit, JavaScript i\u00e7in ESLint gibi ara\u00e7lar ba\u015flang\u0131\u00e7 i\u00e7in m\u00fckemmel olabilir.<\/p>\n 2. CI\/CD Boru Hatt\u0131na Entegrasyon:<\/strong> SAST arac\u0131n\u0131, genellikle kod derleme veya test a\u015famalar\u0131ndan \u00f6nce CI\/CD boru hatt\u0131n\u0131za bir ad\u0131m olarak eklersiniz. Ama\u00e7, her yeni kod commit’i veya pull request ile otomatik olarak g\u00fcvenlik taramas\u0131 yapmakt\u0131r.<\/p>\n \u00d6rnek olarak, bir GitLab CI\/CD pipeline’\u0131nda Python projesi i\u00e7in Bandit SAST taramas\u0131n\u0131 nas\u0131l entegre edebilece\u011fimize bakal\u0131m:<\/p>\n <\/code><\/p>\n Bu \u00f6rnekte, Uzman \u0130pucu: SAST taramalar\u0131n\u0131 geli\u015ftirme ortam\u0131n\u0131za (IDE) de entegre edin. Geli\u015ftiriciler kodu yazarken an\u0131nda geri bildirim ald\u0131klar\u0131nda, g\u00fcvenlik a\u00e7\u0131klar\u0131 hen\u00fcz commit edilmeden d\u00fczeltilebilir. Bu, \"shift-left\" prensibinin en etkili uygulamalar\u0131ndan biridir.<\/p>\n SAST, kaynak kod \u00fczerindeki potansiyel zafiyetleri bulmada harika olsa da, uygulaman\u0131n \u00e7al\u0131\u015f\u0131r haldeki davran\u0131\u015flar\u0131n\u0131 veya \u00fc\u00e7\u00fcnc\u00fc taraf entegrasyonlar\u0131ndan kaynaklanan zafiyetleri tespit edemez. \u0130\u015fte bu noktada Dinamik Uygulama G\u00fcvenlik Testi (DAST) ve Ba\u011f\u0131ml\u0131l\u0131k Taramas\u0131 devreye girer.<\/p>\n DAST ara\u00e7lar\u0131, uygulamay\u0131 \u00e7al\u0131\u015f\u0131r durumda test eder. Bir web uygulamas\u0131n\u0131 d\u00fc\u015f\u00fcn\u00fcn; DAST, uygulamaya d\u0131\u015far\u0131dan bir sald\u0131rgan gibi HTTP\/HTTPS istekleri g\u00f6nderir ve yan\u0131tlar\u0131 analiz ederek potansiyel g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 bulmaya \u00e7al\u0131\u015f\u0131r. OWASP Top 10'da yer alan SQL enjeksiyonu, XSS, k\u0131r\u0131k kimlik do\u011frulama gibi zafiyetleri tespit etmekte olduk\u00e7a etkilidir. DAST, SAST'in ka\u00e7\u0131rabilece\u011fi runtime sorunlar\u0131n\u0131, konfig\u00fcrasyon hatalar\u0131n\u0131 ve d\u0131\u015f entegrasyonlardan kaynaklanan zafiyetleri ortaya \u00e7\u0131kar\u0131r. Bu testler genellikle uygulaman\u0131n test veya haz\u0131rl\u0131k (staging) ortamlar\u0131na da\u011f\u0131t\u0131ld\u0131ktan sonra ger\u00e7ekle\u015ftirilir.<\/p>\n Pop\u00fcler DAST ara\u00e7lar\u0131 aras\u0131nda OWASP ZAP (Zed Attack Proxy), Burp Suite ve Acunetix gibi \u00e7\u00f6z\u00fcmler bulunur. Bir CI\/CD boru hatt\u0131nda DAST entegrasyonu genellikle \u015fu ad\u0131mlar\u0131 i\u00e7erir:<\/p>\n <\/code><\/p>\n Bu \u00f6rnekte, OWASP ZAP'in Docker imaj\u0131 kullan\u0131larak belirli bir URL \u00fczerindeki uygulama taran\u0131r. Sonu\u00e7lar bir HTML raporuna yaz\u0131l\u0131r. DAST, SAST ile birlikte kullan\u0131ld\u0131\u011f\u0131nda \u00e7ok daha kapsaml\u0131 bir g\u00fcvenlik kapsama alan\u0131 sa\u011flar.<\/p>\n Modern uygulamalar, say\u0131s\u0131z a\u00e7\u0131k kaynak k\u00fct\u00fcphane ve \u00fc\u00e7\u00fcnc\u00fc taraf bile\u015fen kullan\u0131r. Bu ba\u011f\u0131ml\u0131l\u0131klar\u0131n her biri potansiyel bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131 ta\u015f\u0131yabilir. Ba\u011f\u0131ml\u0131l\u0131k taramas\u0131, projenizin kulland\u0131\u011f\u0131 t\u00fcm harici k\u00fct\u00fcphaneleri ve onlar\u0131n s\u00fcr\u00fcmlerini analiz ederek, bilinen g\u00fcvenlik a\u00e7\u0131klar\u0131 veritabanlar\u0131yla (\u00f6rne\u011fin NVD - National Vulnerability Database) kar\u015f\u0131la\u015ft\u0131r\u0131r. Bu sayede, uygulaman\u0131z\u0131n dolayl\u0131 yoldan miras ald\u0131\u011f\u0131 zafiyetler tespit edilebilir.<\/p>\n Pop\u00fcler ba\u011f\u0131ml\u0131l\u0131k tarama ara\u00e7lar\u0131 aras\u0131nda OWASP Dependency-Check, Snyk, WhiteSource ve Retire.js (JavaScript projeleri i\u00e7in) bulunur. Bu ara\u00e7lar genellikle paket y\u00f6neticileri (npm, pip, Maven, Gradle) ile entegre \u00e7al\u0131\u015f\u0131r ve proje ba\u011f\u0131ml\u0131l\u0131k a\u011fac\u0131n\u0131 analiz eder.<\/p>\n <\/code><\/p>\n Bu \u00f6rnekte, OWASP Dependency-Check arac\u0131 kullan\u0131larak projenin ba\u011f\u0131ml\u0131l\u0131klar\u0131 taran\u0131r. Ba\u011f\u0131ml\u0131l\u0131k taramas\u0131, \u00f6zellikle yaz\u0131l\u0131m tedarik zinciri g\u00fcvenli\u011fi i\u00e7in kritik \u00f6neme sahiptir. Bilinmeyen veya g\u00fcncel olmayan ba\u011f\u0131ml\u0131l\u0131klar \u00fczerinden gelebilecek sald\u0131r\u0131lara kar\u015f\u0131 koruma sa\u011flar. SAST ve DAST ile birlikte kullan\u0131ld\u0131\u011f\u0131nda, yaz\u0131l\u0131m\u0131n\u0131z\u0131n g\u00fcvenlik duru\u015funu \u00e7ok daha sa\u011flam hale getirir.<\/p>\n Modern bulut tabanl\u0131 uygulamalar\u0131n ve CI\/CD s\u00fcre\u00e7lerinin karma\u015f\u0131kl\u0131\u011f\u0131 artt\u0131k\u00e7a, hassas verilere (veritaban\u0131 \u015fifreleri, API anahtarlar\u0131, sertifikalar vb.) yetkisiz eri\u015fimi engellemek kritik bir hal al\u0131yor. \u0130\u015fte bu noktada Kimlik ve Eri\u015fim Y\u00f6netimi (IAM) ve S\u0131r Y\u00f6netimi (Secret Management) devreye girer. Bu iki kavram, DevSecOps'un temel ta\u015flar\u0131ndan olup, g\u00fcvenli bir altyap\u0131 ve uygulama geli\u015ftirme s\u00fcreci i\u00e7in vazge\u00e7ilmezdir.<\/p>\n IAM, bir organizasyondaki kullan\u0131c\u0131lar\u0131n (insanlar veya makineler) kimliklerini y\u00f6netme ve bu kimliklere hangi kaynaklara ne d\u00fczeyde eri\u015fim yetkisi verilece\u011fini belirleme s\u00fcrecidir. Temel prensip, \"en az ayr\u0131cal\u0131k\" (least privilege) ilkesidir. Yani, bir kullan\u0131c\u0131n\u0131n veya servisin yaln\u0131zca i\u015fini yapmak i\u00e7in ihtiya\u00e7 duydu\u011fu minimum ayr\u0131cal\u0131klara sahip olmas\u0131 gerekir. Fazla yetki, yetkisiz eri\u015fim veya i\u00e7eriden kaynaklanabilecek k\u00f6t\u00fc niyetli hareketler i\u00e7in bir kap\u0131 aralayabilir.<\/p>\n CI\/CD ba\u011flam\u0131nda IAM, otomasyon ara\u00e7lar\u0131n\u0131z\u0131n (\u00f6rne\u011fin Jenkins, GitLab Runner, GitHub Actions) bulut sa\u011flay\u0131c\u0131n\u0131zdaki (AWS, Azure, GCP) veya di\u011fer sistemlerdeki kaynaklara (veritabanlar\u0131, depolama kovalar\u0131, API'ler) g\u00fcvenli bir \u015fekilde eri\u015fmesini sa\u011flamak anlam\u0131na gelir. Bunun i\u00e7in genellikle a\u015fa\u011f\u0131daki y\u00f6ntemler kullan\u0131l\u0131r:<\/p>\n \u015eifreler, API anahtarlar\u0131, veritaban\u0131 ba\u011flant\u0131 dizeleri gibi hassas bilgilerin do\u011frudan kod i\u00e7inde, yap\u0131land\u0131rma dosyalar\u0131nda veya en k\u00f6t\u00fcs\u00fc ortam de\u011fi\u015fkenlerinde saklanmas\u0131 b\u00fcy\u00fck bir g\u00fcvenlik riskidir. Bu t\u00fcr bilgiler kolayca if\u015fa olabilir ve ciddi g\u00fcvenlik ihlallerine yol a\u00e7abilir. S\u0131r y\u00f6netimi ara\u00e7lar\u0131, bu hassas bilgileri g\u00fcvenli bir \u015fekilde saklamak, eri\u015fimi denetlemek ve da\u011f\u0131t\u0131m s\u00fcrecine entegre etmek i\u00e7in tasarlanm\u0131\u015ft\u0131r.<\/p>\n Pop\u00fcler s\u0131r y\u00f6netimi \u00e7\u00f6z\u00fcmleri aras\u0131nda HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager gibi ara\u00e7lar bulunur. Bu ara\u00e7lar genellikle a\u015fa\u011f\u0131daki yetenekleri sa\u011flar:<\/p>\n Ortam De\u011fi\u015fkenlerinde S\u0131r Saklama Tuza\u011f\u0131ndan Nas\u0131l Ka\u00e7\u0131n\u0131l\u0131r?<\/strong><\/p>\n Ortam de\u011fi\u015fkenleri (environment variables), k\u00fc\u00e7\u00fck ve statik yap\u0131land\u0131rma de\u011ferleri i\u00e7in uygun olabilirken, hassas s\u0131rlar i\u00e7in kesinlikle kullan\u0131lmamal\u0131d\u0131r. Bunun nedenleri \u015funlard\u0131r:<\/p>\n S\u0131rlar\u0131 ortam de\u011fi\u015fkenleri yerine, bir s\u0131r y\u00f6netimi \u00e7\u00f6z\u00fcm\u00fcnden g\u00fcvenli bir \u015fekilde \u00e7ekmek en iyi yakla\u015f\u0131md\u0131r. \u0130\u015fte bir \u00f6rnek:<\/p>\n <\/code><\/p>\n Bu yakla\u015f\u0131m, s\u0131rlar\u0131n koddan, ortam de\u011fi\u015fkenlerinden ve hatta d\u00fcz metin yap\u0131land\u0131rma dosyalar\u0131ndan ayr\u0131lmas\u0131n\u0131 sa\u011flar. Uygulamalar ve CI\/CD boru hatlar\u0131, \u00e7al\u0131\u015fma zaman\u0131nda g\u00fcvenli bir \u015fekilde s\u0131r y\u00f6netimi \u00e7\u00f6z\u00fcm\u00fcnden gerekli kimlik bilgilerini \u00e7eker. Bu, g\u00fcvenlik duru\u015funuzu \u00f6nemli \u00f6l\u00e7\u00fcde g\u00fc\u00e7lendirir ve hassas bilgilerin if\u015fa olma riskini minimize eder.<\/p>\n DevSecOps'un teoride ne kadar faydal\u0131 oldu\u011funu g\u00f6rmek kolayd\u0131r, ancak pratikte b\u00fcy\u00fck bir kurulu\u015fa entegrasyonu genellikle \u00f6nemli zorluklarla gelir. Bu vaka analizi, XBank (hayali bir b\u00fcy\u00fck finans kurulu\u015fu) adl\u0131 bir bankac\u0131l\u0131k devinin DevSecOps d\u00f6n\u00fc\u015f\u00fcm yolculu\u011funu, kar\u015f\u0131la\u015ft\u0131\u011f\u0131 engelleri ve bu engelleri nas\u0131l a\u015ft\u0131\u011f\u0131n\u0131 ele almaktad\u0131r. XBank, onlarca y\u0131ld\u0131r geleneksel g\u00fcvenlik ve geli\u015ftirme s\u00fcre\u00e7leriyle \u00e7al\u0131\u015f\u0131yordu; bu da onlar\u0131 eski nesil siber sald\u0131r\u0131lara kar\u015f\u0131 savunmas\u0131z b\u0131rak\u0131yor ve yeni \u00fcr\u00fcnleri piyasaya s\u00fcrme h\u0131zlar\u0131n\u0131 ciddi \u015fekilde d\u00fc\u015f\u00fcr\u00fcyordu.<\/p>\n Ba\u015flang\u0131\u00e7 Durumu ve Motivasyon:<\/strong> XBank, y\u0131llarca s\u00fcren silo bazl\u0131 \u00e7al\u0131\u015fma d\u00fczenine sahipti. Geli\u015ftirme ekipleri kod yazarken, g\u00fcvenlik ekipleri en sonda, neredeyse da\u011f\u0131t\u0131ma haz\u0131r \u00fcr\u00fcnler \u00fczerinde manuel denetimler yap\u0131yordu. Bu durum, s\u00fcrekli gecikmelere, \"g\u00fcvenlik duvar\u0131\" olarak alg\u0131lanan g\u00fcvenlik ekiplerine ve geli\u015ftiricilerin g\u00fcvenlik konusundaki motivasyon eksikli\u011fine yol a\u00e7\u0131yordu. Yeni reg\u00fclasyonlar, artan siber sald\u0131r\u0131 tehditleri ve fintech rakiplerinin h\u0131z\u0131, XBank'\u0131 kapsaml\u0131 bir DevSecOps d\u00f6n\u00fc\u015f\u00fcm\u00fcne itti. Ama\u00e7, g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 erken yakalamak, uyumlulu\u011fu art\u0131rmak ve \u00fcr\u00fcn geli\u015ftirme h\u0131z\u0131n\u0131 kesintiye u\u011fratmadan g\u00fcvenli\u011fi sa\u011flamakt\u0131.<\/p>\n Kar\u015f\u0131la\u015f\u0131lan Temel Zorluklar:<\/strong><\/p>\n \u00c7\u00f6z\u00fcm ve Uygulanan Stratejiler:<\/strong><\/p>\n Sonu\u00e7lar:<\/strong> \u00dc\u00e7 y\u0131ll\u0131k bir d\u00f6n\u00fc\u015f\u00fcm s\u00fcrecinin sonunda XBank, \u00f6nemli ba\u015far\u0131lar elde etti. G\u00fcvenlik a\u00e7\u0131klar\u0131 %60 oran\u0131nda azald\u0131 ve bunlar\u0131n %85'i geli\u015ftirme a\u015famas\u0131nda tespit edilerek d\u00fczeltildi. \u00dcr\u00fcn geli\u015ftirme ve da\u011f\u0131t\u0131m s\u00fcreleri %30 k\u0131sald\u0131, \u00e7\u00fcnk\u00fc g\u00fcvenlik art\u0131k bir engelleyici de\u011fil, s\u00fcrecin ayr\u0131lmaz bir par\u00e7as\u0131yd\u0131. En \u00f6nemlisi, ekipler aras\u0131 i\u015fbirli\u011fi artt\u0131 ve XBank, daha g\u00fcvenli ve \u00e7evik bir yaz\u0131l\u0131m geli\u015ftirme k\u00fclt\u00fcr\u00fc in\u015fa etmeyi ba\u015fard\u0131. Bu vaka analizi, DevSecOps d\u00f6n\u00fc\u015f\u00fcm\u00fcn\u00fcn sadece teknik bir de\u011fi\u015fiklik de\u011fil, ayn\u0131 zamanda kapsaml\u0131 bir k\u00fclt\u00fcrel de\u011fi\u015fim gerektiren zorlu ama \u00f6d\u00fcllendirici bir yolculuk oldu\u011funu g\u00f6stermektedir.<\/p>\n DevSecOps yolculu\u011fumuzda temel g\u00fcvenlik otomasyonlar\u0131n\u0131 anlad\u0131ktan sonra, bir ad\u0131m daha ileri gitmenin ve daha sofistike teknikleri devreye sokman\u0131n zaman\u0131 geldi. Politika Olarak Kod (Policy as Code) ve G\u00fcvenlik A\u011flar\u0131 (Service Mesh) entegrasyonu, modern bulut yerel (cloud-native) uygulamalar\u0131n g\u00fcvenli\u011fini daha derinlemesine sa\u011flamak i\u00e7in g\u00fc\u00e7l\u00fc y\u00f6ntemlerdir. Bu teknikler, \u00f6zellikle mikroservis mimarileri ve Kubernetes ortamlar\u0131nda, g\u00fcvenlik denetimini ve uygulama trafi\u011fi y\u00f6netimini merkezi ve otomatik bir hale getirir.<\/p>\n Politika Olarak Kod (Policy as Code - PAC), g\u00fcvenlik, uyumluluk ve operasyonel politikalar\u0131 insan taraf\u0131ndan okunabilir, s\u00fcr\u00fcm kontrol sistemlerinde saklanabilir ve otomatik olarak uygulanabilir kod format\u0131nda tan\u0131mlama prati\u011fidir. Geleneksel olarak, politikalar belge tabanl\u0131yd\u0131 ve manuel olarak denetleniyordu, bu da hata yapma olas\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131yor ve \u00f6l\u00e7eklenmeyi zorla\u015ft\u0131r\u0131yordu. PAC ile politikalar, kod gibi muamele g\u00f6r\u00fcr: versiyonlan\u0131r, test edilir ve CI\/CD boru hatlar\u0131na entegre edilir.<\/p>\n Neden \u00d6nemli?<\/strong><\/p>\n Uygulama \u00d6rne\u011fi: Open Policy Agent (OPA) ile Kubernetes Politikalar\u0131<\/strong><\/p>\n Open Policy Agent (OPA), Politika Olarak Kod uygulamas\u0131n\u0131n en pop\u00fcler ara\u00e7lar\u0131ndan biridir. OPA, politikalar\u0131 Rego ad\u0131nda y\u00fcksek seviyeli, bildirimsel bir dilde yazar. Kubernetes ortam\u0131nda OPA, bir admission controller olarak \u00e7al\u0131\u015farak, API sunucusuna gelen her kayna\u011f\u0131n (pod, deployment, service vb.) politikalarla uyumlu olup olmad\u0131\u011f\u0131n\u0131 kontrol eder. \u00d6rne\u011fin, \"t\u00fcm pod'lar\u0131n CPU ve bellek limitleri olmal\u0131\" veya \"t\u00fcm konteyner imajlar\u0131 sadece g\u00fcvenilir bir kaynaktan \u00e7ekilmeli\" gibi kurallar\u0131 zorlayabilirsiniz.<\/p>\n <\/code><\/p>\n Bu Rego kodu, Kubernetes'teki bir Pod iste\u011fini denetler ve e\u011fer herhangi bir konteyner i\u00e7in bellek limiti belirtilmemi\u015fse, iste\u011fi reddeder ve bir hata mesaj\u0131 d\u00f6ner. OPA, sadece Kubernetes ile s\u0131n\u0131rl\u0131 de\u011fildir; Terraform, API a\u011f ge\u00e7itleri, hatta SSH eri\u015fim kurallar\u0131 gibi bir\u00e7ok alanda politika denetimi i\u00e7in kullan\u0131labilir.<\/p>\n Uzman \u0130pucu: Politika Olarak Kod \u00e7\u00f6z\u00fcmlerini CI\/CD boru hatt\u0131n\u0131z\u0131n erken a\u015famalar\u0131na entegre edin. Terraform kodunuzun bir g\u00fcvenlik politikas\u0131na uymad\u0131\u011f\u0131n\u0131 da\u011f\u0131t\u0131m \u00f6ncesi \u00f6\u011frenmek, da\u011f\u0131t\u0131m sonras\u0131 ke\u015ffetmekten \u00e7ok daha kolayd\u0131r.<\/p>\n Mikroservis mimarileri, uygulamalar\u0131 k\u00fc\u00e7\u00fck, ba\u011f\u0131ms\u0131z ve birbirleriyle ileti\u015fim kuran servis par\u00e7ac\u0131klar\u0131na b\u00f6ler. Bu, esneklik ve \u00f6l\u00e7eklenebilirlik sa\u011flarken, servisler aras\u0131 ileti\u015fimin g\u00fcvenli\u011fini y\u00f6netme konusunda yeni zorluklar yarat\u0131r. \u0130\u015fte burada Service Mesh devreye girer.<\/p>\n Service Mesh Nedir?<\/strong><\/p>\n Service Mesh, mikroservisler aras\u0131 ileti\u015fimi y\u00f6neten, izleyen ve g\u00fcvenli\u011fini sa\u011flayan \u00f6zel bir altyap\u0131 katman\u0131d\u0131r. Genellikle \"sidecar proxy\" modelini kullan\u0131r; yani her mikroservis \u00f6rne\u011finin yan\u0131na k\u00fc\u00e7\u00fck bir proxy (\u00f6rne\u011fin Envoy) konu\u015fland\u0131r\u0131l\u0131r. T\u00fcm gelen ve giden trafik bu proxy \u00fczerinden ge\u00e7er. Pop\u00fcler Service Mesh \u00e7\u00f6z\u00fcmleri aras\u0131nda Istio, Linkerd ve Consul Connect bulunur.<\/p>\n Service Mesh'in DevSecOps'a Katk\u0131lar\u0131:<\/strong><\/p>\n \u00d6rne\u011fin, Istio ile bir servisin sadece belirli bir ba\u015fka servisten gelen isteklere yan\u0131t vermesini sa\u011flayabiliriz:<\/p>\n <\/code><\/p>\n Bu Istio politikas\u0131, Hem Politika Olarak Kod hem de Service Mesh entegrasyonu, DevSecOps stratejinizi olgunla\u015ft\u0131r\u0131r ve modern, da\u011f\u0131t\u0131k sistemlerinize sa\u011flam bir g\u00fcvenlik \u00e7er\u00e7evesi sa\u011flar. Bu teknikler sayesinde, g\u00fcvenlik kararlar\u0131 kod seviyesine ta\u015f\u0131n\u0131r ve otomatik olarak uygulanarak, insan hatas\u0131 riskini azalt\u0131r ve genel g\u00fcvenlik duru\u015funu g\u00fc\u00e7lendirir.<\/p>\n 100 G\u00fcn DevOps yolculu\u011fumuzun 78. g\u00fcn\u00fcnde, DevSecOps'un modern yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerindeki vazge\u00e7ilmez rol\u00fcn\u00fc derinlemesine inceledik. H\u0131zl\u0131 da\u011f\u0131t\u0131m d\u00f6ng\u00fclerinde g\u00fcvenli\u011fi geri plana atmak yerine, onu s\u00fcrecin her a\u015famas\u0131na entegre etmenin, \"shift-left\" prensibini benimsemenin ve otomasyonun g\u00fcc\u00fcnden yararlanman\u0131n ne kadar kritik oldu\u011funu g\u00f6rd\u00fck. SAST, DAST, ba\u011f\u0131ml\u0131l\u0131k taramas\u0131 gibi ara\u00e7larla kod ve uygulamalar\u0131m\u0131z\u0131 erken a\u015famada g\u00fcvence alt\u0131na al\u0131rken, s\u0131r y\u00f6netimi ve IAM ile hassas bilgilere eri\u015fimi kontrol alt\u0131nda tuttuk. Ayr\u0131ca, Politika Olarak Kod ve Service Mesh gibi ileri d\u00fczey tekniklerle mikroservis mimarilerinin ve bulut yerel ortamlar\u0131n g\u00fcvenli\u011fini nas\u0131l sa\u011flamla\u015ft\u0131rabilece\u011fimizi ke\u015ffettik.<\/p>\n DevSecOps, sadece bir teknoloji y\u0131\u011f\u0131n\u0131 de\u011fil, ayn\u0131 zamanda bir zihniyet de\u011fi\u015fikli\u011fidir. G\u00fcvenli\u011fin t\u00fcm ekibin ortak sorumlulu\u011fu oldu\u011fu, geli\u015ftiricilerin g\u00fcvenlik bilincinin art\u0131r\u0131ld\u0131\u011f\u0131 ve operasyon ekipleriyle uyum i\u00e7inde \u00e7al\u0131\u015f\u0131ld\u0131\u011f\u0131 bir k\u00fclt\u00fcr\u00fc te\u015fvik eder. Bu d\u00f6n\u00fc\u015f\u00fcm zorlu olabilir, ancak XBank vaka analizinde g\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, sonu\u00e7lar\u0131 maliyet tasarrufu, h\u0131zlanm\u0131\u015f teslimat, artan g\u00fcvenlik ve daha g\u00fc\u00e7l\u00fc bir kurumsal itibar \u015feklinde somutla\u015f\u0131r. Gelece\u011fin yaz\u0131l\u0131m d\u00fcnyas\u0131nda rekabet\u00e7i kalabilmek ve siber tehditlere kar\u015f\u0131 ayakta durabilmek i\u00e7in DevSecOps'u benimsemek art\u0131k bir se\u00e7enek de\u011fil, bir zorunluluktur. G\u00fcvenli\u011fi en ba\u015f\u0131ndan itibaren d\u00fc\u015f\u00fcnerek ve otomatize ederek, gelece\u011fe daha g\u00fcvenle bakabiliriz.<\/p>\n Ba\u015flang\u0131\u00e7 i\u00e7in olmazsa olmaz tek bir ara\u00e7 yoktur, ancak genel olarak bir SAST (Statik Uygulama G\u00fcvenlik Testi) arac\u0131 (\u00f6rn: SonarQube, Bandit), bir ba\u011f\u0131ml\u0131l\u0131k taray\u0131c\u0131 (\u00f6rn: OWASP Dependency-Check, Snyk) ve bir s\u0131r y\u00f6netimi \u00e7\u00f6z\u00fcm\u00fc (\u00f6rn: HashiCorp Vault, bulut sa\u011flay\u0131c\u0131n\u0131z\u0131n Secret Manager'\u0131) iyi bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r. Bunlar\u0131 mevcut CI\/CD boru hatt\u0131n\u0131za entegre etmek \u00f6ncelikli olmal\u0131d\u0131r.<\/p>\n Bu, mevcut boru hatt\u0131n\u0131n karma\u015f\u0131kl\u0131\u011f\u0131na, organizasyonun b\u00fcy\u00fckl\u00fc\u011f\u00fcne ve benimsenen ara\u00e7lara g\u00f6re de\u011fi\u015fir. K\u00fc\u00e7\u00fck bir proje i\u00e7in birka\u00e7 hafta s\u00fcrebilirken, b\u00fcy\u00fck bir kurulu\u015fta k\u00fclt\u00fcrel de\u011fi\u015fim ve t\u00fcm ara\u00e7 setinin entegrasyonu aylarca, hatta y\u0131llarca s\u00fcren bir yolculuk olabilir. Kademe kademe ilerlemek, pilot projelerle ba\u015flamak ve s\u00fcrekli iyile\u015ftirme yapmak en iyi yakla\u015f\u0131md\u0131r.<\/p>\n Geli\u015ftiricilerin uyum sa\u011flamas\u0131 i\u00e7in e\u011fitim ve fark\u0131ndal\u0131k kritik \u00f6neme sahiptir. G\u00fcvenlik e\u011fitimlerini eri\u015filebilir k\u0131l\u0131n, g\u00fcvenlik bulgular\u0131 hakk\u0131nda yap\u0131c\u0131 geri bildirimler verin ve g\u00fcvenlik ara\u00e7lar\u0131n\u0131 IDE'lerine entegre etmelerini sa\u011flay\u0131n. En \u00f6nemlisi, g\u00fcvenli\u011fi bir engel olarak de\u011fil, yaz\u0131l\u0131m\u0131n kalitesini art\u0131ran bir de\u011fer olarak sunun ve \"g\u00fcvenlik \u015fampiyonlar\u0131\" olu\u015fturarak geli\u015ftiricilerin s\u00fcrece dahil olmas\u0131n\u0131 te\u015fvik edin.<\/p>\n \"Shift-left\" prensibi, g\u00fcvenlik testleri ve kontrollerinin geli\u015ftirme ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn m\u00fcmk\u00fcn olan en erken a\u015famas\u0131na, yani \"soluna\" kayd\u0131r\u0131lmas\u0131 anlam\u0131na gelir. Kod yaz\u0131ld\u0131\u011f\u0131 anda, tasar\u0131m a\u015famas\u0131nda veya entegrasyon testleri s\u0131ras\u0131nda g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131n aranmas\u0131 ve d\u00fczeltilmesi hedeflenir. B\u00f6ylece, sorunlar daha ucuz ve kolay bir \u015fekilde \u00e7\u00f6z\u00fcl\u00fcr, \u00fcretim ortam\u0131na ula\u015fmalar\u0131 engellenir.<\/p>\n DevSecOps, g\u00fcvenlik ekibinin rol\u00fcn\u00fc ortadan kald\u0131rmaz, aksine d\u00f6n\u00fc\u015ft\u00fcr\u00fcr. G\u00fcvenlik ekibi, manuel denetimler yerine, otomatikle\u015ftirilmi\u015f g\u00fcvenlik ara\u00e7lar\u0131n\u0131 se\u00e7me, yap\u0131land\u0131rma, g\u00fcvenlik politikalar\u0131n\u0131 kodlama, tehdit modelleme yapma, geli\u015ftiricilere rehberlik etme ve yeni g\u00fcvenlik zafiyetlerine kar\u015f\u0131 stratejiler geli\u015ftirme gibi daha y\u00fcksek de\u011ferli i\u015flere odaklan\u0131r. Onlar art\u0131k \"kap\u0131 bek\u00e7isi\" de\u011fil, \"g\u00fcvenlik mimar\u0131 ve dan\u0131\u015fman\u0131\" haline gelirler.<\/p>\n<\/div>\nCI\/CD S\u00fcre\u00e7lerinde G\u00fcvenli\u011fi Nas\u0131l Entegre Ederiz? Ad\u0131m Ad\u0131m Otomasyon Rehberi<\/h2>\n
Statik Uygulama G\u00fcvenlik Testi (SAST) Ara\u00e7lar\u0131 Nas\u0131l Kullan\u0131l\u0131r?<\/h3>\n
\nstages:\n - build\n - test\n - sast\n - deploy\n\nbuild_job:\n stage: build\n script:\n - echo \"Building application...\"\n - # Your build commands here\n tags:\n - docker\n\nsast_job:\n stage: sast\n image: python:3.9-slim-buster # Bandit'i \u00e7al\u0131\u015ft\u0131rmak i\u00e7in Python imaj\u0131\n script:\n - pip install bandit\n - bandit -r . -f html -o bandit_report.html || true # Tarama yapar, hata verse bile pipeline devam eder\n - echo \"Bandit SAST taramas\u0131 tamamland\u0131. Rapor: bandit_report.html\"\n artifacts:\n when: always\n paths:\n - bandit_report.html\n expire_in: 1 day\n allow_failure: true # G\u00fcvenlik a\u00e7\u0131\u011f\u0131 bulunmas\u0131 durumunda pipeline'\u0131 durdurmaz\n tags:\n - docker\n\ndeploy_job:\n stage: deploy\n script:\n - echo \"Deploying application...\"\n - # Your deploy commands here\n tags:\n - docker\n<\/pre>\nsast_job<\/code> ad\u0131m\u0131, projenin k\u00f6k dizinindeki t\u00fcm Python dosyalar\u0131n\u0131 Bandit ile tarar ve bir HTML raporu olu\u015fturur. allow_failure: true<\/code> parametresi, bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131 bulunsa bile boru hatt\u0131n\u0131n durmamas\u0131n\u0131 sa\u011flar, bu genellikle ilk entegrasyon a\u015famalar\u0131nda tercih edilirken, olgunla\u015fm\u0131\u015f projelerde bu de\u011fer false<\/code> olarak ayarlanarak kritik g\u00fcvenlik a\u00e7\u0131klar\u0131 bulundu\u011funda da\u011f\u0131t\u0131m\u0131n engellenmesi hedeflenir.<\/p>\nDinamik Uygulama G\u00fcvenlik Testi (DAST) ve Ba\u011f\u0131ml\u0131l\u0131k Taramas\u0131 Ne \u0130\u015fe Yarar?<\/h3>\n
Dinamik Uygulama G\u00fcvenlik Testi (DAST)<\/h4>\n
\n
\ndast_job:\n stage: dast\n image: owasp\/zap2docker-weekly # OWASP ZAP Docker imaj\u0131\n script:\n - echo \"Waiting for application to be available at ${APP_URL}...\"\n - sleep 60 # Uygulaman\u0131n ba\u015flamas\u0131 i\u00e7in beklenir\n - zap-baseline.py -t ${APP_URL} -g zap_report.html || true\n - echo \"DAST taramas\u0131 tamamland\u0131. Rapor: zap_report.html\"\n artifacts:\n when: always\n paths:\n - zap_report.html\n expire_in: 1 day\n allow_failure: true\n variables:\n APP_URL: \"http:\/\/my-staging-app.example.com\" # Uygulaman\u0131z\u0131n URL'si\n tags:\n - docker\n<\/pre>\nBa\u011f\u0131ml\u0131l\u0131k Taramas\u0131 (Dependency Scanning)<\/h4>\n
\ndependency_scan_job:\n stage: test\n image: alpine\/git # Ya da projenizin diline uygun bir imaj (\u00f6r: python:3.9)\n script:\n - apk add --no-cache curl openjdk11 # Dependency-Check i\u00e7in gerekli\n - curl -L \"https:\/\/github.com\/jeremylong\/DependencyCheck\/releases\/download\/v6.5.0\/dependency-check-6.5.0-release.zip\" -o dc.zip # Versiyon g\u00fcncellenebilir\n - unzip dc.zip\n - .\/dependency-check\/bin\/dependency-check.sh --project \"MyWebApp\" --scan . --format HTML --out .\n - echo \"Ba\u011f\u0131ml\u0131l\u0131k taramas\u0131 tamamland\u0131. Rapor: dependency-check-report.html\"\n artifacts:\n when: always\n paths:\n - dependency-check-report.html\n expire_in: 1 day\n allow_failure: true\n tags:\n - docker\n<\/pre>\nKimlik ve Eri\u015fim Y\u00f6netimi (IAM) ve S\u0131r Y\u00f6netimi (Secret Management) Pratikleri Nelerdir?<\/h2>\n
Kimlik ve Eri\u015fim Y\u00f6netimi (IAM) Nedir ve Neden \u00d6nemlidir?<\/h3>\n
\n
S\u0131r Y\u00f6netimi (Secret Management) Pratikleri Nelerdir? Ortam De\u011fi\u015fkenlerinde S\u0131r Saklama Tuza\u011f\u0131ndan Nas\u0131l Ka\u00e7\u0131n\u0131l\u0131r?<\/h3>\n
\n
\n
\n# K\u00f6t\u00fc Pratik: Ortam de\u011fi\u015fkeninde s\u0131r saklamak\nexport DB_PASSWORD=\"my_super_secret_password\" \n\n# Daha \u0130yi Pratik: S\u0131r y\u00f6netim sisteminden \u00e7ekmek (\u00f6rne\u011fin HashiCorp Vault)\n# Uygulama ba\u015flang\u0131c\u0131nda veya CI\/CD ad\u0131m\u0131 s\u0131ras\u0131nda\n# Vault CLI veya API kullanarak s\u0131rr\u0131 \u00e7ekin\n# Bu \u00f6rnekte, 'my-app\/database\/creds' yolundan bir s\u0131r \u00e7ekiliyor\nexport DB_PASSWORD=$(vault read -field=password secret\/my-app\/database\/creds)\n\n# E\u011fer Kubernetes kullan\u0131l\u0131yorsa, Secret objeleri veya Vault Agent Sidecar da kullan\u0131labilir.\n<\/pre>\nVaka Analizi: B\u00fcy\u00fck Bir Kurulu\u015fta DevSecOps D\u00f6n\u00fc\u015f\u00fcm\u00fc ve Kar\u015f\u0131la\u015f\u0131lan Zorluklar<\/h2>\n
\n
\n
\n
Geli\u015fmi\u015f DevSecOps Teknikleri: Politika Olarak Kod (Policy as Code) ve G\u00fcvenlik A\u011flar\u0131 (Service Mesh) Entegrasyonu<\/h2>\n
Politika Olarak Kod (Policy as Code) Nedir ve Nas\u0131l Uygulan\u0131r?<\/h3>\n
\n
\n# Rego Kodu \u00d6rne\u011fi: T\u00fcm konteynerler i\u00e7in bellek limiti olmal\u0131\npackage kubernetes.admission\n\ndeny[msg] {\n input.request.kind.kind == \"Pod\"\n some i\n not input.request.object.spec.containers[i].resources.limits.memory\n msg := sprintf(\"Konteyner '%v' bellek limiti belirtmeli.\", [input.request.object.spec.containers[i].name])\n}\n\n# Bu kod, Kubernetes'e g\u00f6nderilen her Pod i\u00e7in, \n# herhangi bir konteynerde bellek limiti tan\u0131mlanmam\u0131\u015fsa iste\u011fi reddeder.\n<\/pre>\nG\u00fcvenlik A\u011flar\u0131 (Service Mesh) Entegrasyonu ve Mikroservis G\u00fcvenli\u011fi<\/h3>\n
\n
\napiVersion: security.istio.io\/v1beta1\nkind: AuthorizationPolicy\nmetadata:\n name: productpage-viewer\n namespace: default\nspec:\n selector:\n matchLabels:\n app: productpage # Bu politika productpage servisi i\u00e7in ge\u00e7erlidir.\n action: ALLOW\n rules:\n - from:\n - source:\n principals: [\"cluster.local\/ns\/default\/sa\/reviews\"] # Sadece 'reviews' servis hesab\u0131ndan gelen isteklere izin ver.\n - source:\n namespaces: [\"istio-system\"] # Istio kontrol d\u00fczleminin eri\u015fimine izin ver.\n<\/pre>\nproductpage<\/code> servisine yaln\u0131zca reviews<\/code> servis hesab\u0131ndan veya istio-system<\/code> namespace'inden gelen isteklerin eri\u015fmesine izin verir. Di\u011fer t\u00fcm istekler engellenir. Bu, mikroservis ortam\u0131nda \"segmentasyon\" ve \"least privilege\" ilkelerini uygulamak i\u00e7in olduk\u00e7a g\u00fc\u00e7l\u00fc bir y\u00f6ntemdir.<\/p>\nSonu\u00e7: DevSecOps ile Gelece\u011fe G\u00fcvenle Bakmak ve S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
DevSecOps'a ba\u015flamak i\u00e7in hangi ara\u00e7lar olmazsa olmazd\u0131r?<\/h4>\n
DevSecOps'u mevcut bir CI\/CD boru hatt\u0131na entegre etmek ne kadar s\u00fcrer?<\/h4>\n
Geli\u015ftiricilerin DevSecOps s\u00fcre\u00e7lerine uyum sa\u011flamas\u0131n\u0131 nas\u0131l sa\u011flayabiliriz?<\/h4>\n
DevSecOps'ta \"shift-left\" prensibi tam olarak ne anlama geliyor?<\/h4>\n
DevSecOps, mevcut g\u00fcvenlik ekibimin rol\u00fcn\u00fc nas\u0131l etkiler?<\/h4>\n