GitLab CI'de Trivy ile Otomatik SBOM ve Lisans Uyumluluk Kontrolü

Çevremde bir süredir container imajları ve dosya sistemleri için güvenlik açığı taraması yapmak üzere Trivy kullanıyorum. Son zamanlarda SBOM üretimi ve lisans uyumluluk kontrollerini GitLab CI pipeline'ımıza entegre etmem gerekti. Hedefim basitti: HIGH veya CRITICAL şiddette bir CVE bulunursa veya uyumsuz lisans tespit edilirse pipeline'ı başarısız yapmak. Trivy'nin --format sbom ve --severity bayraklarıyla bu işlem oldukça basitleşiyor.

Trivy'yi GitLab CI'de Kurulum

İlk olarak Trivy'nin CI imajında mevcut olduğundan emin oluyorum. Güncel ve hafif olan resmi Aquasecurity/trivy imajını kullanıyorum. .gitlab-ci.yml dosyamda build aşamasından sonra çalışacak bir job tanımlıyorum:

trivy-sbom-scan:
  image: aquasec/trivy:latest
  stage: test
  script:
    - trivy fs --format sbom --output sbom.spdx .
    - trivy fs --severity HIGH,CRITICAL --exit-code 1 .
  artifacts:
    paths:
      - sbom.spdx
    expire_in: 1 week

İlk komut SBOM'u SPDX formatında oluşturur ve bunu bir artifact olarak kaydeder. İkinci komut ise dosya sisteminde HIGH veya CRITICAL şiddetindeki güvenlik açıklarını tarar ve herhangi biri bulundığında çıkış kodunu 1 olarak ayarlar, bu da job'ı başarısız kılar.

Lisans Uyumluluk Kontrollerini Ekleme

Trivy lisans sorunlarını da varsayılan olarak tarar. Proprietary yapılarımızda GPL-3.0 veya AGPL gibi lisansları engellemek istiyordum. Bunun için bir lisans politikası dosyası ekledim:

# trivy-license-policy.yaml
license:
  allowed:
    - MIT
    - Apache-2.0
    - BSD-3-Clause
  forbidden:
    - GPL-3.0
    - AGPL-3.0
    - LGPL-3.0

Ardından bu politikayı kullanacak şekilde CI job'ımı güncelledim:

    - trivy fs --severity HIGH,CRITICAL --license-policy trivy-license-policy.yaml --exit-code 1 .

Trivy yasaklı bir lisans bulursa taramayı başarısız yapar ve pipeline durur. Bu sayede birşeyleri registry'e push etmeden veya dağıtmadan önce erken geri bildirim alırız.

Sonuçları Görüntüleme ve Sorun Giderme

Bazen Trivy certain dizinlere erişemediği için SBOM üretimi başarısız olabiliyor. Ben bu sorunu restricted submodülleri olan bir monorepo taraması yaparken yaşadım. Çözüm olarak CI runner'ın okuma izni olduğundan emin oldum veya sorunlu yolları açıkça hariç tuttum:

    - trivy fs --format sbom --output sbom.spdx --exclude-dir .git,node_modules .

Ayrıca Trivy'nin SPDX çıktısı oldukça büyük olabiliyor. Bu çıktıyı daha sonra denetim veya uyumluluk ekibi tarafından incelenebilmesi için bir artifact olarak arşivliyorum. Bir önceki yazımda Restic ile yedekleri şifreleme konusunu anlattığım gibi, düzenleştirmeler nedeniyle SBOM'ları tutmamız gerekiyordu ve CI artifact'ları bu süreci kolaylaştırdı.

Bu Yaklaşımın İşe Yaradığı Neden

Trivy'yi bu şekilde kullanarak güvenlik ve uyumluluk kontrollerini kaynak koduna yakın tutuyoruz. Push sonrası dış taramalara güvenmek yerine sorunları erken yakalıyoruz. --severity HIGH,CRITICAL odaklaması gürültüyü azaltıyor — düşük riskli sorunlar için pipeline'ı fail etmiyoruz. Ayrıca Trivy'nin güvenlik veritabanını sık sık güncellemesi sayesinde elle feed yönetimi yapmadan güncel kalabiliyoruz.

Zaten Trivy'yi imaj taraması için kullanıyorsanız, FS-tabanlı SBOM ve lisans kontrollerini GitLab CI'ye eklemek mantıklı bir sonraki adımdır. Hızlı, güvenilir ve mevcut pipeline'larınıza sorunsuz entegre oluyor.

Kapak görseli: www.Pixel.la Free Stock Photos · CC0 (Wikimedia Commons / kamu malı) · https://commons.wikimedia.org/wiki/File:Fruits-grocery-bananas-market_(24300521606).jpg