AB Siber Dayanıklılık Yasası Nedir?
AB Siber Dayanıklılık Yasası (CRA), Avrupa Birliği'nde satılan dijital unsurlar içeren ürünler için zorunlu siber güvenlik gereksinimleri belirleyen bir düzenleme. 2024 sonunda resmi olarak kabul edildi ve Aralık 2027'de tam olarak yürürlüğe giriyor.
Kişisel veri işlemeye odaklanan GDPR'ın aksine, CRA ürünün kendisinin güvenliğine odaklanıyor — nasıl inşa edildiği, güvenlik açıklarının nasıl bildirildiği ve yazılım güncellemelerinin ürünün ömrü boyunca nasıl yönetildiği.
WordPress eklentileri, temaları, SaaS ürünleri veya AB müşterilerine herhangi bir bağlı dijital ürün satıyorsan, bu düzenleme muhtemelen seni kapsıyor.
CRA Kimi Etkiliyor?
Düzenleme, dijital unsurlar içeren ürünlerin "üreticilerini" ve "dağıtıcılarını" hedefliyor. Pratikte bu şunları kapsıyor:
AB pazarında ücretli ürün satan WordPress eklenti ve tema geliştiricileri. Eklentin veri işliyorsa, harici servislere bağlanıyorsa veya daha büyük bir yazılım ekosisteminin parçasıysa, kapsama giriyor.
AB işletmelerine veya tüketicilerine abonelik bazlı araçlar sunan SaaS sağlayıcıları.
AB müşterilerine teslim edilen özel yazılım veya web uygulamaları geliştiren ajanslar ve freelancerlar. Almanya, Fransa, İtalya veya başka herhangi bir AB ülkesindeki bir müşteriye WordPress tabanlı bir ürün teslim ediyorsan, CRA kapsamında "üretici" sayılabilirsin.
Kendi dijital ürünlerini AB müşterilerine satan e-ticaret site sahipleri.
Önemli bir not: ticari olmayan şekilde geliştirilen ve dağıtılan açık kaynak yazılım büyük ölçüde muaf. Ama bir WordPress eklentisinden para kazanıyorsan — kısmen de olsa, freemium model üzerinden de olsa — muhtemelen kapsam içindesin.
CRA Kapsamındaki Temel Gereksinimler
CRA, birkaç spesifik yükümlülük getiriyor. WordPress operatörleri için en alakalı olanlar şunlar:
1. Güvenlik Açığı Bildirim Politikası (VDP)
Güvenlik araştırmacılarının ürününüzdeki güvenlik açıklarını nasıl bildirebileceğini açıklayan, herkese açık erişilebilir bir politikaya sahip olman gerekiyor. Buna Vulnerability Disclosure Policy ya da VDP deniyor.
VDP, tahmin edilebilir bir konumda (siten) bulunmalı, sade bir dilde yazılmalı ve şunları belirtmeli:
- Güvenlik açığı raporu nasıl gönderilir
- Hangi bilgilerin dahil edilmesi gerekir
- Alındığını onaylamak için ne kadar süre alacağın
- Koordineli bir bildirim süreci işletip işletmediğin
2. security.txt Dosyası (RFC 9116)
Güvenlik iletişim bilgileri için standart konum, domain'indeki /.well-known/security.txt. Bu makine tarafından okunabilir dosya, güvenlik araştırmacılarını iletişim bilgilerine ve VDP'ne yönlendiriyor.
CRA, kapsam içindeki ürünler için bunu fiilen bir gereksinim haline getiriyor. Format RFC 9116'da tanımlanmış ve şöyle görünür:
Contact: mailto:security@senin-siten.com
Expires: 2027-12-31T23:59:59.000Z
Policy: https://senin-siten.com/vulnerability-disclosure-policy
3. Yazılım Bileşen Listesi (SBOM)
SBOM, ürününüzdeki tüm yazılım bileşenlerinin resmi bir listesi — yazılım için temelde bir içerik listesi.
Bir WordPress eklentisi için bu şunların belgelenmesi demek:
- Eklentinin kendisi (ad, sürüm, lisans)
- Kullandığı herhangi bir üçüncü taraf kütüphane veya bağımlılık
- Bağımlılık olarak WordPress çekirdeği
SBOM'lar yetkili kurumlar talep ettiğinde erişilebilir olmalı ve daha yüksek riskli ürünler için herkese açık olması gerekebilir.
4. Aktif Güvenlik Açığı Yönetimi
CRA, üreticilerin şunları yapmasını gerektiriyor:
- Ürünlerini bilinen güvenlik açıklarına karşı izlemek
- Güvenlik güncellemelerini zamanında yayınlamak
- Kullanıcıları güvenlik güncellemeleri konusunda bilgilendirmek
- Belirlenmiş bir destek süresi boyunca güvenlik güncellemelerini ücretsiz sağlamak
WordPress eklentileri için bu, bir sürüm yayınlayıp sonra terk edemeyeceğin anlamına geliyor. Eklentini etkileyen bir CVE keşfedilirse, bir düzeltme yayınlamakla yükümlüsün.
5. Uyumluluk Değerlendirmesi ve CE İşareti
Çoğu "standart" dijital ürün (CRA kapsamında Kategori I), düzenlemenin gereksinimlerine karşı bir öz-değerlendirmeden geçmeli ve ürününe CE işaretini iliştirmeli. Değerlendirme belgelenmeli.
Daha yüksek riskli ürünler (Kategori II), tıp cihazlarının veya oyuncakların test edilme şekline benzer şekilde, onaylanmış bir kuruluş tarafından üçüncü taraf değerlendirmesi gerektiriyor.
Çoğu WordPress eklentisi Kategori I'e giriyor ve kendi kendini sertifikalandırabiliyor.
GDPR ve NIS2 Ne Olacak?
CRA, GDPR veya NIS2'nin yerini almıyor — birbirleriyle paralel işliyorlar.
GDPR kişisel veri işlemeyi kapsıyor. WordPress siten veya eklentin AB sakinlerinin kişisel verilerini işliyorsa, CRA'dan bağımsız olarak GDPR uygulanır.
NIS2 (Ağ ve Bilgi Güvenliği Direktifi 2), enerji, sağlık, finans ve dijital altyapı gibi sektörlerdeki — genellikle daha büyük işletmeler olan — "temel" ve "önemli" varlıklara güvenlik gereksinimleri getiriyor. İşletmen veya müşterinin işletmesi bu kategorilerden birine giriyorsa, NIS2 yükümlülükleri CRA'nın üzerine ekleniyor.
Çoğu küçük WordPress işletmesi ve freelancer için birincil odak GDPR ve CRA. NIS2, daha büyük varlıkların daha dar bir kümesine uygulanıyor.
Zaman Çizelgesi — Ne Zaman Ne Olması Gerekiyor
| Tarih | Yükümlülük |
|---|---|
| Şimdi | Boşluk değerlendirmesine başla: ne yapman gerektiğini belirle |
| Eylül 2026 | CRA raporlama yükümlülükleri başlıyor (aktif olarak istismar edilen güvenlik açıklarını 24 saat içinde yetkililere bildirme) |
| Aralık 2027 | Tam CRA gereksinimleri uygulanıyor: VDP, SBOM, security.txt, uyumluluk değerlendirmesi, CE işareti |
Eylül 2026 raporlama yükümlülüğü genellikle göz ardı ediliyor. Tam uyumluluk Aralık 2027'ye kadar gerekmese de, aktif olarak istismar edilen güvenlik açıklarını ENISA'ya 24 saat içinde bildirebilmen gerekecek — ve bu, o tarihten önce izleme süreçlerinin devrede olmasını gerektiriyor.
Mevcut Durumunu Nasıl Kontrol Edersin
Nerede durduğundan emin değilsen, şu sorularla başla:
- Bir güvenlik iletişim adresin var mı? Araştırmacıların veya kullanıcıların ürününüzdeki bir güvenlik sorununu bildirmesi için bir yol var mı?
- Domain'inde
/.well-known/security.txtadresinde bir security.txt dosyası var mı? - Ürününüzdeki tüm yazılım bileşenlerini listeleyebiliyor musun? Eklentilerinin hangi üçüncü taraf kütüphaneleri kullandığını ve mevcut sürümlerini biliyor musun?
- Ürününüzün bağımlılıklarındaki güvenlik açıklarını takip eden bir sürecin var mı?
- Güvenlik pratiklerini belgeledin mi? Bir denetleyici sorduğunda bir uyumluluk değerlendirmesi kanıtı üretebilir misin?
Bunların çoğuna hayır dediysen, yapman gereken işler var — ama net bir checklist ile yönetilebilir.
Checklist'i Otomatikleştirmek İçin Bir Eklenti Kullanma
Bu gereksinimleri manuel olarak çalışmak yerine, Erdo CRA Compliance boşluk değerlendirmesini otomatikleştirir ve gereken belgelendirmeyi doğrudan WordPress panelinden oluşturmana yardım eder.
Eklenti:
Siteni tarar CRA, GDPR ve NIS2 kontrollerine karşı ve renk kodlu bir uyumluluk paneli üretir — yeşil (geçti), sarı (ilgilenilmesi gerekiyor), kırmızı (başarısız).
security.txt dosyanı üretir doğru RFC 9116 formatında ve otomatik olarak /.well-known/security.txt adresinde barındırır. FTP yok, sunucu yapılandırması yok.
Bir Güvenlik Açığı Bildirim Politikası oluşturur site bilgilerine dayanan, sitende bir sayfa olarak yayınlamaya hazır bir şablon.
Bir SBOM üretir tüm aktif eklentileri, sürümlerini ve lisans bilgilerini listeleyen — bir WordPress tabanlı ürün için bir yazılım bileşen listesinin gerektirdiği çekirdek.
PDF denetim raporları dışa aktarır uyumluluk durumunu belgeleyen, müşterilerle, denetçilerle paylaşmaya veya bir uyumluluk değerlendirmesi için kayıt olarak kullanmaya uygun.
Bir uyumluluk beyanı şablonu üretir — CRA kapsamında Kategori I ürünleri için gereken öz-değerlendirme belgesi.
Bunların hiçbiri yasal uyumluluğu garanti etmiyor — bu, spesifik ürününe, nasıl kullanıldığına ve yasal bağlamına bağlı. Ama yapılandırılmış bir başlangıç noktası veriyor ve temel teknik gereksinimlerin yerinde olduğundan emin oluyor.
Farklı Kitleler İçin Pratik Öneriler
Bir WordPress eklenti geliştiricisiysen: Eklentinin bağımlılıklarını belgelemeye başla (composer.json'unu veya paketlediğin üçüncü taraf kütüphaneleri kontrol et). Bir güvenlik iletişim e-postası kur. Basit bir VDP yayınla. Bu üç adım, temel yükümlülüklerin çoğunu kapsıyor ve haftalar değil, birkaç saat sürüyor.
WordPress projeleri teslim eden bir freelancer'sın: Müşterilerinin AB merkezli olup olmadığını ve onlar için kurduğun sitelerin kapsama girip girmediğini kontrol et. CRA uyumluluk belgelendirmesini sözleşmelerinde bir teslimat olarak dahil etmeyi düşün.
Bir ajanssın: Proje teslim sürecine bir CRA uyumluluk checklist'i ekle. AB pazarında dijital ürün alan müşteriler, bu gereksinimleri düşündüğüne dair belge gitmek isteyecek giderek artan ölçüde.
AB'ye yönelik dijital ürün satan bir e-ticaret sitesi işletiyorsun: Aralık 2027 deadline'ını, işletmelerin GDPR'ın Mayıs 2018 deadline'ına davrandığı gibi ele al — ama bu kez daha erken başla.
Özetle
AB Siber Dayanıklılık Yasası, GDPR'dan beri yazılım uyumluluk gereksinimlerindeki en büyük değişiklik. Çoğu site sahibinin son ana kadar büyük ölçüde göz ardı ettiği GDPR'ın aksine, CRA tek bir politika güncellemesiyle çözülemeyecek spesifik teknik gereksinimler getiriyor — gerçek bir uygulama gerektiriyorlar.
İyi haber: WordPress kullanıyorsan, CRA gereksinimlerinin çoğunu ele almak için araçlar şimdiden mevcut. 2026'da değerlendirmeye başlamak, Aralık 2027 deadline'ından önce checklist üzerinde çalışman için sana tam bir yıl veriyor.
Erdo CRA Compliance'ı WordPress.org'dan ücretsiz indir ve bugün ilk uyumluluk taramanı çalıştır.