NIS2 Zafiyet Yönetimi ve Güvenli Yazılım 2026: Article 21(2)(e) Rehberi
| Süreç | NIS2 hedefi | Örnek çıktı |
|---|---|---|
| Satın alma | Güvenlik şartlarını sisteme girmeden belirlemek | Security requirements, tedarikçi değerlendirmesi |
| Geliştirme | Zafiyeti tasarım/kod aşamasında azaltmak | Threat model, code review, SAST/DAST |
| Zafiyet | Açıkları risk bazlı ele almak | Vulnerability register, CVE takibi |
| Yama | Kritik açıkları zamanında gidermek | Patch SLA, istisna ve telafi kontrolü |
| Açıklama | Güvenlik açığı bildirimini yönetmek | VDP, iletişim kanalı, triage kaydı |
| EOL | Desteksiz bileşen riskini azaltmak | Ürün yaşam döngüsü ve migrasyon planı |
NIS2 Article 21(2)(e) tam olarak neyi kapsar?
Directive (EU) 2022/2555 Article 21(2)(e), “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” alanını zorunlu siber risk yönetimi tedbirleri arasında sayar. Hüküm üç ayrı yaşam döngüsü aşamasını aynı anda kapsar: sistemin satın alınması/edinimi, geliştirilmesi ve bakımda tutulması.
Dolayısıyla NIS2 zafiyet yönetimi yalnız güvenlik ekibinin haftalık taramasından ibaret değildir. Satın alma ekibinden geliştiriciye, sistem yöneticisinden hukuk ve tedarikçi yönetimine kadar birden fazla fonksiyon aynı zincirin parçasıdır. Güvenlik kriteri ürün sisteme alındıktan sonra düşünülürse Article 21’in “acquisition” boyutu eksik kalır.
Tedbirler Article 21(1) uyarınca riskle orantılı olmalıdır. İnternete açık kritik kimlik sistemi ile yalnız kapalı ağdaki düşük etkili test uygulamasına aynı yama hedefi verilmesi şart değildir; farklılık risk gerekçesiyle belgelenmelidir.
Yeni yazılım ve donanım alınırken hangi NIS2 kontrolleri uygulanmalı?
Güvenli satın alma sürecinde bilgi güvenliği gereksinimleri ihale/RFP veya sözleşme öncesinde tanımlanmalıdır. Ürünün MFA desteği, şifreleme özellikleri, log üretimi, destek süresi, zafiyet bildirim kanalı, güvenlik güncelleme politikası, alt bileşenleri ve olay bildirim kapasitesi satın alma kriterine çevrilebilir.
Tedarikçinin “end of life” ve “end of support” tarihleri özellikle kayda alınmalıdır. Kritik bir sistemin üç ay sonra destek dışına çıkacağı satın alma aşamasında biliniyorsa, şirket daha baştan yüksek riskli ve kısa ömürlü bir teknoloji borcu yaratmış olur.
Bulut/SaaS ürünlerinde müşteri tarafının güvenlik kontrolü sınırlı olabilir. Bu durumda tedarikçinin bağımsız güvence raporları, penetrasyon testi yaklaşımı, güvenlik olay geçmişi, veri lokasyonu ve zafiyet giderme taahhütleri incelenmelidir. Bu süreç NIS2 tedarik zinciri güvenliği ile birlikte yürütülür.
Secure SDLC NIS2 bakımından neden önemlidir?
Kuruluş kendi yazılımını geliştiriyorsa güvenlik, geliştirme yaşam döngüsüne entegre edilmelidir. Tasarım aşamasında tehdit modelleme, güvenlik gereksinimleri, güvenli kodlama standartları, kod incelemesi, otomatik analiz, sır/credential taraması, bağımlılık yönetimi, test ve üretim öncesi güvenlik kabul kriterleri Secure SDLC’nin parçalarıdır.
Geliştiricinin güvenlik sorumluluğu “yayından sonra güvenlik ekibi test eder” yaklaşımına bırakılamaz. Erken aşamada bulunan hata daha düşük maliyetle giderilir ve kritik zafiyetin üretime taşınma ihtimali azalır.
CI/CD sürecinde güvenlik kontrolleri otomatik hale getirilebilir; ancak otomasyonun yanlış güven duygusu yaratmaması gerekir. Kritik bulgunun istisna edilmesi halinde kim onaylıyor, istisna ne kadar süre geçerli, hangi telafi kontrolü uygulanıyor ve ne zaman kapatılacak soruları cevaplanmalıdır.
Açık kaynak ve üçüncü taraf yazılım bağımlılıkları nasıl yönetilir?
Modern uygulamalar çok sayıda üçüncü taraf ve açık kaynak bileşen kullanır. Kuruluş yalnız kendi yazdığı kodu tararsa yazılım tedarik zinciri riskini kaçırabilir. Kullanılan paketler, sürümler ve doğrudan/dolaylı bağımlılıklar mümkün olduğunca envanterlenmelidir.
Dependency scanning araçları bilinen CVE’leri tespit etmeye yardımcı olur; fakat her CVE aynı iş etkisine sahip değildir. Bileşenin gerçekten kullanılabilir fonksiyonu, internete açıklığı, exploit bulunması ve kritik hizmet bağlantısı değerlendirilmelidir.
SBOM (software bill of materials) birçok organizasyonda bağımlılık görünürlüğünü artıran bir araçtır. NIS2 Article 21 tek başına her kuruluş için belirli formatta SBOM zorunluluğu yazmaz; ancak bileşen görünürlüğü zafiyet yönetimi ve tedarik zinciri güvenliğini somut olarak destekleyebilir.
Zafiyet taraması ve penetrasyon testi nasıl planlanmalı?
Zafiyet taraması; internet yüzeyi, sunucu, uç nokta, ağ cihazı, konteyner, bulut yapılandırması veya uygulama gibi farklı katmanlarda yürütülebilir. Test sıklığı risk, değişiklik hızı ve varlık kritikliğine göre belirlenmelidir. Kritik internet varlıklarında daha sık tarama gerekirken düşük riskli sistemlerde farklı periyot uygulanabilir.
Penetrasyon testi taramadan farklıdır; gerçek saldırı teknikleriyle kontrol etkinliğini değerlendirir. Test kapsamı, yetki, zaman, yasak faaliyetler, veri işleme ve acil durdurma kuralları yazılı olmalıdır. Yetkisiz güvenlik testi hukuki risk doğurabilir.
Türkiye’de bug bounty veya penetrasyon testi organize edilirken TCK 243–244 ve bug bounty yetki sınırları ayrıca dikkate alınmalıdır. Testçinin hangi sistem üzerinde hangi işlemi yapabileceği sözleşmede açık olmalıdır.
NIS2’de yama süresi kaç gündür?
NIS2 Article 21 tüm zafiyetler için tek bir “X gün” yama süresi belirlemez. Kuruluş risk bazlı hedef süreler koymalıdır. Kritik, aktif sömürülen ve internetten erişilebilir açıklar en yüksek önceliğe alınabilir; düşük etkili iç sistem açığı için farklı süre uygulanabilir.
Yama hedefi belirlenirken CVSS puanı yanında exploit durumu, erişilebilirlik, ayrıcalık gereksinimi, veri etkisi, işlevin kritikliği ve telafi kontrolleri değerlendirilmelidir. Yama teknik olarak uygulanamıyorsa ağ segmentasyonu, özelliğin kapatılması, WAF kuralı, erişim kısıtlaması veya ek izleme gibi geçici kontroller kullanılabilir.
İstisna süreci süreli olmalıdır. “İş birimi kabul etti” denilip açık süresiz bırakılmamalı; risk sahibi, gerekçe, telafi kontrolü, yeniden değerlendirme tarihi ve nihai çözüm planı kaydedilmelidir.
Vulnerability disclosure süreci nasıl kurulmalı?
Article 21(2)(e) zafiyetlerin yalnız teknik olarak giderilmesini değil, açıklanması/disclosure sürecini de kapsar. Dış araştırmacı, müşteri veya tedarikçi bir güvenlik açığı bulduğunda nereye bildirecek? Hangi bilgileri verecek? Şirket ne kadar sürede alındı teyidi yapacak? Teknik triage kimin görevi? Bu sorular prosedürde olmalıdır.
Kuruluş security.txt, güvenlik e-posta adresi veya portal kullanabilir. İletişim kanalının düzenli izlenmesi ve spam arasında kaybolmaması gerekir. Bildirimin kişisel veri, ticari sır veya aktif saldırı içerdiği durumlarda hukuk ve olay müdahale ekibi devreye alınmalıdır.
Koordineli açıklama yaklaşımı, araştırmacıya güvenli bildirim imkânı verirken kullanıcılara zarar verecek erken ifşayı da yönetir. Ancak araştırmacının yetkisiz erişim yapması ayrı hukuki konudur; bir VDP’nin kapsamı ve izin verilen testler açık yazılmalıdır.
Destek süresi biten sistemler NIS2 riski midir?
Evet. Üreticinin güvenlik güncellemesi vermediği işletim sistemi, ağ cihazı, kütüphane veya endüstriyel kontrol bileşeni bilinen açıkların kalıcı hale gelmesine yol açabilir. Bu nedenle varlık envanterinde EOL/EOS tarihi tutulmalıdır.
Destek dışı kritik sistem hemen değiştirilemiyorsa risk resmi olarak kaydedilmeli, segmentasyon, erişim kısıtı, uygulama beyaz listeleme, sanal yama ve yoğun izleme gibi telafi kontrolleri uygulanmalıdır. Aynı zamanda bütçeli bir migrasyon planı ve son tarih belirlenmelidir.
Yönetim organı Article 20 kapsamında yüksek riskli EOL durumlarından haberdar olmalıdır. Kritik ve uzun süre açık kalan teknoloji borcu, kurul seviyesinde risk kabulü gerektirebilir.
Değişiklik yönetimi Article 21(2)(e) ile nasıl bağlantılıdır?
Yama ve güvenlik güncellemesi kontrolsüz uygulanırsa hizmet kesintisi yaratabilir. Bu nedenle değişiklik yönetimi; test, onay, geri dönüş planı, zaman penceresi ve sorumluyu belirler. Acil güvenlik yaması için normal süreci hızlandıran fakat iz bırakmayı sürdüren “emergency change” modeli kurulabilir.
Önemli yapılandırma değişiklikleri güvenlik değerlendirmesi tetiklemelidir. Yeni internet portu açılması, kimlik doğrulama yönteminin değişmesi, veri tabanının dışa açılması veya bulut servisinin herkese açık hale getirilmesi gibi değişiklikler yanlış yapılandırma riski taşır.
Değişiklik sonrası doğrulama yapılmalı; güvenlik kontrolünün gerçekten çalıştığı ve beklenmeyen yan etki oluşmadığı teyit edilmelidir.
Article 21(2)(e) uyumu hangi belgelerle kanıtlanır?
- Secure SDLC politikası ve güvenli kodlama standardı,
- ürün/yazılım güvenlik satın alma kriterleri,
- varlık ve yazılım bağımlılık envanteri,
- zafiyet kayıt sistemi ve risk sınıflandırması,
- yama SLA’ları ve istisna kayıtları,
- penetrasyon testi ve tarama raporları,
- vulnerability disclosure prosedürü,
- EOL/EOS takip ve migrasyon planı,
- change management kayıtları,
- düzeltici faaliyet kapanış kanıtları.
Bu belgeler Article 21 genel kontrol matrisi ve Article 20 kurul gözetimiyle ilişkilendirilmelidir. Denetimde aynı zafiyetin farklı sistemlerde tekrarlanması, yalnız bireysel yamaya değil kök süreç eksikliğine işaret eder.
Sık sorulan sorular
NIS2 güvenli yazılım geliştirmeyi açıkça düzenliyor mu?
Evet. Article 21(2)(e), ağ ve bilgi sistemlerinin edinim, geliştirme ve bakımında güvenliği açıkça sayar.
Zafiyet disclosure NIS2’de var mı?
Evet. Aynı hüküm vulnerability handling and disclosure süreçlerini kapsar.
NIS2 kritik yama için 24 saat zorunluluğu getiriyor mu?
Hayır. Article 21 tüm yamalar için tek süre belirlemez. 24 saat Article 23’teki önemli olay erken uyarı takvimiyle ilgilidir.
CVSS puanı tek başına yama önceliği için yeterli mi?
Hayır. Aktif sömürü, internete açıklık, varlık kritiği, veri etkisi ve telafi kontrolleri de değerlendirilmelidir.
SBOM NIS2’de her şirket için açık zorunluluk mu?
NIS2 Article 21 belirli bir SBOM formatını her kuruluş için doğrudan emretmez. SBOM, bağımlılık ve zafiyet görünürlüğünü destekleyen güçlü bir uygulamadır.
Destek süresi bitmiş sistem kullanılabilir mi?
Risk otomatik olarak yasak anlamına gelmez; ancak güvenlik güncellemesi alamayan kritik sistem yüksek risk yaratır ve telafi kontrolü ile migrasyon planı gerekir.
Penetrasyon testi Article 21 uyumuna yardımcı olur mu?
Evet. Güvenli geliştirme ve kontrol etkinliğini ölçmeye yardımcı olur; kapsam ve hukuki yetki yazılı olmalıdır.
Üçüncü taraf yazılım açığı da şirketin NIS2 riskine girer mi?
Evet. Sistem bağımlılıkları ve tedarikçi bileşenleri kuruluşun hizmetini etkiliyorsa zafiyet yönetimine dahil edilmelidir.
Yönetim kurulu zafiyet raporlarını görmeli mi?
Her teknik bulguyu değil; kritik, gecikmiş ve hizmeti etkileyen yüksek riskleri Article 20 gözetimi kapsamında görmesi gerekir.
Bakırcı & Keskin Hukuk Bürosu
Bu yazı genel hukuki bilgilendirme amacı taşır; güvenlik testleri ve zafiyet açıklama programları sistem yetkisi, veri işleme ve uygulanabilir hukuk dikkate alınarak kurulmalıdır.
Hukuki konu hakkında iletişim
İlk iletişimde konuyu, bulunduğunuz ülke veya ili ve varsa tebliğ ya da son işlem tarihini kısaca belirtebilirsiniz. T.C. kimlik numarası, sağlık verisi veya kişisel belge göndermeyiniz. Mesajlaşma tek başına hukuki görüş veya avukatlık ilişkisi oluşturmaz.
