GitLab CI'de Trivy Kullanarak SBOM JSON ve Konteyner CVE Taraması

Ortamımda, SBOM üretimini uyumluluk kontrolü olarak değil, bağımlılık yönetimi için canlı bir veri kaynağı olarak görüyorum. GitLab CI içinde Trivy kullanarak derleme aşamasında SBOM JSON'u üretiyorum ve aynı çıktıyı sonraki aşamalarda CVE taraması ve politika kararları için kullanıyorum. Bu şekilde tarama işlemlerini tekrarlamıyorum ve SBOM'u tek gerçeklik kaynağı olarak tutuyorum.

SBOM JSON'nin Tarama Ötesindeki Önemi

Trivy'yi sadece CVE listeleri için çalıştırdım, fakat gerçek değer SPDX veya CycloneDX JSON formatında SBOM yakalamaya başladığım zaman ortaya çıktı. Bu dosya bir envanter haline gelir: Onaylanmış bağımlılık listeleriyle karşılaştırabilirim, beklenmeyen geçici kütüphaneleri tespit edebilirim veya sürüm politikalarını zorunlu kılan iç araçlara besleyebilirim. Bir durumda, bir temel imaj güncellemesi tarafından getirilen kullanımdan kaldırılmış bir günlükleme kütüphanesini yakaladı — bu kütüphane henüz bilinen bir güvenlik açığı içermediği için CVE taraması onu kaçırdı.

GitLab CI Kurulumu: Derleme, SBOM, Ardından Tarama

Burada .gitlab-ci.yml dosyamın akışını nasıl yapılandırdığım gösterilmiştir:

stages:
  - build
  - sbom
  - scan

variables:
  TRIVY_FORMAT: "spdx-json"
  SBOM_ARTIFACT: "sbom-${CI_COMMIT_SHORT_SHA}.spdx.json"

build_app:
  stage: build
  image: docker:24.0.5
  services:
    - docker:24.0.5-dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

generate_sbom:
  stage: sbom
  image: aquasec/trivy:latest
  script:
    - trivy image --format $TRIVY_FORMAT --output $SBOM_ARTIFACT $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    paths:
      - $SBOM_ARTIFACT
    expire_in: 1 hour

scan_vulns:
  stage: scan
  image: aquasec/trivy:latest
  dependencies:
    - generate_sbom
  script:
    - trivy image --format table --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  allow_failure: false

policy_check:
  stage: scan
  image: python:3.11-slim
  dependencies:
    - generate_sbom
  script:
    - pip install jq
    - |
      COUNT=$(jq '.packages | length' $SBOM_ARTIFACT)
      if [ $COUNT -gt 50 ]; then
        echo "Too many dependencies: $COUNT"
        exit 1
      fi

SBOM artefaktu, sbom aşamasından hem scan hem de policy_check aşamalarına akar. Bu sayede görüntüyü iki kez çekmek veya envanteri yeniden üretmek zorunda kalmıyorum — sadece JSON'u yeniden kullanıyorum.

SBOM JSON'ı Bağımlılık Yönetimi İçin Kullanma

SBOM'u elde ettikten sonra, onu bir bildirim gibi ele alırım. Yukarıdaki policy_check aşamasında, bağımlılık yayılımını sınırlamak için paketleri sayarım. Ayrıca şu amaçlarla da kullanırım:

• İzin verilen kütüphanelerin beyaz listesiyle karşılaştırma (paket adlarını ve sürümlerini çıkarmak için jq kullanılır)
• Bir temel imajın önceki SBOM'da olmayan yeni paketler getirip getirmediğini tespit etme (artifacts arasındaki diff ile)
• LGPL lisanslı bir bileşen özel bir serviste ortaya çıktığında otomatik bilet oluşturma tetikleme

Bu senaryolar hipotetik değildir — Trivy'nin SBOM çıktısından yapılandırılmış verinin ne kadar kolay çıkarıldığını gördüğümden sonra, benzer kontrolleri dahili araçlarımda uyguladım. Daha önce SLSA provenansı konulu yazımda da belirttiğim gibi, makine-okunabilir derleme meta verisine sahip olmak, tedarik zinciri riskini nasıl düşündüğümü değiştirir.

Yıkıntılar ve Ayarlama İpuçları

Trivy’nin SBOM üretimi anında olmaz. Büyük görüntüler için işe 20–40 saniye ekleyebilir. Bunu şu şekilde azaltırım:

• Sadece OS/paket SBOM istiyorsam, --skip-files kullanarak gerekli olmayan yolları atlarım
• Trivy görüntüsünü GitLab CI’nin image çekme politikasıyla önbelleğe alırım (zaten genellikle önbellekte olur)
• Her branşta SBOM üretimi yapmaktan kaçınırım — rules ile sadece merge request ve ana hat (mainline) derlemelerine sınırlarım

Ayrıca çıktı formatına dikkat etmelisin. SPDX JSON ayrıntılıdır; CycloneDX daha hafiftir. Politika kontrolleri için daha hızlı ayrıştırılabildiği için CycloneDX’e geçtim, ancak arşivleme için SPDX’i korurum çünkü uyumluluk araçlarında daha yaygın olarak kabul edilir.

Sonuç

Trivy ile GitLab CI'de SBOM JSON'u üretmek, sadece SBOM gereksinimlerini karşılama kutusunu işaretlemekle kalmaz — aynı zamanda güvenlik taraması ve operasyonel yönetimi güçlendiren, yeniden kullanılabilir bir artefakt oluşturur. SBOM üretimini CVE taramasından ayırıp aynı JSON'u birden fazla aşamada kullanarak, daha hızlı pipeline'lar elde ederim, bağımlılıklar hakkında daha derin içgörü kazanırım ve politikalar değiştiğinde daha az sürprizle karşılaşırım.

Eğer zaten Trivy'yi CI'de çalıştırıyorsan, SBOM'u yakalamaya başla. Daha sonra soru sor: bu envanteri CVE'leri bulmak dışında ne başka işe yararabilir?

Kapak görseli: HD Wallpapers · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/light-abstract-V9L6XXK3LB