CRA uyum yazılımı nasıl seçilir?

01Kısa cevap

• CRA bir yazılım satın almayı şart koşmaz. Şart koştuğu şey çıktılardır: SBOM, zafiyet yönetimi, teknik dosya, Madde 14 bildirimleri ve destek süresi boyunca güvenlik güncellemeleri.
• Gömülü üründe ilk ölçüt, yazılımın sizin firmware imajınızdan bileşen çıkarabilmesi ve bulamadığını açıkça söylemesidir.
• Zafiyet tespitinde tek kaynak yetmez. Madde 14'ü tetikleyen şey aktif istismar kanıtıdır, olasılık puanı değil.
• Bulgu listesi tek başına iş görmez. Her bulgu için verdiğiniz kararın VEX olarak, teknik dosyanın da sürümüyle birlikte saklanabilmesi gerekir.
• Hiçbir yazılım CRA uyumunu tek başına sağlamaz; uygunluk ürün için değerlendirilir.

02Önce neye ihtiyacınız olduğunu yazın

Yazılım seçimine ürünlerinizin CRA'dan doğan işlerini listeleyerek başlayın. Ürünü AB pazarına arz eden üreticinin temel işleri şunlardır:

• Zafiyet yönetimi (Ek I Bölüm II): bileşenleri belirlemek, en azından üst düzey bağımlılıkları kapsayan bir SBOM hazırlamak, açıkları gecikmeden gidermek ve güvenlik güncellemeleri dağıtmak.
• Teknik dosya (Ek VII): risk değerlendirmesi, Ek I gereksinimlerinin nasıl karşılandığı, SBOM ve test kanıtları. Teknik dosya ve AB uygunluk beyanı, ürün piyasaya arz edildikten sonra en az 10 yıl ya da destek süresi boyunca, hangisi daha uzunsa, saklanır (Madde 13(13)).
• Bildirim (Madde 14): aktif istismar edilen açıkları ve ciddi olayları ENISA'nın Tek Raporlama Platformu (SRP) üzerinden 24 saat, 72 saat ve nihai rapor sürelerinde bildirmek. Bu yükümlülük 11 Eylül 2026'dan beri geçerli.
• Destek süresi (Madde 13(8)): ürünün beklenen kullanım süresini yansıtan destek süresi boyunca açıkları izlemek ve gidermek.

Bu listeden hangisini kendi ekibinizle, hangisini bir yazılımla, hangisini dışarıdan destekle yapacağınızı ayırın. Ürün sınıfınızı bilmiyorsanız önce CRA sınıf testini yapın; sınıf, uygunluk değerlendirme yolunu ve dışarıdan ne kadar destek gerekeceğini belirler.

03Sekiz seçim ölçütü

1. Firmware'den SBOM

Gömülü üründe sorun çoğu zaman SBOM'un hiç olmaması değil, eksik olmasıdır. Statik bağlanmış kütüphaneler, RTOS ve çip üreticisinin SDK'sı, tedarikçiden ikili olarak gelen bileşenler derleme sisteminin ürettiği listede görünmeyebilir. Ayrıntılar SBOM rehberinde.

• Yazılım sizin imaj biçimlerinizi (ham ikili, dosya sistemi, Intel HEX, ELF) açabiliyor mu?
• Bulamadığı ya da sürümünü kesinleştiremediği bileşenleri açıkça belirtiyor mu?
• Derleme sisteminizin ürettiği SBOM'u içe alıp imajla karşılaştırabiliyor mu?
• Sonucu CycloneDX ve SPDX olarak dışa aktarabiliyor mu?

2. Zafiyet kaynakları

Tek bir veritabanına bağlı eşleştirme açık kaçırır. NVD her kayda ürün tanımlayıcısı (CPE) eklemez; gömülü kütüphanelerin ve çip SDK'larının açıkları çoğu zaman önce kendi projelerinin ya da üreticinin bülteninde yayımlanır.

• Hangi kaynaklar kullanılıyor: NVD, OSV, CVE Program kayıtları, üretici bültenleri?
• Her bulgu kaynağına bağlanıyor mu?
• Kaynaklar ne sıklıkla güncelleniyor; bir kaynak güncellenemezse yazılım bunu size söylüyor mu?

3. Aktif istismar kanıtı

