Teknik değerlendirmeyi doğrulanabilir adımlara ayırın

Beklenen çıktılar ve karar sahipliği

Değerlendirme başlamadan önce kimin testi yöneteceğini, kanıtı inceleyeceğini ve üretim kararını vereceğini yazılı hale getirin. Teknik test sonucu tek başına üretim onayı değildir.

• Değerlendirme sahibi kapsamı, takvimi, senaryo kimliklerini ve kanıt deposunu yönetir.
• Ürün sahibi beklenen iş akışını ve hangi sapmaların kabul edilebilir olduğunu onaylar.
• Platform sahibi topoloji, kapasite, gözlemlenebilirlik, backup/recovery ve rollback kanıtını onaylar.
• Güvenlik onaylayanı rol sınırları, secret kullanımı, politika kararı, audit izi ve açık riskleri inceler.
• Son teslim paketi; kapsam kaydı, yürütülen senaryolar, kanıt indeksi, bulgu listesi, tekrar testleri ve imzalı karardan oluşur.

Giriş kapısı

Aşağıdaki ön koşullardan biri eksikse ilgili senaryoyu başarısız saymak yerine BLOCKED olarak kaydedin; eksik ön koşulu ürün davranışıyla karıştırmayın.

• Üretim verisi içermeyen izole test ortamı, değiştirilemez image/chart referansı ve kaydedilmiş kaynak kanıtı
• Çalışır PostgreSQL, seçilen filesystem/S3 storage, DNS, ingress/TLS ve gerekli outbound erişim
• Ayrı yönetici, operatör ve sınırlı kullanıcı hesapları; token ve parolalar için onaylı secret kaynağı
• Kontrollü artifact ve CycloneDX test girdileri, beklenen checksum'lar ve güvenli silme planı
• Audit, task, scan, package-usage ve outbound kayıtlarını okuyacak erişim ile zaman senkronizasyonu

Başlamadan önce kapsamı dondurun

Sonuçların karşılaştırılabilir olması için test ortamını ve kabul matrisini uygulama başlamadan kaydedin. Kapsam değişirse mevcut sonucu sessizce güncellemek yerine yeni bir değerlendirme revizyonu açın.

• Organization, project, repository adı/tipi, format, gerçek istemci ve istemci sürümü
• Uygulama image digest'i, chart ve values revizyonu, PostgreSQL sürümü, storage profili ve ağ topolojisi
• Test kullanıcıları, roller, access-policy kapsamı, kimlik sağlayıcı ve kullanılacak secret kaynağı
• Beklenen istemci exit code'u, PASS/WARN/BLOCK veya NOT_EVALUATED sonucu ve toplanacak kayıt kimlikleri
• Kapasite ve süre hedefleri kurum tarafından sağlanmamışsa bunları ürün varsayımı olarak üretmeyin; açık gereksinim olarak kaydedin.

Değerlendirme sırası

Her aşama bir sonraki aşamanın giriş koşulunu ve kanıt listesini üretir. Kritik bir sınır başarısız olduğunda bağımlı senaryoları yürütmeden önce bulguyu sınıflandırın.

1. Kullanılan paket istemcilerini, formatları ve Hosted/Proxy/Group repository modlarını envanterleyin.
2. Uygulama, PostgreSQL, storage, kimlik, ingress/TLS ve outbound ağ topolojisini çıkarın.
3. Önce kimlik ve yetki sınırlarını, sonra repository ve artifact happy-path akışlarını çalıştırın.
4. Proxy, SBOM, politika, risk kabulü, cleanup ve storage gibi asenkron veya güvenlik etkili akışları sınayın.
5. Bağımlılık kesintisi, tekrar deneme, rollback/recovery ve operasyon görünürlüğünü inceleyin.
6. Bulguları tekrar test edin; karar sahipleri kanıt indeksini incelemeden sonuç yayımlamayın.

Asgari senaryo kataloğu

