Cyber Resilience Act: AB Pazarına Ürün Sunan Ekipler İçin Güvenlik Hazırlığı

Cyber Resilience Act (CRA), AB pazarına sunulan dijital unsurlu donanım ve yazılım ürünleri için yaşam döngüsü boyunca siber güvenlik yükümlülükleri getirir. Bu yazı hukuki görüş değildir; ürün, güvenlik ve mühendislik ekiplerinin hazırlık planını oluşturmasına yardımcı olur.

Avrupa Komisyonu'na göre ana yükümlülükler 11 Aralık 2027'den itibaren uygulanacak; aktif olarak istismar edilen zafiyetler ve ciddi olaylara ilişkin raporlama yükümlülükleri 11 Eylül 2026'da başlıyor. Avrupa Komisyonu CRA özeti

İlk Soru: Ürününüz Kapsamda mı?

CRA kapsamı; AB pazarına sunulan donanım, yazılım ve ürünün işlevi için gerekli uzaktan veri işleme çözümlerini içine alabilir. Uygulama, mobil istemci, cihaz firmware'i, SaaS bileşeni veya bağımlılıkların kapsama etkisi ürün bazında değerlendirilmelidir. "Açık kaynak kullanıyoruz" veya "Türkiye merkezliyiz" varsayımları tek başına kapsam dışı olduğunuzu göstermez.

İlk çıktınız bir kapsam notu olmalıdır: ürün sürümü, hedef pazar, dijital bileşenler, tedarikçiler, uzaktan işlem bileşenleri ve ürün sahibini kaydedin. Hukuki kapsam kararını yetkin danışmanla doğrulayın.

CRA Türkiye’deki şirketi nasıl etkileyebilir?

CRA’nın ölçütü şirketin Türkiye’de kurulmuş olması değil, ürünün AB pazarına sunulması ve ürünün dijital unsurlara sahip olmasıdır. Ürün; firmware, masaüstü uygulaması, mobil istemci, SaaS’a bağlı istemci, ağ bileşeni veya uzaktan veri işleme bileşeni içeriyorsa kapsam analizi ürün bazında yapılmalıdır.

Ürün sahibi şu sorulara yazılı cevap vermelidir:

• Ürün AB’de satılıyor, kiralanıyor, ücretsiz dağıtılıyor veya uzaktan hizmet olarak sunuluyor mu?
• Hangi donanım, yazılım, firmware, kütüphane ve uzaktan veri işleme bileşenleri ürünün çalışması için gerekli?
• Üretici, ithalatçı, distribütör veya yetkili temsilci rolleri kimde?
• Ürün başka bir ürünün bileşeni olarak mı, bağımsız bir ürün olarak mı pazarlanıyor?
• Güncelleme, destek ve zafiyet iletişimi hangi ekip tarafından yönetiliyor?

Bu sorular hukuki görüş yerine kapsam dosyasının başlangıcıdır. Nihai sınıflandırma, ürünün teknik özellikleri ve AB’deki rol dağılımı üzerinden yetkin hukuk/compliance danışmanıyla doğrulanmalıdır.

Secure-by-design ve ürün yaşam döngüsü

CRA hazırlığı son sürümde bir pentest raporu üretmekten ibaret değildir. Ürün güvenliği, tasarım kararından destek süresinin sonuna kadar izlenebilir olmalıdır:

1. Tehdit modeli ürünün kullanım, güncelleme ve yönetim yollarını kapsar.
2. Güvenli varsayılanlar; güçlü kimlik doğrulama, en az yetki, güvenli iletişim ve secrets yönetimiyle tanımlanır.
3. Bağımlılık, firmware ve üçüncü taraf servis envanteri sürüm bazında tutulur.
4. Zafiyet triage, düzeltme, müşteri bildirim ve retest sorumluları atanır.
5. Güncelleme kanalı imza, bütünlük, rollback ve destek süresiyle birlikte test edilir.
6. Kullanıcıya güvenli kurulum, yapılandırma, güncelleme ve olay bildirim kanalı sunulur.

