Bugün geliştirilen hemen her yazılım, büyük ölçüde başkaları tarafından yazılmış kod üzerine kurulur. Bir acente yazılımının web paneli, mobil uygulaması ve sunucu tarafı; tarih işlemlerinden PDF üretimine, şifrelemeden ağ isteklerine kadar onlarca, hatta yüzlerce açık kaynak kütüphaneyi kullanır. Bu kütüphanelerin her biri de başka kütüphanelere bağımlıdır. Sonuçta ortaya, ekibin doğrudan yazdığı koddan çok daha büyük bir bağımlılık ağı çıkar.
Bu yapı yazılım geliştirmeyi hızlandırır ve denenmiş çözümlerin kullanılmasını sağlar. Ancak aynı zamanda yeni bir risk alanı yaratır: Uygulamanın güvenliği, artık yalnızca ekibin kendi kodu kadar değil, kullandığı tüm bileşenlerin güvenliği kadardır. Yazılım tedarik zinciri güvenliği bu riski yönetmeye odaklanır.
Tedarik zinciri riskleri nasıl ortaya çıkar?
Bilinen açıklar
Yaygın kullanılan bir kütüphanede bir güvenlik açığı keşfedilir ve yayımlanır. Açığı içeren sürümü kullanan tüm uygulamalar, güncelleme yapılana kadar risk altındadır. Bu tür açıklar herkese açık olduğu için saldırganlar da hangi uygulamaların etkilendiğini taramaya başlar.
Dolaylı bağımlılıklar
Ekibin doğrudan eklediği bir kütüphane güncel ve güvenli olabilir; ancak o kütüphanenin kullandığı başka bir bileşende açık bulunabilir. Dolaylı bağımlılıklar çoğu zaman görünmezdir ve bu nedenle gözden kaçar.
Kötü niyetli paketler
Popüler bir paketin adına çok benzeyen sahte paketler yayımlanabilir ya da bakımı bırakılmış bir paketin kontrolü kötü niyetli birinin eline geçebilir. Bu durumda zararlı kod, olağan bir güncellemeyle uygulamaya girebilir.
Bakımı bırakılmış bileşenler
Uzun süredir güncellenmeyen bir kütüphanede yeni bir açık bulunduğunda, düzeltme yayımlayacak kimse olmayabilir. Bu bileşenler zamanla teknik borca ve güvenlik riskine dönüşür.
Derleme ve dağıtım süreci
Tedarik zinciri yalnızca kütüphanelerden oluşmaz. Kodun derlendiği, test edildiği ve dağıtıldığı araçlar da zincirin halkalarıdır. Bu süreçlerdeki bir zafiyet, temiz kodun yolda değiştirilmesine imkan tanıyabilir.
Riskleri yönetmek için adımlar
- Bileşen envanteri tutun: Uygulamanın kullandığı tüm doğrudan ve dolaylı bağımlılıkların sürümleriyle birlikte listesi, yazılım bileşen listesi (SBOM) olarak tutulur. Yeni bir açık yayımlandığında "bizi etkiliyor mu?" sorusu bu listeyle hızlıca yanıtlanır.
- Sürümleri sabitleyin: Bağımlılıkların sürümleri kilit dosyalarıyla sabitlenir; böylece her derlemede aynı bileşenler kullanılır ve beklenmeyen bir sürüm sessizce uygulamaya girmez.
- Otomatik tarama yapın: Bağımlılıklar bilinen açık veritabanlarına karşı düzenli ve otomatik olarak taranır. Tarama, her kod değişikliğinde ve belirli aralıklarla tekrarlanır.
- Güncellemeyi rutin hale getirin: Güncellemeler yalnızca kritik bir açık çıktığında değil, düzenli bir takvimle yapılır. Küçük ve sık güncellemeler, yıllarca biriktirilip tek seferde yapılan büyük güncellemelerden çok daha az risklidir.
- Yeni bağımlılık eklemeyi sorgulayın: Her yeni kütüphane için bakımının aktif olup olmadığı, ne kadar yaygın kullanıldığı ve gerçekten gerekip gerekmediği değerlendirilir. Birkaç satırla yazılabilecek bir işlev için yeni bir bağımlılık eklemek, saldırı yüzeyini gereksiz yere büyütür.
- Derleme sürecini koruyun: Derleme ve dağıtım araçlarına erişim sınırlandırılır, süreçte kullanılan gizli bilgiler korunur ve üretilen paketlerin bütünlüğü doğrulanır.
Kritik bir açık yayımlandığında
Yaygın bir kütüphanede kritik bir açık duyurulduğunda, hazırlıklı bir ekip şu sırayla hareket eder: Önce bileşen envanteri üzerinden etkilenen sürümün uygulamada kullanılıp kullanılmadığı kontrol edilir. Kullanılıyorsa açığın uygulamadaki gerçek kullanım biçimiyle istismar edilebilir olup olmadığı değerlendirilir. Düzeltilmiş sürüm test ortamında denenir ve otomatik testler çalıştırılır. Ardından güncelleme canlıya alınır ve işlem kayıtları, açığın daha önce istismar edildiğine dair iz için geriye dönük incelenir. Düzeltilmiş sürüm henüz yayımlanmamışsa, ilgili işlevin geçici olarak kısıtlanması gibi ara önlemler değerlendirilir.
Önceliklendirme: Her açık aynı acilde değildir
Otomatik tarama araçları çoğu zaman uzun bir uyarı listesi üretir. Bu listenin tamamını aynı öncelikle ele almak mümkün değildir ve ekibi uyarılara karşı duyarsızlaştırabilir. Önceliklendirmede şu sorular yardımcı olur: Açığı içeren kod uygulamamızda gerçekten çalışıyor mu? Açık dışarıdan erişilebilir bir noktada mı? Açığın istismarı için bilinen bir yöntem var mı? Etkilenen bileşen kişisel veri veya kimlik doğrulama ile ilgili bir işlev mi yürütüyor? Bu sorulara verilen yanıtlar, hangi açığın aynı gün, hangisinin bir sonraki planlı güncellemede ele alınacağını belirler.
Mobil uygulamalarda ek dikkat
Mobil uygulamalar, sunucu tarafından farklı olarak kullanıcıların cihazlarında çalışır ve güncellemeler mağaza onay süreçlerinden geçer. Bu nedenle mobil tarafta bir bağımlılık açığının kapatılması, sunucu tarafına göre daha uzun sürebilir. Analitik, reklam veya bildirim gibi üçüncü taraf mobil kütüphanelerin hangi verilere eriştiğinin bilinmesi de ayrıca önemlidir. Sahada müşteri verisiyle çalışan bir mobil sigorta uygulamasında bu kütüphanelerin sayısını gerekli olanla sınırlamak, hem güvenlik hem de gizlilik açısından değerlidir.
Acenteler açısından ne anlama gelir?
Acenteler, yazılım sağlayıcısının kullandığı bileşenleri doğrudan yönetmez. Ancak bir sağlayıcının tedarik zinciri riskine nasıl yaklaştığı, uzun vadeli güvenlik açısından önemli bir göstergedir. Değerlendirme sırasında şu sorular sorulabilir: Bağımlılıklar düzenli olarak taranıyor mu? Kritik bir açık yayımlandığında nasıl bir süreç işliyor? Güncellemeler hangi sıklıkla yapılıyor? Bileşen envanteri tutuluyor mu?
Acentenin kendi tarafında da benzer bir disiplin uygulanabilir. Ofis bilgisayarlarına kurulan tarayıcı eklentileri ve yardımcı programlar da bir tür tedarik zinciridir. Panel ekranlarını okuyabilen bir tarayıcı eklentisi, müşteri verisine erişebilir. Çalışan bilgisayarlarında yalnızca gerekli ve güvenilir eklentilerin bulunması bu riski azaltır.
Görünmeyen kodun sorumluluğu
Bir yazılımın kullandığı açık kaynak bileşenleri, o yazılımın ayrılmaz bir parçasıdır ve sorumluluğu da yazılımı sunan ekibe aittir. Düzenli tarama, planlı güncelleme ve bilinçli bağımlılık seçimi, bu görünmeyen kodun güvenlik riski olmaktan çıkmasını sağlar. Acente yazılımımızın güncelleme yaklaşımı hakkında bilgi almak için demo talep sayfasından ulaşabilirsiniz.