CRA'daki SBOM gereksinimi tek bir cümle. Ek I Bölüm II madde 1, üreticilerin ürünlerindeki zafiyetleri ve bileşenleri belirleyip belgelemesini istiyor; bunun bir parçası olarak da yaygın kullanılan, makinece okunabilir bir formatta ve en az üst seviye bağımlılıkları kapsayan bir yazılım malzeme listesi (SBOM) hazırlanmasını.

Bu cümle yoruma açık. Nasıl okunacağını ve bir değerlendiricinin büyük ihtimalle neye bakacağını aşağıda bulacaksınız.

Tüzük ne istiyor?

  • Yaygın kullanılan, makinece okunabilir bir format. Pratikte JSON veya XML olarak SPDX ya da CycloneDX. PDF bir liste bu gereksinimi karşılamaz; kendi hazırladığınız bir tablo dosyasının da yaygın kullanılan bir format sayılması pek olası değildir.
  • En az üst seviye bağımlılıklar. Ürün yazılımınız A kütüphanesini, A kütüphanesi de B'yi kullanıyorsa, A üst seviyedir, B dolaylı (transitive) bağımlılıktır. Yasal alt sınır A'dır.
  • Teknik dosyanın parçası. SBOM, otoriteler için sakladığınız dosyada yer alır ve gerekçeli bir talep olduğunda piyasa gözetim otoritesine verilir (Ek VII madde 8).
  • En az on yıl saklanır: Ürün piyasaya sunulduktan sonra en az on yıl, destek süresi daha uzunsa o süre boyunca (Madde 13(13)).

Komisyon, SBOM'un formatını ve unsurlarını bir uygulama tüzüğüyle belirleyebilir (Madde 13(24)). O zamana kadar BSI TR-03183-2 ve NTIA asgari unsurları gibi iyi uygulama kaynakları makul bir başlangıç noktası.

Ne istemiyor?

SBOM'unuzu yayımlamak zorunda değilsiniz. CRA yayımlamayı şart koşmuyor. Kullanıcılarla paylaşabilirsiniz; paylaşırsanız kullanıcı bilgileri SBOM'un nerede olduğunu belirtmelidir (Ek II madde 9). Birçok üretici SBOM'u kurumsal müşterilerine gizlilik sözleşmesiyle veriyor, bunun dışında şirket içinde tutuyor. Hangisini seçerseniz seçin, aynı tercihi SBOM prosedüründe, teknik dosyada ve kullanıcı bilgilerinde yazın. Değerlendirici bunları karşılaştırır.

Üst seviye alt sınırdır. Daha fazlasını hedefleyin.

Son yıllardaki ciddi zafiyetlerin çoğu, kimsenin listelemediği dolaylı bileşenlerdeydi. Sadece üst seviyeyi kapsayan bir SBOM yasanın lafzını karşılar, ama sizi tam da sorunun çıktığı yerde kör bırakır. Araçlarınız tüm bağımlılık ağacını çıkarabiliyorsa onu kullanın.

Her sürüm için bir SBOM

SBOM bir ürünü değil, bir derlemeyi tarif eder. 4.0.1 sürümü düzeltilmiş bir kütüphaneyle çıktığında SBOM'u 4.0.0'ınkinden farklıdır. Yayımlanan her sürüm için bir SBOM tutun ve sürümle birlikte saklayın. Yeni bir zafiyet çıktığında sadece en son sürüm için değil, sahada hâlâ çalışan her sürüm için cevap vermeniz gerekir.

Neden 2027'de değil, bugün önemli?

SBOM gereksinimi 11 Aralık 2027'den itibaren uygulanıyor. İhtiyaç ise daha önce başlıyor. Madde 14 kapsamındaki bildirim 11 Eylül 2026'dan beri uygulanıyor ve ilk soru hep aynı: ürünlerimizin ve sürümlerimizin hangisinde bu bileşen var, zafiyetli işleve erişilebiliyor mu? Her sürüm için bir SBOM varsa bunun cevabı dakikalar sürer. Yoksa günler sürebilir ve 24 saatlik süre beklemez.

Bir bileşen ürününüzde bulunuyor ama istismar edilemiyorsa, bu analizi bir VEX beyanı olarak kaydedin. Baktığınızın ve neden bildirim yapmadığınızın kanıtı odur.

Gömülü yazılımda SBOM nerede eksik kalır?

Tarayıcılar paket bildirim dosyalarında iyi çalışır. Gömülü yazılım ise nadiren sadece paket bildirim dosyalarından oluşur.

  • Çip üreticilerinden gelen ikili dosyalar. Radyo ürün yazılımı, önyükleyiciler ve kapalı sürücüler çoğu zaman meta veri olmadan ikili dosya olarak gelir. Bunları tedarikçinin bilgilerine dayanarak elle ekleyin ve kaynağını not edin.
  • Depoya kopyalanmış kod. Yıllar önce deponuza kopyalanmış, belki yerel değişiklikler yapılmış bir kütüphane, paket yöneticilerini okuyan araçlara görünmez. Onu bulun ve orijinal sürümüyle listeleyin.
  • Statik bağlama. Tek bir imaja bağlanmış kod, tespit edilecek ayrı dosya bırakmaz. SBOM'u sadece bitmiş imajdan değil, neyi bağladığını bilen derleme sisteminizden üretin.
  • Arka uç. Bulut hizmetiniz ürünün parçasıysa (uzaktan veri işleme), onun bileşenlerini de SBOM kapsamınıza almayı düşünün.
  • Tedarikçi bileşenleri. Tedarikçilerinizden teslim ettikleri bileşenlerin SBOM'larını isteyin. Bu, bileşenlerdeki özen yükümlülüğünüzün parçasıdır (Madde 13(5)). Aralık 2027'den itibaren bileşeni ayrıca satan tedarikçilerin zaten buna ihtiyacı olacak.

İşe yarayan bir SBOM kaydında ne olmalı?

Her bileşen için: ad, sürüm, tedarikçi, benzersiz bir tanımlayıcı (package URL veya CPE), kriptografik özet (hash), lisans ve bağımlılık ilişkisi. SBOM'un bütünü için: ürün ve sürüm, hazırlayan, oluşturma zamanı, onu üreten araç ve sürümü. En önemlisi benzersiz tanımlayıcıdır, çünkü SBOM'un zafiyet veritabanlarıyla otomatik eşleşmesini o sağlar.

Kısa kontrol listesi

  1. SPDX ya da CycloneDX seçin ve derinliğe karar verin: alt sınır üst seviye, hedef tüm ağaç.
  2. SBOM'u derleme hattında, sürümle aynı kaynaktan üretin.
  3. İkili ve depoya kopyalanmış bileşenleri kaynağıyla birlikte elle ekleyin.
  4. Yayımlanan her sürüm için bir SBOM'u değiştirmeden en az on yıl saklayın.
  5. Desteklenen sürümlerin tüm SBOM'larını zafiyet kaynaklarıyla en az günde bir eşleştirin.
  6. İstismar edilemeyen bulguları VEX beyanı olarak kaydedin.
  7. SBOM'u paylaşıp paylaşmayacağınıza ve nasıl paylaşacağınıza karar verin, her belgede aynı şeyi yazın.

Bu yazı (AB) 2024/2847 sayılı Tüzüğü sade bir dille açıklar. Hukuki danışmanlık değildir.