Bu kontrollerin her biri teknik dosyada kanıtlanabilir bir kayıtla eşleşmelidir. “Politikamız var” ifadesi; uygulandığını gösteren sürüm, test sonucu, onay ve sorumlu bilgisi bulunmadığında zayıf kalır.

SBOM neden merkezi kanıt hâline geliyor?

SBOM, üründe kullanılan bileşenleri listeleyen tek seferlik bir dosya değildir. Release, platform ve ürün varyantına göre hangi bağımlılığın hangi sürümde bulunduğunu; owner, kaynak, hash ve zafiyet durumuyla ilişkilendiren yaşayan bir envanter olarak tasarlanmalıdır.

Alan	Neden gerekli?
Bileşen adı ve sürümü	Etkilenen paket veya firmware’i ayırmak
PURL veya CPE	Dış zafiyet verisiyle eşleşmek
Kaynak ve lisans	Tedarik zinciri ve kullanım koşulunu izlemek
Release/build kimliği	Hangi müşterinin hangi artefact’i kullandığını bilmek
Owner ve destek durumu	Düzeltme sorumlusunu atamak
Hash/imza	Artefact bütünlüğünü doğrulamak

SBOM’un amacı zafiyeti otomatik kapatmak değildir. Etkilenen ürünleri hızlı belirlemek, kararın nedenini kaydetmek ve müşteriye doğru bildirim yapabilmek için güvenilir bir başlangıç noktasıdır.

Raporlama ile zafiyet yönetimini ayırın

Aktif olarak istismar edilen bir zafiyetin veya ürün güvenliğini etkileyen ciddi bir olayın raporlanması, normal backlog kaydından farklı bir süreçtir. Ekipler en azından şu akışı test etmelidir:

Sinyal / ihbar → Triage ve kapsam doğrulaması
      → Aktif istismar / ciddi olay değerlendirmesi
      → İlk bildirim sorumlusu ve zaman çizelgesi
      → Teknik düzeltme, müşteri iletişimi ve takip raporu

11 Eylül 2026 ve 11 Aralık 2027 tarihleri farklı yükümlülük başlangıçlarını ifade eder; güncel bildirim süresi ve kapsam, ürün rolü ile olay tipine göre resmi metin ve danışmanla doğrulanmalıdır. EUR-Lex Regulation (EU) 2024/2847

90 Günlük Hazırlık Planı

Gün 1–30: Varlık ve risk görünürlüğü

• Her ürün sürümü için bileşen envanteri ve SBOM oluşturun.
• İnternete açık servisleri, varsayılan hesapları, update mekanizmasını ve kriptografik anahtar akışını listeleyin.
• Tehdit modelini ürünün gerçek kullanım senaryolarıyla güncelleyin.
• Kritik bağımlılık ve zafiyetler için owner/son tarih belirleyin.

Gün 31–60: Güvenli geliştirme ve zafiyet süreci

• Secure-by-design gereksinimlerini backlog ve acceptance criterion içine alın.
• Code review, secret scanning, dependency yönetimi ve release onaylarını kanıtlanabilir hale getirin.
• Zafiyet kabul, triage, düzeltme, müşteri bildirimi ve retest akışını yazılı hale getirin.
• Ürün destek süresini, update kanallarını ve end-of-support iletişimini belirleyin.

Gün 61–90: Kanıt ve olay hazırlığı

• Risk değerlendirmesi, SBOM, test sonuçları, release kayıtları ve zafiyet kararlarını tek teknik dosyada ilişkilendirin.
• Aktif istismar şüphesinde kimin 24 saatlik erken uyarıyı, 72 saatlik bildirimi ve takip raporlarını yöneteceğini tatbikatla test edin.
• Kullanıcı dokümantasyonunda güvenli kurulum, güncelleme ve destek iletişimini netleştirin.

