Hangi SBOM Sizin İçin Uygun?

Daha önceki bir blog yazımızda SBOM kavramından bahsetmiştik. Özetle, Yazılım Malzeme Listesi (İng. SBOM – Software Bill of Materials), bir kod tabanında bulunan tüm açık kaynak ve üçüncü taraf bileşenlerin listesidir ve açık kaynak kullanımı durumunda, güvenlik, lisans ve operasyonel risklere hızlı bir şekilde yanıt verebilmenizi sağlar.

Peki Yazılım Malzeme Listesinin CISA tarafından tanımlanmış tipleri olduğunu biliyor musunuz?

Önce CISA’dan bahsedelim. CISA (Cybersecurity & Infrastructure Security Agency) ABD’nin Siber Güvenlik ve Altyapı Güvenliği Ajansıdır. CISA, günümüzün tehditlerine karşı savunma için, ortaklarla birlikte çalışan ve gelecek için daha güvenli ve dayanıklı bir altyapı oluşturmak için sektörle işbirliği yapan bir risk danışmanı olarak görülebilir.

CISA, altı özel SBOM türünü sınıflandırmıştır. Bu sınıflandırmadaki SBOM türleri, yazılım geliştirme yaşam döngüsünün (SDLC) belirli bir aşamasında oluşturulur ve yazılımın o andaki durumunu yansıtır. Aşağıda CISA tarafından tanımlanmış altı SBOM tipini özetliyoruz.

Tasarım Yazılım Malzeme Listesi (Design SBOM)

Tasarım Yazılım Malzeme Listesi, amaçlanan, planlanan yazılım projelerini veya bazıları henüz mevcut olmayan yeni yazılım yapıtları için bileşenlere sahip ürünleri kapsar. Bu bilgiler genellikle tasarım belirtimlerinden, RFP’lerden veya ilk kavramlardan türetilir ve manuel olarak derlenir. Bu SBOM türü genellikle son uygulamaya dahil edilecek bir dizi bağımlılıktan yoksundur. Ancak olası sorunları erkenden ele alarak ekiplerin çalışma planlarını planlamalarına yardımcı olur.

Kaynak Yazılım Malzeme Listesi (Source SBOM)

Kaynak Yazılım Malzeme Listesi, doğrudan bir ürün yapıtı oluşturmak için kullanılan geliştirme ortamı kaynak dosyalarından ve bağımlılıklarından oluşturulur. Tipik olarak, yazılım kompozisyon analizi (SCA) araçlarından manuel açıklamalar ilave edilerek oluşturulur. Bu SBOM türü, tam olarak oluşturulan veya çalışan uygulamada görünürlük olmadan oluşturulur ve bu nedenle daha sonraki yaşam döngüsü bağımlılıklarından yoksun olabilir ve hatta alakasız olanları içerebilir.

Derleme Yazılım Malzeme Listesi (Build SBOM)

Derleme Yazılım Malzeme Listesi, kaynak dosyalar, bağımlılıklar, yerleşik bileşenler ve kısa ömürlü derleme işlemi verileri gibi verilerden derleme işleminin bir parçası olarak oluşturulur. Bu SBOM türünün oluşturulması, düzenli yapılandırma eylemlerini takiben derleme aşamasının bir parçası olarak tamamen otomatiktir. Bu SBOM, üçüncü taraf SBOM’lar, kaynak dosyalar, kod ve yerleşik bileşenler dahil olmak üzere tüm kullanılabilir öğeleri içerir ve ara Derleme ve Kaynak SBOM’ları entegre eder.

Kaynak kodun ötesinde bağımlılıklar içerdiğinden, bu SBOM dağıtılan öğenin öğelerini doğru bir şekilde temsil eder. Bu aşamada oluşturulan SBOM’lar diğer SBOM’ları içerir, bu nedenle son sürüm yapıt SBOM’u için ara Derleme ve Kaynak SBOM’ları entegre edebilirler. Ekipler, güvenli bir teslimat sağlamak için bu aşamada SBOM’yi imzalamayı da seçebilir.

Ne yazık ki, bu SBOM, derleme araçlarıyla tümleştirmek için önemli bir yapılandırma çabası gerektirir. Bazı ekiplerin bunu başarmak için derleme süreçlerini ayarlamaları gerekebilir.

Analiz Yazılım Malzeme Listesi (Analyzed SBOM)

