SBOM: yazılım malzeme listesi

Pazartesi sabahı yaygın bir sıkıştırma kütüphanesinde kritik bir açık duyurulur. Altay Kargo'nun kırk servisi, üç mobil uygulaması ve onlarca konteyner imajı var.

Yönetim tek bir soru sorar: bu kütüphane hangi ürünlerimizde var? Malzeme listesi olmayan ekip her depoyu tek tek tarar, imajları yeniden indirir ve cevabı günler sonra verir. SBOM (Software Bill of Materials, yazılım malzeme listesi) tutan ekip aynı soruyu tek bir sorguyla, birkaç dakikada cevaplar.

SBOM, bir yazılım sürümünün içindeki her bileşeni adı, sürümü, kimliği ve bağımlılık ilişkisiyle kaydeden makinece okunur bir belgedir. Bu derste SBOM'un hangi alanları taşıması gerektiğini, iki baskın formatı ve paket kimliğini öğrenirsin. Sonra syft ile SBOM üretir, grype ve jq ile okur, VEX ile etkilenmezliği kaydedersin.

Bir SBOM'un en az hangi bilgiyi taşıması gerektiği ortak bir belgede tanımlıdır. İlk sürümü 2021'de ABD Ulusal Telekomünikasyon ve Bilgi İdaresi (NTIA) yayımladı. Temmuz 2026'da CISA, NSA, FBI ve on beş uluslararası kurum belgeyi güncelledi ve 2021 sürümünün yerine koydu. Belge iki grup veri alanı tanımlar.

Bileşen verisi her parçayı anlatır: bileşen adı, sürümü, üreticisi, tanımlayıcıları, bağımlılık ilişkisi, özet değeri ve özet algoritması, lisansı. SBOM üst verisi ise belgenin kendisini anlatır: yazarı, yazar imzası, zaman damgası, üretim aracı ve sürümü, veri formatı ve sürümü, üretim bağlamı ve SBOM sürümü. Özet, lisans, yazar imzası ve araç bilgisi 2026'da eklenen alanlar arasındadır.

Veri alanlarının yanında uygulama beklentileri de vardır. Kapsam (coverage) ilkesine göre SBOM, dolaylı bağımlılıklar dahil bütün bileşenleri listeler ve asgari bir derinlik sınırı yoktur. Amaç şudur: SBOM'da adı geçmeyen bir bileşen için yeni bir duyuru gelirse, okuyan kişi rahatça 'bizi etkilemiyor' diyebilmelidir.

Sıklık (frequency) ilkesi, her yeni derleme ve sürüm için yeni bir SBOM ister. Eksik bilgi de açıkça yazılır. Boş bir alan 'yok' anlamına gelmez; yazar o bilginin bilinmediğini ya da paylaşılmadığını belirtir.

SBOM yalnız güvenlik ekibine yaramaz. Hukuk ekibi lisansı, satın alma ekibi tedarikçi riskini aynı belgeden okur. Olay ekibi de etkilenen ürünü buradan bulur.

Asgari öğeler belirli bir dosya biçimi dayatmaz, ama yaygın kullanılan iki format vardır. CycloneDX, OWASP topluluğunun projesidir ve güvenlik kullanımını öne alır. Ecma International onu ECMA-424 adıyla standartlaştırdı.

Güncel sürümü 1.7'dir; JSON, XML ya da Protocol Buffers ile yazılır. SPDX, Linux Foundation projesidir ve lisans uyumu ihtiyacından doğdu.

2.2.1 sürümü ISO/IEC 5962:2021 standardıdır, güncel sürüm 3.0.1'dir. İki format da aynı temel soruları cevaplar. Seçim çoğu zaman alıcının ve araç zincirinin beklentisine göre yapılır. Bazı ekipler ikisini birden üretir; aynı derleme adımı iki dosyayı yan yana yazabilir.

Bileşeni farklı araçlar arasında eşleştirmek için ortak bir kimlik gerekir. PURL (Package URL) bu kimliktir ve Ecma'da ECMA-427 numarasıyla standartlaştı. Genel biçimi pkg:tür/ad-alanı/ad@sürüm?niteleyiciler#alt-yol şeklindedir. pkg şemadır ve hep aynıdır.

Tür ekosistemi söyler: npm, pypi, maven, deb, oci. Ad alanı, npm'de kapsam adı, Maven'da grup kimliğidir. Ad ve sürüm paketi tam olarak belirler. Niteleyiciler mimari ya da depo adresi gibi ek bilgileri taşır.

