OWASP DevSecOps rehberi SCA yönteminin üçüncü taraf ve açık kaynak bileşenleri yönetmek, savunmasız bileşenleri tespit etmek ve lisans bilgisi sağlamak için kullanıldığını belirtir. Aynı rehber, kontrolün yazılım yaşam döngüsünün erken aşamalarına taşınmasını ve bağımlılıkların sürekli izlenmesini önerir.
Başarılı bir SCA nedir stratejisi yalnızca CVE sayısını raporlamaz. Hangi bağımlılığın doğrudan veya transitif geldiğini, üretimde gerçekten kullanılıp kullanılmadığını, güvenli yükseltme sürümünü, lisans durumunu ve yeni bir zafiyet duyurulduğunda hangi ürünlerin etkilendiğini de göstermelidir.
SCA nedir: Hızlı Bakış
| Konu | Pratik yaklaşım |
|---|---|
| Dependency discovery | Doğrudan ve transitif paketleri envantere alın. |
| CVE eşleştirme | Paket ve sürümleri bilinen açıklara karşı kontrol edin. |
| Lisans | Kurum politikasına uymayan lisansları görünür kılın. |
| SBOM | Bileşen envanterini release ile ilişkilendirin. |
| CI/CD | Yeni kritik riskleri merge öncesinde durdurun. |
| Sürekli izleme | Yeni açıklanan zafiyetler için eski release’leri yeniden değerlendirin. |
SCA Nedir? Açık Kaynak Bağımlılıkları İçin 10 Kritik Kontrol
1. Doğrudan ve Transitif Bağımlılıkları Envantere Alın
Package manifest dosyasında geliştiricinin doğrudan eklediği kütüphaneler görünür; fakat bu paketlerin kendi bağımlılıkları da saldırı yüzeyinin parçasıdır. Bu nedenle SCA nedir yaklaşımında dependency tree’nin tamamı görünür olmalıdır.
Maven, npm, NuGet, pip veya Gradle gibi paket yöneticilerinin lock ve manifest dosyalarını tarayın. Her bileşeni repo, uygulama sahibi, release ve production durumu ile ilişkilendirmek, yeni bir CVE çıktığında etkilenen sistemleri hızlı bulmayı sağlar.
2. Paket Kimliği ve Sürümünü Doğrulayın
Yanlış package veya sürüm eşleşmesi gerçekte olmayan bir CVE’nin raporlanmasına ya da gerçek zafiyetin atlanmasına yol açabilir. Özellikle yeniden paketlenmiş bileşenler ve container katmanlarında kimlik tespiti daha zor olabilir.
Kritik bulguda package manager çıktısı, lock dosyası ve SBOM kaydıyla sürümü ikinci kez doğrulayın. SCA nedir sürecinde veri kalitesi, risk puanlaması kadar önemlidir.
3. CVE’leri Gerçek Kullanım Bağlamıyla Önceliklendirin
Yüksek CVSS puanı önemli olsa da tek başına gerçek saldırı riskini açıklamaz. Savunmasız fonksiyonun uygulamada çağrılması, servisin internete açık olması ve exploit bulunması önceliği değiştirebilir.
Risk sıralamasında exploit bilgisi, ulaşılabilirlik, veri hassasiyeti ve iş kritikliğini birlikte kullanın. Böylece geliştiricilere yüzlerce eşit öncelikli alarm göndermek yerine gerçek istismar olasılığı yüksek sorunlara odaklanabilirsiniz.
4. Pull Request Aşamasında Yeni Paketleri Kontrol Edin
Riskli bir bağımlılığın production’a girdikten sonra kaldırılması, daha eklenmeden önce reddedilmesinden daha maliyetlidir. Bu nedenle SCA’yı yalnızca gece çalışan merkezi tarama olarak kullanmayın.
Yeni dependency eklenen pull request’te güvenlik, lisans ve kurum politikası kontrolü çalıştırın. Kritik bulguda güvenli sürüm veya alternatif paket önerisi vermek SCA nedir kontrolünü geliştiricinin günlük iş akışına taşır.
5. Lock Dosyaları ve Tekrarlanabilir Build Kullanın
Geniş sürüm aralıkları farklı build zamanlarında farklı bağımlılıkların çözülmesine neden olabilir. Bu durum hem güvenlik analizini hem olay sonrası incelemeyi zorlaştırır.
Lock dosyalarını sürüm kontrolüne alın, production build’inde belirli sürümlerin kullanıldığını doğrulayın ve desteklenen checksum/bütünlük kontrollerini etkinleştirin. Böylece hangi artefaktın hangi paketlerle üretildiği daha izlenebilir olur.
6. Lisans Risklerini Güvenlik Envanteriyle Birlikte Yönetin
Açık kaynak paketinde bilinen güvenlik açığı olmaması, lisans koşullarının ürününüzle uyumlu olduğu anlamına gelmez. OWASP’ın SCA yaklaşımı zafiyet yanında lisans bilgisini de önemli çıktı olarak ele alır.
Onaylı ve yasaklı lisans politikasını otomatikleştirin; bilinmeyen lisansı da inceleme gerektiren durum olarak işaretleyin. SCA nedir envanterinde güvenlik ve lisans bilgisi aynı bileşen kimliğinde tutulduğunda yönetişim kolaylaşır.
7. SBOM Üretin ve Release ile Eşleştirin
SBOM, uygulamanın hangi bileşenlerden oluştuğunu makine tarafından okunabilir biçimde kaydetmeye yardımcı olur. Ancak build’den kopuk eski bir SBOM gerçek production artefaktını temsil etmeyebilir.
SBOM’u CI/CD sırasında üretin ve mümkünse container veya binary digest’i ile ilişkilendirin. Yeni bir zafiyet duyurusunda merkezi SBOM verisi üzerinden etkilenen ürünleri aramak olay müdahalesini hızlandırır.
8. Terk Edilmiş Paketleri Takip Edin
Bir pakette bugün CVE bulunmaması, projenin sağlıklı biçimde bakıldığı anlamına gelmez. Uzun süredir güncellenmeyen veya bakımcısı kalmayan bağımlılıklar gelecekte ciddi operasyonel risk yaratabilir.
Kritik uygulamalarda bakım durumu, son release tarihi ve alternatif paket planını değerlendirin. Bu yaklaşım SCA nedir konusunu yalnızca geçmiş CVE verisine bağımlı olmaktan çıkarır.
9. Güvenli Sürüme Kontrollü Güncelleme Yapın
Her bulguda doğrudan en son major sürüme geçmek API kırılımı veya üretim hatası oluşturabilir. Güvenlik güncellemesinin uygulama davranışıyla uyumu test edilmelidir.
Patch veya minor güncellemeleri düzenli tutun; kritik update sonrasında unit, integration ve gerektiğinde performance testlerini çalıştırın. Düzeltme bittikten sonra SCA taramasını yeniden çalıştırarak bulgunun gerçekten kapandığını doğrulayın.
10. Production Release’lerini Sürekli Yeniden Tarayın
Bir release yayımlandığı gün güvenli görünebilir; daha sonra aynı sürümü etkileyen yeni bir güvenlik açığı açıklanabilir. Yalnızca build zamanında SCA çalıştırmak bu nedenle yeterli değildir.
Desteklenen tüm production sürümlerini yeni advisory ve CVE verilerine karşı sürekli değerlendirin. Sahiplik, SLA, risk kabul süresi ve düzeltme sonrası re-scan ile SCA nedir süreci sürekli tedarik zinciri güvenliğine dönüşür.
SCA ile SAST Arasındaki Fark
| Teknoloji | Ana odak |
|---|---|
| SCA | Üçüncü taraf ve açık kaynak bağımlılıklarının zafiyet/lisans riski. |
| SAST | Uygulamanın kendi kaynak kodundaki statik güvenlik sorunları. |
| Birlikte | Kendi kodunuz ve dış bağımlılıkları tamamlayıcı biçimde korur. |
SCA nedir ile SAST aynı şey değildir; ikisi birlikte kullanıldığında daha geniş AppSec kapsamı oluşur.
SCA İçin Ölçülebilir Metrikler
- SCA kapsamındaki production uygulama oranı
- Kritik/yüksek açık bağımlılık sayısı
- Ortalama dependency düzeltme süresi
- SBOM üretilen release oranı
- Yasaklı veya bilinmeyen lisans sayısı
- Destek dışı paket sayısı
Sık Yapılan Hatalar
- Sadece doğrudan bağımlılıkları taramak
- CVSS puanını tek öncelik ölçütü yapmak
- Lock dosyalarını göz ardı etmek
- SCA’yı yalnızca release günü çalıştırmak
- Lisans risklerini izlememek
- SBOM üretip güncel tutmamak
- Güncellemeyi test etmeden production’a almak
- Süresiz risk istisnaları oluşturmak
SCA nedir: Sık Sorulan Sorular
SCA neyin kısaltmasıdır?
Software Composition Analysis.
SCA açık kaynak açıklarını bulur mu?
Evet, paket ve sürümleri bilinen zafiyetlerle eşleştirmeye yardımcı olur.
SCA ile SAST aynı mı?
Hayır. SCA dependency, SAST kendi kodunuzun statik analizi odaklıdır.
SCA SBOM üretir mi?
Birçok SCA çözümü SBOM üretme veya SBOM verisini kullanma özelliği sunar.
SCA sadece build sırasında mı çalışmalı?
Hayır. Yeni zafiyetler sonradan açıklandığı için production sürümleri sürekli izlenmelidir.
SCA lisans kontrolü yapar mı?
Birçok araç açık kaynak lisanslarını tespit edip politika kontrolüne yardımcı olabilir.
İlgili İçerikler
Resmî ve Güvenilir Kaynaklar
OWASP — Software Composition Analysis
Sonuç
SCA nedir sorusuna; açık kaynak ve üçüncü taraf bileşenlerini keşfeden, sürüm ve güvenlik açığı bilgisini analiz eden, lisans ve tedarik zinciri risklerini görünür hâle getiren Software Composition Analysis yaklaşımı şeklinde cevap verilebilir.
SCA’yı pull request aşamasından production izlemeye kadar sürekli çalıştırmak ve SBOM ile gerçek kullanım bağlamını birleştirmek, SCA nedir yaklaşımını basit CVE listesinden sürdürülebilir dependency güvenliğine dönüştürür.