Her senaryoya değişmez bir kimlik verin ve başarılı, reddedilen ve geri kazanılabilir hata yollarını ayrı kayıtlar olarak çalıştırın. Kapsam dışı senaryolar N/A gerekçesiyle görünür kalmalıdır.

• EV-001 Kimlik ve RBAC: oturum açma, geçerli rol, yetersiz rol, organization/project/repository kapsam ayrımı ve oturum sonlandırma
• EV-010 Hosted: gerçek istemciyle publish, metadata görünürlüğü, indirme, checksum karşılaştırması, yeniden yayınlama ve yetkisiz istek
• EV-020 Proxy: cache miss, upstream fetch, cache hit, upstream kesintisi, izinli/reddedilen istek ve kayıt izi
• EV-030 Group: üye sırası, ilk eşleşme, bulunamayan paket, yetki farkı ve aynı koordinatın birden çok üyede bulunması
• EV-040 SBOM/politika: bilinen CycloneDX girdisi, bulgular, PASS/WARN/BLOCK, risk kabulü, reevaluation ve CI exit code'u
• EV-050 Yaşam döngüsü: cleanup dry-run, yürütme sınırı, archive/restore veya yeniden yükleme ve storage transfer sayaçları
• EV-060 Operasyon: health/readiness, task hata/retry izi, audit, Package Usage, Operation ve Outbound kayıtlarının uzlaştırılması

Format ve repository kapsam matrisi

Bir formatın listelenmesi her repository modunun ve her istemci sürümünün kabul edildiği anlamına gelmez. Üretimde kullanılacak her kombinasyonu gerçek istemciyle bağımsız bir satır olarak doğrulayın.

• Satır anahtarı: format + istemci/sürüm + işletim sistemi + Hosted/Proxy/Group + authentication yöntemi
• Hosted için publish, resolve/download, metadata ve overwrite/redeploy davranışını kaydedin.
• Proxy için upstream URL'si, cache miss/hit, metadata, timeout ve upstream hata davranışını kaydedin.
• Group için üye sırası, ilk eşleşme, fallback, yetki ve çakışan koordinat davranışını kaydedin.
• Raw ve sınırlı uyumluluklar dahil olmak üzere desteklenmeyen işlemleri açıkça N/A veya FAIL olarak ayırın; sessizce kapsam dışına çıkarmayın.

Güvenlik ve yönetişim testleri

Pozitif erişim testi tek başına yeterli değildir. Aynı nesne üzerinde izin verilen ve reddedilen aktörleri, policy sonucunu ve sunucu tarafı kayıt izini karşılaştırın.

• Yönetici, operatör ve sınırlı kullanıcının organization, project ve repository işlemlerini ayrı hesaplarla çalıştırın.
• API token'ını en düşük gerekli scope ile kullanın; token değerini ekran görüntüsü, komut, log veya kanıt dosyasına yazmayın.
• PASS, WARN, BLOCK ve bağlam yoksa NOT_EVALUATED kararlarını istemci sonucu, policy evaluation ve audit/operation kaydıyla uzlaştırın.
• Risk kabulünde kapsam, gerekçe, referans, actor, expiry, revoke/expiry ve reevaluation davranışını doğrulayın.
• Log örneklerinde authorization header, cookie, parola, token, registry credential veya gereksiz kişisel veri bulunmadığını kontrol edin.

SBOM, politika ve CI kapısı

Kontrollü CycloneDX girdisinin checksum'ını saklayın; aynı girdiden oluşan scan, component, finding ve policy-evaluation zincirini tek test kimliği altında doğrulayın.

• Bilinen temiz, uyarı üreten ve bloklanması beklenen en az üç ayrı girdi kullanın; beklenen sonucu test başlamadan yazın.
• CLI yapılandırma kaynağını, CLI sürümünü, project/environment kapsamını ve gerçek exit code'u kaydedin.
• Asenkron değerlendirmede timeout ve yeniden sorgulama davranışını; aynı girdinin tekrar gönderiminde oluşan kayıtları inceleyin.
• Risk kabulü veya policy değişikliğinden sonra yeni değerlendirmeyi geçmiş sonucu silmeden ilişkilendirin.