Analiz Yazılım Malzeme Listesi, derlemeden sonra yapıtların (ör. yürütülebilir dosyalar, paketler, kapsayıcılar ve sanal makine görüntüleri) analizi yoluyla oluşturulur. Bu tür bir analiz genellikle çeşitli buluşsal yöntemler gerektirir. Bazı bağlamlarda, yapıtların analizi üçüncü taraf araçlarla gerçekleştirildiği için “üçüncü taraf” SBOM olarak da adlandırılabilir.

Bu SBOM türü, otomatik veya manuel olabilen bir ikili analiz aracı gerektirir. Kaynak koduna veya yapı sistemlerine erişim gerekli değildir. Bu tür SBOM, şirket içinde oluşturulan yazılımlara görünürlük sağlamak veya satıcılar veya yazılım üreticileri tarafından sağlanan SBOM’ları doğrulamak için oluşturulur. Ayrıca, farklı aşamalarda çalıştırılan diğer SBOM oluşturma araçlarına gizlenmiş bağımlılıkları da bulabilir. Çünkü, Analiz SBOM’ları buluşsal yöntemlere ve bağlama bağlıdır, sürüm numarası yanlışlıklarına veya eksikliklerine eğilimli olabilirler.

Dağıtılmış Yazılım Malzeme listesi (Deployed SBOM)

Dağıtılmış Yazılım Malzeme Listesi, dağıtılan bir sistemde bulunan yazılımın bir envanterini sağlar. Bu, yapılandırma seçeneklerinin analizini ve (potansiyel olarak simüle edilmiş) bir dağıtım ortamında yürütme davranışının incelenmesini birleştiren diğer SBOM’ların bir derlemesi olabilir.

Bu tür SBOM, bir sistemde kurulu ve mevcut yazılımların manuel olarak incelenmesiyle derlenir. Bu el ile çaba gerektirdiğinden, ekiplerin SBOM’lar tarafından sağlanan bilgileri ve yapıtların yapılandırma bilgilerini dikkate alması ve ardından uygulama davranışını yürütmesi gerekir. Bu, yazılım sağlayıcısı tarafından simüle edilmiş bir ortamda veya operatör tarafından gerçek veya simüle edilmiş bir ortamda yapılabilir.
Dağıtılan SBOM’lar, yazılımın gerçekte nerede çalıştığına ilişkin bağlamı içerebilir, ancak bu bilgileri doğru ve eksiksiz bir şekilde elde etmek zor olabilir ve birçok bağımlılık erişilemeyen kodda bulunabilir.

Çalışma Zamanı Yazılım Malzeme Listesi (Runtime SBOM)

Çalışma Zamanı SBOM’u, sistemde bulunan bileşenlerin yanı sıra harici belirtme çizgilerini veya dinamik olarak yüklenen bileşenleri yakalamak için yazılımı çalıştıran sistemin izlenmesiyle oluşturulur. Bazı bağlamlarda bu, “araçlı” veya “dinamik” SBOM olarak da adlandırılabilir, çünkü genellikle çalışan uygulamalarda “kara kutu” testi gerçekleştiren dinamik bir analiz aracı kullanılarak oluşturulur.

Bu SBOM türü gürültüyü keser ve değerlendirme için hangi bağımlılıkların önceliklendirilmesi gerektiğinin köküne iner. Bu çözümlemeyi çalışan bir uygulamada gerçekleştirmek çok fazla ek yük gerektirir ve uygulamanın tüm işlevlerini ortaya çıkarmak uzun zaman alabilir ve birçok test çalışması gerektirebilir. Bu SBOM’u güvenilir ve doğru hale getirmek için, uygulamanın mimarisi hakkında bilgi sahibi olmadan zor olabilecek bir uygulamanın her derin, karanlık köşesini keşfetmeniz gerekir.

Peki hangi SBOM türü size uygun?

Genel olarak konuşursak, Derleme veya Analiz Edilmiş Yazılım Malzeme Listesi, ekiplerin doğruluk ve verimliliğin kesişimine ulaşmasına yardımcı olur. SBOM’lar, uygulama bağımlılıklarındaki riski belirlemeye yardımcı olmak için yazılım bileşenlerini ortaya çıkarmayı amaçlamaktadır. Bu nedenle, doğruluk hem yazılımı geliştirenler hem de tüketiciler için çok önemlidir.

Derleme SBOM’ları genellikle yazılım oluşturucular için tercih edilen seçimdir. Her yapay sürümün yaşam döngüsü boyunca doğru SBOM’lar oluşturmak için SBOM oluşturmanın SDLC’ye doğrudan entegrasyonla otomatikleştirilmesine olanak tanırlar.

