AB Siber Dayanıklılık Yasası'nın ilk yükümlülükleri 11 Eylül'de yazılım üreticilerini etkileyecek

11 Eylül'de ne olacak

AB'nin Siber Dayanıklılık Yasası'nın (CRA) ilk yükümlülükleri 11 Eylül 2026'da yürürlüğe giriyor ve yaygın olarak paylaşılan bir dev.to incelemesine göre o gün iki zorunlu bildirim yükümlülüğü devreye giriyor: geliştiriciler ürünlerinde aktif olarak istismar edilen açıkları bildirmek ve kullanıcılarını etkileyen ciddi güvenlik olaylarını raporlamak zorunda.

Süreler oldukça kısa. dev.to gönderisine göre, erken uyarı AB'nin siber güvenlik ajansı ENISA'ya 24 saat içinde, tam olay bildirimi 72 saat içinde, açıklar için nihai rapor bir düzeltme mevcut olduğunda 14 gün içinde, ciddi olaylar için ise bir ay içinde ulaştırılmalı. Bu pencerelerin kaçırılması şirketi AB hukuku ihlali durumuna sokuyor.

Kapsam göründüğünden daha geniş

CRA, dijital ürünler için AB'nin ilk yatay siber güvenlik yasası olarak tanımlanıyor: sektöre özgü değil ve isteğe bağlı değil. AB'de satılıyorsa uygulamalar, kütüphaneler, firmware, IoT cihazları, SaaS, masaüstü yazılımları ve framework'lerin tümü kapsam dahilinde. Tek istisnalar, diğer AB kurallarıyla halihazırda kapsanan ürünler — tıbbi cihazlar, araçlar, havacılık ve deniz ekipmanları.

Kritik nokta şu: Bildirim yükümlülükleri, sadece tarihten sonra sevkedilen yazılımlara değil, piyasadaki mevcut ürtlere de uygulanıyor. Yazar, bunun çoğu hukuk ekibinin gözden kaçırdığı ince ayrıntı olduğunu savunuyor: CRA'nın tam gereksinimleri Aralık 2027'ye kadar yürürlüğe girmediği için birçok kişi bol zaman olduğu varsaydı. Yazılım bugün AB'de konuşlandırılmışsa ve gelecek ay istismar edilen bir açık ortaya çıkarsa, 24 saatlik sayaç yine de işlemeye başlıyor.

Bu da şu an itibarıyla şunların hazır olması anlamına geliyor: aktif olarak istismar edilen açıkları tespit etme süreci, bir şeyin bildirim eşiğini karşılayıp karşılamadığını belirleyen bir triage iş akışı, ENISA'nın Tek Bildirim Platformu'na başvuru yapabilecek yetkili bir kişi, güvenlik, hukuk ve ürün ekipleri arasındaki koordinasyon ve düzenleyicilerin talep edebileceği her kararın belgelenmesi.

Açık kaynak sorusu

dev.to yazısı, pek çok kişinin sandığından daha dar bir muafiyete dikkat çekiyor. Ticari amaç olmadan geliştirilen ve dağıtılan açık kaynak — hobi projeleri, kimsenin para kazanmadığı topluluk tarafından desteklenen kütüphaneler — muaf. Ticari bağlantısı olan açık kaynak ise değil: bir şirket bir kütüphaneyi sürdürüyorsa ve ücretli destek, danışmanlık veya ticari bir sürüm sunuyorsa, CRA bu şirketi üretici olarak görüyor ve aynı bildirim ve uygunluk yükümlülüklerini uyguluyor. Yazı, Elastic, MongoDB ve HashiCorp gibi açık çekirdekli (open-core) şirketleri, açık kaynak bağımlılıkları paketleyen ticari yazılım sevkiyatı yapan tüm şirketlerle birlikte tamamen kapsam dahilinde sayıyor.

Aralık 2027 ne getiriyor

Tam gereksinimler Aralık 2027'de geliyor. Kaynağa göre, Ek I Kısım I ürün gereksinimlerini belirliyor: varsayılan olarak güvenli (secure-by-default) tasarım, yayında bilinen istismar edilebilir açığın olmaması, kutudan çıkan güvenli yapılandırma, yetkisiz erişime karşı koruma, veri gizliliği ve bütünlüğü, minimal saldırı yüzeyi, olay kaydı ve izleme, ve tüm destek süresi boyunca güvenlik güncellemeleri. Ek I Kısım II ise süreç gereksinimleri ekliyor: kabul, triage, düzeltme ve ifşayı kapsayan bir açık açıklarını yönetim süreci, her ürün için bir yazılım malzeme listesi (SBOM), on yıl boyunca teknik dokümantasyon saklanması ve CE işareti.

Uygunluk değerlendirmesi ürün sınıfına göre ölçekleniyor: çoğu ürün için kendi kendine değerlendirme, düzenlemenin önemli olarak nitelendirdiği kategoriler — parola yöneticileri, VPN'ler ve kimlik sistemleri gibi — için üçüncü taraf denetim, ve endüstriyel denetleyiciler ile belirli altyapılar gibi kritik ürünler için zorunlu AB sertifikası.

Pratik adımlar

Gönderi, 11 Eylül'den önce AB müşterilerine satıp satmadığınızı teyit etmenizi — CRA, şirketin nerede bulunduğuna bakılmaksızın uygulanıyor — açık kabul ve triage süreci kurmanızı, ENISA'nın bildirim platformuna kaydolmanızı ve bir olay müdahale sürecini belgelemenizi öneriyor.

Aralık 2027'den önce ise Syft, CycloneDX veya SPDX gibi araçlarla SBOM üretmeyi, varsayılan parolalar ve gereksiz açık portlar gibi güvenlik varsayılanlarını denetlemeyi, güncelleme mekanizmalarını gözden geçirmeyi ve geçerli uygunluk rotasını belirlemeyi tavsiye ediyor. Açık kaynak bakımcıları, sponsorlukların, ücretli desteğin, danışmanlığın veya çift lisanslamanın onları kapsam içine sokup sokmadığını kontrol etmeli, SECURITY.md gibi bir güvenlik politikası yayınlamalı ve aşağı yönlü ticari ürünlerin uyum için kendi açık yönetimlerine bağlı olabileceğini bilmeliler.

Neden önemli

dev.to yazarı, CRA'yı AB'nin ürün güvenliği için GDPR'in gizlilik için yaptığını yapması olarak çerçeveliyor; 24 saatlik bildirim penceresi, GDPR'in 72 saatlik ihlal bildiriminden daha sıkı. Geliştiriciler için güvenlik, en iyi uygulamadan somut çıktıları olan bir yasal gereksinime dönüşüyor: SBOM'lar zorunlu hale geliyor, açık yönetimi "boş zamanımız olduğunda düzeltiriz" yaklaşımı yerine belgelenmiş bir süreç gerektiriyor, ve tehdit modelleri ile güvenlik kararları yazılı olarak kaydedilip on yıl saklanmalı. 2025'te hazırlanmaya başlayan şirketlerin durumu fena sayılmazken, şimdi başlayanların bir bildirim hattı kurmak için yaklaşık bir haftası, geliştirme pratiklerini elden geçirmek için yaklaşık 15 ayı var. Bir uyarı: Yukarıdaki ayrıntılar tek bir topluluk gönderisinden geliyor, bu yüzden ekipler harekete geçmeden önce ayrıntıları mevzuat metni (2024/2847) ve Avrupa Komisyonu'nun uygulama rehberiyle doğrulamalı.