DevSecOps Uyum Hattı: Commit'ten Denetime B2B Yol Haritası

Çoğu B2B mühendislik ekibinde birbiriyle konuşmayan iki hat vardır. Biri kodu production'a taşır. Diğeri — genelde bir Excel dosyası ya da paylaşımlı bir sürücüdeki ekran görüntüsü klasörü — denetçiye, kurumsal müşteriye ve düzenleyiciye kodun güvenli olduğunu ispatlamaya çalışır. İkisi buluşuyorsa bile bu, release'ten haftalar sonra olur: bir pull request'i durdurması gereken bulgu, artık bir incident kaydına ya da hiç kimsenin dürüstçe cevaplayamadığı bir güvenlik anketine dönüşmüştür.

Bu boşluğun ölçülebilir bir maliyeti var. Verizon'un 2025 Data Breach Investigations Report'una göre, bilinen açıkların istismarı ilk erişim vektörlerinin %20'sini oluşturuyor — çalıntı kimlik bilgileriyle (%22) neredeyse başa baş — ve açık istismarına dayalı ihlallerde yıllık %34'lük bir artış var; bunun büyük kısmı internete açık edge altyapısını hedefliyor. Bunlar çoğunlukla zero-day değil: dependency ağacında ya da container base image katmanlarında oturan, bilinen CVE'ler. Pipeline'a konacak tek bir geçit, bu paket registry'ye ulaşmadan önce onu durdururdu. Öte yandan DORA'nın 2024 State of DevOps raporu, ekiplerin yalnızca %19'unun "elite" seviyede çalıştığını buldu (talep üzerine deploy, bir günden kısa lead time, %5 civarında change failure rate) — ve bu veri setinde yüksek teslimat performansı ile güçlü güvenlik duruşu birbirine rakip hedefler değil, birlikte ilerliyor.

Bir devsecops uyum hattı, bu boşluğu kapatan mekanizmadır: güvenlik ve uyum kontrollerini kodun geliştiricinin dizüstü bilgisayarından production'a giden yoluna doğrudan yerleştirir; kötü bir deploy'u durduran kanıt, aynı zamanda denetçiyi ya da müşterinin satın alma ekibini tatmin eden kanıttır. Bu yazı, böyle bir hattı kurmanın teknik yol haritası: pipeline mimarisi, araç kategorileri, policy as code, DevSecOps benimsemesini öldüren false positive sorunu ve bu kontrollerin müşterilerinizin gerçekten sorduğu düzenleyici rejimlerle — KVKK, PIPEDA, UAE Bilgi Güvencesi Standartları ve DIFC veri koruma hukuku — nasıl eşleştiği.

Öne Çıkan Bulgular

• Uyum-hazır bir pipeline'ın beş geçit aşaması vardır — pre-commit, PR, build, deploy, runtime — her birinin kendi araç kategorisi ve kendi warn/block politikası vardır. Her şeyi her yerde aynı anda zorunlu kılmaya çalışmak, çoğu devsecops girişiminin başarısız olma nedenidir.
• SBOM (yazılım malzeme listesi) üretimi artık isteğe bağlı bir araç hijyeni değil; Log4Shell sonrası tedarik zinciri denetiminin bir sonucu olarak kurumsal ve kamu satın alma anketlerinde kalıcı bir kalem haline geldi.
• Policy as code (OPA/Rego, Kyverno), "bir güvenlik politikamız var" cümlesini kimsenin okumadığı bir PDF'ten her deploy'da çalışan yürütülebilir bir geçide dönüştürür.
• Benimsemeyi öldüren asıl şey aracın kendisi değil, false positive'lerdir. İlk günden %40 false positive oranına sahip bir pipeline, bir sprint içinde etrafından dolaşılır — geçitleri planlamadan önce triage ve tuning iş akışını planlayın.
• Blocking geçitleri ilk günden devreye almak, engelleyeceği herhangi bir güvenlik açığından çok daha hızlı bir şekilde geliştirici güvenini yok eder. Tanımlı bir tuning penceresiyle warn-then-block, gerçek bir mühendislik ekibiyle temas ettiğinde hayatta kalan tek sıralamadır.
• Aynı pipeline çıktıları (tarama sonuçları, SBOM, imzalı onaylar) hem CI/CD güvenlik duruşunuzu hem de KVKK, PIPEDA, UAE IAS ve DIFC-DP için denetim kanıtını sağlar — uyum kanıtı ile güvenlik tooling'ini asla iki ayrı proje olarak inşa etmemelisiniz.