Analiz Yazılım Malzeme Listeleri, tüketiciye ne gönderdiklerine dair daha iyi ve daha rafine bir resim sağlamak için yazılımcılar tarafından da oluşturulabilir. Tüketiciler, kaynak veya yapı ayrıntılarına erişmeden uygulama kompozisyonunun güvenilir bir resmini elde etmek için kendi başlarına Analiz Edilmiş SBOM’lar oluşturabilir. Bu, geliştiricilerin ve tüketicilerin Analiz Edilmiş bir SBOM’un sonuçları üzerinde işbirliği yapabileceği ve gerekirse deltaları tartışabileceği anlamına gelir.

Derleme ve Analiz Edilen SBOM’lar ayrıca çoğu sektör gereksiniminin karşılanmasına yardımcı olur. Birleştirildiğinde, bu SBOM’lar açık kaynak bağımlılıklarını, özel kodu, temel görüntüleri, üretici yazılımını, işletim sistemlerini ve bir uygulamanın ihtiyaç duyabileceği tüm üçüncü taraf kitaplıklarını içerir. Bu SBOM türleri araç ve otomatik oluşturma gerektirdiğinden, bunların nasıl ve ne zaman oluşturulacağını özelleştirebilir, hangi alanların dahil edileceğini, hangi biçimlerin oluşturulacağını ve SBOM’nin ne zaman oluşturulacağını belirtebilirsiniz.

Gerçi ABD için geçerli ama, buna ek olarak, Derleme ve Analiz SBOM’ları, kamu sektörü dışında bile SBOM’lar için fiili standart haline gelen (ABD) Ulusal Telekomünikasyon ve Bilgi İdaresi’nin (NTIA) minimum SBOM gereksinimlerine uyumluluk da. Bu, bir yazılım üreticisiyseniz müşteri gereksinimlerini karşılayabileceğiniz anlamına gelir. Ve eğer bir yazılım tüketicisiyseniz, satıcılarınızın net gereksinimlerini tanımlamaya başlayabilir ve kendi yazılım tedarik zincirinizin kontrolünü oluşturmaya başlayabilirsiniz.

SBOM yönetimini kullanmaya başlamak

SBOM türlerini özetledikten sonra, şunu sorabilirsiniz: Hepsini nasıl yönetebilirim?

Değişik SBOM tiplerinin Yönetimi için iyi bir SCA (Software Composition Analysis – Yazılım Kompozisyon Analizi) aracından yardım alabilirsiniz. Kuruluşların SBOM üretimi ve tüketimi için birçok gereksinimi vardır ve bunların nasıl önceliklendirileceğini belirlemek zor olabilir. SBOM’lar, uygulama riskini belirlemeye ve yönetmeye yardımcı olmak için yazılım tedarik zinciri görünürlüğü sağladığından, bir SCA aracının işe alınması, görünürlük oluşturmanıza ve onu bu riskle eşleştirmenize yardımcı olabilir.

En kapsamlı SCA araçları, uygulamalardaki, kaynak kodundaki, dosyalardaki, derleme yapıtlarındaki, kapsayıcı görüntülerindeki, kitaplıklardaki, bellenimdeki ve daha fazlasındaki bağımlılıkları keşfedebilir. SCA esas olarak açık kaynak bağımlılıklarını tespit etmek için kullanılsa da, bazı araçlar ekiplerin özel veya ticari bağımlılıkları da geliştirmesine ve tanımasına olanak tanır. Bu analizin sonucu tam bir SBOM’dur.

SCA araçları ayrıca ekiplerin bağımlılıkları riske bağlamasını sağlamak için veri kaynakları sağlar, böylece üç temel risk değerlendirmesi için değerlendirilebilirler.

Güvenlik	Güvenlik açığı önem eşiklerini aşıyor mu? OWASP/SANS uyumluluğu ile uyumlu mu? Güvenlik açıklarının istismar edilebilirliği, düzeltilebilirliği ve erişilebilirliği nedir?
Uyumluluk	Her bir lisansın yükümlülükleri nelerdir? Son uygulamanın nasıl lisanslanacağıyla çelişen herhangi bir lisans var mı? Onaylanan veya yasaklanan listede herhangi bir lisans var mı?
Birleşen Sağlığı	Bileşenin aktif katkıda bulunanları var mı? Bileşenin güvenlik itibarı nedir? Bu, bileşenin en son sürümü mü?

Bir Süreç Oluşturmak

