SLSA: Yazılımın Kaynak Koddan Pakete Güven Zinciri

SLSA nedir sorusu, bir yazılım dosyasının yalnızca zararlı kod içerip içermediğini değil, gerçekten iddia edilen kaynak koddan ve güvenilir bir derleme sürecinden üretilip üretilmediğini anlamak isteyen ekiplerin karşısına çıkar.

Modern bir uygulama tek bir geliştiricinin bilgisayarında yazılıp doğrudan kullanıcıya gönderilmez. Kaynak kod; sürüm kontrol sistemi, pull request süreci, CI/CD platformu, bağımlılıklar, derleyiciler, container image araçları, paket kayıt sistemleri ve dağıtım platformlarından geçer.

Bu zincirin herhangi bir noktasına müdahale edilirse kaynak kod doğru görünmesine rağmen son kullanıcıya farklı veya değiştirilmiş bir paket ulaşabilir.

Supply-chain Levels for Software Artifacts ifadesinin kısaltması olan SLSA, yazılım tedarik zincirindeki güvenlik uygulamalarını aşamalı olarak geliştirmek için oluşturulmuş bir teknik şartname ve güvence modelidir.

SLSA doğrudan antivirüs, zafiyet tarayıcısı veya kod analiz aracı değildir. Yazılımın hangi kaynaktan, hangi süreçle, hangi derleme platformunda ve hangi girdiler kullanılarak üretildiğini kanıtlamaya yardımcı olan kurallar ve doğrulanabilir kayıtlar sunar.

Modelin merkezinde provenance ve attestation kavramları bulunur. Provenance, yazılım paketinin üretim geçmişini açıklar. Attestation ise bu geçmiş veya başka bir güvenlik özelliği hakkında belirli bir kimlik tarafından oluşturulan doğrulanabilir beyanı ifade eder.

Bu rehberde SLSA v1.2 yapısını, Build ve Source Track seviyelerini, provenance doğrulamasını, SBOM ile farkını ve CI/CD süreçlerinde nasıl uygulanabileceğini inceleyeceğiz.

SLSA Nedir?

SLSA, yazılım tedarik zincirinin güvenliğini aşamalı seviyeler üzerinden geliştirmeyi amaçlayan bir şartnamedir.

Hem yazılım üreticileri hem de yazılım tüketicileri için kullanılabilir:

• Üretici, yazılımının güvenilir süreçlerle oluşturulduğunu kanıtlayabilir.
• Tüketici, aldığı paketin beklenen kaynaktan ve derleme sisteminden geldiğini doğrulayabilir.
• Platform ekibi, CI/CD altyapısının hangi güvence seviyesini sağladığını gösterebilir.
• Güvenlik ekibi, yalnızca dosyaya değil üretim zincirine politika uygulayabilir.

SLSA “salsa” şeklinde telaffuz edilir. Yaklaşım tek adımda kusursuz güvenlik beklemek yerine ekiplerin düşük bir seviyeden başlayıp güvence düzeyini aşamalı olarak yükseltmesine dayanır.

SLSA Bir Sertifika mıdır?

SLSA’nın kendisi her yazılım için merkezi bir sertifika düzenleyen kuruluş değildir. Üreticiler ve platformlar, şartnamedeki gereksinimleri uygulayarak belirli güvence seviyelerine ulaşabilir.

Tüketici tarafında ise yalnızca “SLSA uyumlu” ifadesine güvenmek yerine artifact, provenance, imza ve güvenilir builder kimliği doğrulanmalıdır.

SLSA Neden Gereklidir?

Bir yazılımın kaynak kodunu incelemek, indirilen çalıştırılabilir dosyanın aynı kaynak koddan üretildiğini tek başına kanıtlamaz.

Aradaki build sürecinde şu riskler ortaya çıkabilir:

• CI/CD hesabının ele geçirilmesi
• Derleme betiğinin değiştirilmesi
• Resmî olmayan kaynak deposundan build alınması
• Artifact’in build sonrasında değiştirilmesi
• Paket kayıt sistemine sahte sürüm yüklenmesi
• İmzalama anahtarının çalınması
• Bir build çalışmasının başka çalışmayı etkilemesi
• Geliştirici bilgisayarından kontrolsüz yayın yapılması
• Release tag’inin başka commit’e taşınması