"Shift Left" Neden Bir Uygulama Değil de Onay Kutusu Oldu

"Shift left" bir mühendislik pratiği olarak benimsenmeden önce bir slogan olarak benimsendi. Yaygın başarısızlık deseni şu: güvenlik ekibi bir SAST aracı satın alır, main branch'e yönlendirir ve ayda bir mühendislik liderliğine bir PDF rapor gönderir. Geliştiricinin gerçek iş akışında hiçbir şey değişmez. Uyum ekibi ise ayrı olarak kendi tracker'ını — çoğunlukla gerçekten bir Excel dosyasını — tutar; her denetim döngüsünden önce birinin elle ekran görüntüsü alması gereken kontrol-kanıt eşleşmelerini takip eder.

Sonuç, ortak bir veri modeli olmadan örtüşen sorunları çözen iki ayrı organizasyondur. Güvenlik ekibi hangi açığın production'da gerçekten erişilebilir olduğunu söyleyemez. Uyum ekibi denetçiye hangi kontrollerin sürekli uygulandığını, hangilerinin yılda bir kontrol edildiğini söyleyemez. Ve bir SQLi bulgusunu ya da pinlenmemiş bir base image'ı gerçekten düzeltebilecek tek kişi olan geliştiriciler, bunların hiçbirini bir production incident'ı ya da üzerinde adlarının yazılı olduğu bir denetim bulgusu haline gelene kadar görmezler.

Bir devsecops uyum hattı yalnızca tooling sorununu değil, yapısal sorunu çözer: tek pipeline, tek geçit seti, ve kanıt izi ayrı bir proje değil, uygulamanın doğal bir yan ürünüdür.

Pipeline, Aşama Aşama

Bu yazının geri kalanındaki her şey — SBOM, OPA, DAST, false positive yönetimi — bu beş aşamadan birine bağlanır.

Araç seçiminden daha önemli iki tasarım kararı var. Birincisi, ilk günden koşulsuz olarak yalnızca secret tarama block eder — geri kalan her şey bir tuning döneminden geçerek "block" hakkını kazanır (aşağıdaki karşı-örnek bölümüne bakın). İkincisi, her aşama tek bir artifact deposuna yapılandırılmış çıktı yazar (SARIF, CycloneDX JSON, OPA karar logları), çünkü bu depo daha sonra denetim kanıtınız haline gelir — onu iki kez tutmuyorsunuz.

DAST ve IaC Taraması: SAST'in Kapatmadığı İki Boşluk

SAST kaynak kodu okur; Terraform'unuzun public read erişimli bir S3 bucket provision ettiğini söyleyemez, kimlik doğrulaması yapılmış bir API endpoint'inin gerçekten çağrıldığında başka bir tenant'ın verisini sızdırdığını söyleyemez. İki kategori bu boşlukları kapatır.

DAST (Dynamic Application Security Testing), çalışan uygulamayı bir saldırganın yapacağı gibi test eder — bozuk input gönderir, authentication ve authorization sınırlarını yoklar, canlı bir staging ortamına karşı injection ve SSRF kontrolü yapar. OWASP ZAP (açık kaynak, CI içinde script'lenebilir) ya da Burp Suite Enterprise (ticari, authenticated tarama konusunda daha iyi) gibi araçlar kaynak kod üzerinde değil, deploy edilmiş bir ortam üzerinde çalışır. Her staging deploy'unda hızlı, kimlik doğrulamalı bir ZAP baseline taraması, her PR'da değil zamanlanmış (gecelik veya haftalık) daha derin bir aktif tarama çalıştırın — aktif taramalar "her commit'te geçit" modelini bozacak kadar yavaş ve gürültülüdür.

IaC (Infrastructure as Code) taraması, yanlış yapılandırmayı provision edilmeden önce yakalar: aşırı yetkili IAM politikaları, 0.0.0.0/0'a açık security group'lar, şifrelenmemiş storage, eksik logging. Checkov ve tfsec, PR aşamasında Terraform, CloudFormation ve Kubernetes manifest'lerini tarar — bu, ekleyebileceğiniz en yüksek değerli, en düşük gürültülü geçitlerden biridir, çünkü altyapı yanlış yapılandırması deterministiktir (bucket ya public'tir ya değildir), SAST'in pattern-matching false positive oranının aksine.

