---
title: "Score projesi Docker Hardened Images ve OIDC ile release hattını yeniledi"
description: "CNCF Sandbox projesi Score, Docker Hardened Images, Docker Scout ve OIDC ile release pipeline'ını yeniledi. Hangi adım size uyar, neyden vazgeçersiniz?"
image: "https://sezer.in/wp-content/uploads/2026/11/image3-3.png"
url: "https://sezer.in/haberler/docker-hardened-images-score-projesi/"
date: "2026-11-06T10:01:36+03:00"
updated: "2026-11-06T10:01:36+03:00"
author: "Sezer Şanlıkan"
lang: "tr"
source: "https://sezer.in/haberler/docker-hardened-images-score-projesi/"
---

# Score projesi Docker Hardened Images ve OIDC ile release hattını yeniledi

CNCF Sandbox projesi Score, DSOS (Docker-Sponsored Open Source) programına katıldıktan sonra container image'larının base katmanını Docker Hardened Images'a taşıdı ve release pipeline'ını yeniledi. Proje image'larını artık Docker Hub'da da yayımlıyor ve her pull request'te Docker Scout ile CVE karşılaştırması yapıyor. Docker Hub erişimi de 21 Temmuz 2026'da gelen OIDC connections özelliğiyle kısa ömürlü token'a geçti.

## Score nedir ve nerede kullanılır?

Score, iş yükünü çalışacağı platformdan bağımsız biçimde tarif eden açık kaynak bir workload spesifikasyonudur. Geliştirici tek bir Score dosyası yazar; score-compose bunu Docker Compose dosyasına, score-k8s ise Kubernetes manifest'lerine çevirir. Yerel geliştirme ile production ortamı arasındaki yapılandırma farkını azaltmak isteyen platform ekipleri kullanır. CNCF Sandbox aşamasında bir projedir.

## Kısaca Docker Hardened Images nedir

Docker Hardened Images, Docker'ın yayımladığı minimal ve güvenlik odaklı container base image'larıdır. Yalnızca gerekli bileşenleri içerir, varsayılan olarak non-root çalışır, SBOM ve build provenance bilgisiyle gelir. Güvenlik açıkları duyuruldukça yeniden build edilir. Distroless image'lar ve Chainguard Images bu alandaki bilinen alternatiflerdir.

Score'un yazısı bir program tanıtımı gibi okunuyor, fakat adımların çoğu DSOS üyeliğine bağlı değil. Docker Hardened Images Apache 2.0 lisansıyla açık. Docker/github-builder kaynağın kendi ifadesiyle programın parçası değil. OIDC connections da genel bir Docker Hub güncellemesiyle geldi. Container image yayımlıyorsanız aynı sırayı kendi repo'nuzda izleyebilirsiniz.

## Score'un değiştirdiği beş şey

- Image'lar GHCR'a ek olarak Docker Hub'a gidiyor; release workflow iki registry'ye birden push ediyor.
- Her PR'da `docker/scout-action` compare komutu PR image'ını main image'ıyla karşılaştırıyor ve farkı PR'a yorum olarak yazıyor.
- Scout policy'leri üç kuralı denetliyor: root olmayan kullanıcı, critical seviyede CVE olmaması, AGPL v3 lisanslı paket olmaması.
- Base image'lar `dhi.io` altındaki Docker Hardened Images'a taşındı.
- Buildx, login, build-push ve cosign adımları tek bir reusable workflow çağrısına indi.

Lisans policy'si gözden kaçmasın. Ticari ürün geliştiriyorsanız AGPL v3 kontrolünü PR aşamasında yapmak, CVE taraması kadar değerli.

## Docker Hardened Images geçişi ne kazandırıyor

Score'un iki örneği farklı sonuç veriyor. Score-radius CLI'ı zaten `golang:alpine` ve distroless kullanıyordu. `dhi.io/golang` ve `dhi.io/static` geçişinden sonra boyut 0,3 MB düştü, CVE sayısı zaten 0'dı ve öyle kaldı.

Node tabanlı sample-score-app'te tablo değişiyor. 22 paket kalktı, aralarında package manager ve shell var; 2 CVE kapandı. Go binary'si gibi statik iş yüklerinde Docker Hardened Images'tan büyük CVE düşüşü beklemeyin. Kazanç orada SBOM ve SLSA Level 3 provenance tarafında. Node veya benzeri runtime gerektiren image'larda paket ve CVE sayısı gerçekten azalıyor.

Shell'in gitmesi bazı şeyleri zorlaştırıyor. Shell form CMD, HEALTHCHECK ve entrypoint script'i çalışmaz. `kubectl exec` ile sh açamazsınız, debug için `kubectl debug` ile ephemeral container'a geçmeniz gerekir. Image'lar varsayılan olarak non-root çalıştığı için 1024 altındaki portlara bağlanan uygulamaları ve volume izinlerini de kontrol edin:

```
grep -nE "^(CMD|ENTRYPOINT|HEALTHCHECK)" Dockerfile
```

## İmzayı doğrulayan kimlik değişiyor

Eski workflow image'ı Score'un kendi job'ında `cosign sign` ile imzalıyordu. Yeni düzende imzayı atan kimlik `docker/github-builder` içindeki `build.yml`. Image imzasını bir admission policy ile doğruluyorsanız, builder geçişinden sonra eski kimliğe bakan kurallar doğrulamayı reddeder. Policy güncellemesini geçişle aynı PR serisine koyun.

Projenin `cosign verify` örneği, sertifika kimliğini builder workflow'unun adresiyle eşleştiriyor. Bu regex, builder'ı çağıran her repo için aynı sonucu verir. Image'ın gerçekten sizin repo'nuzdan çıktığını görmek için provenance'taki kaynak commit kaydına da bakın.

Build mantığı artık Docker'ın repo'sunda duruyor. Score bunu bilinçli bir takas olarak tanımlıyor. `@v1` tag'i zamanla ilerler; tedarik zinciri politikanız sabitleme istiyorsa commit SHA'ya pin'leyin. Cache açıkken cache girdileri imzalanıp yeniden kullanımdan önce doğrulanıyor, bu da cache poisoning riskini azaltıyor.

## Docker Hub OIDC ile token'ı silin

En hızlı uygulanacak adım bu. Önce uzun ömürlü token kullanan workflow'ları bulun:

```
grep -rn "docker/login-action" .github/workflows/
```

Geçiş için `docker/login-action` v4.5.0 veya üstü, `docker/github-builder` v1.15.0 veya üstü gerekiyor. Job'a `id-token: write` izni verin ve connection ID'yi secret yerine variable olarak saklayın:

```
steps:
  - uses: docker/login-action@v4 # v4.5.0+
    env:
      DOCKERHUB_OIDC_CONNECTIONID: ${{ vars.DOCKER_HUB_OIDC_CONNECTION_ID }}
    with:
      username: ${{ vars.DOCKER_HUB_ORG }}
```

Geçiş bittiğinde eski Organization Access Token'ı Docker Hub'dan iptal edin ve repo secret'ını silin. Aksi halde workflow artık kullanmasa da token geçerli kalır ve çalınabilir.

## Hangi sırayla

1. OIDC geçişi: tek PR, davranış değişmiyor.
2. Scout compare adımını PR'lara ekleyin; önce yalnızca yorum yazsın, build'i kırmasın.
3. Docker Hardened Images geçişine runtime'lı image'lardan başlayın, shell bağımlılığını test ortamında görün.
4. Github-builder geçişini en sona bırakın ve imza doğrulama policy'lerini aynı anda güncelleyin.