AI Destekli Yazılım Geliştirmede SBOM ve Provenance Zinciri

AI destekli yazılım geliştirmede kanıt zincirini tanımlamak

Bir generative ai aracıyla oluşturulan kod için yalnızca Git commit'i saklamak yeterli bir provenance kaydı değildir. İnceleme anında en az dört nesneyi ilişkilendirin: kaynak commit SHA'sı, bağımlılık kilit dosyası hash'i, container image digest'i ve build attestation digest'i. Örneğin release adayını tag yerine immutable digest ile temsil edin: registry.example.com/payments@sha256:.... Tag'ler yeniden işaretlenebildiği için, tag tabanlı bir dağıtımda denetlenen imaj ile çalışan imaj farklılaşabilir.

# Kaynak ve bağımlılık girdilerini build metadata olarak sabitleyin
SOURCE_SHA=$(git rev-parse HEAD)
LOCK_SHA=$(sha256sum package-lock.json | awk '{print $1}')

docker buildx build   --push   --provenance=mode=max   --sbom=true   --label org.opencontainers.image.revision=$SOURCE_SHA   --label com.example.lock-sha=$LOCK_SHA   -t registry.example.com/payments:$SOURCE_SHA .

# Registry'nin döndürdüğü digest'i release manifest'ine yazın.
docker buildx imagetools inspect registry.example.com/payments:$SOURCE_SHA

Buradaki kritik ayrıntı, LLM çıktısının doğrudan bir güven sınırı olmadığıdır. Modelin önerdiği yeni bir paket adı mevcut görünse bile package manager başka bir registry, Git URL'si veya postinstall script'i çekebilir. Pull request üzerinde package-lock.json, pnpm-lock.yaml ya da poetry.lock değişimini ayrı bir risk sinyali olarak işaretleyin; kaynak kod diff'i temiz olsa bile bağımlılık grafiği değişmiş olabilir.

SBOM üretimi: LLM kodu ve bağımlılık grafiğini ayrı doğrulamak

SBOM'u yalnızca final image'dan üretmek, build aşamasında indirilen fakat runtime imajına kopyalanmayan araçları görünmez bırakır. Runtime envanteri için Syft ile CycloneDX üretin; build toolchain riski için ise lockfile'ı ayrı tarayın. Grype veya OSV-Scanner sonucunu paket adıyla değil, mümkünse purl ve sürümle eşleştirin. Aynı paket adının farklı ecosystem'lerde bulunması, özellikle LLM'nin önerdiği kısa paket adlarında yanlış pozitif veya dependency confusion incelemesine neden olur.

IMAGE=registry.example.com/payments@sha256:REPLACE_WITH_DIGEST

# Çalışacak imajın SBOM'u
syft "$IMAGE" -o cyclonedx-json=sbom.cdx.json

# Kilit dosyasına göre bilinen açık taraması
osv-scanner --lockfile=package-lock.json --format=json > osv-lock.json

# SBOM'u imaj digest'ine imzalayarak bağlayın
cosign attest --yes   --predicate sbom.cdx.json   --type cyclonedx   "$IMAGE"

Yaygın hata, taramayı bir kez çalıştırıp sonuçtaki kritik açık sayısını release kararı olarak kullanmaktır. Daha güvenilir kural, yeni eklenen bileşenlerin delta'sını hesaplamaktır. Önceki onaylı SBOM ile aday SBOM'daki purl kümelerini karşılaştırın; yalnızca yeni bileşenler için CVSS, exploit durumu ve erişilebilir attack surface incelemesi açın. Bu yaklaşım, base image'ın zaten kabul edilmiş bulgularının her pull request'te inceleme kuyruğunu kaplamasını önler.

CI CD pipeline içinde imza, kimlik ve digest doğrulaması

Bir ci cd pipeline, attestation üretiyor diye otomatik olarak güvenilir olmaz. İmzayı üreten iş akışının kimliğini de doğrulayın. Cosign keyless akışında Fulcio sertifikasındaki issuer ve certificate identity değerlerini, sadece korumalı ana dalda çalışan build workflow'una sabitleyin. Pull request fork'ları için verilen kısa ömürlü token'ın release imzası üretmesine izin vermeyin; aksi durumda doğrulanabilir ama yetkisiz bir attestation elde edebilirsiniz.

IMAGE=registry.example.com/payments@sha256:REPLACE_WITH_DIGEST

cosign verify-attestation   --type cyclonedx   --certificate-identity-regexp='https://github.com/acme/payments/.github/workflows/release.yml@refs/heads/main'   --certificate-oidc-issuer='https://token.actions.githubusercontent.com'   "$IMAGE" | jq -e '
    .payload | @base64d | fromjson |
    .predicateType == "https://cyclonedx.org/bom"'

# Doğrulama başarısızsa jq veya cosign non-zero döner ve job durur.

Bu komutu deploy job'unda, kubectl apply'dan önce çalıştırın ve doğrulanan digest'i deployment manifest'ine yazın. Kubernetes tarafında imagePullPolicy: Always kullanmak digest drift sorununu çözmez; digest zaten immutable olduğundan asıl mesele manifest'in tag değil digest taşımasıdır. EKS, GKE veya başka bir yönetilen cluster kullanılsa da bu doğrulama CI runner'da aynı şekilde çalışır.

Cloud native mimaride LLM değişikliklerini ölçmek ve geri almak

