{"id":619,"date":"2026-10-05T12:00:00","date_gmt":"2026-10-05T12:00:00","guid":{"rendered":"https:\/\/konteynerium.com\/index.php\/2026\/10\/05\/sbom-provenance-ve-cosign-ile-imaj-imzalama-tedarik-zinciri\/"},"modified":"2026-10-05T12:00:00","modified_gmt":"2026-10-05T12:00:00","slug":"sbom-provenance-ve-cosign-ile-imaj-imzalama-tedarik-zinciri","status":"publish","type":"post","link":"https:\/\/konteynerium.com\/index.php\/2026\/10\/05\/sbom-provenance-ve-cosign-ile-imaj-imzalama-tedarik-zinciri\/","title":{"rendered":"Tedarik Zinciri G\u00fcvenli\u011fi: SBOM, Provenance ve Cosign ile \u0130maj \u0130mzalama"},"content":{"rendered":"

Bir imaj\u0131 \u00e7al\u0131\u015ft\u0131rmadan \u00f6nce \u00fc\u00e7 soruya cevap verebilmelisiniz: \u0130\u00e7inde ne var?<\/strong> (SBOM) Nas\u0131l ve nerede \u00fcretildi?<\/strong> (provenance) Ger\u00e7ekten bizim \u00fcretti\u011fimiz imaj bu mu?<\/strong> (imza). Bunlar yaz\u0131l\u0131m tedarik zinciri g\u00fcvenli\u011finin \u00fc\u00e7 temel ta\u015f\u0131d\u0131r ve Docker’\u0131n modern ara\u00e7lar\u0131yla bug\u00fcn birka\u00e7 komutla elde edilebilir. Zafiyet taramas\u0131 (bkz. Container Image G\u00fcvenli\u011fi<\/a>) “i\u00e7indeki paketlerde bilinen a\u00e7\u0131k var m\u0131?” sorusunu yan\u0131tlar; bu yaz\u0131 onun tamamlay\u0131c\u0131s\u0131d\u0131r.<\/p>\n

\n i<\/span><\/p>\n

Neyi test ettik, neyi etmedik?<\/strong> Provenance \u00fcretimini Docker 29.4 + Buildx 0.33 \u00fczerinde ger\u00e7ekten \u00e7al\u0131\u015ft\u0131rd\u0131k. SBOM \u00fcretimi ve cosign<\/code> ad\u0131mlar\u0131n\u0131 bu ortamda deneyemedik (SBOM taray\u0131c\u0131 imaj\u0131 i\u00e7in Docker Hub eri\u015fimi, cosign i\u00e7in de a\u011f eri\u015fimi gerekiyor); bu b\u00f6l\u00fcmler resmi Docker ve Sigstore dok\u00fcmantasyonuna dayan\u0131r. Komutlar\u0131 kendi ortam\u0131n\u0131zda \u00f6nce deneme imaj\u0131nda \u00e7al\u0131\u015ft\u0131r\u0131n.<\/p>\n<\/div>\n

1. SBOM: imaj\u0131n malzeme listesi<\/h2>\n

SBOM (Software Bill of Materials), bir imaj\u0131n i\u00e7indeki paketlerin, k\u00fct\u00fcphanelerin ve s\u00fcr\u00fcmlerin envanteridir. Yeni bir zafiyet a\u00e7\u0131kland\u0131\u011f\u0131nda (\u00f6rne\u011fin “\u015fu k\u00fct\u00fcphanenin 2.3 s\u00fcr\u00fcm\u00fcnde kritik a\u00e7\u0131k var”) imajlar\u0131n\u0131z\u0131 tek tek yeniden taramak yerine SBOM’lara bakarak etkilenen imajlar\u0131 hemen bulabilirsiniz.<\/p>\n

Buildx, SBOM’u build s\u0131ras\u0131nda \u00fcretip imaja attestation<\/em> olarak ekleyebilir:<\/p>\n

docker buildx build --sbom=true --tag kullanici\/uygulama:1.0 --push .\n\n# ya da push etmeden dosya olarak do\u011frulay\u0131n\ndocker buildx build --sbom=true --output type=local,dest=out .\n# out\/sbom.spdx.json dosyas\u0131 olu\u015fur<\/code><\/pre>\n
Dok\u00fcmantasyona g\u00f6re SBOM, SPDX standard\u0131nda JSON olarak \u00fcretilir. Registry’deki bir imaj\u0131n SBOM’unu g\u00f6rmek i\u00e7in:<\/p>\n
docker buildx imagetools inspect kullanici\/uygulama:1.0 --format \"{{ json .SBOM }}\"<\/code><\/pre>\n
Varsay\u0131lan olarak yaln\u0131zca son a\u015fama<\/strong> taran\u0131r. Multi-stage build’de ara a\u015famalar\u0131n da (\u00f6rne\u011fin derleme ara\u00e7lar\u0131n\u0131n) listelenmesini istiyorsan\u0131z Dockerfile’a ARG BUILDKIT_SBOM_SCAN_STAGE=true<\/code> ekleyebilirsiniz (bkz. Multi-Stage Build<\/a>).<\/p>\n
Denemeye \u00e7al\u0131\u015ft\u0131\u011f\u0131m\u0131zda BuildKit’in SBOM’u docker\/buildkit-syft-scanner<\/code> adl\u0131 bir taray\u0131c\u0131 imaj\u0131 \u00e7ekerek \u00fcretti\u011fini g\u00f6rd\u00fck; yani build ortam\u0131n\u0131z\u0131n bu imaja (registry’ye) eri\u015febilmesi gerekir. Kapal\u0131 bir a\u011fda \u00e7al\u0131\u015f\u0131yorsan\u0131z taray\u0131c\u0131 imaj\u0131n\u0131 \u00f6nceden kendi registry’nize aynalaman\u0131z gerekir.<\/p>\n
2. Provenance: imaj nas\u0131l \u00fcretildi?<\/h2>\n
Provenance, bir imaj\u0131n kim taraf\u0131ndan, hangi kaynaktan, hangi komutlarla \u00fcretildi\u011fini kaydeder (SLSA \u00e7er\u00e7evesiyle uyumlu). Mod se\u00e7ene\u011fi vard\u0131r: mode=min<\/code> temel bilgiyi, mode=max<\/code> build arg\u00fcmanlar\u0131, komutlar gibi ayr\u0131nt\u0131lar\u0131 da i\u00e7erir.<\/p>\n
docker buildx build --provenance=mode=max --output type=local,dest=out .<\/code><\/pre>\n
Bu komutu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131m\u0131zda \u00e7\u0131kt\u0131 dizininde provenance.json<\/code> olu\u015ftu ve i\u00e7indeki predicateType<\/code> alan\u0131 https:\/\/slsa.dev\/provenance\/v1<\/code> idi; yani standart bir SLSA provenance belgesi. Bir imaj\u0131n --provenance=mode=max<\/code> ile registry’ye g\u00f6nderilmi\u015f halini incelemek i\u00e7in:<\/p>\n
docker buildx imagetools inspect kullanici\/uygulama:1.0 --format \"{{ json .Provenance }}\"<\/code><\/pre>\n
\n  !<\/span><\/p>\n
\u00d6nemli \u00f6n ko\u015ful:<\/strong> Attestation’lar imaj indeksinin (image index) i\u00e7inde saklan\u0131r. Docker dok\u00fcmantasyonuna g\u00f6re klasik imaj deposu bu yap\u0131y\u0131 tutamaz; docker<\/code> s\u00fcr\u00fcc\u00fcs\u00fcyle attestation i\u00e7in containerd imaj deposu gerekir. Docker 29.4 kurulumumuzda docker info<\/code> \u00e7\u0131kt\u0131s\u0131nda driver-type: io.containerd.snapshotter.v1<\/code> g\u00f6r\u00fcn\u00fcyordu; sizinki farkl\u0131ysa docker-container<\/code> s\u00fcr\u00fcc\u00fcl\u00fc bir builder kullan\u0131n. Ayr\u0131ca varsay\u0131lan davran\u0131\u015f (hangi attestation’\u0131n otomatik eklendi\u011fi) s\u00fcr\u00fcme ve \u00e7\u0131kt\u0131 bi\u00e7imine g\u00f6re de\u011fi\u015febilir \u2014 beklentiye b\u0131rakmay\u0131p --sbom<\/code> ve --provenance<\/code> bayraklar\u0131n\u0131 a\u00e7\u0131k\u00e7a yaz\u0131n. Biz type=oci<\/code> \u00e7\u0131kt\u0131s\u0131n\u0131 bayraks\u0131z ald\u0131\u011f\u0131m\u0131zda attestation eklenmedi\u011fini g\u00f6rd\u00fck.<\/p>\n<\/div>\n
3. \u0130mzalama: bu imaj ger\u00e7ekten bizim mi?<\/h2>\n
SBOM ve provenance imaj\u0131n ne oldu\u011funu<\/em> anlat\u0131r; imza ise kim taraf\u0131ndan yay\u0131mland\u0131\u011f\u0131n\u0131 ve sonradan de\u011fi\u015ftirilmedi\u011fini<\/em> kan\u0131tlar. A\u00e7\u0131k kaynak d\u00fcnyas\u0131nda yayg\u0131n ara\u00e7 Sigstore’un cosign<\/strong>‘\u0131d\u0131r. \u0130ki mod vard\u0131r: anahtar tabanl\u0131 ve anahtars\u0131z (keyless).<\/p>\n
# Anahtars\u0131z (OIDC ile; Google\/GitHub\/Microsoft hesab\u0131yla do\u011frular)\ncosign sign kullanici\/uygulama@sha256:ABC...\n\n# Anahtar \u00e7ifti ile\ncosign generate-key-pair\ncosign sign --key cosign.key kullanici\/uygulama@sha256:ABC...<\/code><\/pre>\n
\u0130mzay\u0131 etiket yerine digest<\/strong> ile atmak \u00f6nemlidir: etiket sonradan ba\u015fka bir imaj\u0131 i\u015faret edebilir (bkz. \u0130maj ve Container Fark\u0131<\/a>), digest ise i\u00e7eri\u011fe ba\u011fl\u0131d\u0131r. Do\u011frulama:<\/p>\n
# Anahtars\u0131z imza: kimin imzalad\u0131\u011f\u0131n\u0131 a\u00e7\u0131k\u00e7a belirtin\ncosign verify kullanici\/uygulama@sha256:ABC... \\\n  --certificate-identity=ben@ornek.com \\\n  --certificate-oidc-issuer=https:\/\/accounts.google.com\n\n# GitHub Actions ile imzaland\u0131ysa\ncosign verify kullanici\/uygulama@sha256:ABC... \\\n  --certificate-identity-regexp=https:\/\/github.com\/kurulu\u015f\/depo \\\n  --certificate-oidc-issuer=https:\/\/token.actions.githubusercontent.com\n\n# Anahtar \u00e7iftiyle\ncosign verify --key cosign.pub kullanici\/uygulama@sha256:ABC...<\/code><\/pre>\n
Do\u011frulamada --certificate-identity<\/code> ve --certificate-oidc-issuer<\/code> de\u011ferlerini mutlaka<\/em> belirtin; bu olmadan “birisi imzalam\u0131\u015f” demenin g\u00fcvenlik de\u011feri \u00e7ok d\u00fc\u015f\u00fckt\u00fcr. \u00d6nemli olan, “herhangi bir imza” de\u011fil, “bekledi\u011fim kimli\u011fin imzas\u0131” olmas\u0131d\u0131r. cosign’\u0131n bayraklar\u0131 ve \u00e7\u0131kt\u0131 bi\u00e7imi s\u00fcr\u00fcmler aras\u0131nda de\u011fi\u015febildi\u011fi i\u00e7in kulland\u0131\u011f\u0131n\u0131z s\u00fcr\u00fcm\u00fcn cosign sign --help<\/code> \u00e7\u0131kt\u0131s\u0131na bak\u0131n.<\/p>\n
Hepsini bir arada: \u00f6rnek CI ak\u0131\u015f\u0131<\/h2>\n
    \n
  1. \u0130maj\u0131 --sbom=true --provenance=mode=max<\/code> ile build edip registry’ye g\u00f6nderin.<\/li>\n
  2. Push sonras\u0131 digest’i al\u0131n.<\/li>\n
  3. cosign sign<\/code> ile digest’i imzalay\u0131n (CI’da anahtars\u0131z imza i\u00e7in pipeline’a OIDC kimli\u011fi verilir).<\/li>\n
  4. Da\u011f\u0131t\u0131m \u00f6ncesi (admission kontrol\u00fc ya da da\u011f\u0131t\u0131m beti\u011finde) cosign verify<\/code> ile kimli\u011fi do\u011frulay\u0131n; do\u011frulanamayan imaj\u0131 \u00e7al\u0131\u015ft\u0131rmay\u0131n.<\/li>\n<\/ol>\n
    CI\/CD taraf\u0131 i\u00e7in CI\/CD ile Docker<\/a> yaz\u0131s\u0131na bak\u0131n; tarama ad\u0131m\u0131n\u0131 da pipeline’a eklemeyi unutmay\u0131n.<\/p>\n
    SBOM’u tarama ile birle\u015ftirmek<\/h2>\n
    SBOM yaln\u0131zca envanter de\u011fil, s\u00fcrekli bir tarama girdisidir: SBOM’dan zafiyet taramas\u0131 yapan ara\u00e7lar vard\u0131r (Trivy ve Grype gibi), b\u00f6ylece imaj\u0131 yeniden \u00e7ekmeden “bug\u00fcn a\u00e7\u0131klanan zafiyetten hangi imajlar\u0131m\u0131z etkileniyor?” sorusunu yan\u0131tlars\u0131n\u0131z. Bu sitedeki G\u00fcvenlik Merkezi<\/a>‘nde Docker Bench ve Falco konular\u0131yla birlikte d\u00fc\u015f\u00fcn\u00fcn: SBOM “ne var”, tarama “a\u00e7\u0131k var m\u0131”, imza “do\u011fru imaj m\u0131”, Falco “\u00e7al\u0131\u015f\u0131rken ne yap\u0131yor” sorular\u0131n\u0131n cevab\u0131d\u0131r.<\/p>\n
    H\u0131zl\u0131 kontrol listesi<\/h2>\n
      \n
    • \u0130majlar\u0131n\u0131z --sbom=true<\/code> ve --provenance=mode=max<\/code> ile mi build ediliyor?<\/li>\n
    • Builder attestation destekliyor mu (containerd imaj deposu veya docker-container<\/code> s\u00fcr\u00fcc\u00fcs\u00fc)?<\/li>\n
    • \u0130majlar\u0131 etiketle de\u011fil digest<\/strong> ile imzal\u0131yor ve do\u011fruluyor musunuz?<\/li>\n
    • Do\u011frulamada beklenen kimlik (--certificate-identity<\/code>) ve sa\u011flay\u0131c\u0131 (--certificate-oidc-issuer<\/code>) belirtiliyor mu?<\/li>\n
    • Da\u011f\u0131t\u0131m hatt\u0131n\u0131z imzas\u0131z imaj\u0131 reddediyor mu?<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
      \u0130maj\u0131n\u0131z\u0131n i\u00e7inde ne var, nas\u0131l \u00fcretildi ve ger\u00e7ekten sizin mi? Buildx ile SBOM ve provenance \u00fcretimini, cosign ile digest imzalamay\u0131 ve kimlik do\u011frulamas\u0131yla verify etmeyi ad\u0131m ad\u0131m \u00f6\u011frenin.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"seviye":[9],"class_list":["post-619","post","type-post","status-publish","format-standard","hentry","category-orkestrasyon-guvenlik","seviye-ileri"],"_links":{"self":[{"href":"https:\/\/konteynerium.com\/index.php\/wp-json\/wp\/v2\/posts\/619","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/konteynerium.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/konteynerium.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/konteynerium.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/konteynerium.com\/index.php\/wp-json\/wp\/v2\/comments?post=619"}],"version-history":[{"count":0,"href":"https:\/\/konteynerium.com\/index.php\/wp-json\/wp\/v2\/posts\/619\/revisions"}],"wp:attachment":[{"href":"https:\/\/konteynerium.com\/index.php\/wp-json\/wp\/v2\/media?parent=619"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/konteynerium.com\/index.php\/wp-json\/wp\/v2\/categories?post=619"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/konteynerium.com\/index.php\/wp-json\/wp\/v2\/tags?post=619"},{"taxonomy":"seviye","embeddable":true,"href":"https:\/\/konteynerium.com\/index.php\/wp-json\/wp\/v2\/seviye?post=619"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}