Yazılım ve veri bütünlüğü hataları

Yazılım artık tek bir ekibin yazdığı koddan ibaret değildir. Bir uygulama onlarca açık kaynak paketi, bir yapı hattı, bir konteyner imajı ve dış bir betik üstünde yükselir. Bütünlük hatası, bu zincirin herhangi bir halkasının doğrulanmadan güvenilmesidir. Bir güncelleme imzasız kurulur, bir paket sağlama toplamı denetlenmeden indirilir, bir betik bütünlük denetimi olmadan sayfaya eklenir.

Her durumda uygulama, iddia edilen içeriğin gerçekten o kaynaktan geldiğini kanıtlamadan kabul eder. OWASP bu riski 2025 listesinde iki ayrı başlıkta toplar ve ikisini de aynı soruya bağlar: bu içeriğin bütünlüğünü doğruladım mı? Soruyu sormayan her halka, saldırganın en sevdiği giriş noktasıdır.

2025 listesinde iki komşu başlık vardır. Yazılım ve veri bütünlüğü hataları, bir yazılımın ya da verinin bütünlüğünü imza ve sağlama toplamıyla doğrulamamaktır; güvensiz serileştirmeyi açma da bu başlığın altındadır. Yazılım tedarik zinciri hataları ise daha geniştir ve yazılımı kurma, dağıtma ya da güncelleme sürecindeki kırılmaları kapsar. Bu ikinci başlık 2021'deki eski ve zafiyetli bileşenler maddesini genişletti ve 2025 listesinde üçüncü sıraya çıktı, çünkü saldırganlar tek tek uygulamalar yerine onları besleyen zinciri hedef alıyor.

Ayrım basittir. Bütünlük başlığı doğrulama mekanizmasına bakar: imza var mı, sağlama toplamı denetleniyor mu? Tedarik zinciri başlığı ise kaynağın ve sürecin kendisine bakar: bu paket kimden geldi, hangi hatta üretildi?

2020 sonunda ortaya çıkan SolarWinds olayı bu riski görünür kıldı. Saldırganlar bir ağ izleme ürününün yapı sunucusuna sızıp resmî güncellemenin içine kod ekledi. İmza yine geçerli göründü, çünkü imzalama adımı kodun değiştirildiği andan sonra geldi. Yaklaşık on sekiz bin kurum bu güncellemeyi resmî diye kurdu ve olay aylarca fark edilmedi.

Buradaki ders nettir: imza, yalnız imzalanan şey gerçekten yapı hattından çıktığı hâliyle korunursa işe yarar. Yapıdan sonra araya giren bir değişiklik, geçerli bir imzanın arkasına rahatça saklanır. İmzayı erken atmak değil, doğru anda ve değişmeyen bir çıktı üstüne atmak önemlidir.

Bağımlılık karışıklığı farklı bir kapıdan girer. Şirket içi bir paket adını herkese açık bir pakethanede kimse almamışsa, saldırgan aynı adı kendi hesabında daha yüksek bir sürümle yayımlar. Paket yöneticisi çoğu zaman en yüksek sürümü seçer ve iç paketin yerine dışarıdaki sahteyi indirir.

Kurulum betiği çalıştığı an saldırganın kodu geliştiricinin makinesinde ya da yapı sunucusunda çalışır. Bu yöntem 2021'de pek çok büyük şirkette denendi ve sonuçlar sorumlu ifşayla bildirildi. Saldırı hiçbir sunucuyu doğrudan hedef almaz, yalnız paket yöneticisinin sürüm seçme kuralını kendi lehine çevirir.

Hile basit, etkisi büyüktür. Saldırganın tek bilmesi gereken, hedefin içeride hangi paket adlarını kullandığıdır; bu adlar çoğu zaman hata izlerinde ya da açık depolarda görünür.

Şema, güvenliğin tek bir noktada değil her aşamada kurulduğunu gösterir. Tasarımda tehdit modeli, kodda gözden geçirme, testte otomatik tarama çalışır. Yayın aşaması genelde en az denetlenen kısımdır, oysa saldırganın asıl hedefi burasıdır.

Yapı hattına yazma yetkisi olan biri, testi geçmiş kodu değiştirmeden yayına sokabilir. Bu yüzden yapı sunucusuna erişim en az yetki ilkesiyle sınırlanır, her adım kaydedilir ve üretilen paket bir imzayla mühürlenir. İmza, paketin tam olarak hattan çıktığı hâliyle kullanıcıya ulaştığını kanıtlar. İmza adımı yapının en sonunda, değişmeyen çıktı üstüne gelmelidir.