SBOM Üretimi: Satın Alma Ekipleri Neden Şimdi Bunu Soruyor

Software Bill of Materials (SBOM), belirli bir build artifact'indeki her bileşenin — doğrudan ve transitive dependency'ler, base image katmanları, dil paketleri — makine tarafından okunabilir envanteridir; genellikle CycloneDX ya da SPDX formatında. Build zamanında Syft ile üretin (syft packages docker:your-image:tag -o cyclonedx-json) ya da bir build sistemi eklentisi olarak (cyclonedx-maven-plugin, cyclonedx-npm); artifact başına bir SBOM saklayın, release başına bir tane değil.

Bunun "olsa iyi olur" durumundan "satın alma kontrol listesi kalemi"ne dönüşmesinin nedeni Log4Shell'dir (Aralık 2021): binlerce kuruluş, log4j-core'un üç dependency derinliğinde nerede gömülü olduğuna dair bir envanteri olmadığı için sadece maruz kalıp kalmadıklarını anlamak için günler harcadı. Kurumsal ve kamu alıcılar artık güvenlik anketlerinin ve sözleşme şartlarının bir parçası olarak rutin olarak bir SBOM istiyor — her satırını okuyacakları için değil, kendi güvenlik ekiplerinin bir sonraki Log4Shell benzeri sorguyu günler yerine dakikalar içinde ürününüze karşı çalıştırabilmesi için. Pipeline'ınız istek üzerine belirli bir build hash'i için SBOM üretemiyorsa, bu artık B2B satış döngülerinde anlaşmayı bloke eden bir eksiklik, sadece güvenlik açısından "olsa iyi olur" değil.

Container ve Base Image Hijyeni

Ekibinizin ship ettiği container CVE'lerinin çoğu uygulama kodundan gelmedi — base image'dan geldi. Maruziyeti gerçekten azaltan pratik kurallar:

• Base image'ları mutable tag ile değil digest ile pinleyin (FROM node:20.11-slim@sha256:...) — bir tag yarın farklı, daha yeni (ya da tehlikeye atılmış) bir image'a işaret edebilir.
• Saldırı yüzeyini ve triage etmeniz gereken CVE sayısını küçültmek için minimal ya da distroless base image'ları (gcr.io/distroless/*, Alpine, chainguard images) tercih edin.
• Uygulama kodu değişmese bile sabit bir kadansta (haftalık makul bir varsayılan) yeniden build edip tarayın — base image CVE'leri sürekli açıklanıyor, altı ay önce taramasını geçmiş bir container hâlâ temiz olmayabilir.
• Non-root çalıştırın, ihtiyaç duymadığınız Linux capability'lerini düşürün ve resource limit'leri ayarlayın — bunlar Dockerfile hijyen önerisinden ibaret değil, admission zamanında OPA/Kyverno ile zorlanabilir.
• Build zamanında Trivy ya da Grype ile tarayın, fix mevcut olan Critical seviyesinde block edin; fix'i olmayan Critical'lar sessizce geçmesin, süresi olan takip edilen bir istisnaya gitsin.

OPA ile Policy as Code: Politikayı Yürütülebilir Hale Getirmek

Open Policy Agent (OPA), deploy politikasını kimsenin uygulamadığı bir wiki sayfası yerine kod (Rego) olarak ifade etmenizi sağlar. Gerçekçi bir örnek — root olarak çalışan ya da resource limit'i olmayan herhangi bir Kubernetes deployment'ını reddetme:

package kubernetes.admission

deny[msg] {
    input.request.kind.kind == "Pod"
    container := input.request.object.spec.containers[_]
    not container.securityContext.runAsNonRoot
    msg := sprintf("container '%s' must set runAsNonRoot: true", [container.name])
}

deny[msg] {
    input.request.kind.kind == "Pod"
    container := input.request.object.spec.containers[_]
    not container.resources.limits.memory
    msg := sprintf("container '%s' is missing memory limits", [container.name])
}