LLM tarafından önerilen bir refactor'un gecikme veya kaynak tüketimi etkisini tahmin etmeyin, izole bir canary ölçümü yapın. OpenTelemetry ile endpoint, image digest ve Git SHA'yı resource attribute olarak yayınlayın; ardından k6 ile aynı senaryoyu eski ve aday digest'e karşı çalıştırın. Başarı eşiğini örneğin hata oranı yüzde 0.1'in altında, p95 gecikme farkı en fazla yüzde 5 olacak şekilde pipeline parametresi yapın. Ölçümü aynı node pool, aynı istek gövdesi ve sabit virtual user sayısıyla tekrarlamak gerekir; farklı autoscaling durumları karşılaştırmayı geçersiz kılar.

// k6-smoke.js
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 40,
  duration: '3m',
  thresholds: {
    http_req_failed: ['rate<0.001'],
    http_req_duration: ['p(95)<=250']
  }
};

export default function () {
  const r = http.get(`${__ENV.BASE_URL}/v1/quote`);
  check(r, { '200 response': (x) => x.status === 200 });
}

Önce mevcut release digest'i için BASE_URL=https://stable.example.com k6 run k6-smoke.js, sonra canary için aynı komutu çalıştırın ve k6 JSON çıktısını saklayın. Ardından Prometheus'ta histogram_quantile(0.95, sum by (le) (rate(http_server_request_duration_seconds_bucket{image_digest="$DIGEST"}[5m]))) sorgusuyla sunucu metriklerini kontrol edin. İstemci tarafı k6 ölçümü ile sunucu histogramının birlikte kötüleşmesi CPU, GC veya downstream çağrı sorununa; yalnızca istemci ölçümünün kötüleşmesi ingress veya ağ katmanına işaret eder. Bu ayrım olmadan yapılan rollback kararları sıkça yanlış bileşeni hedefler.

Yazılım eğitimi laboratuvarında uçtan uca uygulanabilir ortam

Çalışan geliştiricilere yönelik bir yazılım eğitimi veya teknoloji eğitimi laboratuvarında hedef, bir yapay zeka kursu demosu yapmak değil, denetlenebilir bir release üretmektir. yapay zeka eğitimi, llm eğitimi ve vibe coding eğitimi modüllerinde katılımcı önce bir modelden küçük bir endpoint üretmesini ister, sonra bu değişikliğin lockfile delta'sını, testini ve SBOM'unu review eder. Bir vibe coding kursu ödevinde kabul kriterini 'uygulama çalışıyor' yerine 'imaj digest'i, CycloneDX belgesi ve Cosign doğrulaması mevcut' olarak tanımlayın.

devops eğitimi ve docker eğitimi için aynı uygulamayı yerelde minikube start --driver=docker ile çalıştırıp minikube image load registry.example.com/payments:dev komutuyla cluster'a yükleyin. kubernetes eğitimi kısmında deployment manifest'inde mutable tag kullanımını reddeden bir admission kuralı ekleyin. Bu pratik, container orchestration kararlarının uygulama kodundan bağımsız olmadığını gösterir: digest seçimi, rollout ve rollback davranışını doğrudan belirler.

aws eğitimi ve google cloud eğitimi laboratuvarlarında registry erişimini uzun ömürlü erişim anahtarlarıyla değil, CI sağlayıcısının OIDC federation mekanizmasıyla verin. terraform kullanan infrastructure as code deposunda registry, workload identity ve Kubernetes namespace yetkilerini ayrı modüllere bölün. Örneğin release rolünün yetkisini yalnızca belirli repository subject claim'iyle sınırlandırın; aynı cloud native mimari içinde geliştiricinin yerel kimliğiyle production registry'ye yazabilmesi, imza zincirini anlamsız hale getirir.

Sık Sorulan Sorular

AI destekli yazılım geliştirme sürecinde SBOM ne zaman üretilmeli?

SBOM'u final container image push edildikten sonra immutable image digest'i üzerinden üretin ve CycloneDX belgesini cosign attest ile aynı digest'e bağlayın. Ayrıca package-lock.json veya eşdeğer lockfile için ayrı bir OSV-Scanner taraması çalıştırın; runtime imajı ve build bağımlılıkları aynı envanter değildir.

Docker eğitimi içinde Cosign ile container image doğrulaması nasıl yapılır?

Önce imajı tag yerine sha256 digest ile referanslayın. Ardından cosign verify-attestation komutunda --certificate-identity-regexp ve --certificate-oidc-issuer parametrelerini zorunlu tutun. Sadece imzanın geçerli olması yetmez; imzayı üreten CI workflow'unun beklenen korumalı branch'ten geldiği de doğrulanmalıdır.

Kubernetes eğitimi için minikube üzerinde SBOM doğrulaması test edilebilir mi?

Evet. minikube start --driver=docker ile cluster'ı başlatın, imajı minikube image load ile yükleyin ve deploy öncesi CI job'unda cosign verify-attestation çalıştırın. Yerel cluster, registry erişim politikalarının tümünü taklit etmese de digest pinleme, attestation doğrulaması ve rollback manifest'i testleri için yeterlidir.

Terraform ve infrastructure as code ile AI kod üretiminde hangi erişim sınırı kurulmalı?

Terraform ile CI OIDC subject claim'ine bağlı, yalnızca belirli repository ve branch için geçerli bir registry push rolü tanımlayın. Pull request workflow'larına production push veya signing yetkisi vermeyin. Bu sınır, LLM'nin ürettiği bir workflow değişikliğinin fork veya geçici branch üzerinden release imzası üretmesini engeller.