Yazılım tedarik zinciri güvenlik politikası, yalnızca açık kaynak paketlerini taramakla sınırlı olmamalıdır; ticari yazılımlar, bulut hizmetleri, CI/CD araçları ve tedarikçi erişimleri de aynı çerçevede yönetilmelidir.
KOBİ’ler için en pratik başlangıç, görünür bir envanter oluşturmak, sorumluları atamak ve risk seviyesine uygun kontrolleri seçmektir. SBOM ve bağımlılık tarama platformları görünürlüğü artırabilir, ancak sonuçları değerlendirecek süreç olmadan tek başına yeterli değildir.
Araç lisansı, entegrasyon yükü, ekip zamanı ve gerekirse güvenlik danışmanlığı birlikte değerlendirilmelidir. Politikanın amacı sıfır risk sözü vermek değil, kritik bileşenlerde karar alma ve müdahale süresini daha yönetilebilir hale getirmektir.
Bir Bakışta
- İlk öncelik, kullanılan yazılımları, bağımlılıkları, bulut servislerini ve sorumlularını görünür hale getirmektir.
- SBOM ve bağımlılık taraması, özellikle orta ve ileri seviye kontrollerde bileşen riskini takip etmeyi kolaylaştırabilir.
- Araç seçimi, lisansın yanında entegrasyon, eğitim, yönetim süresi ve destek kapsamı üzerinden yapılmalıdır.
| Kontrol seviyesi | Uygun durum | Öncelikli kontroller | Karar odağı |
|---|---|---|---|
| Temel | Sınırlı yazılım portföyü ve küçük ekip | Varlık envanteri, güncelleme takibi, erişim kayıtları | Süreç sahipliği ve düzenli takip |
| Orta | Kendi yazılımını geliştiren veya çok sayıda tedarikçi kullanan ekip | SBOM, bağımlılık taraması, tedarikçi değerlendirmesi | Platform entegrasyonu ve tarama kapsamı |
| İleri | Kritik hizmet, yoğun CI/CD kullanımı veya yüksek operasyonel bağımlılık | Yetki sınırlandırma, imzalama, sürekli izleme, olay tatbikatı | İç uzmanlık, yönetilen hizmet ve danışmanlık dengesi |
Güvenlik politikasının ilk hedefi: görünür envanter ve sorumluluk dağılımı
Bir politikanın ilk çıktısı uzun bir doküman değil, hangi bileşenin nerede kullanıldığını gösteren güvenilir bir envanter olmalıdır. Açık kaynak bağımlılıkları, üçüncü taraf kütüphaneler, ticari yazılımlar, CI/CD araçları, bulut servisleri ve dış kaynak geliştiriciler aynı risk görünümünde ele alınmalıdır. Envanter eksikse bir güvenlik açığının hangi ürünü veya hizmeti etkilediğini anlamak zorlaşır.
İlk üç adım: kritik yazılımları, bağımlılıkları ve sahiplerini belirleme
Önce iş açısından kritik uygulamalar belirlenir. Ardından bu uygulamaların kullandığı paketler, üçüncü taraf servisler, güncelleme kanalları ve kod depoları listelenir. Her kayıt için bir iş sahibi ve mümkünse teknik sorumlu atanması, güncelleme veya zafiyet bildirimi geldiğinde kararın sahipsiz kalmasını önler.
Yönetim, geliştirme, BT ve satın alma ekiplerinin görev sınırları
Yönetim risk önceliklerini ve kaynak kullanımını onaylar. Geliştirme ekibi bağımlılıkları, kod depolarını ve CI/CD akışlarını yönetir. BT ekibi erişim, kayıt ve hizmet sürekliliği kontrollerinde rol alır. Satın alma ise tedarikçi değerlendirmesi, sözleşme kapsamı, destek koşulları ve veri işleme maddelerini takip eder. Tek bir ekibin tüm süreci sahiplenmesi yerine görev sınırlarının yazılı olması daha işletilebilir bir model sunar.
Üst yönetim için kısa risk özeti nasıl hazırlanır?
Özet; kritik sistemleri, bilinen bağımlılık görünürlüğünü, açık kararları ve kaynak ihtiyacını sade biçimde göstermelidir. Teknik ayrıntı yerine “hangi hizmet etkilenebilir, düzeltme için hangi ekip gerekir, tedarikçi desteği var mı?” sorularına yanıt vermek daha yararlıdır. Etki; bileşenin kritikliği, internete açıklık durumu, istismar olasılığı ve düzeltme imkânına göre değerlendirilmelidir.
Hangi kontroller gerçekten gerekli? Risk seviyesine göre karşılaştırma
Her kurumun aynı kapsamda güvenlik platformuna ihtiyacı olmayabilir. Buna karşılık, yalnızca en ucuz aracı seçmek de görünmeyen yönetim yükü yaratabilir. Doğru seviye; yazılım üretim modeli, tedarikçi sayısı, teknik ekip kapasitesi ve kritik hizmetlerin yapısına göre seçilmelidir.
Temel seviye: varlık envanteri, güncelleme takibi ve erişim kayıtları
Temel seviyede hedef, kullanılan yazılım ve hizmetleri takip edebilmek, güncelleme sorumluluğunu belirlemek ve erişim hareketlerini kayıt altına almaktır. Özellikle yönetici hesapları, kod deposu erişimleri ve bulut servislerindeki yetkiler gözden geçirilmelidir. Bu seviyede bile gizli anahtarların korunması ve erişimlerin gereksiz genişletilmemesi önemlidir.
Orta seviye: SBOM, bağımlılık taraması ve tedarikçi değerlendirmesi
SBOM, yazılım ürünündeki bileşenleri ve bağımlılıkları görünür kılmak için kullanılabilir. Bağımlılık tarama platformu, bu envanterin güncel kalmasına ve incelenmesi gereken bileşenlerin öne çıkmasına yardımcı olabilir. Ancak tarama sonucu otomatik olarak iş etkisini göstermez; ilgili bileşenin kurum mimarisindeki kullanımı ayrıca incelenmelidir. Tedarikçiler için güvenlik bildirimi, destek kapsamı ve veri işleme koşulları da değerlendirme sürecine dahil edilmelidir.
İleri seviye: CI/CD güvenliği, imzalama, sürekli izleme ve olay tatbikatı
CI/CD süreçlerinde yetki sınırlandırma, gizli anahtarların güvenli yönetimi ve kayıtların izlenmesi temel alanlardır. İleri seviye yaklaşımda yazılım artefaktlarının güvenilirliği, değişikliklerin izlenebilirliği ve olay anındaki iletişim akışı da ele alınır. Olay tatbikatı, ekibin gerçek bir bildirim veya kritik bağımlılık sorunu karşısında kimin ne yapacağını test etmek için kullanılabilir.
Araç lisansı, ekip zamanı ve dış hizmet maliyetini birlikte değerlendirme
Güvenlik aracı bütçesi yalnızca yıllık lisans maliyetinden oluşmaz. Kullanıcı ve depo sayısı, tarama sıklığı, mevcut araçlarla entegrasyon ihtiyacı, eğitim, yönetim süresi ve destek seviyesi toplam sahip olma maliyetini etkiler. İç ekip sonuçları yorumlayacak kapasiteye sahip değilse, yönetilen hizmet veya güvenlik danışmanlığı seçeneği ayrıca değerlendirilebilir.
Politika oluşturma süreci: envanterden onaya kadar pratik adımlar
İşletilebilir politika, ekiplerin günlük kararlarında kullanabileceği açık kurallar içerir. Çok genel ifadeler yerine hangi durumun kim tarafından onaylanacağı, hangi kayıtların tutulacağı ve istisnaların nasıl ele alınacağı tanımlanmalıdır.
Yazılım, bulut hizmeti ve üçüncü taraf bileşen listesini çıkarma
Liste; geliştirilen ürünleri, hazır yazılımları, SaaS çözümlerini, bulut servislerini, açık kaynak paketlerini ve dış kaynak geliştirme ilişkilerini kapsamalıdır. Her kalem için kullanım amacı, sorumlu kişi, erişim türü ve güncelleme kaynağı not edilebilir. Bu liste, sonraki SBOM talebi veya tedarikçi kontrolü için temel oluşturur.
Kabul edilen risk, yasaklı bileşen ve onay akışı tanımlama
Politikada hangi risklerin geçici olarak kabul edilebileceği, hangi bileşenlerin ek inceleme gerektirdiği ve kimlerin onay vereceği belirtilmelidir. Kritik bir bileşen için istisna veriliyorsa gerekçe, sorumlu ve gözden geçirme zamanı kayıt altına alınmalıdır. Böylece “acil ihtiyaç” gerekçesi kalıcı ve görünmez bir riske dönüşmez.
Güncelleme, zafiyet düzeltme ve istisna süreçlerini yazılı hale getirme
Bir güncelleme bildirimi geldiğinde ilk değerlendirmeyi kimin yapacağı, etkilenen sistemin nasıl belirleneceği ve tedarikçi desteğinin ne zaman devreye alınacağı açık olmalıdır. Düzeltmenin hemen yapılamadığı durumlarda geçici önlem, kabul eden kişi ve yeniden değerlendirme adımı tanımlanmalıdır. Süreler kurumun sözleşmesel ve sektörel yükümlülüklerine göre değişebilir.
Politikanın test edilmesi ve periyodik gözden geçirme takvimi
Politika yayımlandıktan sonra örnek bir bileşen bildirimi veya erişim değişikliği üzerinden test edilebilir. Envanterin, SBOM kayıtlarının ve tedarikçi bilgilerinin güncelliği düzenli olarak gözden geçirilmelidir. Yeni bir bulut hizmeti, yeni dış kaynak ekip veya önemli mimari değişiklik olduğunda politika kapsamı tekrar kontrol edilmelidir.
Sık yapılan hatalar ve risk azaltma yolları
Sadece açık kaynak paketlerine odaklanmak
Açık kaynak paketleri önemli olsa da ticari yazılımlar, güncelleme kanalları, SaaS hizmetleri ve tedarikçi erişimleri de tedarik zincirinin parçasıdır. Kapsamı yalnızca paket taramasına indirgemek, kritik bağımlılıkları görünmez bırakabilir.
SBOM oluşturup güncel tutmamak
SBOM, ürün değiştikçe güncellenmediğinde karar değeri azalır. Envanter üretim süreciyle ilişkilendirilmeli; yeni bağımlılık, sürüm değişikliği veya dağıtım sonrasında gözden geçirilecek bir akış kurulmalıdır.
Tedarikçi güvenlik beyanını doğrulamadan kabul etmek
Tedarikçi beyanı tek başına yeterli kanıt olarak görülmemelidir. Sözleşmedeki bildirim süreleri, destek kapsamı, veri işleme koşulları ve erişim yetkileri incelenmelidir. Gereken doğrulama düzeyi hizmetin kritikliğine göre belirlenmelidir.
Gizli anahtarları CI/CD kayıtlarında veya kod depolarında bırakmak
Gizli anahtarlar, erişim belirteçleri ve benzeri bilgiler için ayrı koruma yaklaşımı gerekir. CI/CD kayıtlarının izlenmesi, erişimlerin sınırlandırılması ve kod depolarındaki yetkilerin düzenli kontrolü bu riski azaltmaya yardımcı olur.
Kurum tipine göre uygulanabilir politika örnekleri
Kendi ürününü geliştiren SaaS ekipleri
Bu ekipler için bağımlılık görünürlüğü, SBOM üretimi, kod deposu yetkileri ve CI/CD kontrolleri önceliklidir. Bağımlılık tarama platformu seçerken mevcut geliştirme akışına entegrasyon ve sonuçların geliştirici ekip tarafından yönetilebilir olması değerlendirilmelidir.
Hazır yazılım ve bulut hizmeti kullanan KOBİ’ler
Hazır yazılım kullanan kurumlarda tedarikçi sözleşmesi, güncelleme kanalı, destek kapsamı ve kullanıcı erişimleri öne çıkar. Envanterde hangi iş biriminin hangi SaaS hizmetini kullandığı net olmalıdır. Satın alma sürecine kısa bir güvenlik kontrolü eklemek, sonradan oluşabilecek belirsizliği azaltabilir.
Dış kaynak yazılım geliştirme hizmeti alan kurumlar
Dış kaynak ekiplerin kod depolarına, bulut ortamlarına ve gizli bilgilere erişimi net sınırlarla tanımlanmalıdır. Teslim edilen yazılımın bileşen görünürlüğü için SBOM talebi değerlendirilebilir. Sözleşmede olay bildirimi, erişimin sonlandırılması ve destek sorumlulukları açık yazılmalıdır.
Düzenlemeye tabi sektörlerde ek doğrulama ihtiyacı
Düzenlemeye tabi alanlarda kurumun sözleşmesel veya sektörel yükümlülükleri ek kontroller gerektirebilir. Zorunlu politika maddeleri her kurum için aynı değildir. Hukuki, finansal veya düzenleyici uygunluk konusunda yetkin uzman görüşü gerekebilir.
Seçim kriterleri ve karşılaştırma özeti
Güvenlik platformu, danışmanlık veya yönetilen hizmet seçerken şu noktaları birlikte kontrol edin:
- Tarama kapsamı açık kaynak bağımlılıklarını, ticari yazılımları ve gerekli entegrasyonları ne ölçüde destekliyor?
- Lisans modeli kullanıcı, depo, tarama sıklığı ve destek seviyesine göre nasıl değişiyor?
- Mevcut CI/CD, kod deposu ve bulut servisleriyle entegrasyon için ne kadar ekip zamanı gerekiyor?
- Sonuçları inceleme, istisna yönetimi ve raporlama için iç ekip kapasitesi yeterli mi?
- Destek SLA’sı, veri saklama koşulları ve tedarikçi olay bildirim süreci teklifte açık mı?
- Deneme ortamında kurumun gerçek depo ve iş akışıyla sınırlı bir doğrulama yapılabiliyor mu?
Teklif kapsamını, deneme ortamı koşullarını ve destek SLA’sını aynı karar tablosunda karşılaştırmak; yalnızca lisans bedeline göre seçim yapmaktan daha sağlıklı bir yaklaşım olur. Resmî kapsam, entegrasyon şartları ve destek ayrıntıları ilgili sağlayıcının teklif ve sözleşme belgelerinden kontrol edilmelidir.
Sonuç
Yazılım tedarik zinciri güvenliği, tek seferlik bir araç satın alma projesi değildir. Envanter, sorumluluk, tedarikçi kontrolü ve olay yönetimi aynı politikanın parçalarıdır. Küçük bir ekip temel kontrollerle başlayıp ihtiyaç arttıkça SBOM, bağımlılık taraması ve CI/CD güvenliği gibi alanları genişletebilir. En önemli nokta, seçilen kontrolün ekip tarafından sürdürülebilir biçimde işletilebilmesidir.
Bilmekte Fayda Var
SBOM, bileşen görünürlüğü sağlayabilir; ancak bir açığın gerçek etkisi, kurumun mimarisi ve bileşeni kullanma şekli incelenmeden kesinleşmez.
Tedarikçi sözleşmesi, teknik güvenlik araçları kadar önemlidir; bildirim süresi, destek kapsamı ve veri işleme şartları operasyonel riski etkileyebilir.
Ücretsiz araçlar başlangıç için faydalı olabilir, fakat entegrasyon, sonuç inceleme ve kayıt takibi için ekip zamanı gerektirebilir.
Önemli Notlar
Belirli bir güvenlik aracının fiyatı, yerel destek seviyesi veya kapsadığı kontroller teklif alınmadan kesin kabul edilmemelidir. Kurum için zorunlu politika maddeleri sektör düzenlemelerine ve sözleşmesel yükümlülüklere göre farklılaşabilir. Hukuki, finansal veya düzenleyici uygunluk değerlendirmesi gerektiğinde yetkin uzmanlardan görüş alınmalıdır.
Sık Sorulan Sorular
Q1. Yazılım tedarik zinciri güvenliği için SBOM hazırlamak her şirket için gerekli mi?
A1. SBOM, yazılım bileşenlerini ve bağımlılıkları görünür kılmak için yararlı olabilir. Ancak gereklilik, kurumun geliştirme modeli, kullandığı bileşenler, sözleşmesel şartlar ve sektörel yükümlülüklere göre değişebilir.
Q2. Küçük bir yazılım ekibi güvenlik aracına mı yoksa dış danışmanlığa mı bütçe ayırmalı?
A2. Bu seçim ekibin sonuçları inceleme, entegrasyon kurma ve süreci işletme kapasitesine bağlıdır. Araç lisansı yanında eğitim, yönetim süresi ve destek ihtiyacı; danışmanlıkta ise kapsam, teslimatlar ve devam eden işletim sorumluluğu karşılaştırılmalıdır.
Q3. Tedarikçi güvenlik değerlendirmesinde sözleşmeye hangi maddeler eklenmelidir?
A3. Olay bildirim süreleri, destek kapsamı, veri işleme koşulları, erişim yetkileri ve ilişki sona erdiğinde erişimlerin kaldırılması gibi başlıklar değerlendirilmelidir. Uygun maddeler, hizmetin niteliğine ve kurumun yükümlülüklerine göre uzman görüşüyle netleştirilmelidir.