Penetrasyon Testinin Rolü

CRA hazırlığı yalnızca belge üretmek değildir. Pentest ve ürün güvenliği testi; threat model varsayımlarını, kimlik doğrulama akışlarını, update mekanizmasını, API erişim kontrolünü ve üçüncü taraf bileşen riskini gerçek saldırı yollarıyla doğrular. Bulguların düzeltildiğini gösteren retest kaydı, teknik dosyadaki en değerli kanıtlardan biridir.

Minimum Kanıt Seti

Kanıt	Sahibi	Ne gösterir?
Ürün risk değerlendirmesi	Ürün + güvenlik	Hangi tehditlerin ve kontrollerin değerlendirildiği
SBOM ve bağımlılık kaydı	Mühendislik	Hangi bileşenlerin hangi sürümde kullanıldığı
Zafiyet yönetim kaydı	PSIRT/güvenlik	Bulgunun triage, düzeltme ve bildirim süreci
Release ve update kaydı	Engineering	Hangi güvenlik düzeltmesinin ne zaman yayımlandığı
Pentest/retest raporu	Bağımsız test ekibi	Kritik varsayımların saldırı altında doğrulandığı

CRA takvimini "2027'de bakarız" diye ertelemek, 2026'daki raporlama hazırlığını ve ürün mimarisi kararlarını riske atar. En iyi başlangıç; kapsamı netleştirmek, kanıt sahibini atamak ve zafiyet sürecini bugünden test etmektir.

Sık sorulan sorular

Türkiye’de kurulu olmak CRA kapsamından çıkarır mı?

Hayır. Ürünün AB pazarına sunulması ve dijital unsurlara sahip olması kapsam değerlendirmesinde belirleyicidir. Şirketin kuruluş yeri tek başına muafiyet oluşturmaz.

SBOM tek başına CRA uyumluluğu sağlar mı?

Hayır. SBOM, bileşen görünürlüğünün bir parçasıdır. Risk değerlendirmesi, güvenli geliştirme, zafiyet yönetimi, güncelleme, kullanıcı dokümantasyonu ve uygunluk kanıtları birlikte ele alınmalıdır.

Pentest zorunlu bir uyum belgesi midir?

Pentest tek başına uyum belgesi değildir. Tehdit modelindeki varsayımları ve teknik kontrolleri doğrulayan güçlü bir kanıt olabilir. Kapsamı ürün sınıfı ve uygunluk değerlendirme yolu ile birlikte belirlenmelidir.

11 Eylül 2026’dan önce ne hazırlanmalı?

Ürün kapsam notu, PSIRT/incident rol dağılımı, SBOM, zafiyet triage akışı, bildirim karar ağacı, iletişim şablonları ve kanıt deposu masa başı tatbikatla doğrulanmalıdır.

Teknik dosya için kanıt haritası

CRA hazırlığında ekiplerin sık yaptığı hata, belgeleri birbirinden kopuk tutmaktır. Risk değerlendirmesindeki bir kontrolün hangi test, release veya kullanıcı dokümanıyla doğrulandığı izlenemiyorsa dosya büyür ama kanıt gücü artmaz.

Gereksinim alanı	Teknik kanıt	Sahibi
Ürün kapsamı	Ürün varyantı, pazar, rol ve dijital bileşen haritası	Product/compliance
Risk değerlendirmesi	Threat model, abuse case, risk kararı ve owner	Product security
Bileşen görünürlüğü	SBOM, dependency lockfile, firmware ve build hash’i	Engineering
Güvenli geliştirme	Code review, SAST/DAST, secret scan ve release onayı	DevSecOps
Zafiyet yönetimi	PSIRT kaydı, triage, düzeltme, müşteri bildirimi ve retest	Security/PSIRT
Güncelleme	İmza, dağıtım, rollback, destek ve end-of-life prosedürü	Engineering/operations
Kullanıcı güvenliği	Kurulum, varsayılan ayar, güncelleme ve olay bildirim dokümanı	Product/support

