“Güvenlik artık testte değil, tasarımda başlar.”
“Uyum sadece bir denetim değildir, bir zihniyettir.”
Bankacılık sektöründe 2026 yılı, yalnızca yeni teknolojilerin değil, yeni sorumlulukların yılı olacak.
BDDK’nın “Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmeliği”,
artık her kurumun güvenliği nasıl tasarlayıp geliştirdiğini yakından ilgilendiriyor.
Ve bu dönüşümün iki anahtarı var:
Secure by Design
DevSecOps
Neden Secure by Design?
“Secure by Design” yaklaşımı, güvenliğin en baştan, tasarım aşamasında dahil edilmesi anlamına gelir.
Artık “önce kodla, sonra test et” dönemi bitti.
Bugünün güvenlik stratejisi şu mottoda özetleniyor:
“Güvenliği sonradan eklemeyin, baştan inşa edin.”
Bu yaklaşım, BDDK’nın Madde 20 (Güvenli Yazılım Geliştirme) ve
Madde 25 (Bilgi Güvenliği Yönetimi) ile doğrudan örtüşür.
Örnek:
Bir bankanın müşteri onboarding uygulaması tasarlanırken, gizli veriler, API erişimleri ve oturum yönetimi tasarımın içine dahil edilmelidir — sadece test aşamasına bırakılmamalıdır.
DevSecOps Neden Kritik?
DevSecOps, yazılım geliştirme sürecine güvenliği entegre eden kültürel ve teknik bir devrimdir.
CI/CD boru hattında (pipeline)
Sürekli kod analizi (SAST)
Zafiyet taramaları (DAST)
Container ve IaC güvenlik kontrolleri
gibi süreçler, otomatik hale getirilir.
Yani “güvenlik sonradan eklenen bir engel değil,
otomatik çalışan bir destek sistemine” dönüşür.
BDDK Uyumuna Etkisi:
Madde 22: Değişiklik yönetimi süreçleri izlenebilir hale gelir.
Madde 23: Güvenlik testleri otomasyona bağlanır.
Madde 25: Sürekli izleme (continuous monitoring) sağlanır.
[Infografik: Secure by Design ve DevSecOps Uyum Haritası]
Planlama aşamasında güvenlik gereksinimlerini belirle
Kodlama sürecine statik analiz ve otomatik testleri entegre et
Dağıtım sonrası sürekli izleme ve geri bildirim sistemi oluştur
Hangi Eğitimlerle Hazırlanabilirsiniz?
| Eğitim | BDDK Maddesi | Odak Alanı |
|---|---|---|
| Secure by Design Eğitimi | Madde 20, 25 | Güvenli mimari tasarım, OWASP Top 10, LLM güvenliği |
| DevSecOps Eğitimi | Madde 22, 23 | CI/CD, SAST, DAST, IaC, otomasyon |
| Application Security for Developers | Madde 20-23 | STRIDE, güvenli kodlama, zafiyet yönetimi |
| Certified Java and Web Application Security | Madde 20 | Java, Spring, Log4Shell güvenliği |
| Certified C# and Web Application Security | Madde 20 | .NET, OWASP, XSS, CSRF koruması |
| Programming Foundations | Madde 20 | Kodlama temelleri, veri yapıları, güvenli mantık |
Bu eğitimler, kurumların teknik ekiplerini denetime değil, güvenliğe hazır hale getirir.
Gerçek Hayattan Bir Senaryo
Bir finans kuruluşu, yeni bir dijital kredi uygulaması geliştirirken DevOps sürecine güvenlik adımı eklemedi.
Sızma testinde, CI pipeline içinde açık bir API anahtarı bulundu.
BDDK denetimi, “Madde 23 – Güvenlik Testi Eksikliği” raporu oluşturdu.
Sonuç?
Uygulama canlıya alınmadan, güvenli DevSecOps yapısı inşa edildi — ve süreç tekrarlanabilir hale geldi.
“DevSecOps bir araç değil, bir kültürdür.
Secure by Design ise bu kültürün planlama safhasındaki kalbidir.”
Sık Sorulan Sorular
Secure by Design yaklaşımı yasal olarak zorunlu mu?
Evet. Madde 20, güvenli tasarım ve kodlama prensiplerini zorunlu kılar.
DevSecOps uygulamak için özel bir araç gerekir mi?
Hayır, önemli olan araç değil süreçtir. GitLab, Jenkins, Azure DevOps veya AWS fark etmez; güvenlik entegrasyonu zorunludur.
BDDK’ya göre eğitim şart mı?
Evet. Denetimlerde geliştiricilerin güvenli yazılım geliştirme eğitimleri aldığına dair kanıt istenir.
Nereden başlamalıyım?
Secure by Design
ve DevSecOps
eğitimleri en kritik başlangıç noktalarıdır.
Güvenliği Sürece Dahil Et, Uyum Kendiliğinden Gelir
Yönetmeliklere uymanın en etkili yolu, onları geliştirme sürecine entegre etmektir.
“Secure by Design” planlamada başlar, “DevSecOps” onu yaşatır.
Denetimi değil, güvenliği hedefle.