pkg:npm/[email protected] bir npm paketidir, pkg:pypi/[email protected] bir Python paketidir. npm kapsamının başındaki @ işareti PURL içinde hep %40 olarak kodlanır. Açık veritabanları paketi bu kimlikle aradığı için PURL eksikse eşleştirme sessizce bozulur.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "metadata": {
    "timestamp": "2026-10-01T09:14:02+03:00",
    "tools": { "components": [ { "name": "syft", "version": "1.52.0" } ] }
  },
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.20",
      "purl": "pkg:npm/[email protected]",
      "licenses": [ { "license": { "id": "MIT" } } ]
    }
  ],
  "dependencies": [
    { "ref": "pkg:npm/[email protected]", "dependsOn": [ "pkg:npm/[email protected]" ] }
  ]
}

Belgeyi yukarıdan oku. bomFormat ve specVersion, veri formatını ve sürümünü verir. metadata altındaki timestamp üretim zamanını, tools ise üretim aracını ve sürümünü kaydeder.

components dizisindeki her nesne bir bileşendir. type, name, version, purl ve licenses alanları bileşen verisinin büyük bölümünü karşılar. dependencies dizisi ilişkiyi kurar; rapor-sablon'un lodash'a bağımlı olduğu burada yazar.

Şimdi eksikleri bul. Bileşende hashes alanı yoktur, çünkü syft kilit dosyasını okudu ve paket arşivini görmedi. SBOM yazarı alanı da yoktur. 2026 asgari öğelerine göre bu iki alan ya doldurulur ya da açıkça bilinmiyor diye işaretlenir.

SBOM elle yazılmaz. Bir araç kaynak klasörünü, derlenmiş yapıyı ya da konteyner imajını inceler ve listeyi çıkarır. Yaygın araçlardan biri syft'tir; trivy ve cdxgen de aynı işi yapar. syft aynı taramadan birden fazla format üretebilir.

Her -o bayrağı bir format ve bir dosya adı alır. Altay Kargo'nun derleme hattındaki SBOM adımı iki taramadan oluşur. Biri kaynak klasörünü, öbürü yayımlanacak imajı tarar. Ardından jq ile dosyanın üretim zamanı ve bileşen sayısı hızlıca kontrol edilir.

$ syft scan dir:./iade-servisi \
    -o cyclonedx-json=sbom.cdx.json \
    -o spdx-json=sbom.spdx.json
$ syft scan kayit.altaykargo.example/iade-servisi:1.4.2 \
    -o cyclonedx-json=iade-imaj.cdx.json
$ jq -r '.metadata.timestamp, (.components | length)' iade-imaj.cdx.json
2026-10-01T09:16:40+03:00
187

Komutları sırayla oku. İlk komut kaynak klasörünü tarar ve iki dosya yazar: CycloneDX ve SPDX.

İkinci komut imajı kayıt sunucusundan çeker ve katmanlarındaki paketleri listeler. Son komut jq ile üretim zamanını ve bileşen sayısını yazar. İki SBOM aynı şeyi anlatmaz. Kaynaktan üretilen liste derleme öncesini, imajdan üretilen liste derleme sonrasını yansıtır.

İmajda temel imajın işletim sistemi paketleri de vardır, kaynakta yoktur. 2026 asgari öğeleri bu farkı üretim bağlamı (generation context) alanıyla kaydetmeni ister: derleme öncesi, derleme ya da derleme sonrası. Müşteriye ya da olay ekibine verdiğin SBOM, gerçekten çalışan yapıyı anlatmalıdır.

Üretim her derlemede çalışmalıdır. SBOM adımı derleme hattına eklenir, çıktı sürümle birlikte saklanır ve sürüm numarasıyla bulunur. Yeni bir duyuru geldiğinde yalnız bugünkü sürümü değil, sahada çalışan eski sürümleri de sorgularsın. Bu yüzden yayımlanan her sürümün SBOM'u silinmeden arşivlenir.

SBOM sürümü alanı da burada işe yarar. Aynı yazılım sürümü için SBOM düzeltilirse belge sürümü artar, yazılım sürümü aynı kalır. Elle ve yılda bir üretilen liste ara sürümlerdeki değişiklikleri kaçırır. Üstelik ekibe 'listemiz var' diye yanlış bir güven verir.

SBOM'u alan taraf onu açık veritabanıyla eşleştirir. grype, SBOM dosyasını sbom: önekiyle okur ve kaynağa ya da imaja yeniden dokunmadan tarar. Altay Kargo'nun iade servisi için üretilen SBOM şu raporu verir.

Satırlar varsayılan olarak RISK sütununa göre sıralanır. --fail-on high bayrağı eklenirse komut, bu eşikte ya da üstünde bir bulgu olduğunda 2 çıkış koduyla biter. Derleme hattı böylece açıklı bir sürümü kendiliğinden durdurur.