SLSA bu risklerin tamamını aynı seviyede çözmez. Her seviye belirli tehditlere karşı daha güçlü güvence sağlar.

Yazılım Tedarik Zinciri Nedir?

Yazılım tedarik zinciri, kaynak kodun yazılmasından son kullanıcıya veya üretim ortamına ulaşmasına kadar geçen bütün sistem ve işlemleri kapsar.

SLSA’nın Temel Kavramları

Software Artifact Nedir?

Artifact, geliştirme veya build süreci sonunda üretilen ve dağıtılabilen yazılım çıktısıdır.

Artifact Örnekleri

• Çalıştırılabilir uygulama dosyası
• Java JAR veya WAR paketi
• npm paketi
• Python wheel dosyası
• NuGet paketi
• Android APK veya AAB dosyası
• Container image
• Firmware dosyası
• Derlenmiş kütüphane
• Dağıtım arşivi

SLSA doğrulamasında artifact genellikle kriptografik digest ile tanımlanır. Böylece aynı ada sahip fakat içeriği değiştirilmiş dosyalar birbirinden ayrılabilir.

Provenance Nedir?

Provenance, bir yazılım artifact’inin üretim geçmişini açıklayan metadata’dır.

Türkçede köken, menşe veya üretim geçmişi olarak açıklanabilir.

Provenance İçinde Bulunabilecek Bilgiler

• Artifact’in kriptografik özeti
• Build işlemini yapan platformun kimliği
• Kullanılan kaynak deposu
• Kaynak kodun commit veya revision bilgisi
• Kullanılan build türü
• Build parametreleri
• Build zamanı
• Build sırasında çözümlenen girdiler
• Build işleminin tamamlanma durumu

Provenance, “Bu paket güvenlidir” şeklinde genel bir iddia değildir. Daha çok “Bu digest’e sahip paket, belirtilen builder tarafından, belirtilen kaynak ve build süreciyle üretildi” şeklinde doğrulanabilir bir üretim kaydıdır.

Provenance Tek Başına Yeterli mi?

Hayır. Provenance oluşturulmuş fakat imzalanmamışsa saldırgan tarafından değiştirilmesi kolay olabilir. İmzalı olsa bile doğrulanmıyorsa yalnızca depolanan bir metadata dosyası olarak kalır.

Attestation Nedir?

Attestation, yazılım artifact’i veya üretim süreci hakkında belirli bir kimliğin oluşturduğu doğrulanabilir beyan anlamına gelir.

Attestation Örnekleri

• Build provenance
• SBOM
• Zafiyet tarama sonucu
• Test sonucu
• Kod inceleme kaydı
• Lisans tarama sonucu
• Kaynak güvence seviyesi

Attestation’ın anlamlı güvenlik sağlaması için üç sorunun cevaplanması gerekir:

1. Beyan gerçekten beklenen kimlik tarafından mı oluşturuldu?
2. Beyan, kullanılan artifact’e gerçekten ait mi?
3. Beyandaki bilgiler kuruluşun güvenlik politikasına uyuyor mu?

SLSA Track Yapısı

SLSA v1.2, güvenlik gereksinimlerini farklı tedarik zinciri alanlarına ayıran track yapısını kullanır.

Build Track

Kaynak kodun artifact’e dönüştürüldüğü build sürecinin güvenliğine odaklanır.

Source Track

Kaynak kod değişikliklerinin nasıl oluşturulduğu, saklandığı, korunduğu ve incelendiğiyle ilgilenir.

Bir kuruluş Build L3 seviyesine ulaşırken kaynak kod yönetiminde daha düşük bir Source seviyesinde kalabilir. Seviyeler track bazında değerlendirilmelidir.

SLSA Build Track

SLSA Build Level 1

Build L1 seviyesinde artifact’in nasıl oluşturulduğunu gösteren provenance bulunmalıdır.

Temel Beklentiler

• Tutarlı bir build süreci kullanılmalıdır.
• Build platformu provenance üretmelidir.
• Provenance artifact ile birlikte tüketiciye sunulmalıdır.
• Artifact kriptografik digest ile tanımlanmalıdır.
• Kaynak ve build süreci hakkında temel bilgi bulunmalıdır.

Build L1 Ne Sağlar?

Yanlış commit’ten veya hatalı build sürecinden yayın yapılması gibi operasyonel hataların tespit edilmesini kolaylaştırır.

Build L1’in Sınırlaması

