SBOM’ların yönetmelikle talep edilmesini bekleyemeyiz


Eski reklamlar ürkütücü olabilir – sağlık veren özellikleriyle övünen sigara reklamları, bir zamanlar şeker yüklü şekerlemenin diyet yardımcısı olarak reklamı yapıldı ve alkolsüz içeceklerin bebekler için süt alternatifi olarak reklamı yapıldı. Yönetmelikler sayesinde bunların hiçbiri bugün geçerli olmayacaktı elbette. Gıdaların reklamı daha sorumlu bir şekilde yapılmalı ve içerikleri, özellikle de alerjenler, ambalaj üzerinde açıkça belirtilmelidir.

SBOM yönetmeliği

Yazılım malzeme listeleri (SBOM’ler), yazılım için içerik listeleri gibidir. Hiçbir yazılım baştan sona oluşturulmaz ve bir SBOM, onu oluşturmak için kullanılan yapı taşlarını listeler. Ve gıda alerjisi olan herkesin yemek yemeden önce mikrodalgada hazır yemeklerine giren yiyeceklerin listesini inceleyebilmesi gerektiği gibi, işletmelerin de yalnızca hangi yazılımın kullanıldığını değil, yazılımlarının hangi yazılımı kullandığını da bilmesi gerekir. .

SBOM’lara duyulan ihtiyaç

Malzeme listeleri (diğer adıyla bileşen listeleri, diğer adıyla ürün tarifleri) imalatta yaygındır. Ürün reçetesi, bir ürünü üretmek için gereken her şeyin, miktarların ve bunların nasıl elde edileceğinin yapılandırılmış, standartlaştırılmış bir listesidir. Satın almaları planlamak ve gecikmeleri en aza indirmek için hayati önem taşırlar; verimli hiçbir üretici, hayati parçaların gelmesini beklerken bileşenlerle dolu depolarda mahsur kalmak istemez. Ayrıca bir arıza veya başka bir sorun olduğunda ilk başvurulacak yer burasıdır.

SBOM’lar benzer şekilde çalışır. SBOM, bir yazılım parçasında bulunan tüm açık kaynak ve üçüncü taraf bileşenlerinin bir listesidir, ancak bundan da fazlasını içerir: her bileşenin sürüm numaralarını, lisanslarını ve yama durumunu içerir. Tıpkı imalatta olduğu gibi, bir şeyler ters gittiğinde bu temel bir referans malzemesi haline gelir. Arızalı bir bileşen keşfeden bir üretici, hangi ürününün geri çağrılması gerekebileceğini anlayabilir. Açık kaynaklı yazılım kullanan bir işletme, bir şeyler ters giderse güvenlik açıklarının nerede olabileceğini hemen anlayabilir.

Log4Shell güvenlik açığı mükemmel bir örnektir. Log4j, adından da anlaşılacağı gibi, hataları ve olayları günlüğe kaydetmek ve bunları yöneticilere iletmek için kullanıldı. Birisi bir web sitesini ziyaret ederse ve bir 404 hatası alırsa, bu büyük olasılıkla Log4j tarafından günlüğe kaydedilir; bunlardan birçoğu oluyorsa, bu bir soruna işaret eder. Kullanışlılığı onu her yerde hazır ve nazır hale getirdi ve bu onu sapkın bir şekilde oldukça belirsiz hale getirdi – her yerde kullanılan ve kimsenin gerçekten düşünmediği varsayılan bir yazılım parçası. Log4j’nin kod enjekte etmek için kullanılabileceği ortaya çıktığında, bu, milyonlarca sunucunun saldırıya uğrayabileceği ve ele geçirilebileceği anlamına geliyordu. NIST güvenlik açığı veritabanı, ona mümkün olan en yüksek değer olan 10’luk bir CVSS (Ortak Güvenlik Açığı Puanlama Sistemi) derecesi verir.

