Güvenli Yazılım Geliştirme (Tasarımdan Güvenli)
Güvenliği en sona bırakmak pahalıya patlar. Yazılım geliştiren kuruluşlar için güvenliği tasarımın ve sürecin parçası yapmanın temelleri.
Güvenli yazılım geliştirme, test aşamasına sıkıştırılmış bir kontrol listesi değildir; yazılımın tasarımından işletimine ve açık yönetimine kadar uzanan bir yaşam döngüsü disiplinidir. NIST SP 800-218, Güvenli Yazılım Geliştirme Çerçevesi (SSDF) 1.1 (Şubat 2022), herhangi bir yazılım geliştirme yaşam döngüsüne eklenebilecek üst düzey uygulamalar kümesi sunar. Amaçları: sürüme giren açıkları azaltmak, istismar edilenlerin etkisini sınırlamak ve kök nedenleri ele alarak tekrarlarını önlemek. Bu rehber, SSDF’yi kurumun geliştirme programına yerleştirmek için bir yol haritası verir.
Dört uygulama grubu
| Grup | Ne ister? | Örnek uygulamalar |
|---|---|---|
| Kurumu hazırlayın (PO) | İnsanların, süreçlerin ve teknolojinin güvenli geliştirmeye hazır olması. | Güvenlik gereksinimlerini belgelemek (PO.1), rol ve eğitimleri tanımlamak (PO.2), araç zincirini belirlemek (PO.3), güvenlik kontrol ölçütleri koymak (PO.4), geliştirme ortamlarını ayırıp korumak (PO.5). |
| Yazılımı koruyun (PS) | Yazılımın tüm bileşenlerini kurcalamaya ve yetkisiz erişime karşı korumak. | Kaynak kodu erişim kontrolüyle saklamak (PS.1), bütünlük doğrulama bilgisi yayımlamak (PS.2), sürümleri arşivlemek ve kaynağını kanıtlayabilmek (PS.3). |
| İyi korunan yazılım üretin (PW) | Güvenlik açıkları en aza indirilmiş yazılım üretmek. | Tasarımda risk modellemesi (PW.1), bileşen seçimi ve doğrulaması (PW.4), güvenli kodlama (PW.5), derleme araçlarının güvenli yapılandırılması (PW.6), kod incelemesi (PW.7), çalıştırılabilir kod testi (PW.8), güvenli varsayılan ayarlar (PW.9). |
| Açıklara müdahale edin (RV) | Kalan açıkları tespit etmek, gidermek ve tekrarlarını önlemek. | Açıkları belirlemek ve doğrulamak (RV.1), analiz edip risk müdahalesi planlamak (RV.2), kök nedenleri incelemek ve geliştirme sürecini güncellemek (RV.3). |
Tasarımda başlayın
SSDF, güvenlik gereksinimlerinin ve tehdit modellemesinin geliştirmeden önce yapılmasını bekler: yazılımın neyi koruduğunu, kimin saldırabileceğini ve veri akışlarındaki güven sınırlarını belirleyin. Açıkların önemli bölümü kodlamadan değil, tasarım kararlarından doğar. Güvenli varsayılan ayarlar da bu aşamada belirlenir; kullanıcıdan güvenli hâle getirmesini beklemek yerine yazılım güvenli gelmelidir (PW.9).
Üçüncü taraf ve açık kaynak bileşenler
Satın alınan, açık kaynak veya ticari bileşenlerin güvenliği de sizin sorumluluğunuzdadır. SSDF bunları edinirken ve sürdürürken kurumun gereksinimlerini karşıladıklarını yaşam döngüsü boyunca doğrulamayı ister (PW.4.1, PW.4.4). Örnekleri arasında araç zincirine bilinen açıkların otomatik tespitini eklemek, her bileşenin hâlâ bakımda olduğunu ve ömrünü doldurmadığını denetlemek, bakımı biten bileşenler için eylem planı yapmak ve onaylı bileşenleri kaynak (provenance) bilgisiyle birlikte listelemek sayılır. Pratikte bu, bir yazılım malzeme listesi (SBOM↗), bağımlılık taraması ve bileşen kaynağının doğrulanması demektir.
Otomasyon ve geri bildirim
İnceleme ve testler elle yapılabilir; ölçeklenebilmesi için araç zincirine eklenmelidir. PO.3 ve PO.4, kullanılacak araçları belirlemeyi ve geliştirme sürecinde güvenlik kontrollerinin ölçütlerini tanımlamayı öngörür. Kod incelemesi veya analizi (PW.7), çalıştırılabilir kod testi (PW.8) ve açık yönetimi (RV) birbirini besler: bulunan her açığın kök nedeni analiz edilmeli, benzer açıklar tüm kod tabanında aranmalı ve geliştirme süreci güncellenmelidir (RV.3).
Kaynaklar ve son gözden geçirme
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 (Şubat 2022): uygulama grupları PO, PS, PW, RV.
Son gözden geçirme: 21 Ekim 2026. Bu içerik bilgilendirme amaçlıdır; çerçevenin güncel sürümü için NIST’in resmî sayfasına bakın.