Veri yaşam döngüsü ve operasyon dayanıklılığı

Cleanup, storage transferi, backup/recovery ve rollback farklı kanıt düzeyleridir. Bir görevin tamamlandı görünmesi tek başına veri bütünlüğü veya geri kazanılabilirlik kanıtı değildir.

• Cleanup dry-run adaylarını kapsam ve retention kuralıyla karşılaştırın; gerçek yürütmeden sonra metadata, nesne ve sayaçları uzlaştırın.
• Storage transferinde candidate, processed, failed ve byte sayaçlarını kaynak/hedef envanteriyle karşılaştırın; başarısız öğeleri görünür tutun.
• PostgreSQL, artifact nesneleri ve raw SBOM aynı recovery noktasına geri yüklenmediyse backup/restore kontrolünü PASS vermeyin.
• Bağımlılık kesintilerinde readiness, kullanıcıya yansıyan hata, task retry/checkpoint ve toparlanma süresini kaydedin.
• Kontrollü rollback veya forward-recovery prova edilmemişse üretim etkisini ve karar sahibini açık kanıt açığı olarak bırakın.

Kanıt paketi

Her senaryonun kanıtı yalnız ekran görüntüsünden oluşmamalıdır. Tekrar üretilebilir girdi, zaman damgası, beklenen ve gerçek sonuç ile ilgili sistem kayıtlarını aynı test kimliği altında birleştirin.

• Çalıştırılan secret içermeyen komut veya adımlar, istemci sürümü, UTC zaman damgası ve gerçek exit code/çıktı
• Artifact, image veya SBOM için checksum/digest ve kaynak dosyanın erişimi kısıtlı test kopyası
• Correlation, task, scan, policy-evaluation, audit ve gerektiğinde package-usage/outbound kimlikleri
• Başarılı akışın yanında yetki reddi, validation hatası, dependency failure ve toparlanma sonucu
• Açık kalan her konu için severity, üretim etkisi, sorumlu, gerekli kanıt, hedef tarih ve tekrar test kimliği

İndirilebilir değerlendirme planı

Şablonu her değerlendirme için kopyalayın; placeholder alanlarını doldurun ve secret değerlerini hiçbir zaman dosyaya eklemeyin. actual/result alanları yürütme öncesinde NOT_RUN kalmalıdır.

evaluation:
  id: "SK-EVAL-YYYY-NNN"
  name: "Smart Kubaba technical evaluation"
  owner: "<evaluation-owner>"
  approvers:
    product: "<product-owner>"
    platform: "<platform-owner>"
    security: "<security-approver>"
  window:
    startsAt: "YYYY-MM-DDTHH:mm:ssZ"
    endsAt: "YYYY-MM-DDTHH:mm:ssZ"
  evidenceRoot: "<restricted-evidence-location>"

target:
  environment: "<evaluation-environment>"
  sourceEvidence: "c1be012"
  imageDigest: "<immutable-image-digest>"
  chartVersion: "<chart-version>"
  databaseVersion: "<postgresql-version>"
  storageProfile: "<filesystem-or-s3-profile>"
  ingressAndTlsProfile: "<ingress-and-ca-profile>"

clients:
  - id: "CLIENT-01"
    format: "<maven-npm-docker-pypi-etc>"
    repositoryMode: "<hosted-proxy-group>"
    client: "<real-client-name>"
    version: "<client-version>"
    operatingSystem: "<os-and-version>"

scenarios:
  - id: "EV-001"
    title: "<scenario-title>"
    owner: "<executor>"
    prerequisites: ["<prerequisite>"]
    input: "<artifact-sbom-or-request-reference>"
    expected: "<observable-outcome>"
    actual: "NOT_RUN"
    result: "NOT_RUN" # PASS | FAIL | BLOCKED | NOT_RUN
    evidence:
      clientOutput: "<path-or-record-id>"
      checksum: "<sha256-when-applicable>"
      taskOrScanId: "<identifier-when-applicable>"
      auditOrCorrelationId: "<identifier-when-applicable>"
    finding: "<finding-id-or-null>"