Provenance eksik veya imzasız olabilir. Kasıtlı saldırgan tarafından taklit edilmesine karşı güçlü güvence sağlamaz.

SLSA Build Level 2

Build L2, build işleminin hosted bir platformda gerçekleştirilmesini ve provenance’ın platform tarafından doğrulanabilir biçimde oluşturulmasını gerektirir.

Temel Özellikler

• Build, yönetilen veya hosted bir platformda çalışır.
• Provenance build platformu tarafından oluşturulur.
• Provenance’ın gerçekliği doğrulanabilir.
• Tüketici, imzayı veya eş değer kimlik doğrulamasını kontrol eder.
• Artifact digest’i provenance ile eşleştirilir.

Build L2 Hangi Riski Azaltır?

Artifact’in derlendikten sonra değiştirilmesi veya provenance’ın sahte bir dosyayla değiştirilmesi daha kolay tespit edilebilir.

Hosted Platform Neden Önemlidir?

Build kayıtlarının yalnızca geliştiricinin kontrolündeki bilgisayarda üretilmesi yerine, kimliği ve güvenlik sınırları tanımlanmış platform tarafından oluşturulmasını sağlar.

SLSA Build Level 3

Build L3, güçlendirilmiş ve izole build ortamı gerektirir.

Temel Güvenceler

• Farklı build çalışmaları birbirini etkileyememelidir.
• Kullanıcı tarafından tanımlanan build adımları provenance imzalama sırrına ulaşamamalıdır.
• Provenance build platformunun güven sınırı içinde oluşturulmalıdır.
• Build ortamında kalıcı müdahale ihtimali azaltılmalıdır.
• Artifact’in resmî kaynak ve süreçten üretildiğine ilişkin güçlü kanıt sağlanmalıdır.

Build İzolasyonu Ne Anlama Gelir?

Bir build sırasında bırakılan dosya, süreç veya yapılandırmanın sonraki build çalışmasını etkilememesi gerekir.

Geçici ve tek kullanımlık runner kullanımı, ağ kısıtlamaları ve kısa ömürlü kimlik bilgileri bu amaca katkıda bulunabilir.

Build L3 Her Şeyi Çözer mi?

Hayır. Güvenilir kabul edilen build platformunun kendisi kötü niyetli bir yönetici tarafından kontrol ediliyorsa SLSA seviyesi tek başına tam koruma sağlamaz. Hangi builder kimliklerinin güvenilir kabul edildiği dikkatle yönetilmelidir.

SLSA Source Track

Source Track, kaynak kodun belirli bir revision hâline nasıl geldiğini ve bu süreçte hangi teknik kontrollerin uygulandığını ele alır.

SLSA Source Level 1

Source L1 seviyesinde kaynak kod modern bir sürüm kontrol sistemi içinde saklanır ve yönetilir.

Temel Özellikler

• Kaynak deposu benzersiz biçimde tanımlanabilir.
• Her revision benzersiz bir kimliğe sahiptir.
• Değişiklikler insanlar tarafından incelenebilir biçimde gösterilebilir.
• Belirli bir kaynak anına geri dönülebilir.

Git yaygın bir örnektir fakat SLSA Source Track yalnızca Git kullanımını zorunlu tutmaz.

SLSA Source Level 2

Source L2 seviyesinde değişiklik geçmişinin güvenilir biçimde korunması ve source provenance oluşturulması beklenir.

Temel Kontroller

• Branch geçmişi korunur.
• Kimlerin hangi değişikliği yaptığı kaydedilir.
• Force push gibi geçmişi değiştiren işlemler sınırlandırılır.
• Release tag’lerinin taşınması veya silinmesi engellenir.
• Source revision için provenance üretilir.
• Kullanıcı ve otomasyon kimlikleri doğrulanır.

Bu seviye, kaynak kodun yalnızca mevcut hâlini değil, o hâle nasıl ulaştığını da incelemeyi mümkün kılar.

SLSA Source Level 3

Source L3, kuruluşun tanımladığı teknik kontrollerin protected branch ve tag’lerde sürekli olarak uygulanmasını ister.

Teknik Kontrol Örnekleri

• CI testleri geçmeden merge yapılamaması
• Belirli güvenlik taramalarının zorunlu olması
• İmzalı commit veya tag politikası
• Secret scanning kontrolü
• Belirli ekiplerden onay alınması
• Doğrudan main branch’e push yapılmasının engellenmesi