$ grype sbom:./sbom.cdx.json
NAME    INSTALLED  FIXED IN  TYPE  VULNERABILITY        SEVERITY  EPSS          RISK
lodash  4.17.20    4.17.21   npm   GHSA-35jh-r3h4-6jhm  High      21.3% (97th)  15.7
lodash  4.17.20    4.17.21   npm   GHSA-29mw-wpgm-hmr9  Medium    7.3% (94th)   3.8
lodash  4.17.20    4.18.0    npm   GHSA-r5fr-rjxr-66jc  High      2.6% (84th)   2.0
lodash  4.17.20    4.17.23   npm   GHSA-xxjr-mmjv-4gpg  Medium    1.8% (78th)   1.1
lodash  4.17.20    4.18.0    npm   GHSA-f23m-r3pf-42rh  Medium    0.4% (29th)   0.2

$ jq -r '.components[] | select(.name=="xz") | "\(input_filename) \(.version)"' arsiv/*/iade-imaj.cdx.json
arsiv/1.4.1/iade-imaj.cdx.json 5.4.5
arsiv/1.4.2/iade-imaj.cdx.json 5.4.5

Sütunları oku. NAME ve INSTALLED bileşeni ve kurulu sürümü verir. FIXED IN açığı kapatan sürümdür, TYPE ekosistemi söyler. VULNERABILITY kayıt kimliği, SEVERITY önem derecesidir.

EPSS sütunu istismar olasılığını, parantez içinde de yüzdelik dilimi gösterir. RISK, grype'ın istismar olasılığını ve etkiyi birleştirdiği bir sıralama puanıdır. İlk satırdaki komut enjeksiyonu hem yüksek önemli hem en olası açıktır. Alttaki jq komutu başka bir işe yarar.

Yeni bir xz duyurusu geldiğinde hiçbir şeyi yeniden taramazsın. Arşivdeki bütün imaj SBOM'larında xz bileşenini arar, dosya adıyla birlikte kurulu sürümü yazdırırsın. Her satır bir sürümün cevabıdır: sahadaki iki sürümde de xz 5.4.5 var.

Her eşleşme gerçek bir risk değildir. Altay Kargo'nun kodu _.template fonksiyonunu hiç çağırmıyorsa ilk satırdaki açık iade servisini etkilemez. Bu kararı yalnız bir toplantı notunda tutarsan sonraki taramada bulgu yeniden açılır.

VEX belgesi kararı makinece okunur hâle getirir. OpenVEX ve CISA'nın tanımladığı dört durum vardır: not_affected (etkilenmiyor), affected (etkileniyor), fixed (düzeltildi) ve under_investigation (inceleniyor). not_affected durumu bir gerekçe ister.

Örneğin vulnerable_code_not_in_execute_path, açıklı kodun çalışma yolunda olmadığını söyler. CycloneDX aynı bilgiyi analysis alanında not_affected, exploitable, in_triage ve resolved gibi durumlarla taşır. grype, --vex bayrağıyla verilen belgeyi okur ve etkilenmeyen bulguyu sonuçtan ayırır.

Bir SBOM yalnız doğru olduğu kadar işe yarar. En sık hata, kaynak klasöründen üretilen SBOM'u imajın SBOM'u gibi dağıtmaktır. Kaynak listesi temel imajın işletim sistemi paketlerini, örneğin xz ya da openssl'i, hiç görmez. İkinci hata yalnız doğrudan bağımlılıkları yazmaktır; kapsam ilkesi dolaylı katmanı da ister.

Üçüncü hata zaman damgasını ve yazar alanını boş bırakmaktır. Alıcı listeyi kimin ne zaman ürettiğini bilmezse ona güvenemez. SBOM'un kendisi de değiştirilebilir bir dosyadır. Asgari öğelere yazar imzası alanı bu yüzden eklendi.

Yaygın yöntem, SBOM'u imajın imzalı bir kanıtı (attestation) olarak yayımlamaktır. cosign attest komutu SBOM'u imaj özetine bağlar ve imzalar. Alıcı da cosign verify-attestation ile hem imzayı hem bağı doğrular.

Düzenleyiciler de SBOM'u artık doğrudan ister. AB Siber Dayanıklılık Yasası (Cyber Resilience Act, Tüzük 2024/2847) 10 Aralık 2024'te yürürlüğe girdi. Yasa, dijital öğe içeren ürünlerin üreticisinden bir SBOM hazırlamasını ve bunu teknik belgenin parçası olarak tutmasını ister. Aktif istismar edilen açıkları ve ciddi olayları bildirme yükümlülüğü 11 Eylül 2026'da başladı.

Ana yükümlülükler 11 Aralık 2027'de uygulanmaya başlar. Bildirim süreleri kısadır ve hangi ürününün etkilendiğini bilmeyen üretici zamanında bildirim yapamaz. AB pazarına ürün satan Türk yazılım şirketi de bu takvime uyar. Bileşen envanteri, bu yükümlülüklerin ön koşuludur.