Bu harita, auditor’a sunulacak klasör yapısından önce ürün ekibinin günlük çalışma biçimini düzeltir. Her release’in kendi SBOM’u, test sonucu ve onayı saklanır; sonradan genel bir PDF hazırlayıp geçmişteki kararlara kanıt üretmeye çalışılmaz.

IoT ve uzaktan yönetilen ürünlerde özel riskler

IoT, edge veya endüstriyel cihaz satan ekipler için ürün güvenliği uygulama koduyla sınırlı kalmaz. Boot zinciri, cihaz kimliği, provisioning, OTA update, debug portları, bulut API’si ve fiziksel sıfırlama akışı birlikte test edilmelidir.

Özellikle şu sorular ürün kabul kriterlerine girmelidir:

• Fabrika varsayılan kimlik bilgileri ilk kurulumda zorunlu olarak değişiyor mu?
• Cihaz yalnızca imzalı ve bütünlüğü doğrulanmış firmware’i kabul ediyor mu?
• Güncelleme yarıda kaldığında cihaz güvenli ve geri alınabilir bir duruma dönebiliyor mu?
• Kullanımdan kaldırılan cihazın sertifikası, token’ı ve bulut kaydı iptal ediliyor mu?
• Yönetim API’si tenant, cihaz sahibi ve rol bazında erişimi ayırıyor mu?
• Fiziksel erişim, debug arayüzü veya yerel reset üzerinden kimlik doğrulama atlanabiliyor mu?

Bu kontrollerin bulguları OT/ICS güvenlik değerlendirmesi, external attack surface yönetimi ve ürün güvenliği testleriyle birlikte teknik dosyaya bağlanabilir.

Türkiye’den AB’ye satış için ekip yapısı

CRA hazırlığı tek bir “compliance owner”ın işi olarak kurulursa teknik kararlar geç görünür olur. Minimum çalışma grubu ürün sahibi, engineering, product security, PSIRT, legal/compliance, support ve gerektiğinde bağımsız test ekibinden oluşmalıdır.

İlk toplantıda şu dört karar yazılı hâle getirilmelidir:

1. Kapsam kararını kim verecek ve hangi belgelerle destekleyecek?
2. Aktif istismar veya ciddi olay sinyalini kim triage edecek?
3. İlk bildirim, müşteri iletişimi ve teknik düzeltme arasında kim koordinasyon sağlayacak?
4. Kanıt deposunun sahibi, saklama süresi ve erişim modeli ne olacak?

Bu sahiplik modeli, Türkiye’deki mühendislik ekibi ile AB’deki ithalatçı/distribütör veya yetkili temsilci arasındaki iletişim boşluğunu azaltır. CRA hakkında hukuki pozisyon üretmez; teknik ve operasyonel hazırlığın nerede başlayacağını görünür kılar.

CRA hazırlığında sık yapılan hatalar

• Ürünü yalnızca şirket merkezi Türkiye’de olduğu için kapsam dışı saymak
• SBOM’u release yerine proje seviyesinde tutmak
• “Open source” kullanımını güvenlik sorumluluğundan muafiyet gibi görmek
• PSIRT ve bildirim akışını yalnızca politika dokümanında bırakmak
• Güncelleme mekanizmasını yalnızca fonksiyon testiyle doğrulamak
• Pentest raporunu düzeltme ve retest kanıtından bağımsız saklamak
• Ürünün müşteri, tenant ve uzaktan yönetim modelini teknik dosyada göstermemek

İyi hazırlık, tüm riskleri sıfırladığını iddia etmez. Kapsamı, varsayımları, kalan riski, sorumluyu ve sonraki doğrulama tarihini açıkça gösterir.