Kontrolün yalnızca dokümana yazılması yeterli değildir. Kaynak kontrol sistemi tarafından teknik olarak uygulanması ve uygulandığına ilişkin kanıt üretilmesi gerekir.

SLSA Source Level 4

Source L4 seviyesinde protected branch’e giren değişiklikler iki güvenilir kişi tarafından değerlendirilmelidir.

İki Taraflı İnceleme

Kabul edilebilir örnekler şunlardır:

• Değişikliği yükleyen kişi ve farklı bir güvenilir inceleyici
• Değişikliği hazırlayandan farklı iki güvenilir inceleyici

Neden Önemlidir?

Tek bir geliştiricinin veya ele geçirilmiş tek hesabın kaynak kodu kontrolsüz biçimde değiştirme olasılığını azaltır.

Son Değişiklik de İncelenmeli mi?

Evet. İnceleme tamamlandıktan sonra koda yeni değişiklik eklenirse son revision da yeniden değerlendirilmelidir.

Build Track ile Source Track Arasındaki Fark

Güvenilir kaynak yönetimi, güvenli build olmadan yeterli değildir. Benzer şekilde güvenli build platformu da kaynak deposuna kötü niyetli kodun onaylı biçimde girmesini engelleyemez.

SLSA ile SBOM Arasındaki Fark

SBOM, yazılım içerisinde hangi bileşenlerin ve bağımlılıkların bulunduğunu gösteren envanterdir.

SLSA ise yazılımın hangi kaynak ve süreç kullanılarak üretildiğine ilişkin güvence sağlar.

SBOM’un yapısı hakkında ayrıntılı bilgi için SBOM Nedir? rehberini inceleyebilirsiniz.

Dijital İmza ile SLSA Arasındaki Fark

Dijital imza, artifact’in imzalandıktan sonra değiştirilip değiştirilmediğini ve imzayı hangi kimliğin oluşturduğunu doğrulamaya yardımcı olur.

Ancak yalnızca imzaya bakmak şu soruları cevaplamayabilir:

• Artifact hangi kaynak deposundan üretildi?
• Hangi commit kullanıldı?
• Hangi build platformu çalıştı?
• Hangi build parametreleri kullanıldı?
• Build ortamı izole miydi?

SLSA provenance bu bağlamı sunar. Dijital imza ise provenance’ın ve artifact’in gerçekliğini doğrulamak için kullanılabilecek mekanizmalardan biridir.

SLSA Hangi Tehditleri Azaltır?

Resmî Olmayan Kaynaktan Build

Provenance doğrulaması kaynak deposunun veya revision’ın beklenen değerle eşleşmediğini gösterebilir.

Build Sonrasında Artifact Değiştirme

Artifact digest’i provenance ile eşleşmezse doğrulama başarısız olur.

Sahte Provenance Oluşturma

Doğrulanabilir platform kimliği ve imza kullanımı, sahte provenance’ın tespit edilmesine yardımcı olur.

Build Çalışmaları Arasında Müdahale

Build L3 izolasyonu, bir çalışmanın başka bir çalışmaya dosya veya süreç bırakmasını engellemeyi amaçlar.

Tek Hesapla Kaynak Değişikliği

Source L4’teki iki taraflı inceleme, tek kişinin kontrolsüz biçimde protected branch’e değişiklik eklemesini zorlaştırır.

Registry veya Aktarım Müdahalesi

Tüketici artifact’i kendisi doğruladığında registry ya da aktarım sırasında değiştirilen dosyayı tespit edebilir.

SLSA Artifact Doğrulaması Nasıl Yapılır?

Provenance üretilmesi yeterli değildir. Dağıtım veya kullanım öncesinde otomatik olarak doğrulanmalıdır.

Birinci Adım: Artifact Digest’ini Kontrol Edin

Provenance içindeki subject digest ile kullanılacak dosyanın digest’i eşleşmelidir.

İkinci Adım: İmzayı Doğrulayın

Provenance’ın gerçekten beklenen platform veya kimlik tarafından oluşturulduğu doğrulanmalıdır.

Üçüncü Adım: Builder Kimliğini Kontrol Edin

Her imzalayan builder güvenilir kabul edilmemelidir. Kuruluşun izin verdiği builder kimlikleri tanımlanmalıdır.

