CRA hazırlığı kod tabanında başlar: zafiyetleri bulmak için 7 soru

Siber Dayanıklılık Yasası (CRA) sıklıkla politik ya da raporlama kaynaklı bir zorluk olarak görülür; ancak dijital öğe üreticileri için etkisi çok daha erken kendini gösterir: pull request'lerde, build pipeline'larında, sürüm onaylarında ve test setlerinde. Bir şirket, hangi sürümlerin etkilendiği, hangi bileşenin risk yarattığı ve düzeltmenin gerçek üründe çalışıp çalışmadığı gibi basit mühendislik sorularını önceden yanıtlayamazsa, kullanılan bir güvenlik açığına dair güvenilir bir rapor sunamaz.

Çoktan yürürlüğe giren süreler

CRA kapsamında dijital öğe üreticileri, Avrupa Birliği raporlama süreci aracılığıyla aktif olarak kullanılan güvenlik açıklarını ve ciddi olayları bildirmekle yükümlüdür. Bu gereklilik bu yılın 11 Eylül'ünden itibaren geçerlidir; kalan yükümlülüklerin büyük bölümü ise 2027 Aralık'ta yürürlüğe girecektir. Tarihler önemlidir, ancak mühendislik liderleri için daha faydalı soru, yazılım teslim sisteminin güvenilir güvenlik sonuçlarını kaydedip bunları kanıtlayıp kanıtlayamayacağıdır. Yanıt, tek bir güvenlik aracında ya da son dakikada yapılan bir denetimde nadiren saklıdır.

Politikadan gözlemlenebilir kontrole

Birçok kuruluş güvenli geliştirme kurallarına zaten sahiptir. Zorluk, politikalar ile kod tabanı, pipeline ve sürüm kanıtlarının sıklıkla birbiriyle örtüşmemesidir. Boşlukları bulmanın pratik yolu, her kontrolü dört düzeyde değerlendirmektir: gerekçesiz, kararsız, standart ve zorunlu. Standart düzey önemli bir eşiktir: tek bir mühendise ya da elektronik tabloya bağlı kontrol modern hıza dayanamaz; zorunlu kontrol ise tehlikeli bir değişikliği otomatik olarak durdurur.

Boşlukları ortaya çıkaran yedi soru

Makale, kod tabanına odaklanan yedi kontrol öneriyor: güvenli varsayılanlar ürüne yerleşik mi; ekip yetkilendirme ve kriptografi gibi hassas değişiklikleri tanıyabiliyor mu; her sürüm tam kaynağa ve SBOM dahil bileşenlere kadar izlenebiliyor mu; kod birleştirilmeden önce gerekli kontroller çalışıyor mu; ciddi bir bulgu build'i ya da sürümü durdurabiliyor mu; testler düşmanca ve beklenmedik davranışları kontrol ediyor mu; ve sürüm testleri çalışma anında güvenliğin gerçek davranışını doğruluyor mu.

Risk temelli önceliklendirme ve AI'nin etkisi

Değerlendirme sonucu, riske göre sıralanmış bir plan olmalıdır: internete açık bir üründe eksik güvenli varsayılan, düşük riskli bir iç bileşenin otomasyon boşluğundan daha acildir. Ürünün açıklığı, işlevin kritikliği, sömürülebilirliği ve etkilenen sürümlerin sayısı dikkate alınır. Buna ajan tabanlı geliştirmenin artışı da ekleniyor: Sonar araştırmasına göre geliştiricilerin %96'sı AI tarafından yazılan koda tamamen güvenmediğini söylüyor, ancak yalnızca %48'i bunu commit'ten önce her zaman kontrol ediyor. Bu fark, kod insana mı yoksa bir ajana mı ait olduğuna bakılmaksızın otomatik kontrolü vazgeçilmez kılıyor.

Düzenleyici yükümlülüğün ötesinde CRA, kod tabanına yerleşik ve kanıt üreten kontroller gerektirir. Bunu disiplinli biçimde yapan kuruluşlar yalnızca raporlama sürelerini karşılamakla kalmaz, olayları da önler.