Bazı ülkelerde, yazılım ürünlerinin üretiminde ve tüketiminde güvenlik amacı ile bir SBOM sağlanması yükümlülüğü vardır. Bir Güvenlik ölçüsü olarak kullandığınız bir yazılımın içindeki komponentleri ve bunların güvenlik durumunu bilmek isteteyebilirsiniz. Bu manuel olarak yapılabilse de, SBOM oluşturmayı derleme sistemlerine dahil etmek ve her değişiklik veya yeni derlemeyle yeniden oluşturulan SBOM’ların alınmasını otomatikleştirmek için API’leri kullanmak en iyi uygulamadır. Bu, makine tarafından okunabilen SBOM’lar üretir ve bu da SBOM’ları bir SCA aracına geri aktarmayı mümkün kılar. Bu, güvenlik, lisans ve kalite riski için bağımlılıkları hızlı ve sürekli olarak değerlendirmenize olanak tanır.
Tabi, SBOM oluşturmayı yalnızca bir belge olarak değil, bir süreç olarak görmelisiniz. Herhangi bir SBOM, uygulama bileşenlerini listeleyecektir, ancak SBOM oluşturmayı bir yaklaşım olarak ele almak, dinamik tedarik zinciri görünürlüğü ve yukarı akış risk yönetimi sağlar.
SBOM’ları bir süreç olarak ele almak, şunları yapmanız gerektiği anlamına gelir:

• • Nelerin dahil edileceğine, bir SBOM’un ne sıklıkta oluşturulacağına ve SBOM yönetimi için hangi teknolojilerin kullanılacağına odaklanın.

• • SBOM’ları nasıl içe aktaracağınızı öğrenin. Bunlar, uygulama güvenliği duruşu yönetim araçlarına, SCA araçlarına ve hatta bir veritabanına, yani birden çok SBOM’yi bir araya getirmenize ve sonunda portföyünüzdeki tüm uygulamalar için bağımlılıkları riskle ilişkilendirmenize olanak tanıyan her şeye aktarılabilir.

• • Eyleme dönüştürülebilir SBOM tüketimi gerektir. Birçok kuruluş, yazılım satıcılarından SBOM’lar talep eder, ancak riski azaltmak için bunları değerlendiremez veya kullanamaz.

• • SBOM’lar için kendi gözetim zincirinizi atayın. Gözetim zinciri, bir ürünün yaşam döngüsünün ve yolculuğunun doğrulanabilir bir kopyası olarak hizmet veren bir sertifikasyon mekanizması oluşturur.

• • SBOM’ları önemli paydaşlarla güvenli bir şekilde paylaşın ve gözetim zinciri boyunca bütünlüklerini koruyun.

• • SBOM arama ve sorgulamayı etkinleştirin. Bu, bir sonraki ünlü güvenlik açığı manşetlere çıktığında maruz kalmanızı anlamanızı sağlar.

Forcerta Size Nasıl Yardım Edebilir?

SBOM üretimi ve yönetimi söz konusu olduğunda, “herkese uyan tek bir çözüm” bulmak mümkün olmayabilir. Farklı ekiplerin farklı SBOM ihtiyaçları olması doğaldır. Kafa karışıklığını önlemek bakımından, burada bahsedilen SBOM yönetim yaklaşımındaki temel yapı taşlarına odaklanarak doğru yönde ilerlemeye başlayabilir.

Forcerta olarak sunduğumuz Synopsys Black Duck SCA, SBOM yönetiminin temellerini karşılayan ve ekiplere ihtiyaç duydukları hızlı başlangıcı sağlayabilen bir dizi araç ve hizmet sunar. Synopsys Black Duck SCA, tek bir kullanıcı deneyimi içinde uygulama bağımlılıklarını tanımlar, birinci taraf SBOM’lar oluşturur, üçüncü taraf SBOM’ları içe aktarır, bağımlılık riskini ortaya çıkarır ve düzeltmeye rehberlik eder. Bu şekilde, yazılım üreticileri ve tüketiciler tedarik zinciri görünürlüğü sağlayabilir ve riski belirlemek ve azaltmak için adımlar atabilir.

Tabi şunu unutmamalı ki, SCA araçları çözümün yalnızca bir parçasıdır. Müşterilerimizin bir SBOM’u bir belgeden verimli bir sürece dönüştürmelerine yardımcı olmak için, bir müşterimizin benzersiz durumunu anlamak ve eksiksiz bir SBOM yönetim stratejisi oluşturmaya yardımcı olmak için uzmanlığımızı ve danışmanlık hizmetlerimizi sağlayabiliriz.

Kaynaklar:
1 – Synopsys – A Guide to CISA’s Six Types of SBOMs
2 – CISA – Types of Software Bill of Materials (SBOM)