Dördüncü Adım: Kaynak Depoyu Karşılaştırın

Artifact’in kuruluş tarafından kabul edilen resmî repository’den üretildiği doğrulanmalıdır.

Beşinci Adım: Build Parametrelerini İnceleyin

Build türü ve dışarıdan verilen parametreler beklenen politika ile karşılaştırılmalıdır.

Altıncı Adım: Politika Kararı Verin

Doğrulama başarılı değilse artifact registry’ye kabul edilmemeli veya üretim ortamına dağıtılmamalıdır.

CI/CD Sürecine SLSA Nasıl Eklenir?

Kaynak Deposu

• Main ve release branch’lerini koruyun.
• Force push işlemini sınırlandırın.
• Pull request incelemesini zorunlu kılın.
• Gerekli test ve taramaları merge koşulu yapın.
• Yönetici işlemlerini kayıt altına alın.

Build Platformu

• Geliştirici bilgisayarından üretim build’i yayımlamayın.
• Tek kullanımlık veya temiz runner tercih edin.
• Build sırasında uzun ömürlü anahtar kullanmayın.
• Build girdilerini açıkça tanımlayın.
• Provenance’ı otomatik oluşturun.

Artifact Registry

• Dosyaları digest ile tanımlayın.
• Yalnızca güvenilir CI kimliğinin yayın yapmasına izin verin.
• Provenance ve diğer attestations kayıtlarını saklayın.
• Değiştirilemez sürüm politikaları kullanın.

Dağıtım Platformu

• Dağıtımdan önce provenance doğrulaması yapın.
• Kaynak repository ve builder allowlist kullanın.
• Tag yerine mümkün olduğunda digest kullanın.
• Başarısız doğrulamada dağıtımı engelleyin.

GitHub Actions ile SLSA

GitHub Actions, binary ve container image gibi çıktılar için artifact attestations oluşturabilir.

Genel İş Akışı

1. Kaynak kod protected branch üzerinden build sürecine girer.
2. GitHub Actions artifact’i üretir.
3. Artifact’in digest’i hesaplanır.
4. Build provenance attestation oluşturulur.
5. Attestation platform kimliğiyle ilişkilendirilir.
6. Artifact ve attestation registry’ye gönderilir.
7. Tüketici veya dağıtım sistemi attestation’ı doğrular.

Reusable Workflow Yaklaşımı

Build ve provenance üretimini merkezi reusable workflow içinde toplamak, ekiplerin kendi workflow dosyalarında imzalama sürecini değiştirmesini zorlaştırabilir.

Dikkat Edilecek Nokta

Yalnızca YAML dosyasına attestation adımı eklemek yeterli değildir. Repository izinleri, workflow kimliği, runner güvenliği ve tüketici tarafındaki doğrulama da yapılandırılmalıdır.

Kubernetes Dağıtımlarında SLSA Doğrulaması

Kubernetes admission controller, cluster’a gönderilen container image’ın provenance ve diğer attestations kayıtlarını doğrulayabilir.

Örnek Politika

• Image yalnızca izin verilen registry’den gelmelidir.
• Image digest ile sabitlenmiş olmalıdır.
• Build provenance bulunmalıdır.
• Provenance güvenilir builder tarafından oluşturulmalıdır.
• Kaynak repository kuruluşun resmî deposu olmalıdır.
• Minimum Build L2 veya L3 gereksinimi sağlanmalıdır.

Bu politika, yalnızca image adını ve tag’ini kontrol etmekten daha güçlü güvence sağlayabilir.

Kimliklere otomatik güven verilmemesi yaklaşımı için Zero Trust Mimarisi Nedir? içeriğini inceleyebilirsiniz.

Kuruluşlar İçin SLSA Uygulama Yol Haritası

Aşama 1: Envanter

• Kaynak depolarını listeleyin.
• Build platformlarını belirleyin.
• Artifact ve container registry’lerini bulun.
• Üretim dağıtım yollarını çıkarın.

Aşama 2: Kaynak Kod Kontrolleri

• Main ve release branch’lerini koruyun.
• Kimlik doğrulamasını merkezîleştirin.
• Değişiklik geçmişinin değiştirilmesini önleyin.
• Kod inceleme politikasını oluşturun.

Aşama 3: Build L1

• Tutarlı build süreci tanımlayın.
• Her artifact için provenance üretin.
• Artifact digest’lerini saklayın.