decision:
  outcome: "NOT_DECIDED" # PROCEED | CONDITIONAL_PROCEED | DO_NOT_PROCEED
  conditions: []
  decidedAt: null
  approvedBy: []

Bulgu, tekrar test ve kapanış

Başarısız veya engellenmiş bir kontrolü silmeyin. İlk kanıtı koruyun; düzeltme ve tekrar testi yeni, bağlantılı kayıtlar olarak ekleyin.

• P0/Bloker: yetki aşımı, veri kaybı veya bütünlük riski, kritik istemci akışının çalışmaması ya da güvenli recovery yolunun bulunmaması
• P1/Yüksek: hedef kapsamda önemli güvenlik, operasyon veya gözlemlenebilirlik boşluğu; üretim öncesi kapanmalıdır.
• P2/Koşullu: açık etkisi, geçici kontrolü, sahibi ve kapanış tarihi bulunan; karar sahiplerince yazılı kabul edilebilen boşluk
• Tekrar test kaydı ilk senaryo/bulgu kimliğini, uygulanan düzeltmeyi, yeni kanıtı ve sonucu onaylayan kişiyi içermelidir.

Karar standardı

Bir yetkinliği yalnız başarılı senaryoda çalıştığı için kabul etmeyin. Kapsamdaki istemciler, yetki sınırları, hata davranışı, geri dönüş planı ve operasyon sahipliği birlikte onaylanmalıdır. Kanıtı bulunmayan başlık kabul değil, kanıt açığı olarak kalır.

• PROCEED: tüm kapsam satırları yürütülmüş, P0/P1 açık değil, recovery sınırı biliniyor ve ürün/platform/güvenlik sahipleri kanıtı onaylamıştır.
• CONDITIONAL_PROCEED: yalnız yazılı etkisi, geçici kontrolü, sahibi ve kapanış tarihi bulunan koşullu maddeler açıktır.
• DO_NOT_PROCEED: yetki/veri bütünlüğü ihlali, kritik akış başarısızlığı, doğrulanmamış recovery veya karar vermeye yetecek kanıtın bulunmaması söz konusudur.
• Sayısal puan kritik bir kontrolü telafi etmez; karar her zaman kapsam, bulgu ve onay kayıtlarıyla birlikte yayımlanır.

Yeniden doğrulama tetikleyicileri

Onay belirli release ve topoloji içindir. Aşağıdaki değişikliklerden etkilenen senaryolar yeniden açılmalı; önceki kanıt Superseded olarak korunmalıdır.

• Uygulama image'i, Helm chart/values, veritabanı migration'ı veya PostgreSQL sürümü
• Storage backend'i, bucket/path düzeni, ingress/TLS, DNS, proxy veya outbound ağ politikası
• Kimlik sağlayıcı, rol/access policy, token scope'u veya secret rotation yöntemi
• Paket istemcisi/sürümü, repository modu, upstream kaynağı, policy veya intelligence verisi
• Üretim yük profili, kapasite hedefi, RTO/RPO gereksinimi veya operasyon sahibi

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

Denetlenen kaynak snapshot'ıyla çalışan demo üzerinde Repository, Artifact, Sources, Scan History, Policy, Risk Acceptances, intelligence/cleanup-storage task'ları ile Audit, Package Usage ve Outbound kayıt ekranları kimlik doğrulanmış, salt-okunur oturumda başarıyla açıldı. Bu kontrol değerlendirme yüzeylerinin mevcut olduğunu doğrular; kontrollü test girdisi, yetki reddi, hata enjeksiyonu, rollback ve sorumlu onayı üretmediği için sayfanın durumu Değerlendirme rehberi olarak kalır.