Savunma sanayiinde güvenli yazılım geliştirme: SAST ve DAST araçları, CWE/SANS Top 25 açıkları, askeri yazılım denetimi ve kaynak kod güvenlik rehberi.
Hızlı Özet (TL;DR)
Savunma sanayii, askeri komuta kontrol sistemleri, aviyonik görev bilgisayarları ve insansız hava araçlarında (İHA) çalışan yazılımlar, doğrudan devlet destekli siber korsanların (APT) ve istihbarat servislerinin hedefindedir. Bu nedenle Savunma Sanayii Başkanlığı (SSB) ve ana yüklenici kurumlar (ASELSAN, HAVELSAN, TUSAŞ, ROKETSAN, TÜBİTAK), alt yüklenicilerden teslim aldıkları kaynak kodların SAST (Statik Uygulama Güvenlik Testi), SCA (Yazılım Bileşen Analizi) ve DAST (Dinamik Uygulama Güvenlik Testi) denetimlerinden “Sıfır Kritik/Yüksek Zafiyet” ile geçirilmesini şart koşar.
Askeri ve Kritik Sistemlerde Kaynak Kod Güvenliği Neden Hayati Önem Taşır?
Ticari bir web sitesinde veya mobil uygulamada unutulan bir yazılım hatası en fazla hizmet kesintisine veya maddi zarara yol açarken; bir savunma sanayii projesinde, radar alt sisteminde veya endüstriyel kontrol (SCADA/PLC) yazılımında bulunan tek bir bellek taşması (Buffer Overflow) zafiyeti, sistemin sahada kilitlenmesine veya düşman unsurlar tarafından uzaktan ele geçirilmesine neden olabilir.
Geleneksel yazılım geliştirme süreçlerinde güvenlik testleri genellikle projenin en sonunda, ürün teslim edilmeden birkaç gün önce yapılır. Oysa kod yazımı bittikten sonra mimari bir güvenlik açığını kapatmanın maliyeti, kodlama aşamasında kapatmaya göre 30 ila 100 kat daha yüksektir. Bu yüzden modern savunma sanayii ve imalat siber güvenlik projelerinde “Shift-Left Security” (Güvenliği Sola Kaydırma) prensibi uygulanır; yani güvenlik kontrolleri daha ilk kod satırı yazıldığı anda geliştiricinin IDE ekranında ve CI/CD derleme hattında başlar.
SAST, DAST ve SCA Arasındaki Temel Farklar
Savunma projelerinin kabul testlerinde (FAT / SAT) denetçilerin raporunu talep ettiği üç temel uygulama güvenliği (AppSec) metodolojisi aşağıdaki tabloda karşılaştırılmıştır:
| Karşılaştırma Kriteri | SAST (White-Box / Statik Kod Analizi) | SCA (Yazılım Bileşen ve Kütüphane Analizi) | DAST (Black-Box / Dinamik Güvenlik Testi) |
|---|---|---|---|
| Analiz Aşaması | Kod yazım aşamasında, derleme (Build) öncesinde | Paket bağımlılıkları eklendiğinde ve derleme sırasında | Uygulama çalışırken, çalışma zamanında (Runtime / Test ortamı) |
| Gereksinim | Kaynak kodun kendisine veya bayt koduna tam erişim | package.json, pom.xml, CMakeLists ve kütüphane ağacı | Çalışan bir web arayüzü, REST API veya ağ servisi |
| Tespit Ettiği Açıklar | Buffer Overflow, SQL Injection, Null Pointer, Hardcoded Password | Açık kaynak kütüphanelerdeki bilinen CVE zafiyetleri ve lisans riskleri | Kimlik doğrulama hataları, yetki aşımı (IDOR), sunucu yapılandırma açıkları |
| Referans Standartlar | MISRA C/C++, CERT C, CWE Top 25, DISA STIG | SBOM (Yazılım Malzeme Listesi - CycloneDX / SPDX), NVD CVE | OWASP Top 10, OWASP API Security Top 10 |
Gömülü Sistemlerde MISRA C/C++, CERT ve CWE Top 25 Disiplini
Savunma, havacılık (DO-178C) ve otomotiv (ISO 26262) sektörlerinde C ve C++ dilleriyle geliştirilen gömülü yazılımlar (Firmware / RTOS) için standart SAST taraması yeterli değildir. Derleyicinin hata vermediği ancak çalışma zamanında belirsiz davranışlara (Undefined Behavior) yol açan kod kalıplarını yakalamak için MISRA C:2023, MISRA C++ ve SEI CERT Coding Standards kuralları zorunlu tutulur:
- Dinamik Bellek Yönetimi Kısıtlamaları: Uçuş veya atış kontrol sistemlerinde çalışma esnasında kontrolsüz
malloc()/free()kullanımı bellek parçalanmasına (Heap Fragmentation) ve sistemin aniden durmasına yol açabileceği için statik analiz araçlarıyla kesin olarak engellenir. - Sınır Kontrolleri ve Tip Güvenliği (CWE-119 / CWE-787): Dizilerin (Array) sınırlarının dışına yazılması (Out-of-bounds Write) ve işaretçi (Pointer) aritmetiği hataları, SAST motorlarının Veri Akış Analizi (Taint Analysis) ve Soyut Yorumlama (Abstract Interpretation) algoritmalarıyla satır satır tespit edilir.
- Sıkı Döngü ve Karmaşıklık Sınırı (Cyclomatic Complexity): Bir fonksiyonun döngüsel karmaşıklığının belirlenen eşik değeri (örneğin 10 veya 15) aşmasına izin verilmez; böylece kodun test edilebilirliği ve deterministik çalışması garanti altına alınır.
Güvenli Yazılım Geliştirme Yaşam Döngüsü (SSDLC ve DevSecOps)
Ana yüklenici kabul denetimlerinden tek seferde geçebilen bir yazılım ekibinin uyguladığı 4 aşamalı Güvenli Yazılım Geliştirme Yaşam Döngüsü (SSDLC) şu şekildedir:
1. Gereksinim Aşamasında Tehdit Modellemesi (Threat Modeling)
Henüz tek satır kod yazılmadan önce yazılımın mimari veri akış diyagramları (DFD) çizilir. STRIDE metodolojisi kullanılarak sahtecilik (Spoofing), veri tahrifatı (Tampering), inkar (Repudiation), bilgi sızıntısı (Information Disclosure), hizmet engelleme (DoS) ve yetki yükseltme (Elevation of Privilege) vektörleri belirlenir.
2. Otomatik CI/CD Güvenlik Kapıları (Quality & Security Gates)
Geliştirici kodunu GitLab, GitHub veya Azure DevOps deposuna gönderdiğinde (Pull/Merge Request), CI/CD boru hattı otomatik olarak SonarQube, Checkmarx, Fortify veya Semgrep gibi SAST araçlarını tetikler. Eğer yeni yazılan kodda CWE Top 25 veya OWASP kapsamında Kritik (Critical) ya da Yüksek (High) seviyeli bir zafiyet varsa, sistem derlemeyi otomatik olarak reddeder (Build Fail) ve kodun ana dala (main branch) birleştirilmesine izin vermez.
3. Üçüncü Parti Kütüphane Denetimi (SCA) ve SBOM Üretimi
Modern bir yazılımın ortalama %70’i açık kaynaklı kütüphanelerden oluşur. Log4Shell vakasında olduğu gibi, sizin yazdığınız kod kusursuz olsa bile kullandığınız bir alt kütüphanedeki açık tüm sistemi tehlikeye atar. Bu nedenle her sürümde yazılımın içindeki tüm bileşenlerin envanterini gösteren SBOM (Software Bill of Materials - Yazılım Malzeme Listesi) otomatik üretilir ve bilinen CVE açıklarına karşı taranır.
4. Gizli Bilgi Sızıntısı Taraması (Secret Scanning) ve Kaynak Kod Koruma
Kod içine yanlışlıkla gömülmüş veritabanı parolaları, özel şifreleme anahtarları (Private Keys), JWT sırları veya API token’ları Git geçmişine girmeden önce Pre-Commit kancalarıyla yakalanır. Ayrıca geliştiricilerin çalıştığı bilgisayarlarda kaynak kodların USB belleklere veya kişisel bulut hesaplarına kopyalanmasını önlemek için uç noktalarda DLP (Veri Sızıntısı Önleme) politikaları ve geliştirme ağını dış dünyadan ayıran güvenlik duvarı (Firewall) kuralları uygulanır.
Yazılımlarınızın ana yüklenici kabul testleri öncesinde bağımsız güvenlik denetimlerini yaptırmak, kaynak kod analizi ve sızma testi raporlarınızı hazırlamak için Sızma Testi Hizmetleri sayfamızı ziyaret edin.
Sıkça Sorulan Sorular
SAST aracının bulduğu “False Positive” (Yanlış Alarm) bulgularını ana yüklenici denetiminde nasıl açıklarız?
Statik kod analizi araçları kodu çalıştırmadan matematiksel modellerle incelediği için bazen başka bir katmanda filtrelenmiş güvenli bir kodu da “Potansiyel Açık” (False Positive) olarak işaretleyebilir. Savunma sanayii kabul denetimlerinde bu bulguları rapordan keyfi olarak silemezsiniz. Bunun yerine her yanlış pozitif bulgu için mühendislik gerekçesini, girdinin hangi fonksiyonda doğrulandığını (Sanitization) açıklayan resmi bir Zafiyet Değerlendirme ve Bastırma Raporu (Suppression / Justification Document) hazırlayarak başdenetçinin onayına sunmanız gerekir.
Sızma testi (Pentest) yaptırdık, yine de SAST (Kaynak Kod Analizi) yaptırmak zorunda mıyız?
Evet, ikisi birbirinin alternatifi değildir. Sızma testi (Pentest) ve DAST dışarıdan çalışan uygulamaya yapılan “Kara Kutu” (Black-Box) testidir; yalnızca dışarıya açık arayüzlerdeki zafiyetleri bulabilir. Oysa SAST “Beyaz Kutu” (White-Box) analizidir; doğrudan kaynak kodun içini okuyarak henüz dışarıdan tetiklenmemiş gizli mantık hatalarını, arka kapıları (Backdoor), bellek taşmalarını ve ölü kod bloklarını yakalar. Kritik savunma projelerinde hem SAST hem de bağımsız Pentest raporu birlikte talep edilir.
Kaynak kodlarımızı bulut tabanlı SAST araçlarına yüklemek gizlilik (TGB / CUI) ihlali yaratır mı?
Kesinlikle yaratır. Savunma sanayii projelerine, Tesis Güvenlik Belgesi (TGB) kapsamındaki işlere veya CMMC/CUI verilerine ait kaynak kodlar hiçbir koşulda yurt dışındaki genel bulut (SaaS) kod analiz servislerine yüklenmemelidir. Tüm SAST, SCA ve Git sunucuları kurumun kendi sistem odasında, dış internetten izole edilmiş yerel sunucular (On-Premise / Air-Gapped) üzerinde çalıştırılmalıdır.