Tekrarlanabilir SARIF delta kararıyla release kapısı kurun

1. İşi ve kanıt sınırını tanımlayın

İki geçerli SARIF raporu arasındaki güvenlik değişimi, scanner’ın değişebilen etiketi yerine kararlı konum ve kural kanıtlarıyla yeniden üretilebilir mi?

Başlamadan önce karar sahibini, kabul eşiğini, başarısızlıkta yapılacak işlemi ve saklanacak artifact’leri yazın. Böylece araç sonucu sonradan amaca göre yorumlanmaz.

2. Hazırlık ve doğrulama yöntemi

1. Her iki belgeyi SARIF 2.1.0 yapısına karşı fail-closed doğrulayın; sürüm, runs, results, locations ve execution notifications kusurlarını sessizce yutmayın.
2. Bulguları kural kimliği, normalize edilmiş fiziksel konum, mesaj ve kısmi fingerprint kanıtlarıyla eşleyin. Araç adı ya da sonuç sırası tek başına kimlik değildir.
3. Yeni bulgu, çözülmüş bulgu, devam eden bulgu ve şiddet artışını ayrı sayın; suppress edilmiş kayıtların bütçeye girip girmediğini politikada görünür tutun.
4. Aynı girdi byte’ları ve politika için deterministik artifact üretin; kararın kapsamadığı tarama kalitesini veya release güvenliğini receipt’e yazmayın.

Bozuk, eksik veya kapsamı karşılaştırılamayan girdide güvenilir karar üretilemiyorsa süreç fail-closed kalmalıdır. INDETERMINATE, eksik kanıtı PASS gibi göstermemek için gerçek bir sonuç sınıfıdır.

3. Cerrahi rollout sırası

1. Baseline’ın commit, tarayıcı sürümü, kural paketi ve kapsamını değiştirilemez build artifact’i olarak kaydedin.
2. Release bütçesini repo politikası içinde incelemeye açın; suppression ve execution failure davranışını açıkça seçin.
3. Aday taramayı aynı kapsamda çalıştırın, schema doğrulamasından geçmeyen dosyada gate’i durdurun.
4. Delta artifact’lerini PR’a ekleyin; reviewer’a yeni, artan, çözülen ve eşlenemeyen bulguları ayrı gösterin.
5. Merge kararını receipt ve exact input hash’leriyle arşivleyin; güvenlik taramasının yerine geçmediğini koruyun.

4. Kaçınılacak kısa yollar

5. Güvenli işlenmiş örneği yeniden üretin

Önce sentetik fixture byte’larını doğrulayın, sonra Türkçe çalışma tezgâhında yükleyin. Üretilen artifact’lerin hash’lerini receipt ile karşılaştırın; sayfadaki açıklamayı yeni bir run sonucu sanmayın.

• baseline.sarifSHA-256 fbc18d49e1f35752fce06eadeab57d7af9458db849f68a78a24bfb06f52c7c22
• candidate-pass.sarifSHA-256 fbc18d49e1f35752fce06eadeab57d7af9458db849f68a78a24bfb06f52c7c22
• candidate-block.sarifSHA-256 b1c23c9d0b42814927795cb5e7c87c1d7a766c54cd31c00479441bf4c91bff09

Fixture beklenen davranışı göstermiyorsa gerçek veriye geçmeyin. Sorunu, tarayıcı sürümünü, dosya hash’ini ve gözlenen sonuç sınıfını düzeltme kanalına ekleyin.

6. Kabul, durdurma ve kayıt kararı

PASS yalnız seçili politika içinde kabul anlamına gelir. BLOCK, tanımlı eşik aşıldığı için ilerlemenin durmasıdır. INDETERMINATE ise girdinin veya motor kanıtının güvenilir karar için yetersiz olduğunu söyler. Her üç sonuçta da exact input hash, artifact hash’leri, araç sürümü, varsayımlar ve sınırlar korunmalıdır.

Yöntem sınırı ve gizlilik

Araç kodu taramaz, zafiyetin sömürülebilirliğini doğrulamaz, suppression gerekçesini onaylamaz ve release’in güvenli olduğunu garanti etmez. Sonuç yalnız sağlanan iki rapor, eşleme yöntemi ve seçili yerel bütçe için geçerlidir.

Ham kullanıcı girdisi analitiğe gönderilmemelidir. Dosya adı, sorgu metni, kişisel veri veya içerik byte’ları yerine yalnız allowlist tool slug, result sınıfı, artifact sayısı ve sample işareti gibi operasyonel alanlar kullanılmalıdır.

Kaynaklar

• OASIS SARIF 2.1.0 final standardı
• OASIS SARIF 2.1.0 final JSON Schema
• GitHub: SARIF dosyası desteği
• GitHub: code scanning sonuçlarını değerlendirme