Her şeyi güncel tutma tavsiyesi iyidir, ancak yalnızca bir yere kadar gider. Farklı yazılım türleri farklı hızlarda güncellenir, bu nedenle bir yama beklemenin yeterince iyi olduğunun garantisi yoktu. Dahili olarak kabul edilen ve genellikle bu tür saldırılara karşı savunmasız olmayan ve yama yapılmasının daha az önemli olduğu düşünülen sunuculara saldırmak da mümkündü.

Bir SBOM, bu durumda inanılmaz derecede değerlidir ve güvenlik ekiplerine güvenlik açıkları ortaya çıktıklarında nerede olduklarını gösteren kullanışlı bir hazır hesaplayıcı sağlar.

Düzenleme bekleniyor

SBOM’lara ihtiyacımız var. İyi haber şu ki, SBOM’ları talep eden düzenlemeler ABD’de ve başka yerlerde çalışıyor. ABD hükümeti, federal kurumların SBOM’ları standart bir formatta benimsemesini talep etti, ancak bunun gerekli olup olmadığı “yazılımın kritikliğine” bağlı.

AB, Siber Direnç Yasası teklifine sahiptir ve Birleşik Krallık, yönetilen hizmet sağlayıcılarını halihazırda kritik altyapı için geçerli olan mevcut yasaların kapsamına sokmayı amaçlamaktadır.

Ancak, herhangi bir düzenlemede olduğu gibi, yasama organlarından geçerken pek çok belki ve uyarı vardır. Gereksinimlerin inovasyonu engelleyebileceği ve daha küçük işletmelerin ekstra bürokrasi ile engellenebileceği endişesi var. Bu yeni siber güvenlik kuralları, SolarWinds hack’i gibi tedarik zinciri saldırılarına bir yanıt niteliğindedir ve günümüzde BT’nin büyük bölümünü destekleyen büyük sağlayıcıları hedefleme olasılığı daha yüksektir.

Tavsiyemiz, düzenlemeyi beklememek ve SBOM’lara yönelik katı talepler zaten varmış gibi hareket eden politikaları yürürlüğe koymaktır. Sanki katı düzenlemelere sahip bir G-adamı yarın habersiz gelecek ve bu belgelerin kendisine gösterilmesini talep edecekmiş gibi davranın.

Bunu daha basit hale getirebilecek yürürlükte standartlar vardır – iyi bilindiği ve bir ISO standardı olduğu için, kullanılmaması için çok iyi bir neden olmadıkça SPDX formatı kullanılmalıdır.

En önemlisi, güvenlik açıkları olabilecek bileşenlerin hızlı bir şekilde bulunabileceği bir sistemin kullanılmasıdır. SBOM’lerin oluşturulması, tipik olarak bir CI/CD işlem hattı kullanılarak derleme zamanı yöntemleriyle yapılmalıdır, yani SBOM her zaman güncel olacaktır. Üretilen her sürüm için bir tane oluşturulmalıdır, böylece hala kullanılabilecek eski sürümler gerekirse kontrol edilebilir.

Tedarikçilerden SBOM’larını devretmelerini talep etmenin, potansiyel bir rekabet sorunu olan çözümlerini oluşturmak için kullandıkları programlar olan gizli soslarını açığa çıkarmak anlamına gelme riski vardır. Düzenlemeler çok ileri gidebilir ve özdenetim yeterince ciddiye alınmazsa kötü düzenleme mümkündür.

Ne geliştiriciler ne de güvenlik ekipleri bekleyemez; SBOM’ları şimdi uygulamaya koymaları ve talep etmeleri gerekiyor, bu da onları bir sonraki büyük hack’ten önce normalleştirmeleri gerekiyor. Bu sadece güvenlikle ilgili değil, beklenmedik olaylara veya güvenlik açıklarına yanıt verme yeteneğinize güvenen iş ortakları ve müşterilerle ilgili. Bir sonraki CVSS Seviye 10 etkinliği vurduğunda, “endişelenme, bizde bu var” diyebilmek çok değerli olacak.



Source link