Daha yeni bir olay aynı dersi tazeledi. 2024'te yaygın sıkıştırma kütüphanesi xz-utils'in 5.6.0 ve 5.6.1 sürümlerine, iki yılı aşkın sürede güven kazanmış bir katkıcı eliyle gizli bir arka kapı yerleştirildi. Zararlı yük depoda sıradan test dosyaları gibi duruyordu. Onu çözüp yapıya katan betik ise yalnız yayımlanan sürüm arşivinde vardı.

Bir geliştirici, SSH girişlerinin beklenenden yavaş ve fazla işlemci harcadığını kurcalarken kapıyı fark etti. Olay, sürümler kararlı dağıtımlara geniş ölçüde girmeden durduruldu.

CISA, kütüphaneyi arka kapısız bir sürüme, örneğin 5.4.6'ya düşürmeyi önerdi. Buradaki ders şudur: güvenin kime verildiği de bir tedarik zinciri sorusudur. Tek bir güvenilen kişi, binlerce sistemin kapısını açabilir.

Bu olayları tespit etmek, kodu okumaktan çok süreci izlemektir. Yapı hattına kimin eriştiği, hangi bağımlılığın ne zaman eklendiği ve her yayının hangi imzayla çıktığı kayıt altına alınır. Beklenmedik bir saatte atılan bir yayın, imzasız çıkan bir paket ya da sürüm listesine sessizce giren yeni bir ad, erken birer işarettir.

Bir kurumun güvenlik ekibi bu yüzden yalnız ürünü değil, ürünü üreten hattı da bir varlık gibi korur. En zayıf halka çoğu zaman en az bakılan yerdir; görünürlük olmadan bu halkayı kimse fark etmez.

Kilit dosyası bağımlılık karışıklığına karşı ilk savunmadır. package-lock.json, poetry.lock ya da benzeri bir dosya her paketin tam sürümünü ve sağlama toplamını sabitler. Kurulum sırasında bir sağlama toplamı tutmazsa işlem durur.

İkinci savunma ad alanıdır: iç paketlere @altaykargo/ gibi bir kapsam verirsin ve bu kapsamı herkese açık kayıtta da kendi adına alırsın. Böylece dışarıda aynı adla sahte paket yayımlanamaz.

Üçüncüsü kaynak kilididir: kurulum o kapsam için yalnız kendi özel depondan çeker, herkese açık kayda hiç bakmaz. Yapı sunucusunda ise en az yetki geçerlidir; günlük bir geliştirici hesabı yayın imzasına erişmez. Bu dört önlem bir arada, sürüm seçme hilesini her yönden kapatır.

Donmuş kurulum bu savunmayı pratiğe döker. npm ci komutu, kilit dosyasındaki tam sürüm ve sağlama toplamını değiştirmeden kurar. package.json ile kilit dosyası birbirini tutmazsa komut hata verir ve kilidi güncellemek yerine durur.

Kurulumdan önce node_modules klasörünü tümden siler, yani eski ve beklenmedik bir paket geride kalmaz. npm install ise gerektiğinde kilidi güncelleyebilir, bu da sağlama toplamı korumasını zayıflatır. Bu yüzden yapı hattında kurulum install değil ci ile yapılır. Hat her çalıştığında aynı, doğrulanmış ağacı kurar; iki farklı makinede iki farklı sonuç çıkmaz.

Kilit dosyası neyin kurulacağını sabitler, ama kurulan sürümün bilinen bir açığı olup olmadığını söylemez. Bu ikinci soruyu tarama araçları cevaplar. npm audit ya da OSV-Scanner kilit dosyasını okur ve her paketi açık veritabanlarıyla karşılaştırır. Çıktıda paket adı, kullandığın sürüm, açığın kimliği ve varsa düzeltilmiş sürüm yer alır.

Doğru sıra şudur: hat önce donmuş kurulumla aynı ağacı kurar, sonra o ağacı tarar. Tarama kritik bir açık bulursa yapı durur. Bir sonraki soru, hattın ilk adımındaki o kurulum komutunu yazmanı ister.