Bunu merge öncesi CI'da Kubernetes manifest'lerinize karşı Conftest ile çalıştırın, deploy zamanında da OPA Gatekeeper ya da Kyverno ile bir admission controller olarak tekrar çalıştırın — aynı politika, iki kez uygulanmış: biri PR aşamasında hızlı bir uyarı, diğeri runtime'da gerçek bir güvenlik kontrolü. Bu tekrar kasıtlıdır: ihlali PR aşamasında yakalamak geliştirici için daha ucuzdur; aynı ihlali admission aşamasında tekrar yakalamak asıl güvenlik kontrolünüzdür, çünkü PR aşaması kontrolleri merge yetkisi ve bir --no-verify olan herkes tarafından atlanabilir.

False Positive Sorunu: Benimsemeyi Gerçekten Öldüren Şey

Bu, çoğu DevSecOps girişiminin atladığı ve başarısız olmalarının nedeni olan kısımdır. Varsayılan kural setleriyle çalıştırılan bir SAST ya da SCA aracı, gerçek bir kod tabanına karşı bulguların rutin olarak %30-50'sini gürültü olarak işaretler — ölü kod yolları, test fixture'ları, mevcut ama hiç çağrılmayan dependency'ler, tarayıcının tanımadığı sanitization. Geliştiriciler ilk haftalarını bu oranı elle triage ederek geçirirse, araca güvenmeyi bırakırlar; bir ekip bir güvenlik aracına güvenmeyi bıraktığında ya --no-verify ile atlatılır ya da kimsenin kaldırmadığı bir allow_failure: true alır.

Geçidi kurmadan önce triage iş akışını kurun:

