Kurulum ve ürün akışlarını üretim öncesinde doğrulayın

Amaç, kapsam ve karar yetkisi

Bu kontrol listesi tek başına bir ürün yeterlilik beyanı değildir. Hedef release ve topoloji için hangi akışların denendiğini, hangi kanıtın üretildiğini ve üretime geçiş kararını kimin verdiğini görünür kılan bir değerlendirme çerçevesidir.

• Kapsama uygulama image/chart veya kaynak referansı, veritabanı migration seviyesi, storage tipi, ingress/TLS modeli ve identity provider dahil edilmelidir.
• Kritik kullanıcı yolculukları, kullanılacak repository tipleri ve gerçek paket istemcileri test başlamadan önce adlandırılmalıdır.
• Testi uygulayan, bulguyu inceleyen, riski kabul eden ve üretim kararını veren roller aynı kayıtta ayrıştırılmalıdır.
• Kapsam dışı bırakılan her konu gerekçesi ve üretim etkisiyle yazılmalı; sessizce geçmiş sayılmamalıdır.

Kanıt paketi hazırlığı

Her kontrol için sorumlu, ortam, tarih, giriş verisi, beklenen sonuç ve kanıt bağlantısı kaydedilmelidir.

• Kapsamdaki organization, project, repository, format, client ve kullanıcı rollerini dondurun.
• Test paketleri ve SBOM'lar üretim verisi ya da secret içermemelidir.
• Başarılı ve reddedilen senaryolar için correlation/job/scan kimliklerini saklayın.
• Ekran görüntüsü, log ve dışa aktarılan kayıtlarda token, cookie, parola, bağlantı dizesi ve kişisel veriyi maskeleyin.
• Kanıt deposunda değiştirilemez adlandırma, erişim sahibi ve saklama süresi tanımlayın; yalnız sohbet veya geçici terminal çıktısına güvenmeyin.

Ortam hazır oluş kapısı

Fonksiyonel kontroller başlamadan önce hedefe benzeyen ortamın kimliği ve bağımlılıkları doğrulanmalıdır. Hazır oluş kapısı geçilmezse sonraki sonuçlar koşullu olarak kaydedilir ve üretim kanıtı sayılmaz.

• DNS, ingress, TLS zinciri, güvenilen CA'lar ve saat senkronizasyonunu hem yönetim arayüzünden hem paket istemcisi yolundan doğrulayın.
• PostgreSQL bağlantısı ve migration durumu ile Local veya S3 uyumlu storage health/usage sonucunu kaydedin.
• OIDC/LDAP veya built-in kimlik yolunu; grup/rol eşlemesini ve devre dışı kullanıcı davranışını hedef yapılandırmayla sınayın.
• Proxy ve intelligence akışları için gereken outbound hedeflerini allowlist ile eşleştirin; beklenmeyen egress'i başarısızlık olarak kaydedin.
• Test başlangıcında boş veya bilinen bir baseline alın; önceki çalıştırmalardan kalan cache, task veya acceptance kayıtlarının sonucu etkilemesini önleyin.

Kabul sırası

1. Repository oluşturma, Hosted publish/download/restore ve immutable overwrite reddini çalıştırın.
2. Proxy connection/cache/negative-cache ile Group first-match sırasını ve anonymous proxy-only sınırını doğrulayın.
3. OSV full/incremental görevini, CycloneDX scan'i ve PASS/WARN/BLOCK/NOT_EVALUATED sonuçlarını kanıtlayın.
4. Risk acceptance oluşturma, reevaluation, expiry/revoke ve immutable history davranışını doğrulayın.
5. Cleanup dry-run, gerçek run, archive/restore ve storage transfer checksum kontrollerini tamamlayın.
6. Audit, Package Usage, Operation, Outbound ve task kayıtlarını giriş/çıkış kanıtıyla uzlaştırın.

Repository ve istemci kontrolleri