Aşama 4: Build L2

• Build işlemlerini hosted platforma taşıyın.
• Provenance’ı platform kimliğiyle doğrulanabilir hâle getirin.
• Dağıtım öncesi imza kontrolü ekleyin.

Aşama 5: Build L3

• Build çalışmalarını birbirinden izole edin.
• İmzalama materyalini build script’lerinden ayırın.
• Kısa ömürlü kimlikler kullanın.
• Builder güvenliğini düzenli değerlendirin.

Aşama 6: Politika Uygulama

• Registry kabul kuralları oluşturun.
• Kubernetes admission politikaları ekleyin.
• Minimum SLSA seviyesini risk bazlı belirleyin.
• Başarısız doğrulamaları görünür hâle getirin.

Örnek Saldırı ve Savunma Senaryosu

Normal Süreç

Bir ekip, Git deposundaki v2.4.0 tag’ini kullanarak container image oluşturur ve registry’ye gönderir.

Saldırı

Saldırgan bir geliştiricinin registry parolasını ele geçirir. Kendi bilgisayarında zararlı değişiklik içeren farklı bir image üretir ve aynı sürüm adıyla registry’ye yüklemeye çalışır.

Yalnızca Tag Kontrol Ediliyorsa

Dağıtım sistemi image adını ve v2.4.0 tag’ini gördüğü için zararlı image’ı kabul edebilir.

SLSA Doğrulaması Kullanılıyorsa

Dağıtım sistemi şu kontrolleri yapar:

• Image digest’i provenance ile eşleşiyor mu?
• Provenance güvenilir CI platformundan mı geldi?
• Kaynak repository resmî depo mu?
• Build türü beklenen workflow mu?
• Artifact minimum güvence seviyesini sağlıyor mu?

Saldırgan yalnızca registry parolasına sahip olduğu için güvenilir builder tarafından oluşturulmuş geçerli provenance üretemez ve dağıtım engellenir.

SLSA’nın Sınırlamaları

Kaynak Kodun Güvenli Olduğunu Kanıtlamaz

Resmî kaynak kodun kendisi güvenlik açığı veya kötü niyetli iş mantığı içerebilir.

Bağımlılık Risklerinin Tamamını Çözmez

Build provenance girdileri gösterebilir fakat her bağımlılığın güvenli olduğunu otomatik olarak kanıtlamaz.

Güvenilir Builder Seçimi Gerektirir

Doğrulama sistemi hangi builder kimliklerine güvenileceğini bilmelidir. Yanlış root of trust yapılandırması güvenceyi zayıflatır.

Operasyonel Karmaşıklık Ekleyebilir

Provenance saklama, anahtar veya kimlik yönetimi, politika motoru ve doğrulama araçları kurulmalıdır.

Eski Sistemler Desteklemeyebilir

Legacy build platformlarının otomatik provenance üretmesi veya güçlü izolasyon sağlaması zor olabilir.

Tek Başına Uyum Kanıtı Değildir

SLSA, güvenli yazılım geliştirme programının yalnızca bir bölümüdür. Kod güvenliği, zafiyet yönetimi, erişim kontrolü ve olay müdahalesi ayrıca uygulanmalıdır.

SLSA Kontrol Listesi

SLSA Uygulamasında Sık Yapılan Hatalar

• SLSA’yı yalnızca bir belge üretme işi sanmak
• Provenance oluşturup hiçbir yerde doğrulamamak
• Artifact digest’ini provenance ile eşleştirmemek
• Her imzalayan kimliği güvenilir kabul etmek
• Geliştirici bilgisayarından üretim paketi yayımlamak
• Uzun ömürlü registry anahtarlarını build içinde kullanmak
• Build runner’larını temizlemeden tekrar kullanmak
• Tag’in değişmez olduğunu varsaymak
• Kaynak branch korumasını yalnızca prosedüre bırakmak
• Build ve Source seviyelerini birbirine karıştırmak
• SBOM bulunduğu için provenance’a ihtiyaç olmadığını düşünmek
• Dijital imzanın bütün build sürecini açıkladığını varsaymak
• Yalnızca üretici beyanına güvenmek
• Dağıtım sistemine politika eklememek
• Builder platformunun güvenliğini değerlendirmemek
• Legacy build’leri görünmez biçimde istisna tutmak

SLSA İçin Güvenilir Kaynaklar