Madde 14'ün 24 saatlik süresini başlatan şey, bir açığın aktif olarak istismar edildiğinin farkına varmaktır. Bu yüzden yazılım istismar kanıtını (CISA KEV kataloğu, ENISA'nın EUVD'sindeki istismar edilen açıklar listesi) olasılık puanlarından ayırmalıdır. FIRST EPSS bir açığın istismar edilme olasılığını tahmin eder; önceliklendirmede işe yarar ama istismar kanıtı değildir.

• İstismar kanıtı olan bulgular ayrıca işaretleniyor mu?
• Madde 14 adayı olan bir bulguda karar kimde kalıyor?

4. VEX ve analist kararları

Gömülü bir imajda çıkan açıkların bir kısmı üründe derlenmeyen ya da çalışmayan kodla ilgilidir. Bunu ayırt etmek bir analist kararıdır ve gerekçesiyle kaydedilmelidir. VEX (Vulnerability Exploitability eXchange), bir açığın ürünü etkileyip etkilemediğini makinece okunur biçimde bildirir.

• Her bulgu için karar ve gerekçe kaydediliyor mu; kimin ne zaman karar verdiği görünüyor mu?
• CSAF VEX ya da OpenVEX belgesi üretiliyor mu; belge resmî şemaya göre doğrulanıyor mu?
• Yeni bir firmware sürümünde önceki kararlar doğru taşınıyor mu?

5. Teknik dosya

Teknik dosya, piyasa gözetim otoritesinin isteyebileceği belgedir. Yazılımın ürettiği şey bir rapor değil, Ek VII'nin yapısına uyan ve ürün sürümüne bağlı bir dosya olmalıdır.

• Ek I'in her gereksinimi için durum, karar ve kanıt kaydediliyor mu?
• Teknik dosya ve AB uygunluk beyanı taslağı üretiliyor mu?
• Dosya o günkü haliyle dondurulabiliyor mu (imza, zaman damgası); yıllar sonra açılabilecek biçimlerde (PDF, JSON) dışa alınabiliyor mu?

6. Madde 14 bildirimi

Bildirimler ENISA'nın Tek Raporlama Platformu (SRP) üzerinden yapılır. Platformun ilk sürümünde API yoktur; bildirimler web arayüzünden girilir (SRP rehberi). Bu yüzden bir yazılım bildirimi sizin yerinize gönderemez; süreleri izleyebilir ve formu hazırlayabilir.

• 24 saat, 72 saat ve nihai rapor süreleri farkına varma anından itibaren izleniyor mu?
• Form alanları SRP'deki sırayla hazırlanıyor mu; koordinatör CSIRT seçimi için Madde 14(7)'ye göre yardım var mı?
• Gönderilen bildirimin bir kopyası tarihiyle saklanıyor mu?

7. Barındırma ve veri

CRA, verilerin AB'de tutulmasını şart koşmaz. Ama firmware imajları ve düzeltilmemiş açıklar, ticari sır ve güvenlik açısından en hassas verilerinizdir; olay kayıtları ve cihaz telemetrisi ise kişisel veri de içerebilir. Bu yüzden müşterileriniz verinin nerede işlendiğini sorar; kişisel veri içeren kısımlar için GDPR ve KVKK'nın yurt dışı aktarım kurallarını da değerlendirmeniz gerekir.

• Veriler hangi ülkedeki veri merkezinde tutuluyor; alt işleyenler kimler?
• Müşteriler arasında veri ayrımı nasıl sağlanıyor?
• Sözleşme bittiğinde verileriniz hangi biçimde ve ne kadar sürede teslim edilip siliniyor?

8. Sürümler ve destek süresi

CRA yükümlülükleri ürün piyasaya çıktığında bitmez. Yazılım her firmware sürümünü ayrı tutmalı, yayımlanmış sürümlerin bileşenlerini yeni açıklara karşı izlemeye devam etmeli ve destek süresinin sonunu hatırlatmalıdır.

04Yazılım türleri ve kime uyduğu

Piyasadaki çözümler kabaca üç gruba ayrılır. Gruplar keskin değildir; bir ürün birden fazlasını kapsayabilir. Tablo genel eğilimleri gösterir, belirli bir ürünü değil.

