AB Siber Dayanıklılık Yasası'nın bildirim kuralları 11 Eylül'de yürürlüğe giriyor

Bildirim saati 11 Eylül'de başlıyor

AB'nin Siber Dayanıklılık Yasası (CRA) kapsamındaki bildirim yükümlülükleri 11 Eylül 2026'da uygulanabilir hale geliyor ve yazılım ekiplerinin bu saatin kendilerine uygulanıp uygulanmadığını önceden bilmesi gerekiyor. Bu, Faultline Security adlı firmanın —SaaS şirketleri için sızma testi ve AI red teaming çalışmaları yürüten bir firma— bir uygulayıcısının dev.to'daki yazısının ana mesajı.

Yazıya göre o tarihten itibaren "dijital unsurlu ürünlerin" üreticileri, aktif olarak istismar edilen zafiyetleri ve ciddi güvenlik olaylarını tek bir platform üzerinden sabit bir takvimle bildirmek zorunda: 24 saat içinde erken uyarı, 72 saat içinde daha kapsamlı bir bildirim ve zafiyetler için 14 gün içinde, ciddi olaylar içinse bir ay içinde nihai rapor. Bildirim yükümlülüğünün yanlış yönetilmesi halinde cezalar 15 milyon euroya veya küresel cironun %2,5'ine kadar çıkabiliyor.

Yazı, bunu CRA'nın tam son teslim tarihinden dikkatlice ayırıyor. CE işareti ve geri kalan temel gereklilikler 11 Aralık 2027'de geliyor. 11 Eylül ise dar bir dilimi kapsıyor: kimin neyi ve ne kadar hızlı bildirmek zorunda olduğu.

Kapsam sorusu

Yazara göre ekiplerin takıldığı yer, yasanın kendilerini kapsayıp kapsamadığına karar vermektir. SaaS için ayrım oldukça net. Müşterinin makinesine veya altyapısına hiçbir şey kurulmayan, tamamen tarayıcı üzerinden sunulan yazılımlar genellikle CRA değil, AB'nin NIS2 direktifi kapsamına giriyor.

Kurulabilir herhangi bir şey göndermek tabloyu değiştiriyor. Yazıya göre masaüstü uygulamaları, mobil uygulamalar, tarayıcı eklentileri, müşterilerin koduna gömülü SDK'lar, CLI araçları ve on-premises agent veya connector'ların tümü dijital unsurlu ürün sayılıyor. Ve bulut arka ucu, kurulu bileşenin çalışma biçimi için kritik olduğunda, uzaktan işleme de kapsama dahil ediliyor.

Bu da birçok B2B satıcısının farkında olmadan bulunduğu bir gri alan bırakıyor: amiral gemisi ürün olarak bir web uygulaması, yanında hafif bir masaüstü istemcisi, müşterilerin kurduğu bir izleme agent'ı veya entegrasyonlar için bir SDK. Bu ek bileşenlerden herhangi biri, çekirdek ürün saf SaaS olsa bile şirketi CRA bölgesine çekebiliyor.

Yazar, tek bir ay içinde dört kurucuyla "bu bize uyguluyor mu" görüşmesi yaptığını bildiriyor. Dördü de cevabın evet olduğunu sanıyordu; ikisi yanılıyordu. Hata iki yönlü işliyor. Kapsamı olduğundan büyük varsaymak uyum çabasını boşa harcatırken, küçük varsaymak hukuken bağlayıcı bir bildirim son teslim tarihini kaçırmak anlamına geliyor.

Zor olan kısım tespit

Yazıya göre kuralların prosedürel tarafı kolay yarı. Her ekip 24 saat, 72 saat ve nihai rapor aralıklarını esas alan bir kontrol listesi oluşturabilir. Gerçekten zor olan sorun, bildirilmesi gereken şeyi fark etmektir. Çoğu ekip zafiyetleri kendi izleme sistemleri aracılığıyla öğrenmiyor; bunları bir müşteriden, dışarıdan bir araştırmacıdan ya da çoktan içeride olan bir saldırgandan duyuyor.

Yeni rejim altında o keşif anı, ekip aynı anda kendi kod tabanının tanıdık olmayan bir köşesini triage ederken ve ilk kez önemli sonuçlar doğuracak bir rapor tasarlarken yasal bir geri sayım başlatıyor. Test hizmetleri satan ve bu teşviki açıkça kabul eden yazarın savı şu: Zayıf noktalarınızı kendi takviminizde keşfetmek, bir olayın ortasında, canlı olarak, bir düzenleyicinin saati izlerken keşfetmekten temelden farklı bir deneyimdir.

Neden önemli

11 Eylül uzak bir uyum ufuku değil, somut ve uygulanabilir bir tarih ve CRA'nın 2027'deki daha geniş gerekliliklerinden yıllar önce geliyor. 24 saatlik erken uyarı yükümlülüğü ancak bir ekip kendi sistemlerinde aktif istismarı gerçekten tespit edebiliyorsa işe yarar; bu da düzenleyici bir yükümlülüğün bir kısmını salt hukuki değil, mühendislik ve gözlemlenebilirlik sorununa dönüştürüyor. dev.to yazısı ayrıca kapsam yanlış değerlendirmesinin küçük şirketler arasında yaygın olduğunu, kurucuların her iki yönde de yanlış tahmin ettiğini öne sürüyor. Bir web ürününün yanında SDK, agent, eklenti veya masaüstü istemcisi gönderen her ekip için ilk pratik adım, son teslim tarihinden önce —bir olay soruyu dayatmadan önce— hangi bileşenlerin kapsandığını ve bildirim iş akışından kimin sorumlu olduğunu haritalamaktır.