Dış bir betik de tedarik zincirinin parçasıdır. Bir sayfa, bir dağıtım ağından JavaScript çekiyorsa, o betiği barındıran hesap ele geçtiğinde sayfaya kod ekleyen kişi sen değil o hesap olur. Alt kaynak bütünlüğü bu kapıyı kapatır. Betik etiketine beklenen içeriğin özetini integrity olarak, köken bilgisini de crossorigin olarak eklersin.

Tarayıcı betiği indirir, özetini hesaplar ve beklenen değerle karşılaştırır. Özet tutmazsa betiği yüklemez ve bir ağ hatası döner. Böylece dağıtım ağındaki hesap ele geçse bile değişmiş betik çalışmaz; adres aynı kalsa da içerik doğrulanır. Bu önlem, kendi sunucunda tutmadığın her dış dosya için düşünülmeye değer.

<script src="https://cdn.example/arayuz.min.js"
        integrity="sha384-PZ/9eJRnxql2PrG0jXa8mgua6TrrkjJc34DvTpw/nTlDvZTiR0NZWhdSNtWwvw6H"
        crossorigin="anonymous"></script>

Örneği oku. src, betiğin indirileceği adrestir. integrity alanı, güvendiğin sürümün sha384 özetini taşır; tarayıcı indirdiği içeriğin özetini bununla karşılaştırır. crossorigin gereklidir, çünkü başka kökenden gelen bir dosyada bütünlük denetimi yalnız CORS isteğiyle çalışır.

Birden çok özet verirsen tarayıcı en güçlü algoritmayla üretilenleri kullanır. Betik tek karakter bile değişse özet tutmaz ve yükleme durur. Böylece dağıtım ağının hesabına değil, içeriğin kendisine güvenirsin. Dikkat edilecek bir nokta var: özeti güncellemeyi unutma.

Betiğin meşru yeni bir sürümü çıktığında, etiketteki özeti de yeni sürüme göre yenilersin. Yoksa tarayıcı doğru betiği bile reddeder. Bu bakım yükü, hesap ele geçmesine karşı kazanılan güvenliğin yanında küçük kalır.

Aynı ilke konteyner imajlarında da geçerlidir. Herkese açık bir kayıttan çekilen bir imaj imzasızsa, o kaydın hesabı ele geçtiğinde imajın içeriği de değişebilir. Çalışan konteyner, iddia ettiği imajın aynısı olmayabilir.

İmza doğrulaması burada da aynı soruyu sorar: bu içerik gerçekten iddia ettiği yerden mi geldi? Üretim sunucuları yalnız imzalı imajları kabul edecek biçimde ayarlanırsa, değişmiş bir imaj imza tutmadığı için reddedilir. İmajı kendi özel kaydına kopyalamak ya da düşük yetkiyle çalıştırmak faydalı olsa da, imzasızlık sorununu tek başına çözmez. Kopyalanan imaj da imzasızsa, aynı belirsizliği taşır.

Düşük yetki ise olası zararı küçültür ama içeriğin doğru kaynaktan geldiğini kanıtlamaz. Çözüm, çıktının kaynağını kanıtlayan imzadır ve bu imzanın üretim sunucusunda zorunlu kılınmasıdır. Aşağıda Altay Kargo'nun portal imajı, çalıştırılmadan önce doğrulanıyor.

$ cosign verify registry.example/altay/portal:1.4.2 \
    --certificate-identity-regexp '^https://github.com/kurum/portal/' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com

Verification for registry.example/altay/portal:1.4.2 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

Komutu satır satır oku. İlk satır doğrulanacak imajı verir. --certificate-identity-regexp, imzanın kurumun kendi deposundaki yapı hattından gelmesini ister. Başka bir depodan atılmış geçerli bir imza bile bu yüzden reddedilir.

--certificate-oidc-issuer, o kimliği hangi sağlayıcının verdiğini sabitler; burada yapı hattının kimlik sağlayıcısıdır. Çıktıdaki üç satır üç denetimi anlatır: imza iddiaları tutuyor, imza herkese açık şeffaflık kaydında var, imzalayan sertifika güvenilen bir köke bağlanıyor. Kimlik ya da sağlayıcı tutmazsa komut hata verir ve imaj çalışmaz. Üretimde bu denetimi elle değil, kümeye giren her imajı yoklayan bir kabul denetleyicisiyle otomatik yaparsın.