Üretimde kullanılacak her format ve repository tipi kendi gerçek istemcisiyle sınanmalıdır. Bir formatın tek bir modda geçmesi Hosted, Proxy ve Group davranışlarının tamamını kanıtlamaz.

• Hosted için yetkili publish, resolve/download, metadata görünürlüğü, checksum ve immutable sürüm üzerine yazma reddini kanıtlayın.
• Proxy için ilk upstream çekimi, cache hit, negative-cache süresi, upstream kesintisi ve yalnız izinli hedeflere outbound erişimi ayrı sonuçlar olarak kaydedin.
• Group için üye sırası, first-match sonucu, yetki kesişimi, bulunamayan paket ve bir üyenin erişilemez olduğu hata davranışını sınayın.
• Anonymous erişim kullanılacaksa yalnız onaylanan proxy okuma sınırında kaldığını; Hosted publish ve yönetim API'lerine taşmadığını doğrulayın.
• İstemci sürümü, kullanılan endpoint, repository URL'si, paket koordinatı ve istemcinin gerçek exit code/çıktısını kanıta ekleyin.

Güvenlik ve yönetişim kontrolleri

PASS, WARN veya BLOCK etiketi tek başına yeterli değildir; karar girdisi, kapsam, kullanıcıya yansıyan sonuç ve değiştirilemez geçmiş aynı correlation bağlamında uzlaştırılmalıdır.

• Organization, project ve repository kapsamlarında izin verilen ve reddedilen rol senaryolarını ayrı kullanıcılarla çalıştırın.
• Bilinen bir CycloneDX girdisini checksum ile saklayın; scan, finding, advisory ve policy evaluation zincirinin aynı girdiye bağlandığını doğrulayın.
• PASS, WARN, BLOCK ve bağlam yoksa NOT_EVALUATED sonuçlarını istemci davranışı, audit/operation kaydı ve cache/upstream etkisiyle karşılaştırın.
• Risk acceptance için kapsam, gerekçe, referans, actor ve expiry bilgisini; ardından reevaluation, revoke/expiry ve geçmişin korunmasını sınayın.
• API token'ı yalnız izin verilen scope ile sınayın; token değerini hiçbir kanıta yazmadan oluşturma, kullanma, reddetme ve iptal davranışını kaydedin.

Veri bütünlüğü ve kurtarılabilirlik

Silme, arşivleme ve storage değişikliği içeren akışlar yalnız görev tamamlandı etiketiyle kabul edilmemelidir. Metadata, nesne, checksum ve geri dönüş davranışı birlikte kontrol edilmelidir.

• Cleanup dry-run adaylarını gerçek çalıştırma öncesinde onaylayın; kapsam dışı ve saklama kuralınca korunan artifact'ların aday olmadığını gösterin.
• Archive/restore sonrasında paket istemcisiyle okuma yapın ve boyut/checksum değerini işlem öncesi baseline ile eşleştirin.
• Storage transferinde candidate, processed, failed ve byte sayaçlarını kaynak/hedef envanteriyle uzlaştırın; başarısız öğeleri tek tek görünür tutun.
• Backup/restore kanıtı yayımlanmamışsa dosya veya bucket kopyasını tam recovery kanıtı saymayın; PostgreSQL, artifact nesneleri ve raw SBOM için ortak recovery point isteyin.
• Rollback prova edilmediyse etkiyi, manuel geri dönüş adımlarını ve karar sahibini açık bir kanıt açığı olarak kaydedin.

Operasyon ve gözlemlenebilirlik

Her kritik senaryonun yönetim ekranı dışındaki operasyon izi de bulunmalıdır. Amaç yalnız sonucun oluştuğunu değil, bir işletim ekibinin sonucu izleyip açıklayabildiğini göstermektir.

