· kaynak dev.to (home feed)
AB CRA el kitabı, küçük ekipler için 24 saat ve 72 saatlik açıklama bildirimlerini haritalandırıyor
dev.to'da yayımlanan bir el kitabı, aktif olarak istismar edilen açıklar için AB Siber Dayanıklılık Yasası'nın 24 saatlik erken uyarı ve 72 saatlik bildirim yükümlülüklerini, GitHub issue'ları ve SBOM araçlarını kullanarak süreci takip ederek küçük ekiplere adım adım anlatıyor.

Oleksandr Kuryzhev'in dev.to'da yayımladığı adım adım bir el kitabı, birçok küçük mühendislik ekibinin artık karşılaştığı bir sorunu ele alıyor: AB Siber Dayanıklılık Yasası'nın açıklama bildirimi yükümlülüklerini yerine getirmek — makaleye göre bu yükümlülükler 11 Eylül 2026'dan itibaren zorunlu. Rehber, yasal bir yükümlülüğü — aktif olarak istismar edilen açıklar için 24 saat içinde erken uyarı ve 72 saat içinde kapsamlı bildirim — GitHub issue'ları, SBOM'lar ve birkaç shell komutu üzerine kurulu somut bir araç setine dönüştürüyor.
Kurallar ne gerektiriyor
dev.to makalesine göre, dijital öğeler içeren ürünleri AB pazarına sunan üreticiler, aktif olarak istismar edilen açıkları bildirmek zorunda. Erken uyarı 24 saat içinde yapılmalı ve, geçerliyse, ürünün bulunduğu bilinen üye devletleri adlandırmalı. Onu 72 saat içinde daha kapsamlı bir bildirim izliyor; bu bildirim genel ürün bilgilerini, açığın ve istismarın niteliğini, alınan düzeltici veya hafifletici önlemleri ve kullanıcıların kendilerinin alabileceği önlemleri kapsıyor. Bildirimler, ENISA tarafından kurulmuş tek bir bildirim platformu üzerinden iletiliyor; gönderimler belirlenen koordinasyon CSIRT'sine ve ENISA'ya ulaşıyor. Makalenin kontrol listesi ayrıca, bir düzeltici önlemden itibaren 14 gün içinde verilmesi gereken nihai rapora ve yönetmeliğin 14. Maddesine atıf yapıyor.
Yazı, baskıyı bir senaryoyla çerçeveliyor: bir müşteri cuma günü saat 18:40'ta bir firmware güncelleme daemon'ı için bir proof-of-concept gönderiyor ve istismar hâlihazırda herkese açık bir forumda görülüyor. Son tarihler saat bazında işliyor, hafta sonları dahil. Büyük satıcıların bunun için uyum personeli var; küçük ekiplerde ise nöbetçi olan kim varsa o — yazar da bu yüzden el kitabının rapor gelmeden önce hazır olması gerektiğini savunuyor.
Olay öncesi hazırlık
Makale, zorunlu gördüğü ön koşulları sıralıyor. Birincisi, kapsam kararı: (AB) 2024/2847 sayılı Tüzük kapsamında hangi ürünlerin dijital öğeler içeren ürün sayıldığı — yazı, salt barındırılan SaaS'ın genellikle farklı şekilde ele alındığını ve açık kaynak bakıcılarının daha hafif yükümlülükleri olduğunu not ediyor. İkincisi, ENISA bildirim platformunda, olay ortasında değil önceden oluşturulmuş bir hesap. Üçüncüsü, biri karar verici biri gönderici olmak üzere isimlendirilmiş iki kişi, her birinin bir yedeğiyle — çünkü tek bir kişi 72 saatlik bir pencereyi kapsayamaz.
Gelen bildirimler konusunda yazar, bir SECURITY.md dosyası ve standart well-known yolunda bir security.txt yayımlamayı, GitHub'ın gizli açıklama bildirimi özelliğini etkinleştirmeyi ve güvenlik posta kutusunu, üretim uyarılarıyla aynı sayfalayıcıya yönlendirmeyi öneriyor; çünkü hafta sonu boyunca okunmamış bir rapor yine de süreci başlatabilir. El kitabı ayrıca farkındalığı yazılı olarak tanımlamalı — makale, karar vericinin istismara dair güvenilir kanıtı kaydettiği zaman damgasını, ilk e-postanın düştüğü anı değil, öneriyor — ancak böyle bir tanımın geçerli olup olmadığının bir hukuk danışmanı sorusu olduğunu belirtiyor.
Tek komutla saati başlatmak
Temel otomasyon, farkındalık zamanını kaydeden, iki son tarihi de tarih dizesi ayrıştırma yerine epoch aritmetiğiyle hesaplayan ve gh CLI üzerinden bir GitHub issue açan küçük bir bash betiği. Issue; farkındalık zaman damgasını, 24 saatlik ve 72 saatlik son teslim zamanlarını ve karar verici onayı, üye devlet listesi, her iki gönderim ve nihai düzeltici sürümü kapsayan bir kontrol listesini taşıyor. GitHub böylece kalıcı, zaman damgalı bir kayıt sağlıyor. Yazının işaret ettiği bir tuzak: macOS BSD date ile geliyor ve betiğin ihtiyaç duyduğu bayraklar yok; ekipler GNU coreutils kurmalı, yoksa betik en kötü anda başarısız olur.
Kanıt oluşturmak
Bildirim içeriği için makale bir kanıt hattı oluşturuyor: syft ile gerçekten sevk edilen artifact'in bir SBOM'unu üretin, bileşenleri grype ile açıklarla eşleştirin, ardından ortaya çıkan CVE tanımlayıcılarını jq kullanarak CISA'nın Bilinen İstismar Edilen Açıklar kataloğuyla kesiştirin. Her iki kümede de görünen her CVE, sevk edilen bileşenlerde bir yerde istismar edildiği bilinen bir açığa işaret ediyor — yazar bunu karar verici için güçlü bir tetikleyici olarak görüyor, yasal bir test olarak değil: telemetri ve müşteri raporları da sayılır ve katalogda bulunmama hiçbir şey kanıtlamaz. Yazı ayrıca, gönderimin baskı altında yazılan bir metin değil boşluk doldurma haline gelmesi için her iki rapor için Markdown şablonları tutmayı ve çıktı biçimleri sürümler arasında değiştiği için araç bayraklarını güncel belgelere karşı yeniden doğrulamayı öneriyor.
Maliyetler ve uyarılar
Makale, bunun hukuki tavsiye değil mühendislik rehberi olduğunun ve kapsamın bir hukuk danışmanıyla doğrulanması gerektiğinin açıkça altını çiziyor. Ayrıca maliyet tarafını da kabul ediyor: eklenen nöbet yükü ve süreç ağırlığı — ki AB pazarına hiçbir şey sevk etmeyen ekipler bunu makul bir şekilde atlayabilir.
Neden önemli
CRA'nın bildirim yükümlülükleri, çoğu zaman hiçbir hukuk veya uyum fonksiyonu olmayan ekiplerin üzerine biniyor. Bu el kitabını öne çıkaran, yasal bir süreyi mühendislerin zaten kullandığı artefaktlere dönüştürmesi: zaman damgalı bir uyum kaydı olarak issue takipçisi, kanıt olarak SBOM hattı, tetikleyici olarak bir shell alias'ı. Ayrıca gerçekten zor olan kısmı yalıtıyor: aktif istismarın farkında olunması, birilerinin sahiplenmesi ve zaman damgası basması gereken operasyonel bir olaydır ve oradaki belirsizlik, 24 saatlik bir son tarihin kazanılıp kaybedildiği yerdir. Saat bazlı son teslim tarihli açıklama yükümlülükleri AB'nin ötesine yayıldıkça, yönetmelikleri betiklere ve kontrol listelerine kodlama bu biçimi, küçük ekiplerin tekrar tekrar kullanacağı bir örüntü olarak görünüyor.
- #cyber-resilience-act
- #vulnerability-disclosure
- #eu
- #security
- #compliance