01Sorun ve çözüm
Yazılım bileşen analizi (SCA), uygulamanızın içinde hangi paketlerin, hangi sürümlerle ve hangi yoldan bulunduğunu çıkarır; bunları zafiyet veritabanları ve lisans bilgileriyle eşleştirir. Hizmetin değeri listeyi üretmekte değil, listeyi ayıklamaktadır: hangi açığın kodunuzda gerçekten çağrılan bir fonksiyonda olduğunu, hangisinin yalnızca test aracında kaldığını ayırıyor ve güncellemeleri uygulamayı bozmayacak sırayla planlıyoruz.
02Kimler için
Yazılım bileşen analizi (SCA) kimler için gerekli
Açık kaynak kullanan her yazılım ekibi için geçerlidir; bazı durumlarda zorunlu hâle gelir.
- Paket güncellemelerini yıllardır ertelemiş, bağımlılık dosyası kontrolden çıkmış uygulamaları olan ekipler
- Kurumsal alıcılarından ya da ihale şartnamesinden yazılım malzeme listesi (SBOM) talebi alan yazılım firmaları
- Ürünlerini kapalı kaynak olarak satan ve kullandıkları paketlerin lisans yükümlülüklerini bilmeyen şirketler
- Dış bir firmadan teslim aldığı kodun içindeki üçüncü taraf bileşenleri değerlendirmek isteyen işletmeler
- GitHub Dependabot gibi araçların açtığı yüzlerce uyarıyı önceliklendiremeyen geliştirme ekipleri
03İhtiyaçlar
Bağımlılık yönetiminde karşılaşılan sorunlar
Sorun çoğunlukla açıkların varlığı değil, hangisinin önemli olduğunun bilinmemesidir.
- 01
Dolaylı bağımlılıklar
Projeye eklenen bir paket, onlarca başka paketi beraberinde getirir. Açık çoğunlukla bu derinlikte çıkar ve doğrudan güncelleme ile kapatılamaz; üst paketin yeni sürümü ya da sürüm sabitleme gerekir.
- 02
Uyarı kalabalığı
Otomatik araçlar her bilinen açığı aynı ağırlıkla raporlar. Geliştirme bağımlılığındaki düşük riskli bir kayıt ile canlıda internete açık bir uç noktayı etkileyen açık aynı listede durunca ekip ikisine de bakmaz.
- 03
Lisans uyumu
GPL veya AGPL gibi güçlü copyleft lisanslı bir bileşen, kapalı kaynak dağıtılan bir üründe kaynak kodu paylaşma yükümlülüğü doğurabilir. Lisanssız ya da belirsiz lisanslı paketler de ayrı bir risktir.
- 04
Terk edilmiş ve sahte paketler
Bakımcısı bırakmış paketler açıkları için yama almaz; adı popüler bir pakete benzetilmiş zararlı paketler ise yazım hatasıyla projeye girebilir.
04Özellikler
Analizde yaptıklarımız
Her bulgu, geliştiricinin bir sonraki adımını netleştirecek biçimde raporlanır.
- 01
SBOM üretimi
Uygulamanın ve varsa konteyner imajının bütün bileşenleri CycloneDX ya da SPDX biçiminde makine tarafından okunabilir bir malzeme listesine dönüştürülür.
- 02
Erişilebilirlik ve bağlam analizi
Açığın bulunduğu fonksiyonun kodunuzdan çağrılıp çağrılmadığı, paketin yalnızca geliştirme ortamında mı kullanıldığı ve etkilenen servisin internete açık olup olmadığı değerlendirilir.
- 03
Güncelleme yol haritası
Kapatılacak açıklar, kırıcı sürüm değişiklikleri göz önüne alınarak gruplanır; hangi güncellemenin hangi testlerle doğrulanacağı belirtilir.
- 04
Lisans raporu
Her bileşenin lisansı ve dağıtım modelinize göre doğurduğu yükümlülük listelenir; hukuki yorum gerektiren durumlar hukuk danışmanınıza iletilmek üzere ayrıca işaretlenir.
05Entegrasyonlar
Desteklenen paket ekosistemleri ve araçlar
Analiz, projenizin kullandığı dillere ve geliştirme hattına göre kurulur.
- 01
Paket yöneticileri
npm, PyPI, Maven ve Gradle, NuGet, Composer ve Go modülleri gibi ekosistemlerin kilit dosyaları üzerinden kesin sürüm bilgisi alınır.
- 02
Konteyner imajları
Uygulama paketlerine ek olarak temel imajdaki işletim sistemi paketleri de Trivy ya da Grype gibi araçlarla taranır.
- 03
Sürekli izleme
Üretilen SBOM'lar OWASP Dependency-Track gibi bir platforma yüklenerek yeni bir açık yayımlandığında hangi uygulamaların etkilendiği hemen görülebilir.
- 04
CI hattı ve otomatik güncelleme
GitHub Actions, GitLab CI ya da Jenkins hattına tarama adımı eklenir; Dependabot veya Renovate gibi araçların açtığı güncelleme talepleri düzenli hâle getirilir.
06Süreç
Yazılım bileşen analizi (SCA) hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Yazılım bileşen analizinde zafiyet verisinin önceliklendirilmesi
Bileşenler NVD, GitHub Advisory Database ve OSV gibi kaynaklarla eşleştirilir; aynı açığın farklı kaynaklarda farklı paket adıyla geçebildiği durumlar elle düzeltilir. Önceliklendirmede yalnızca CVSS puanına bakılmaz: açığın gerçek saldırılarda kullanıldığı biliniyorsa, örneğin CISA'nın aktif olarak istismar edilen açıklar listesinde yer alıyorsa ya da EPSS tahmini yüksekse öne alınır.
Devamını okuDaha az göster
SCA kaynak kodunuzun mantığını değil, kullandığınız hazır parçaları inceler; bu yüzden kendi kodunuzdaki hataları bulan statik analizle birlikte düşünülmelidir. Kilit dosyası olmayan projelerde ilk iş sürümleri sabitlemek olur, çünkü her derlemede farklı paket sürümü inen bir uygulamada analiz sonucu da her gün değişir.
08Çalışma modelleri
Bu hizmette çalışma modelleri
- 01
Proje bazlı
Sabit kapsam, sabit fiyat ve belirli teslim tarihi
Kapsamı belli, teslim tarihi olan işler için.
- Yazılı kapsam ve kabul ölçütleri
- Sabit fiyat ve belirli teslim tarihi
- Teslim ve kabul adımları sözleşmede
- 02
Danışmanlık
Saatlik veya günlük teknik danışmanlık
Karar, denetim veya yön belirleme gereken durumlar için.
- Saatlik veya günlük çalışma
- Yazılı rapor ve öneriler
- Ekibinizle birlikte çalışma
09Sık sorulan sorular
Yazılım bileşen analizi (SCA) hakkında sık sorulan sorular
SCA ile kaynak kod analizi arasındaki fark nedir?
Kaynak kod analizi sizin yazdığınız koddaki hataları arar. Yazılım bileşen analizi ise projeye dahil ettiğiniz üçüncü taraf paketlerdeki bilinen açıkları ve lisansları inceler. İkisi farklı riskleri kapsar ve birlikte kullanıldığında anlamlı bir resim çıkar.
Yazılım bileşen analizi (SCA) fiyatları neye göre değişir?
Uygulama ve depo sayısı, kullanılan dil ve paket ekosistemleri, konteyner imajlarının dahil edilmesi, erişilebilirlik analizinin derinliği, lisans incelemesi ve CI hattına kalıcı kurulum istenip istenmediği teklifi belirler.
Bulunan her açığı kapatmak zorunda mıyız?
Hayır. Çağrılmayan bir fonksiyondaki ya da yalnızca test aracındaki açık, gerekçesiyle kabul edilebilir. Önemli olan bu kararın kayda geçmesi ve paketin kullanım biçimi değiştiğinde yeniden değerlendirilmesidir.
Bir alıcı bizden SBOM istiyor; ne teslim etmeliyiz?
Genellikle CycloneDX ya da SPDX biçiminde, her sürüm için güncellenen bir dosya beklenir. Talebin hangi biçimi ve hangi ayrıntı düzeyini istediğini birlikte okuyup derleme hattınızın bu dosyayı otomatik üretmesini sağlarız.
Paketleri güncellemek uygulamamızı bozar mı?
Ana sürüm atlamaları davranış değiştirebilir. Bu yüzden güncellemeleri küçük gruplar hâlinde, otomatik testler ve kritik akışların elle kontrolüyle ilerletmeyi öneriyoruz; testi zayıf projelerde önce en riskli akışlar için test eklenir.
Yazılım bileşen analizi (SCA) firmasına kodumuzu göndermemiz gerekir mi?
Gerekmez. Analiz kendi ortamınızda ya da CI hattınızda çalıştırılabilir; çoğu durumda yalnızca kilit dosyaları ve derleme çıktısı yeterlidir. Kodun dışarı çıkmaması gereken yapılarda çalışma tamamen sizin altyapınızda yürütülür.
10İlgili hizmetler