SBOM Nedir? Syft ve CycloneDX ile SBOM Üretme Rehberi
Aziz Özdemiroğlu
Yeni bir açık duyurulduğunda ilk soru hep aynıdır: "Biz bunu kullanıyor muyuz?" Yazılım malzeme listesi (SBOM, Software Bill of Materials), bu soruya dakikalar içinde cevap vermenizi sağlayan, yazılımınızdaki tüm bileşenlerin makinece okunabilir envanteridir. Bu rehberde SBOM'un ne olduğunu, SPDX ile CycloneDX formatları arasındaki farkı, Syft ile nasıl üretileceğini ve CI/CD hattına nasıl entegre edileceğini uygulamalı olarak anlatıyoruz.
Kısaca
- SBOM, bir yazılımın içerdiği tüm paketlerin (doğrudan ve dolaylı) adını, sürümünü, lisansını ve kaynağını listeleyen standart bir belgedir.
- İki baskın format var: SPDX (Linux Foundation, ISO/IEC 5962) ve CycloneDX (OWASP, Ecma-424).
- Syft ile kaynak dizinden veya container imajından tek komutla SBOM üretilir. Grype veya Trivy ile aynı SBOM açık taramasında kullanılır.
- SBOM'u her sürümde üretip artefakt olarak saklarsanız, yeni bir CVE çıktığında etkilenen sürümleri geriye dönük bulabilirsiniz.
- AB Siber Dayanıklılık Yasası (Cyber Resilience Act) gibi düzenlemeler, dijital ürün üreticilerinden SBOM tutmalarını bekliyor.
SBOM neden gerekli?
Modern bir uygulamanın kodunun büyük çoğunluğu açık kaynak bağımlılıklardan oluşur. Doğrudan eklediğiniz 30 paket, dolaylı bağımlılıklarla yüzlerce pakete dönüşebilir. SBOM olmadan:
- Log4Shell gibi bir açıkta "hangi servislerimiz etkileniyor?" sorusu günlerce sürebilir.
- Lisans uyumluluğu (GPL bileşeni ticari üründe mi?) belirsiz kalır.
- Müşterilerinize veya denetçilere tedarik zinciri şeffaflığı sunamazsınız.
Formatlar: SPDX ve CycloneDX
| SPDX | CycloneDX | |
|---|---|---|
| Sahibi | Linux Foundation | OWASP |
| Standart | ISO/IEC 5962:2021 | Ecma-424 |
| Güçlü yanı | Lisans ve hukuki uyumluluk ayrıntısı | Güvenlik kullanım senaryoları, VEX, hizmetler, ML-BOM |
| Dosya biçimleri | JSON, YAML, RDF, tag-value | JSON, XML, Protobuf |
| Yaygın kullanım | Lisans denetimi, Linux dağıtımları | Güvenlik açığı yönetimi, uygulama güvenliği araçları |
Pratik öneri: Güvenlik odaklıysanız CycloneDX JSON ile başlayın. Müşteriniz SPDX istiyorsa Syft ikisini de aynı anda üretebilir.
SBOM'da neler bulunur?
Minimum bir SBOM kaydı en az şunları içermelidir:
- Bileşen adı ve sürümü
- Benzersiz tanımlayıcı: PURL (Package URL, ör.
pkg:npm/[email protected]) ve/veya CPE - Tedarikçi / yayıncı
- Bileşenler arası bağımlılık ilişkisi
- SBOM'u üreten araç ve oluşturulma zamanı
- Mümkünse lisans ve kriptografik özet (hash)
{
"type": "library",
"name": "lodash",
"version": "4.17.21",
"purl": "pkg:npm/[email protected]",
"licenses": [{ "license": { "id": "MIT" } }]
}
Syft ile SBOM üretmek
Kurulum
# Linux/macOS
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
# veya Homebrew
brew install syft
Betiği borulamadan önce içeriğini okumak iyi bir alışkanlıktır. Alternatif olarak GitHub sürümlerinden imzalı ikili dosyayı indirip doğrulayabilirsiniz.
Kaynak dizinden
syft dir:. -o cyclonedx-json=sbom.cdx.json
Container imajından (önerilen)
İmaj SBOM'u, gerçekten dağıtılan içeriği yansıtır. İşletim sistemi paketleri (apk, deb, rpm) de dahildir:
syft ghcr.io/ornek/uygulama:1.4.2 \
-o cyclonedx-json=sbom.cdx.json \
-o spdx-json=sbom.spdx.json
Hızlı inceleme
syft ghcr.io/ornek/uygulama:1.4.2 -o table | head -20
jq '.components | length' sbom.cdx.json # bileşen sayısı
jq -r '.components[] | select(.name=="openssl") | .version' sbom.cdx.json
SBOM ile açık taraması
# Grype, imajı yeniden taramadan doğrudan SBOM üzerinden çalışır
grype sbom:./sbom.cdx.json --fail-on high
# Trivy de SBOM okuyabilir
trivy sbom sbom.cdx.json --severity HIGH,CRITICAL
Bu ayrımın önemi şu: SBOM'u bir kez üretip saklarsınız, açık veritabanı her gün güncellenir. Aynı SBOM'u yarın yeniden tararsanız bugün bilinmeyen açıkları da yakalarsınız.
CI/CD entegrasyonu (GitHub Actions)
name: sbom
on:
push:
tags: ["v*"]
permissions:
contents: write # sürüme dosya eklemek için
jobs:
sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@<SHA> # v5
with: { persist-credentials: false }
- name: İmajı derle
run: docker build -t uygulama:${{ github.ref_name }} .
- name: SBOM üret
uses: anchore/sbom-action@<SHA> # v0
with:
image: uygulama:${{ github.ref_name }}
format: cyclonedx-json
output-file: sbom.cdx.json
- name: Açık taraması
uses: anchore/scan-action@<SHA> # v6
with:
sbom: sbom.cdx.json
fail-build: true
severity-cutoff: high
- name: SBOM'u sürüme ekle
env:
GH_TOKEN: ${{ github.token }}
run: gh release upload "${{ github.ref_name }}" sbom.cdx.json --clobber
SBOM'u imaja iliştirmek ve imzalamak
SBOM'un imajla birlikte taşınması, alıcının doğruluğundan emin olması için önemlidir. Sigstore cosign ile SBOM'u imaja bir tasdik (attestation) olarak ekleyebilirsiniz:
cosign attest --predicate sbom.cdx.json --type cyclonedx ghcr.io/ornek/uygulama:1.4.2
cosign verify-attestation --type cyclonedx \
--certificate-identity-regexp 'https://github.com/ornek/.*' \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
ghcr.io/ornek/uygulama:1.4.2
VEX: "Açık var ama bizi etkilemiyor"
Tarayıcılar çoğu zaman, açıklı fonksiyonun hiç çağrılmadığı bileşenler için de alarm üretir. VEX (Vulnerability Exploitability eXchange) belgeleri, bir CVE'nin ürününüzü etkileyip etkilemediğini gerekçesiyle belirtmenizi sağlar (not_affected, affected, fixed, under_investigation). CycloneDX VEX'i doğrudan destekler. OpenVEX de yaygın bir alternatiftir. Bu belgeler gürültüyü azaltır ve müşterilerinize net bilgi verir.
Uygulamalı senaryo: yeni bir CVE çıktı, etkileniyor muyuz?
Diyelim ki sabah, yaygın kullanılan bir sıkıştırma kütüphanesinde kritik bir açık duyuruldu ve 1.4.0 ile 1.4.6 arası sürümler etkileniyor. Elinizde son 20 sürümün SBOM'ları bir klasörde (veya artefakt deposunda) duruyorsa:
# Tüm SBOM'larda paketi ve sürümünü listele
for f in sboms/*.cdx.json; do
jq -r --arg f "$f" '.components[]? | select(.name=="ornek-sikistirma") | "\($f)\t\(.version)"' "$f"
done | sort -V -k2
Çıktı size hangi sürümünüzün hangi kütüphane sürümünü içerdiğini saniyeler içinde gösterir. Ardından:
- Etkilenen sürümlerden hangilerinin hâlâ üretimde çalıştığını dağıtım kayıtlarınızla eşleştirin.
- Kütüphaneyi güncelleyip yeni bir sürüm çıkarın ve yeni SBOM'un düzeltilmiş sürümü içerdiğini doğrulayın.
- Açığın ürününüzü gerçekten etkilemediğini analizle gösterebiliyorsanız (ör. açıklı fonksiyon hiç çağrılmıyor), bunu bir VEX kaydıyla belgeleyin ve müşterilerinizle paylaşın.
SBOM'u olmayan bir ekip aynı soruyu cevaplamak için her depoyu tek tek klonlayıp kilit dosyalarını incelemek, container imajlarını tek tek taramak zorunda kalır.
SBOM'ları nerede saklamalı?
| Seçenek | Artı | Eksi |
|---|---|---|
| Git sürümüne (release) ek dosya | Basit, sürümle birlikte | Merkezi sorgulama zor |
| OCI kayıt defterinde imaj tasdiki | İmajla birlikte taşınır, imzalanabilir | Sorgulamak için araç gerekir |
| Dependency-Track gibi SBOM platformu | Merkezi pano, sürekli açık takibi, politika kontrolleri | Ek bir servis işletmek gerekir |
Birden fazla ürün veya ekip varsa OWASP Dependency-Track gibi bir platforma SBOM'ları otomatik yüklemek, "etkileniyor muyuz?" sorusunu bir arama kutusuna indirger.
SBOM programı kontrol listesi
- Her sürüm etiketi için otomatik SBOM üretiliyor (imaj tabanlı)
- SBOM'lar sürümle birlikte saklanıyor (release, artefakt deposu veya OCI tasdiki)
- SBOM'lar günlük olarak güncel açık veritabanına karşı yeniden taranıyor
- Kritik bulgular build'i durduruyor, bilinçli istisnalar VEX ile belgeleniyor
- Lisans politikası (ör. "AGPL yok") otomatik kontrol ediliyor
- Yeni bir CVE çıktığında "hangi sürümlerimiz etkileniyor?" sorusu tek sorguyla cevaplanabiliyor
Sonuç
SBOM, tedarik zinciri güvenliğinin "envanter" adımıdır. Envanteriniz yoksa koruyamazsınız. Syft ile ilk SBOM'unuzu üretmek beş dakika sürer. Asıl değer ise onu her sürümde otomatik üretip saklamaktan ve düzenli taramaktan gelir. Bir sonraki büyük açık duyurusunda "etkileniyor muyuz?" sorusuna günler yerine dakikalar içinde cevap verebilirsiniz.
