GitLab CI'de SBOM ve Provenance ile SLSA Seviye 2 Uygulaması

Eğer konteynerize edilmiş iş yükleri çalıştırıyorsanız veya ikili dosyalar dağıtıyorsanız, SLSA Seviye 2, yapıdan sonra artefaktların müdahale edilmediğine dair bir temel garantisi sunar. Benim GitLab CI ardışık düzenlerimde, bu garantiyi SBOM üretimi, in-toto provenance kanıtlama ve cosign tabanlı imzalama ile birleştirerek sağlıyorum. Bu sadece bir kutuyu işaretlemekle ilgili değil — gönderdiğiniz şeylerin derlediğinizle tamamen aynı olduğundan emin olmaktır.

Syft ile GitLab CI'de SBOM Üretimi

İlk adım bir Yazılım Malzeme Listesi (SBOM) oluşturmaktır. Bunun için Syft'i tercih ederim; çünkü hızlı, çeşitli formatları destekler ve Docker tabanlı işlerde temiz bir şekilde entegre olur. .gitlab-ci.yml dosyamda genellikle şöyle bir bölüm kullanırım:

sbom:
  stage: test
  image: 
    name: ghcr.io/anchore/syft:latest
    entrypoint: [""]
  script:
    - syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o spdx-json > sbom.spdx.json
    - syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o cyclonedx > sbom.cdx.json
  artifacts:
    paths:
      - sbom.spdx.json
      - sbom.cdx.json
    expire_in: 1 week

Bu iş, imajın oluşturulduğu ve kayıt defterine pushed olduğu zaman sonra çalıştırırım. SPDX ve CycloneDX formatlarını ikisi de üretirim çünkü farklı tüketicilerin farklı beklentileri olabilir — dahili araçlar genellikle SPDX'i tercih ederken, dış iş ortakları CycloneDX talep eder. Bu artefaktlar bir hafta boyunca saklanır; böylece aşağı akış işleri veya el ile incelemeler üzerinden erişilebilir olur.

in-toto ile Provenance Kanıtlama Oluşturma

SLSA Seviye 2, artefaktın nasıl üretildiğini gösteren bir provenance gerektirir; bu derleme parametreleri ve kaynak konumunu da içerir. Bunun için slsa-github-generator aracını kullanırım (GitLab'e uyarlanmış haliyle). Temel prensip, derleme ortamını değiştirilemez şekilde yakalamaktır.

provenance:
  stage: build
  image: 
    name: gcr.io/slsa-framework/slsa-github-generator:latest
    entrypoint: [""]
  script:
    - SLSA_GITHUB_GENERATOR_NAME=gitlab-ci SLSA_GITHUB_GENERATOR_VERSION=$CI_PIPELINE_ID \
      slsa-github-generator -source=$CI_PROJECT_URL -commit=$CI_COMMIT_SHA \
        -workflow=.gitlab-ci.yml -output=provenance.attestation
  artifacts:
    paths:
      - provenance.attestation
    expire_in: 1 week

Bu kanıt, imaj ve SBOM ile birlikte saklanır. Daha sonra doğrulama araçları, derlemenin belirtilen kaynak ve pipeline tanımıyla eşleşip eşleşmediğini kontrol edebilir. Bir dikkat etmen gereken nokta: bu adım sırasında runner'ın gitlab.com'a ağ erişimi olduğundan emin ol; aksi takdirde kaynak veya CI yapılandırmasını getiremeyecektir.

cosign ile Artifakt İmzalama

Son olarak, cosign kullanarak konteyner imajını imzalayorum. Anahtar çifti (COSIGN_KEY ve COSIGN_PASSWORD) GitLab CI değişkenlerinde saklanır. Bu sayede dağıtım zamanında kontrol edilebilir bir imza elde etmiş oluruz.

sign:
  stage: deploy
  image: 
    name: gcr.io/projectsigstore/cosign:latest
    entrypoint: [""]
  script:
    - echo "$COSIGN_KEY" | cosign key load -
    - echo "$COSIGN_PASSWORD" | cosign sign --key - $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  only:
    - main
    - merge_requests

İmzalama işlemini sadece korumalı dallara (main ve merge requestleri) sınırlarım; bu da anahtar pozlama riskini azaltır. İmza, ekstra bir altyapı gerektirmeden OCI kayıt defterinde imajın yanında saklanır. Daha sonra doğrulama yaparken, cosign verify --key $COSIGN_PUBKEY $IMAGE komutu hem imzanın geçerliliğini hem de etkinse şeffaflık günlüğünü de kontrol eder.

SLSA Seviye 2 için Tümünü Birleştirme

SLSA Seviye 2 ilan etmek için şunlara ihtiyacınız vardır:

Barındırılan bir derleme platformu (GitLab CI bu kriteri karşılar)
Derleme parametreleri ve kaynağını içeren provenance
Üretilen SBOM
İmzalı artefaktlar

Benim ardışık düzenim, bu dört öğenin de üretilmesini ve ya artefakt olarak saklanmasını ya da imaja eklenmesini sağlar. Üretim ortamında, Kyverno veya OPA/Gatekeeper gibi kabul denetleyicileri kullanarak şu koşulların sağlanmadığı sürece dağıtımı engellerim:

Imajın geçerli bir cosign imzasına sahip olması
SBOM'un mevcut ve ayrıştırılabilir olması
Provenance'in güvenilir bir kaynağa ve değiştirilmemiş .gitlab-ci.yml dosyasına ait olduğunu göstermesi

Bu sadece teori değil — bu yöntemi kullanarak yapılandırma hatalı runner'ları ve imzasız imaj göndermeye çalışan forked MR'leri yakaladım. Eğer zaten GitLab CI kullanıyorsanız, bu adımları eklemek maliyet açısından düşük olur ama supply chain güvenliğinizi önemli ölçüde artırır. Önce SBOM üretimiyle başlayın, ardından provenance ve imzalama katmanlarını ekleyin. Daha önce systemd-nspawn ile CI'yi güvenli hale getirme konulu yazımda da belirttiğim gibi, derleme ortamlarını izole etmek yardımcı olur — ama SLSA size bunu kanıtlayabileceğiniz denetim izi verir.

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