• Task durum geçişlerini, retry/lease veya checkpoint bilgisini ve item-level hata özetlerini sonuç kaydıyla bağlayın.
• Audit, Package Usage, Operation ve Outbound kayıtlarında actor, zaman, hedef, sonuç ve correlation alanlarının tutarlı olduğunu kontrol edin.
• Health/readiness sinyallerini bağımlılık kesintileriyle sınayın; alarm eşiği ve operasyon sahibini kurumun izleme sisteminde belgeleyin.
• Loglarda secret, authorization header, cookie, SBOM içeriği veya gereksiz kişisel veri bulunmadığını örneklemle doğrulayın.

Bulgu sınıflandırma ve tekrar test

Başarısız bir kontrol silinmemeli veya yalnız serbest metinle kapatılmamalıdır. Üretim etkisi, yeniden üretim adımı, düzeltme referansı ve tekrar test sonucu ilk kanıtla ilişkilendirilmelidir.

• Bloker: veri kaybı/bütünlüğü, yetki aşımı, kritik paket akışının çalışmaması veya güvenli rollback bulunmaması; geçiş kararı verilemez.
• Yüksek: kritik olmayan fakat üretim güvenliğini ya da işletilebilirliği önemli ölçüde etkileyen açık; açık risk onayı olmadan kapatılamaz.
• Orta/düşük: etki, geçici önlem, owner ve hedef tarih tanımlıysa koşullu kabul adayına alınabilir.
• Tekrar test aynı test kimliğinin yeni çalıştırması olarak tarih, ortam farkı ve yeni kanıt bağlantısıyla kaydedilmelidir.

Kapanış kriterleri

• Her kritik akışta başarılı senaryo, yetki reddi, doğrulama hatası ve kurtarılabilir hata sonucu bulunur.
• Açık kalan konu yetkinlik olarak değil; sorumlu, hedef tarih ve gerekli kanıtla kanıt açığı olarak işaretlenir.
• Üretim onayı yalnız test kapsamı, rollback kararı ve platform sorumluları imzalandıktan sonra verilir.

Kanıt kayıt şablonu

Her test sonucu aynı alanlarla kaydedilirse farklı ekiplerin kanıtı yeniden çalıştırması ve release'ler arasında karşılaştırması kolaylaşır.

• Test kimliği, tarih/saat, uygulayan kişi ve onaylayan sorumlu
• Uygulama image/chart/source referansı ile PostgreSQL, storage ve istemci sürümleri
• Ön koşul, maskelenmiş giriş, tekrar edilebilir komut/aksiyon ve beklenen sonuç
• Gerçek sonuç, checksum, correlation/task/scan/audit kimliği ve kanıt bağlantısı
• Başarısızsa etki, recovery/rollback adımı, sorumlu ve tekrar test tarihi

Üretime geçiş kararı

Sonuçlar tek bir kapanış kaydında özetlenmeli; koşullu kabul kanıtsız bir tam kabul gibi sunulmamalıdır.

• Geçiş: tüm kritik kriterler geçti, rollback denendi ve operasyon sahipleri onayladı.
• Koşullu geçiş: yalnız düşük etkili açık maddeler için süreli risk sahibi ve geri dönüş tetikleyicisi tanımlandı.
• Geçiş yok: veri bütünlüğü, yetkilendirme, recovery, kritik format veya gözlemlenebilirlik kanıtı eksik.

Kabul sonrası kayıt

Onaylanan kapsam, kaynak snapshot'ı ve topoloji değişmeden saklanmalıdır. Image/chart, veritabanı migration'ı, storage, ingress, identity provider, istemci veya policy davranışı değiştiğinde etkilenen kontroller yeniden çalıştırılmalıdır.

Canlı demo doğrulaması — 1 Ağustos 2026

Demo oturumunda bu kontrol listesinin kapsadığı repository/artifact, intelligence, scan/policy, risk acceptance, task, audit, package usage, outbound, storage, proxy ve identity yönetim yüzeyleri salt-okunur olarak açıldı. Ancak liste aynı test kimliği altında baştan sona çalıştırılmadı; red/hata senaryoları, checksum zinciri, recovery/rollback ve imzalı kapanış kaydı üretilmedi. Bu nedenle doküman doğru biçimde Değerlendirme rehberi statüsündedir.