Cyber Resilience Act'in (CRA) ürün ekiplerini ilgilendiren ilk tarihi, raporlama yükümlülüklerinin başladığı 11 Eylül 2026'dır. Ana yükümlülükler 11 Aralık 2027'de devreye girer. Raporlama süreçlere ve insanlara bağlıdır, bunları kurmak da zaman alır. Bu nedenle her şeyden önce raporlamayı ele almak gerekir.
Hangi yükümlülük ne zaman geçerli
CRA, (AB) 2024/2847 sayılı Tüzüktür. Avrupa Komisyonu'nun CRA sayfasına göre CRA, dijital unsurlar içeren ürünlerin planlanması, tasarımı, geliştirilmesi ve bakımı boyunca üreticiler için zorunlu siber güvenlik gereklilikleri getirir. Ayrıca üreticilerin, ürün yaşam döngüsü boyunca güvenlik açıklarını yönetmesini şart koşar.
| Tarih | Ne olur |
|---|---|
| 10 Aralık 2024 | CRA yürürlüğe girdi |
| 11 Eylül 2026 | Raporlama yükümlülükleri uygulanmaya başlar |
| 11 Aralık 2027 | Ana yükümlülükler uygulanmaya başlar |
Uyumlu ürünler CE işareti taşıyacak, kuralların uygulanmasını ise ulusal piyasa gözetimi otoriteleri denetleyecektir. Siber güvenlik açısından özel önem taşıyan bazı ürünlerin, AB pazarında satılmadan önce onaylanmış bir kuruluş (notified body) tarafından üçüncü taraf değerlendirmesinden geçmesi gerekebilir. Ürününüzün bu ayrımın hangi tarafında kaldığını erken belirleyin, çünkü zaman planınızı değiştirir.
Komisyon, üreticilere yönelik pratik bir rehberi de 27 Temmuz 2026'da yayımladı. Aşağıdaki süreçlerden herhangi biri için tasarım kararı vermeden önce bu rehberi okuyun.
Güvenli geliştirme kanıtları
Düzenleyiciler ve müşteriler ne yaptığınızı soracak. Bu yüzden kayıtları sonradan yeniden oluşturmak yerine, olağan işin yan ürünü olarak üretin. Bilinen bir yapı kullanmak işi kolaylaştırır.
NIST Secure Software Development Framework, SP 800-218, halihazırda uyguladığınız SDLC'ye ekleyebileceğiniz, üst düzey temel pratiklerden oluşan bir kümedir. Belirtilen amaçları şunlardır: yayımlanan yazılımdaki açıkları azaltmak, geriye kalanların etkisini düşürmek ve kök nedenleri gidererek tekrarlarını önlemek. Ayrıca alıcılar ve tedarikçilerle kullanabileceğiniz ortak bir sözlük sunar. Bu bir ABD belgesidir ve CRA kontrol listesi değildir; bu yüzden onu bir iskelet olarak ele alın.
Her sürüm için saklamaya değer kanıtlar:
- değişikliği kapsayan tehdit modeli veya tasarım incelemesi
- kod incelemesi ve güvenlik testleri dahil test sonuçları
- sürümleriyle birlikte bağımlılık listeleri ve bunlardaki bilinen sorunlarla ilgili aldığınız kararlar
- isim ve tarih içeren sürüm onayı
CISA'nın Secure by Design materyali iki pratik noktayı daha ekler. Sorumluluk üst yönetim düzeyinde olmalıdır ve varsayılanlar önemlidir: MFA, loglama ve SSO ek ücret ödenmeden, kutudan çıktığı gibi kullanılabilir olmalıdır. Ürününüz bunları ücretli eklenti olarak satıyorsa, bunun sorgulanmasını bekleyin. CISA ayrıca memory safe yol haritalarına dair rehberlik yayımlar; kodunuz C veya C++ ise okumaya değer.
Güvenlik açığı yönetimi ve raporlama
11 Eylül 2026'dan itibaren üreticiler, aktif olarak istismar edilen güvenlik açıklarını ve Komisyon'un raporlama sayfasında sıralanan diğer kalemleri bildirmek zorundadır. Kesin kapsam ve kullanılacak kanal için o sayfayı kontrol edin. Bu yazı dahil, hiçbir özete güvenmeyin.
Nihai ayrıntılar ne olursa olsun, kurum içinde ihtiyacınız olanlar:
- Tek bir bildirim noktası. Ürün sitesinde ve dokümantasyonda yer alan, izlenen bir güvenlik iletişim adresi; sorumlusu ve vekili belli olmalı.
- Bir triyaj rutini. Bir bildirimin geçerli olup olmadığına, istismar edilip edilmediğine ve hangi ürün ve sürümleri etkilediğine belirli bir süre içinde biri karar vermeli. Tutarlı bir önem derecesi puanı bunu hızlandırır; ekipte puanlar üzerinde uzlaşmak için CVSS hesaplayıcımız işinize yarar.
- Bir raporlama karar yolu. İstismar edilen bir güvenlik açığının rapor gerektirdiğine kimin karar verdiğini ve raporu kimin ilettiğini yazılı hale getirin. Bunu kurgusal bir senaryoyla bir kez prova edin; gerçekte mesai dışında yaşanacaksa provayı da mesai dışında yapın.
- Her kararın kaydı. Kapsam dışı olduğuna karar verdiğiniz bildirimler ve gerekçeleri de dahil.
Ürününüzün içinde ne olduğunu bilmiyorsanız raporlama işlemez. Gönderilen her sürüm için güncel bir bileşen envanteri tutun, çünkü yeni bir güvenlik açığına maruziyeti hafızadan değerlendiremezsiniz.
Güncelleme süreçleri
Komisyon, zamanında güvenlik güncellemesi yapılmamasını CRA'nın ele aldığı sorunlardan biri olarak belirtir. Ürünler, kullanıcıları koruyacak şekilde tasarlanmalı, güncellenmeli ve bakımı yapılmalıdır. Pratikte bu, güncelleme yolunuzu özelliklerinizi test ettiğiniz ciddiyetle test etmeniz anlamına gelir.
Her ürün hattında şunları kontrol edin:
- Bir güvenlik düzeltmesini özellik sürümünden ayrı olarak yayımlayabiliyorsunuz.
- Müşteriler bir güncellemenin var olduğunu öğrenebiliyor ve kurulum için destek çağrısı gerekmiyor.
- Eski sürümlerin, müşterilerin satın almadan önce görebileceği, açıkça belirtilmiş bir destek bitiş tarihi var.
- Donanımda, bir yıl boyunca çevrimdışı kalmış bir cihazı güncellemeyi ve yarıda başarısız olan bir cihazı kurtarmayı test ettiniz.
Yaygın eksiklik teknoloji değil, sahipliktir. Pek çok ekip bir yamayı bir günde üretebilir, sonra yayımlama yetkisinin kimde olduğunu bulmak için üç hafta harcar.
Teknik dokümantasyon
Kullandığım kaynaklar teknik dosyanın zorunlu içeriğini listelemiyor; bu içeriği yasa metninden ve Komisyon'un rehberinden almalısınız. Pratik nokta şudur: dokümantasyon, yukarıdaki kanıtlardan sürekli olarak derlenmeli, son tarihten önceki son çeyrekte yazılmamalıdır.
Her ürün için, bir sahibi olan bir dokümantasyon klasörü ya da repository bölümü oluşturun. İçine tasarımı ve risk değerlendirmesini, bileşen envanterini, test sonuçlarını, güvenlik açığı yönetimi prosedürünü ve güncelleme politikasını koyun. Ürünle birlikte sürümleyin. Bir denetçi ya da otorite dosya istediğinde, onu sıfırdan hazırlatmak yerine dışa aktarabilmek istersiniz.
Komisyon'un CRA'nın tamamladığını belirttiği NIS2 Directive kapsamına da giriyorsanız, iki ayrı set tutmak yerine aynı olay ve güvenlik açığı prosedürlerini yeniden kullanın.
Nereden başlamalı
- Komisyon'un 27 Temmuz 2026 tarihli rehberini ve raporlama sayfasını okuyun; hangi ürünlerinizin kapsamda olduğunu ve herhangi birinin onaylanmış kuruluş gerektirip gerektirmediğini yazın.
- Güvenlik açığı bildirimi ve istismar edilen güvenlik açıklarının raporlanması için bir sorumlu belirleyin, bir güvenlik iletişim adresi yayımlayın ve bu çeyrekte bir prova yapın.
- Desteklenen her sürüm için bir bileşen envanteri üretin ve bunu build sürecinizin parçası haline getirin.
- Mevcut SDLC'nizi SSDF pratikleriyle eşleştirin, eksikleri kaydedin ve her sürüm için inceleme, test ve onay kayıtlarını saklamaya başlayın.
- Güncelleme yolunuzu uçtan uca test edin ve her ürün için destek bitiş tarihlerini yayımlayın.
- Ürün bazında dokümantasyon klasörünü oluşturun ve elinizde zaten olanlarla doldurun. Eksikler konusunda dışarıdan bir bakış isterseniz, danışmanlık hizmetimiz ve güvenli yazılım geliştirme hizmetimiz tam olarak bu konuları kapsar.