• SLSA v1.2 Güncel Şartname
• SLSA Hakkında
• SLSA Build Track Seviyeleri
• SLSA Source Track Gereksinimleri
• SLSA Artifact Doğrulama Rehberi
• GitHub Artifact Attestations
• NIST Secure Software Development Framework
• TeknoTürkiye – SBOM Nedir?
• TeknoTürkiye – GitOps Nedir?
• TeknoTürkiye – Infrastructure as Code Nedir?

SLSA Hakkında Sık Sorulan Sorular

SLSA nedir?

Yazılımın kaynak kod, build ve dağıtım zincirinde değiştirilme riskini azaltmak için aşamalı güvenlik seviyeleri tanımlayan tedarik zinciri güvenliği şartnamesidir.

SLSA neyin kısaltmasıdır?

Supply-chain Levels for Software Artifacts ifadesinin kısaltmasıdır.

SLSA nasıl okunur?

Genellikle “salsa” şeklinde telaffuz edilir.

Güncel SLSA sürümü hangisidir?

Güncel onaylı sürüm SLSA v1.2’dir.

SLSA v1.2 ne zaman yayımlandı?

24 Kasım 2025 tarihinde yayımlandı.

SLSA v1.2 ile ne değişti?

Kaynak kod yönetimini kapsayan Source Track eklendi ve şartname birden fazla track yapısına göre düzenlendi.

SLSA bir güvenlik aracı mıdır?

Hayır. Araçların ve platformların uygulayabileceği gereksinimleri, seviyeleri ve kanıt modellerini tanımlayan şartnamedir.

SLSA bir sertifika mıdır?

Merkezi olarak her yazılıma verilen standart bir sertifika değildir. Belirli build ve kaynak süreçlerinin şartnamedeki seviyeleri sağlaması amaçlanır.

SLSA Build seviyeleri nelerdir?

Build L0, L1, L2 ve L3 seviyeleri bulunur. L0 belirli güvence bulunmadığını ifade eder.

SLSA Source seviyeleri nelerdir?

Source L1, L2, L3 ve L4 seviyeleri bulunur.

Build L1 ne sağlar?

Artifact’in nasıl üretildiğini gösteren provenance’ın bulunmasını sağlar.

Build L2 ne sağlar?

Hosted build platformu tarafından oluşturulan ve gerçekliği doğrulanabilen provenance gerektirir.

Build L3 ne sağlar?

Build çalışmaları arasında izolasyon ve provenance imzalama materyalinin build adımlarından korunması gibi güçlü kontroller gerektirir.

Source L4 ne anlama gelir?

Protected branch’e giren değişikliklerin iki güvenilir kişi tarafından değerlendirilmesini gerektirir.

Provenance nedir?

Bir yazılım paketinin hangi kaynak, builder, parametre ve girdiler kullanılarak üretildiğini açıklayan metadata’dır.

Attestation nedir?

Bir yazılım artifact’i veya üretim süreci hakkında doğrulanabilir biçimde oluşturulan beyan veya kanıttır.

SLSA ile SBOM aynı mıdır?

Hayır. SBOM yazılımın bileşenlerini, SLSA ise üretim zincirinin ve build sürecinin bütünlüğünü ele alır.

SBOM ve SLSA birlikte kullanılır mı?

Evet. SBOM içerik görünürlüğü, SLSA ise üretim geçmişi ve bütünlük güvencesi sağlar.

Dijital imza SLSA yerine geçer mi?

Hayır. İmza dosyanın gerçekliğini doğrulamaya yardımcı olur ancak build’in kaynak ve süreç ayrıntılarını tek başına açıklamaz.

SLSA yazılımdaki zafiyetleri bulur mu?

Hayır. Zafiyet taraması ayrı kontroller gerektirir. SLSA, ağırlıklı olarak tedarik zinciri bütünlüğüne odaklanır.

SLSA zararlı kodu engeller mi?

Zararlı kodun tedarik zincirine yetkisiz biçimde eklenmesini zorlaştırabilir. Fakat zararlı kod resmî süreçte onaylanırsa bunu otomatik olarak tespit etmez.

Provenance imzalanmalı mı?

Build L2 ve üzerindeki güvence için provenance’ın gerçekliği doğrulanabilir olmalıdır. Dijital imza bunun yaygın yöntemlerinden biridir.

Provenance neden doğrulanmalıdır?