Çoğu üretici bu türleri birleştirir: süreçleri danışmanla kurar, süreklilik isteyen işleri (SBOM, açık izleme, kararlar, belgeler, bildirim süreleri) bir yazılıma bırakır. Seçerken türe değil, yukarıdaki ölçütlerden hangilerinin karşılandığına bakın.

05Satıcıya sorulacak sorular

1. Kendi firmware imajımızla deneme yapabilir miyiz; sonuçta hangi bileşenlerin bulunamadığını görebilir miyiz?
2. Hangi zafiyet kaynaklarını kullanıyorsunuz ve bir bulgunun kaynağını nasıl görürüz?
3. Aktif istismar kanıtını EPSS gibi olasılık puanlarından nasıl ayırıyorsunuz?
4. VEX belgeniz hangi biçimde ve hangi doğrulayıcıdan geçiyor?
5. Teknik dosya Ek VII'nin hangi bölümlerini kapsıyor; hangi bölümleri biz yazıyoruz?
6. Madde 14 sürelerini hangi andan başlatıyorsunuz; bildirim formunun hangi alanlarını hazırlıyorsunuz?
7. Verilerimiz hangi ülkede tutuluyor; alt işleyenleriniz kimler?
8. Sözleşme biterse verilerimizi ve belgelerimizi hangi biçimde alırız?
9. Yol haritanızdaki özellikleri canlı olanlardan nasıl ayırıyorsunuz?

06Dikkatle okunacak iddialar

• "CRA sertifikalı yazılım": CRA bir uyum yazılımını onaylamaz ya da sertifikalandırmaz. Uygunluk, ürün için üretici ya da onaylanmış kuruluş tarafından değerlendirilir.
• "Otomatik uyum": Yazılım kanıt toplar ve belge hazırlar; risk kararlarını, açık kararlarını ve uygunluk beyanını üretici verir.
• "SRP'ye otomatik gönderim": SRP'nin ilk sürümünde API yoktur. Bu değişirse ENISA duyurur; iddiayı ENISA'nın sayfasıyla karşılaştırın.
• Kalite puanı uygunluk demek değildir: Bir SBOM'un alanlarının dolu olması içeriğinin doğru olduğu anlamına gelmez.

07Bizim yaklaşımımız

TegmenSoft'u bu ölçütlere göre kurduk. Platformda bugün canlı olanlar:

• Firmware'den SBOM: ham ikili, dosya sistemi, Intel HEX, S-record ve ELF imajlarını açar, bulamadığını açıkça yazar; derleme sisteminizin CycloneDX ya da SPDX SBOM'unu içe alıp analizle karşılaştırır.
• Kaynaklar: NVD, OSV, CVE Program kayıtları ve üretici bültenleri; her bulgu kaynağına bağlanır, güncellenemeyen kaynak tarihiyle bildirilir.
• İstismar kanıtı: CISA KEV ya da ENISA EUVD'de istismar edildiği bilinen açıklar öne alınır ve Madde 14 adayı olarak işaretlenir; EPSS yalnız sıralamada kullanılır. Karar sizde kalır.
• VEX: analist kararları gerekçesiyle kaydedilir; CSAF VEX ve OpenVEX belgeleri resmî doğrulayıcıdan geçer.
• Teknik dosya: Ek I gereksinim kartları, risk değerlendirmesi ve AB uygunluk beyanı taslağı; Ek VII teknik dosyası PDF ve JSON olarak imzalanır ve RFC 3161 zaman damgasıyla dondurulur.
• Madde 14: 24 saat, 72 saat ve nihai rapor süreleri izlenir, SRP formu hazırlanır, Madde 14(7)'ye göre koordinatör CSIRT önerilir; her gönderim imzalı ve zaman damgalı arşivlenir.
• Barındırma: platform Almanya'daki bir veri merkezinde çalışır; her sorgu sizin kiracınızla sınırlanır.
• Destek süresi: her ürünün destek süresi kayıtlıdır; bitişe yaklaşırken uyarı verilir.

Yapmadıklarımız da var: uygunluk değerlendirmesi yapmayız, onaylanmış kuruluşun yerini tutmayız ve ilk süreç kurulumunda danışmanlığın yerini almayız. Bir SBOM'u ücretsiz SBOM karnesinde deneyebilir, kendi firmware'inizle pilot programa başvurabilirsiniz.

08Sık sorulan sorular