1. Alımda otomatik triage. Bulguları severity ve dosya sahipliğine (CODEOWNERS) göre doğrudan sorumlu ekibe yönlendirin, darboğaz haline gelen merkezi bir güvenlik kuyruğuna değil.
2. Süresi dolan istisna, asla sessiz istisna. Bir istisna, zorunlu bir gerekçe ve bir son kullanma tarihi (severity'ye göre 30, 60 ya da 90 gün) içeren bir YAML/JSON kaydıdır — # nosemgrep: reason="test fixture, not reachable" expires=2026-10-01. Süresi dolan istisnalar otomatik olarak yeniden açılır; sessizce eskimezler.
3. Kuralı tune edin, kategoriyi kapatmayın. Belirli bir Semgrep kuralı kod tabanınızın idiomuna karşı yanlış tetikleniyorsa (örneğin sadece dahili kullanılan bir HTTP client'a yanlış SSRF eşleşmesi), kuralı düzeltin ya da kapsamını daraltın — tek bir kural gürültülü diye organizasyon genelinde SSRF tespitini kapatmayın.
4. False positive oranını birinci sınıf bir metrik olarak takip edin. MTTR ve escaped defect ile aynı dashboard'da her ay gözden geçirin (aşağıdaki metrikler bölümüne bakın). 90 gündür tune edilmemiş bir kural seti aktif olarak geliştirici güvenini kaybediyordur.
5. Geliştiricilere sessiz bir bypass değil, loglanan hızlı bir override yolu verin. Acil bir deploy mümkün olmalı — loglanmış, süre sınırlı ve bir sonraki iş gününde gözden geçirilen, kalıcı bir --force alışkanlığı değil.

Pipeline Kontrollerini Düzenleyici Yükümlülüklerle Eşleştirmek

Aşağıdaki tablo, yaygın pipeline kontrollerini Türkiye ve Körfez'e yönelik bir B2B pratiğinde müşterilerinizin ve düzenleyicilerin en çok sorduğu uyum rejimleriyle eşleştiriyor; KVKK öncelikli, ama PIPEDA, UAE IAS ve DIFC-DP de kapsanıyor. Bu tabloyu "bu kontroller genellikle şu yükümlülükleri destekler" olarak okuyun, hukuki kesinlik olarak değil — hiçbiri kendi veri akışlarınıza ve sözleşmelerinize özel hukuk müşavirliği incelemesinin yerini tutmaz; belirli para cezası tutarları, uygulama tarihleri ya da sertifikasyon takvimleri bir pipeline dokümanının iddia edeceği kapsamın dışındadır.

Güncellik notu, çünkü bu kısım gerçekten değişiyor: KVKK'nın sınır ötesi veri aktarımı rejimi, Temmuz 2024'te yayımlanıp Eylül 2024'te yürürlüğe giren düzenlemeyle esaslı biçimde değişti; açık rızayı varsayılan aktarım dayanağı olmaktan çıkarıp yerine yeterlilik kararı, Kişisel Verileri Koruma Kurulu tarafından yayımlanan standart sözleşmeler, bağlayıcı şirket kuralları ya da tanımlı istisnaları getirdi — bu yazının hazırlandığı tarih itibarıyla Türkiye henüz ülke bazında bir yeterlilik kararı yayımlamadı, dolayısıyla standart sözleşmeler pratikteki varsayılan mekanizma. PIPEDA, Kanada'nın özel sektör gizliliği için yürürlükteki federal kanunu olmaya devam ediyor — Consumer Privacy Protection Act'i getirecek olan Bill C-27, Ocak 2025'te parlamentonun askıya alınmasıyla gündemden düştü ve orijinal haliyle yeniden sunulmadı; bu yüzden artık yasada olmayan bir tasarıya değil, PIPEDA'ya göre inşa edin. NESA, UAE Siber Güvenlik Konseyi altındaki Signals Intelligence Agency (SIA) bünyesine katıldı ve Bilgi Güvencesi Standartları bu yapı altında güncellenmeye devam ediyor — bir müşteri teslimatında belirli bir kontrol sayısı belirtmeden önce güncel standart versiyonunu BAE hukuk danışmanınızla ya da doğrudan SIA ile teyit edin. DIFC'nin veri koruma hukuku 2025 ortasında (DIFC Law No. 1/2025) esaslı biçimde değişti; sınır ötesi aktarım yeterliliği değerlendirmesinde değişiklikler ve yeni bir özel dava hakkı da dahil — 2025 öncesi herhangi bir DIFC-DP rehberliğini güncel kabul etmeyin.

Türk müşteri tabanınız varsa ya da Türkiye mukimlerinin verisini işliyorsanız, yukarıdaki pipeline kontrolleri gerekli ama tek başına yeterli değildir — bu hattın altında oturması gereken organizasyonel ve sözleşmesel katman için KVKK Veri Koruma Uyum Yol Haritası yazımızı okuyun.

90 Günlük Devreye Alma Sıralaması

Gerçek bir mühendislik ekibiyle temas ettiğinde hayatta kalan şey, tek seferlik bir geçiş değil, aşamalı bir yol haritasıdır.

Uyum kanıtı (tarama logları, SBOM arşivi, istisna kaydı, OPA karar logları) 30. güne kadar zaten tek bir saklama deposuna akıyor olmalı — devreye almadan sonraki ilk denetim döngünüzden çok önce elinizde altı ayı aşkın sürekli kanıt istersiniz, sonradan yeniden inşa ettiğiniz kanıt değil.

Önemli Metrikler: MTTR ve Escaped Defect Rate

İki metrik pipeline'ın gerçekten çalışıp çalışmadığını, sadece çalışır göründüğünü değil, söyler.

Açıklar için MTTR (Mean Time to Remediate): bir bulgunun bir tarayıcıda ilk görünmesinden çözümüne (düzeltme ya da süresi olan bir istisnayla resmi kabul) kadar geçen süre, her severity seviyesi için ayrı ayrı ölçülür. Ticketing sisteminizdeki (Jira, Linear) tarayıcının bulgu ID'sine bağlı zaman damgası çiftlerinden hesaplayın — çoğu SAST/SCA aracı API üzerinden otomatik ticket oluşturmayı destekler, bunu anekdot değil ölçülebilir bir şey haline getiren de budur. Severity'ye göre ayrı takip edin; tüm severity'ler genelinde 45 günlük bir ortalama MTTR, hızla kapatılan bir Low yığınının arkasında 90 gündür düzeltilmemiş bir Critical'ı gizleyebilir.

Escaped defect rate: hareketli bir pencerede, SDLC boyunca (pre-prod artı production) keşfedilen toplam açığa karşı production'da (runtime tarama, bug bounty ya da incident yoluyla) keşfedilen açıkların yüzdesi. Pipeline çalışıyorsa, daha fazla kategori merge öncesinde "warn"dan "block"a geçtikçe bu, ardışık 90 günlük pencerelerde düşme eğilimi gösterir. DORA'nın araştırması bunu doğrudan teslimat performansına bağlıyor — elite seviyedeki organizasyonlar (2024 State of DevOps raporuna göre yanıt verenlerin yaklaşık %19'u), %5'in altı change failure rate'i sürekli güvenlik pratikleriyle birleştiriyor; bu bir tesadüf değil, değişiklikleri küçük ve geri alınabilir tutan aynı mühendislik disiplininin, açıkların production'a kaçmasını da engellemesinden kaynaklanıyor.

Karşı Örnek: İlk Günden Blocking Geçitler Neden Benimsemeyi Yok Eder

Bir güvenlik ekibi, mühendislikle gerçek bir ortaklık kurmadan devreye almayı üstlendiğinde en sık gördüğümüz başarısızlık modeli şu: SAST, SCA ve IaC taraması, kimsenin gerçek kod tabanına karşı tune edilmeden ilk günden blocking modunda devreye girer. İlk haftada kırk pull request bloklanır, üçte biri sonradan test fixture'ı ya da hiç erişilemeyen kod yolu olduğu ortaya çıkan bulgulardır. Geliştiriciler tam olarak sizin onların yerinde yapacağınız şeyi yapar: engelin etrafından en hızlı yolu bulurlar. Bu, git commit --no-verify demektir, pipeline config'inde continue-on-error: true işaretli bir güvenlik aracı adımı demektir, ya da kırk cevaplı "bu kontrolü nasıl atlarım" başlıklı bir Slack thread'i demektir. Bu desen bir kez yerleşince, kural setini üç hafta sonra düzeltseniz bile geri dönmez — güven gitmiştir ve yeniden kazanmak kaybetmekten çok daha uzun sürer.

Çözüm sıralamadır, daha yumuşak kurallar değil. Yukarıdaki 90 günlük tabloda tarif edilen tuning penceresi boyunca yalnızca warn, blocking'e geçiş için takvim tarihi değil açık ve yayımlanmış bir eşik olarak false positive oranı. Geliştiricilere neyin geldiğini ve nedenini tam olarak söyleyin, iyileşen false positive trend çizgisini gösterin, override yolunu gizli değil görünür ve loglu yapın. Bunu yapan ekipler, geliştirici güvenini kaybetmeden blocking geçitlere ulaşır; doğrudan blocking'e atlayan ekipler ise herkesin sessizce etrafından dolaştığı bir pipeline'a sahip olur — bu, hiç pipeline olmamasıyla işlevsel olarak aynıdır, sadece artık uyum ekibi bir tane olduğunu sanmaktadır.

Anti-Pattern'ler ve Sık Yapılan Hatalar

• Varsayılan kural setleriyle tarayıp hemen block etmek. Varsayılan kurallar kimsenin özel kod tabanı için tune edilmemiştir; en az bir tam bulgu döngüsünü triage edene kadar bunları block değil warn için kullanın.
• SBOM'u release başına bir kez üretmek, build başına değil. Release kadansındaki bir SBOM, "hangi belirli build hash'i açığa çıktı" sorusunu cevaplayamaz — bu tam olarak müşterinizin güvenlik ekibinin soracağı soru.
• Uyum eşleştirme tablosunu hukuki görüş gibi ele almak. Tablo kontrolleri destekler; sözleşmelerin, veri akışlarının ya da sınır ötesi aktarım mekanizmalarının hukuk müşavirliği incelemesinin yerini tutmaz.
• Bulgularda sahiplik olmaması. Kimsenin bir SLA içinde triage etmekten sorumlu olmadığı bir kuyruğa rapor veren bir tarayıcı, düzeltme değil alert üretir.
• Container'ı bir kez tarayıp bir daha rebuild etmemek. Build zamanında temiz olan bir base image, kodunuzun tek satırı değişmeden yeni açıklanan CVE'ler biriktirir.
• Bir blog yazısından OPA/Rego politikasını kendi manifest'lerinize karşı test etmeden kopyalamak. Gerçek bir deploy'a karşı hiç çalıştırılmamış bir politika ya sessizce başarısız olur ya da her şeyi bloklar — bir admission controller'a bağlamadan önce gerçek bir manifest kümesine karşı conftest test ile test edin.
• Süresi olmayan istisnalar. İnceleme tarihi olmayan bir istisna, kağıt üzerinde iz bırakan kalıcı bir delik demektir.

Sık Sorulan Sorular

DevSecOps pipeline nedir, pratikte ne anlama gelir? Güvenlik incelemesinin ayrı ve olay sonrası yapılması yerine, belirli aşamalara — pre-commit, PR, build, deploy ve runtime — gömülü güvenlik ve uyum geçitlerine sahip mevcut CI/CD hattınızdır.

CI/CD'ye her build'i bozmadan güvenlik geçitleri nasıl eklerim? Her yeni geçidi yalnızca warn modunda başlatın, 30-60 gün false positive oranını ölçün, kural setini gerçek bulgulara göre tune edin, oran anlaşılan bir eşiğin altına indiğinde block'a geçin. Yukarıdaki 90 günlük devreye alma tablosuna bakın.

Kamu müşterilerine satış yapmıyorsam SBOM'a ihtiyacım var mı? Giderek daha fazla evet — kurumsal B2B satın alma anketleri artık herhangi bir kamu sözleşmesi şartından bağımsız olarak doğrudan bunu istiyor, büyük ölçüde Log4Shell tedarik zinciri paniğinin bir mirası olarak.

SAST, DAST ve SCA arasındaki gerçek fark nedir? SAST, çalışmadan önce kaynak kodunuzu güvensiz pattern'ler için okur. SCA (software composition analysis), dependency'lerinizi bilinen açık veritabanlarına karşı kontrol eder. DAST, çalışan uygulamayı dışarıdan bir saldırganın yapacağı gibi test eder ve diğer ikisinin göremediği yapılandırma ve runtime sorunlarını yakalar.

Bir DevSecOps pipeline'ını gerçekçi olarak ne kadar sürede uyum-hazır hale getirebilirim? Beş aşamanın tamamında tam warn-then-block uygulamasına ulaşmak için 90 günlük aşamalı bir devreye alma planlayın, artı ilk ciddi denetim döngüsüyle karşılaşmadan önce yaklaşık altı aylık sürekli kanıt toplama.

Geliştiricilerin güvenlik kontrollerini devre dışı bırakmasını nasıl önleriz? Herhangi bir şeyi blocking yapmadan önce false positive oranını düzeltin, geliştiricilere gerçek acil durumlar için loglanan ve süre sınırlı bir override yolu verin, devreye alma takvimini ve eşikleri görünür kılın — amaç, kimsenin etrafından dolaşmak için sebebi olmadığı bir pipeline'dır.

İlgili İçerikler

• KVKK Veri Koruma Uyum Yol Haritası — Türkiye'ye yönelik operasyonlar için bu hattın altında oturması gereken organizasyonel ve sözleşmesel kontroller.
• SAMA & NESA Siber Güvenlik Uyum Planı — bu hat üzerine inşa edilen Körfez fintech ve finansal hizmet ortamları için düzenleyici detaylar.
• Sağlık Sektörü Siber Güvenliği ve PHIPA Uyumu — aynı geçitlerin Kanada sağlık verisi yükümlülükleriyle nasıl eşleştiği.
• Suudi Kurumlar için Bulut Geçiş Rehberi: NCA ECC — Suudi NCA gereksinimleri altında bir bulut geçişi sırasında bu hattın kontrollerini uygulamak.

D-Elite Solutions ile Görüşün

D-Elite Solutions'ın mühendislik ve güvenlik ekibi, Kanada ve Körfez genelinde regüle B2B yazılım şirketleri için CI/CD pipeline'ları kurar ve sertleştirir; devreye alma sıralamasını teslimat hızını bozmadan denetimden geçecek şekilde planlamak için doğrudan mühendislik liderliğiyle çalışır. Kıdemli bir mühendisle mevcut pipeline'ınızı gözden geçirmek için ücretsiz danışmanlık randevusu alın — yukarıdaki aşamalara karşı somut bir eksik listesi ve ekibiniz için gerçekçi bir devreye alma sıralamasıyla çıkarsınız, devam etme yükümlülüğü olmadan.