Son güncelleme: 2026-11-02
“Satın alacağımız ürün için güncel bir yazılım bileşen envanteri (SBOM) paylaşır mısınız?”
Talep önce satış ekibine, ardından yazılım ekibine ulaşır. Birisi bağımlılık listesini dışa aktarır. Dosya müşteriye gönderilmeden önce yanıtlanması gereken daha yararlı bir soru vardır: Bu dosya tam olarak neyi tanımlıyor?
Küçük bir SaaS ekibi için pratik yanıt; belirli bir sürümle ilişkilendirilmiş, makine tarafından okunabilir bir SBOM ile kapsamını, bilinen eksiklerini ve güncelleme sürecini açıklayan kısa bir nottur. Güvenlik açığı soruları için bir iletişim kanalı da ekleyin. Paketi eksiksiz olarak sunmadan önce müşterinin gerekliliklerinden farklı kalan noktalar üzerinde mutabık kalın.
SBOM, müşterinin yazılımınızın bileşenlerini anlamasına yardımcı olur. Üründe hiçbir güvenlik açığı bulunmadığını kanıtlamaz.
Müşterinin kabul kriterleriyle başlayın. Hangi ürünü veya dağıtımı kastettiklerini, sistemlerinin hangi biçimi ve spesifikasyon sürümünü kabul ettiğini sorun. Yalnızca mevcut envanteri mi, sözleşme boyunca güncellemeleri mi, yoksa her ikisini mi beklediklerini öğrenin.
Sağlayıcının işlettiği SaaS hizmetlerinde “güncel” ifadesinin bir referans noktasına ihtiyacı vardır. Canlı ortamdaki dağıtım, dosyayı oluşturduğunuz tarih ile satın alma ekibinin incelediği tarih arasında değişebilir. Ekin her zaman güncel kalacağını taahhüt etmek yerine hangi sürümü ve dağıtımın hangi andaki durumunu kapsadığını belirtin.
SBOM talebini güvenlik açığı raporu, sızma testi raporu veya güvenlik soru formu taleplerinden de ayırın. Bunlar farklı sorulara yanıt verir. Müşteri “hiçbir güvenlik açığı olmadığını gösteren bir SBOM” istiyorsa bileşen bilgilerini ve ayrıca tarih belirtilmiş bir güvenlik açığı değerlendirmesini sunabileceğinizi açıklayın.
Yazılım ekibi kapsamı kontrol etmeden teslim tarihi taahhüt etmeyin. Önerilen kapsamı kısaca teyit etmek, gelişigüzel belirlenmiş bir son tarihe yetişmek için açıklamasız bir çıktı göndermekten daha yararlıdır.
Yazılım bileşen envanteri (Software Bill of Materials, SBOM), yazılım bileşenlerini ve aralarındaki ilişkileri yapılandırılmış biçimde kaydeder. İnsanların ve araçların ürünün içeriğini yorumlayabilmesi için bileşen kimliklerini, sürümlerini ve bunları destekleyen üst verileri içerebilir.
Bu envanter; güvenlik açığı inceleme, yama uygulama ve diğer operasyonel süreçlerde kullanıldığında yararlı bir güvenlik kanıtına dönüşür. Dosyanın oluşturulması, bu süreçlerin işlediğini tek başına göstermez.
Örneğin Syft bileşen envanterleri oluşturur; Grype ise bir SBOM’u bilinen güvenlik açığı bilgileriyle karşılaştırarak analiz edebilir. Taramanın eşleşme bulmaması; bilinmeyen güvenlik açıklarının, envanterde eksik kalan bileşenlerin veya analizin kapsamı dışındaki kusurların bulunmadığını göstermez.
Aşağıdaki iş akışı, satın alma taleplerine yanıt vermek için pratik bir yaklaşımdır. Her SaaS sağlayıcısının aynı yasal SBOM yükümlülüğüne tabi olduğu anlamına gelmez. Bu yazının dayandığı teknik rehber bağlayıcı olmayan öneriler sunar; sözleşme ve mevzuat gereklilikleri ayrıca değerlendirilmelidir.
Dağıtıma alınabilecek tek bir ürün veya hizmetle başlayın. Büyük bir SaaS platformunda bu; bir API konteyneri, arka plan işleyicisi veya tarayıcı uygulaması olabilir. Satın alma ekibi platformun tamamını istediyse ilk envanterin yalnızca bir bölümü kapsadığını açıklayın ve kalan bölümlerin nasıl teslim edileceği üzerinde anlaşın.
Sürüm veya derleme kimliğini ve varsa derleme çıktısının değişmez özet değerini (digest) kaydedin. Müşterinin gerçekten kullandığı yazılımı hangi envanterin tanımladığını belirleyebilmek için dağıtım eşleştirmesini kurum içinde saklayın.
Konteyner içinde çalışan bir API için kapsamın; uygulama paketlerini, bu paketlerin getirdiği dolaylı bağımlılıkları, programlama dilinin çalışma zamanını ve temel imajdaki işletim sistemi paketlerini içerip içermediğine karar verin. Tarayıcı için oluşturulan paketleri, yardımcı konteynerleri (sidecar) ve imaj oluşturulduktan sonra eklenen bileşenleri ayrıca kontrol edin. Tek bir imaj taramasının bunların tamamını kapsadığını varsaymayın.
Uzaktaki bir ödeme veya e-posta hizmeti için de sınır net olmalıdır. Sağlayıcının kendi yazılım bileşimini bilmeden entegrasyonu tanımlayabilirsiniz. Bu tür dış hizmet bağımlılıklarını ayrı olarak veya biçimin desteklediği hizmet alanlarında belgeleyin; envanterinizin dışında kalanları açıklayın.
Oluşturma yöntemi önemlidir. Syft, imajlar ve dizinler için farklı varsayılan kataloglayıcılar kullanır: İmaj taramaları kurulu paketlere odaklanırken dizin taramaları beyan edilen bağımlılıkları da toplayabilir. Bu nedenle bir kaynak kod deposunun taranması ile son imajın taranması aynı sonuçları vermek zorunda değildir.
Yalnızca derleme sırasında kullanılan bağımlılıklar da tedarik zinciri güvenliği açısından önemli olabilir. Müşteriye sunulan çalışma zamanı envanterinin dışındalarsa bunu belirtin ve kurum içinde uygun bir kayıt tutun.
Müşteriyle CycloneDX veya SPDX biçimi, spesifikasyon sürümü ve dosya kodlaması üzerinde anlaşın. Yalnızca “JSON” demek yeterli değildir: Müşterinin içe aktarma aracı, dosyanın içindeki şemayı anlayabilmelidir. En yeni spesifikasyonun her iki tarafın da desteklediği sürüm olduğunu varsaymayın.
Konteyner sunan bir ekip için Syft olası başlangıç araçlarından biridir. Konteyner imajlarını, dizinleri ve arşivleri destekler; CycloneDX ve SPDX çıktıları üretebilir. Varsayılan squashed imaj kapsamı, son dosya sistemini temsil eder. all-layers taraması ise sonradan silinmiş dosyalar dahil önceki katmanların içeriğini de kapsar. Kapsamı bilinçli seçin ve kaydedin.
Gerektiğinde derleme çıktısı taramasını, derleme sisteminden veya kullanılan ekosistemden elde edilen kanıtlarla destekleyin. Bir çalışma arkadaşınızın aynı süreci tekrarlayabilmesi için oluşturma aracının sürümünü sabitleyin; sürümü ve yapılandırmayı kaydedin.
Çalışma düzeni olarak, bağımlılık veya temel imaj güncellemeleri nedeniyle yeniden derlenenler dahil, dağıtıma aldığınız her sürüm için envanter oluşturun. Müşterilerin güncellemelere nasıl ulaşacağını ayrıca kararlaştırın: Erişimi kontrollü bir portal, sürüm bildirimi veya tanımlı başka bir kanal kullanabilirsiniz. “latest” adlı tek dosyanın üzerine yazmak yerine geçmiş sürümlerin kayıtlarını saklayın.
Yeni bir güvenlik açığı duyurusu, değişmemiş bir sürümün yeniden değerlendirilmesini gerektirebilir. Bu, bileşen envanterinin mutlaka değişmesi gerektiği anlamına gelmez. Yazılımdaki değişikliklerle yazılımın riskleri hakkındaki bilginizdeki değişiklikleri ayırt edin.
Yazılım ekibi lideri gibi hesap verebilir bir sorumlu belirleyin. Sürüm mühendisliği ekibi oluşturma işlemini yürütebilir, güvenlik ekibi bulguları inceleyebilir, müşteri sorumlusu teslimatı koordine edebilir. Ancak paketin üzerinde anlaşılmış ürünü tanımladığını teyit etmekten yine adı belirlenmiş bir kişi sorumlu olmalıdır.
Sözdizimini ve içeriği ayrı ayrı kontrol edin. Şema doğrulamasından geçen bir dosya yine de yanlış derlemeyi tanımlıyor olabilir. Seçili bileşenleri derleme kayıtlarıyla ve dağıtıma alınan çıktıyla karşılaştırın. Eksik sürümleri, beklenmeyen bileşenleri ve eksik ilişkileri inceleyin.
Bilinmeyen bir bilgiyi, “yok” anlamına gelebilecek boş bir alana dönüştürmeyin. Sınırlamayı, kapsama etkisini ve konuyu kimin inceleyeceğini kaydedin.
Aşağıdaki örnek, insanların okuyabileceği bir açıklamadır; eksiksiz veya şemaya uygun bir SBOM değildir. Ürün, kuruluş ve bileşen adlarının tamamı kurgusaldır; hiçbiri Kooch’u veya bir müşterisini temsil etmez.
pkg:generic/example-request-parser@3.2.1.Gerçek bir teslimatta oluşturma aracını ve sürümünü, yapılandırmayı, doğrulama sonucunu ve mevcut bileşen özet değerlerini de kaydedin. Çıktıyı eksiksiz göstermek için eksik üst verileri uydurmayın.
Hem bilgilere kimlerin erişebileceğine hem de ne kadar ayrıntı göreceklerine karar verin. Bunlar ayrı kararlardır.
Tam ayrıntı: Üzerinde anlaşılan, makine tarafından okunabilir envanteri sunun; uygunsa erişimi sınırlandırın. Tam bir SBOM’un herkese açık olarak indirilebilir olması gerekmez.
Sınırlı ayrıntı: Bilgi açıklama kısıtlamalarının gerekçelendirdiği ve müşterinin kabul ettiği durumlarda kapsamı azaltılmış bir envanter sunun. Çıkarılan bilgileri ve bunun sonuçlarını belirtin. Sürümleri veya bağımlılıkları açıklamadan kaldırmayın; filtrelenmiş bir belgeyi eksiksiz olarak sunmayın.
Yalnızca özet: İlk inceleme aşamasında kapsamı, kapsama düzeyini ve yanıt sürecinizi açıklayan bir özet sunabilirsiniz. Özet görüşmeyi destekleyebilir; ancak satın alma ekibi kabul etmedikçe talep edilen makine tarafından okunabilir SBOM’un yerini tutmaz.
Asıl belgeyi kurum içinde saklayın. Düzenlenmiş her çıktıya ayrı bir kimlik verin ve yeniden doğrulayın; kayıtları kaldırmak bozuk referanslara yol açabilir.
Birbirinden ayrı üç lisans konusu vardır: Oluşturma aracının lisansı, belirlediği bileşenlerin lisansları ve SBOM verilerine uygulanan koşullar. Syft’in kendisi Apache-2.0 lisanslıdır. Bu bilgi, her bağımlılığın lisansına uygun kullanılıp kullanılmadığını veya envanterin hangi gizlilik koşullarıyla paylaşılması gerektiğini açıklamaz.
Burada biçime ilişkin somut bir ayrıntı önem taşır. SPDX 2.3 serisi spesifikasyonu, SPDX üst verileri için CC0-1.0 şartını getirir; Syft’in belgelenmiş SPDX çıktısında da bu veri lisansı değeri bulunur. Spesifikasyon, belirli SPDX belge koleksiyonlarının açıklanmasına ve bu belgelerin tedarikçilerinin kimliğinin belirtilmesine ilişkin sözleşmesel kısıtlamaları da açıkça kabul eder. Bu nedenle üst veri lisanslaması, envanteri herkese açık yayımlama yükümlülüğüyle karıştırılmamalıdır.
Gizliliğin önem taşıdığı durumlarda önerilen paylaşım koşullarını, kullanılan gerçek biçim, çıktı ve tedarikçi kısıtlamalarıyla birlikte yetkin bir hukuk danışmanına inceletin. Bulut tabanlı tarama veya SBOM platformlarında hangi bilgilerin yüklendiğini, kimlerin erişebildiğini, saklama koşullarını ve müşteriyle paylaşım haklarını da kontrol edin. Bunlar seçilen hizmete ve sözleşmeye bağlıdır.
Müşteriye SBOM’daki bir tutarsızlığı veya güvenlik açığı endişesini bildirebileceği, düzenli takip edilen bir iletişim adresi ya da portal sunun. İlk değerlendirmeyi kimin yapacağını, acil konuların nasıl üst sorumlulara aktarılacağını ve bir sonraki bilgilendirmenin nasıl yapılacağını açıklayın. Yalnızca ekibinizin karşılayabileceği yanıt sürelerini taahhüt edin.
Güvenlik açığı sonuçları paylaşıyorsanız tarihlerini, tarama aracını, kullanılan veri tabanının hangi andaki sürümünü esas aldığınızı ve kapsam dışı bırakılan veya sonuçlarda bastırılan bulguları belirtin. Grype mevcut bir SBOM’u tarayabilir; sonuçları kullanılan envantere ve güvenlik açığı bilgilerine bağlıdır.
Müşteri bir bileşene dikkat çektiğinde, sonuca varmadan önce ilgili ürün sürümünü ve dağıtımı değerlendirin. Desteklendiği durumlarda Vulnerability Exploitability eXchange (VEX), yani güvenlik açıklarının istismar edilebilirliğine ilişkin bilgi paylaşımı, ürüne özgü durumu ve gerekçesini iletmek için kullanılabilir. “Etkilenmiyor” sonucunun kanıtla desteklenmesi gerekir; yalnızca bulgu sayısını azaltmak için uygulanacak bir etiket değildir.
Bir konu incelenirken sorumluluğun kimde olduğu açık kalsın. Henüz giderim tarihi belli olmasa bile müşteri bir sonraki bilgilendirmeyi ne zaman bekleyebileceğini bilmelidir.
Olay sinyalleri için de aynı operasyonel soru geçerlidir: Kim alır, kim harekete geçer? Beş veri ihlali tespit yolu başlıklı yazımız, bu bildirim kanallarının neden önemli olduğunu ele alıyor.
İlk satın alma yanıtı için bu pratik kontrol listesini müşterinin gereklilikleriyle birlikte kullanın. Liste, sözleşme veya mevzuatla belirlenmiş bir SBOM profilinin yerini tutmaz.
Oluşturma günlüklerini, yapılandırmayı, doğrulama kanıtlarını ve ayrıntılı inceleme kayıtlarını kurum içinde saklayın; üzerinde anlaşıldığında ve uygun olduğunda ek kanıt paylaşın.
Bir sonraki adımınız, satın alma ekibine yanıt vermeden önce tek bir sorumlu atamak ve dağıtıma alınabilecek tek bir ürünün envanterini çıkarmaktır. Ardından tam olarak ne sunabileceğinizi, kapsam dışında nelerin kaldığını ve envanteri nasıl yararlı tutacağınızı açıklayın.
Bu talep güvenlik sorumlulukları ve kanıtlar konusunda daha geniş eksikleri ortaya çıkarıyorsa Kooch’un ISO 27001 hazırlık ve BGYS desteğini inceleyin. Ekibinizin düzenlemesi gereken süreç ve kanıtları görüşmek için Kooch ile iletişime geçin.
Kaynakların incelendiği tarih: 2026-11-02.