Doğrulanmayan provenance, saldırganın değiştirebileceği sıradan bir metadata dosyası olarak kalabilir.

Builder kimliği nedir?

Artifact’i üreten build platformunu veya workflow’u tanımlayan kimliktir.

Root of Trust nedir?

Doğrulama sisteminin hangi builder, sertifika, imza veya kimliklere güveneceğini belirleyen temeldir.

SLSA GitHub Actions ile kullanılabilir mi?

Evet. GitHub Actions artifact attestations ve reusable workflow yapılarıyla build provenance oluşturabilir.

SLSA GitLab ile kullanılabilir mi?

Şartname belirli tek bir platformla sınırlı değildir. Gerekli provenance ve güvenlik kontrollerini sağlayan farklı CI/CD sistemlerinde uygulanabilir.

SLSA Kubernetes’te nasıl kullanılır?

Admission controller veya politika motoru, yalnızca güvenilir builder tarafından oluşturulmuş ve doğrulanmış image’ların cluster’a alınmasını sağlayabilir.

Container image tag’i yeterli midir?

Hayır. Tag’ler değiştirilebilir. Dağıtımlarda image digest’i ve doğrulanabilir provenance kullanmak daha güçlü güvence sağlar.

Küçük ekipler SLSA uygulayabilir mi?

Evet. Önce kaynak kodu sürüm kontrolüne almak ve otomatik provenance üretmek gibi düşük maliyetli adımlarla başlanabilir.

Her yazılım Build L3 olmalı mı?

Gereken seviye yazılımın riskine göre belirlenmelidir. Kritik sistemler daha yüksek güvence gerektirebilir.

SLSA DevSecOps’un yerini alır mı?

Hayır. DevSecOps programı içinde yazılım tedarik zinciri bütünlüğünü güçlendiren bir model olarak kullanılır.

SLSA SSDF ile ilişkili midir?

SLSA uygulamaları, NIST Secure Software Development Framework içerisindeki provenance ve yazılım tedarik zinciri güvenliği çalışmalarını destekleyebilir.

Reproducible build SLSA için zorunlu mudur?

Güncel Build Track seviyelerinin tamamında her yazılım için tam reproducible build zorunluluğu bulunmaz. Ancak tekrar üretilebilirlik ek güvence sağlayabilir.

Build provenance nerede saklanmalıdır?

Artifact ile güvenilir biçimde ilişkilendirilebilen registry, attestation servisi veya paket ekosistemi içinde saklanabilir.

SLSA doğrulaması ne zaman yapılmalıdır?

Artifact registry’ye kabul edilirken, bağımlılık olarak alınırken ve üretim ortamına dağıtılmadan önce yapılabilir.

SLSA Nedir? Sonuç

SLSA nedir sorusunun temel cevabı, yazılımın kaynak koddan dağıtılabilir pakete kadar uzanan üretim zincirini doğrulanabilir ve aşamalı güvenlik kontrolleriyle koruyan bir şartname olduğudur.

SLSA yalnızca dosyanın imzalı olmasına değil, hangi kaynak koddan, hangi builder tarafından ve hangi build süreciyle üretildiğine ilişkin kanıt bulunmasına odaklanır.

Build L1 provenance görünürlüğü sağlar. Build L2 hosted build platformu ve doğrulanabilir provenance gerektirir. Build L3 ise build izolasyonu ve imzalama bilgilerinin kullanıcı tanımlı işlemlerden korunması gibi daha güçlü kontroller sunar.

Source Track; sürüm kontrolü, değişiklik geçmişi, sürekli teknik politikalar ve iki taraflı kod incelemesiyle kaynak kodun nasıl oluştuğunu güvence altına alır.

SBOM yazılımın içinde hangi bileşenlerin bulunduğunu gösterirken SLSA bu yazılımın nasıl üretildiğine ilişkin güven sağlar. Bu nedenle iki yaklaşım birbirinin alternatifi değil, tamamlayıcısıdır.

Provenance üretmek tek başına yeterli değildir. Artifact digest’i, provenance imzası, builder kimliği, kaynak repository ve build parametreleri dağıtım öncesinde otomatik olarak doğrulanmalıdır.

Kuruluşlar önce kaynak ve build envanterini çıkarmalı, ardından düşük seviyelerden başlayıp risklerine uygun Build ve Source seviyelerine aşamalı biçimde ilerlemelidir.