22 tek sayfalık kılavuz. ENISA bunları 19 Mart 2026’da devreye soktu — hedefi avukatlar değil, Cyber Resilience Act altında ürün geliştirirken terleyen mühendisler.
Bakın, CRA AB ürün ekiplerinin üzerinde gölge gibi — rollout’tan beri uyumsuzlukta 15 milyon € veya küresel cironun %2,5’i ceza riski var. Ama çoğu rehber? Uyum meraklıları için yasal metin yığınları. ENISA’nın Güvenli Tasarım ve Güvenli Varsayılan Kılavuzu (v0.4) işleri tersine çeviriyor, dev takımlarına somut kontrol listeleri, kanıt şartları ve yarın GitHub’a yapıştırabileceğin yayın kapıları veriyor.
Neden ENISA Kılavuzu Yalın Takımlar İçin Fark Yaratıyor
Temiz ayrım: Güvenli Tasarım için 14 ilke (nasıl tasarlayacağın), Güvenli Varsayılan için 8 ilke (kutu açılır açılmaz davranış). Her kılavuz? Beş bölüm — ilke, amaç, kontrol listesi, asgari kanıt, yayın kapısı. Fazlalık yok. Yayın kapısını CI/CD’ye kopyala, gerçek güvenlikle yayınları kilitle.
Playbook 4.13’teki zafiyet yönetimi örneğini alın. Dokümandan direkt alıntı:
İlke: Zafiyet ve yama yönetimi pratik, tekrarlanabilir olmalı ve riske göre önceliklendirilmeli. Takımlar, araştırmacılar ve müşterilerden gelen sorun bildirimleri için basit bir kanal, hızlı karar üreten iç triyaj süreci istiyor.
Amaç: Kod, bağımlılıklar, altyapı ve firmware’de gerçek dünya maruziyetini azaltacak kadar hızlı zafiyet tespiti, önceliklendirme ve giderme. Odak: Basit bildirim-onarım akışı, net SLA’lar, yamayı güvenilir kılan güncelleme mekanizması.
O kontrol listesi? Bildirim kanalları (tarama, raporlar), “internet’e açık mı?” gibi şiddet derecesi bayraklarıyla triyaj, proaktif bağımlılık yamaları, güvenli düzeltmeler, iletişimi kapatan döngü. Kanıt: Zafiyet panosu, SLA’lar, CI taramaları, SBOM’lar. Kapı: Kritik yüksekler için istisnasız blok.
Tek sayfa. Bağımsız. Diğer 21’i de aynı vurucu — erişim kontrolü, veri minimizasyonu, ne derseniz. Ek C, bunları CRA Ek I yükümlülüklerine bağlıyor. Pat, denetim geçirmez.
Ama bence farkı: Bu, 2013’teki PCI-DSS 3.0 listelerini andırıyor. O zamanlar belirsiz “güvenlik duvarı kur” görmezden geliniyordu; kopyala-yapıştır tablolar? Verizon DBIR verilerine göre iki yılda kullanım %40 fırladı. ENISA da aynı bahse oynuyor — ENISA Güvenli Tasarım Kılavuzu SharePoint’te çürümez, PR’larda yaşar.
Tehdit Modelleme Artık Güvenlik Ekibi Olmadan da İşliyor mu?
ENISA, özellik ve düzeltme arasında mekik dokuyan takımlar için STRIDE tabanlı 5 adımlı süreç eklemiş — Sahtecilik’ten Yetki Yükseltme’ye.
Adım 1: Kapsamı belirle, zaman sınırlı — iç/dış ne, dağıtım bağlamı, varsayımlar (“müşteri ağı düpedüz düşman değil” gibi — doküman burada kesiliyor ama anladınız).
Yanlış pattern’ler yakalanmış: Tek seferlik törenler, çabuk bayatlayan aşırı detaylı modeller, değişiklik sonrası atlama. Tekrarlı, hafif tutun. Bu kılavuzlarla eşleştir, tehdit modelleme sprint’lere oturur, engellemez.
Pazar açısı? AB ürün sorumluluğu sıkılaşıyor — Gartner bugün geliştiricilerin %60’ını “güvenlik cahili” görüyor. Bu kılavuz köprüyü kuruyor, orta ölçek takımlar için CRA onarım maliyetlerini %30-50 düşürebilir (hesabıma göre, benzer ISO 27001 geçişlerine dayalı).
Şüpheci bakış: v0.4 taslak haliyle kamu danışma süreci devam ediyor. Geri bildirim şişirebilir. Ama format? Kurşun geçirmez. ENISA PR pompalamıyor; araç dağıtıyor.
ENISA Kılavuzu CRA Uyumu Altını mı Yoksa Bir Kontrol Listesi Daha mı?
Kısa cevap: Altın. CRA Ek I 50’den fazla talep ediyor — güvenli tasarım, varsayılan konfigürasyonlar, zafiyet yönetimi. ENISA bunları net bağlıyor. Artık standup’larda “yönetmeliği nasıl yorumlayalım” kavgası yok.
Sekiz risk aktivitesi de var: Tehditleri belirle, değerlendir, tedavi et, izle. Yalın operasyonlara cuk oturuyor. Tahmin: 2027 finaline kadar AB’ye dönük açık kaynak projelerinin %70’i (Kubernetes dağıtımları düşünün) bu kapıları fork’layacak — taslak sonrası GitHub trendlerinde fork’lar zaten patlıyor.
Abar
