Açık Kaynak Kütüphaneler ve Software Supply Chain Güvenliği: SCA ve SBOM Rehberi

Açık kaynak bağımlılıkları uygulamanın saldırı yüzeyinin parçasıdır: SCA, SBOM, transitive dependency ve tedarik zinciri saldırıları.

Modern bir yazılım projesinin tamamı geliştiricilerin sıfırdan yazdığı kodlardan oluşmaz.

Tam tersine günümüzde geliştirilen uygulamaların çok büyük bölümü açık kaynak kütüphaneler, üçüncü taraf paketler, framework'ler, container image'ları ve dış bağımlılıklar üzerine kuruludur.

Bir geliştirici yalnızca birkaç satır kod yazarak oldukça karmaşık bir fonksiyonu uygulamasına ekleyebilir.

Örneğin;

authentication,
PDF oluşturma,
görsel işleme,
JSON parsing,
loglama,
veritabanı erişimi,
encryption,
network iletişimi

gibi birçok işlem hazır kütüphaneler üzerinden gerçekleştirilebilir.

Bu yaklaşım yazılım geliştirme hızını ciddi şekilde artırır.

Ancak beraberinde yeni bir güvenlik sorusu getirir:

Kullandığımız kodun ne kadarını gerçekten biz yazdık?

Ve bundan daha önemli ikinci soru şudur:

Yazmadığımız kodun güvenli olduğundan nasıl emin oluyoruz?

Bir uygulamanın geliştirici tarafından yazılan kaynak kodu tamamen güvenli olabilir.

SAST hiçbir kritik bulgu üretmeyebilir.

Manuel kod analizi başarılı olabilir.

Ancak uygulamanın kullandığı üçüncü taraf bir kütüphanede kritik güvenlik açığı bulunabilir.

Bu durumda saldırgan doğrudan sizin kodunuzdaki bir hatayı kullanmaz.

Kullandığınız dependency içerisindeki güvenlik açığını hedefler.

Modern yazılım güvenliğinde bu alan genel olarak:

Software Supply Chain Security

yani yazılım tedarik zinciri güvenliği kapsamında değerlendirilir.

Bu güvenlik modelinin en önemli bileşenlerinden ikisi ise:

SCA – Software Composition Analysis

SBOM – Software Bill of Materials

yaklaşımlarıdır.

SCA kullanılan üçüncü taraf bileşenleri ve bunların bilinen güvenlik risklerini analiz etmeyi amaçlar.

SBOM ise uygulamanın hangi yazılım bileşenlerinden oluştuğunu görünür hale getirir.

Bu iki yaklaşım modern Application Security programlarının vazgeçilmez parçaları haline gelmektedir.

1. Software Supply Chain Nedir?

Software Supply Chain, bir yazılımın geliştirilmesinden production ortamına ulaşmasına kadar kullanılan bütün bileşenleri, araçları ve süreçleri kapsayan tedarik zinciridir.

Bu zincir yalnızca geliştiricinin yazdığı kaynak koddan oluşmaz.

Örneğin bir web uygulamasının yazılım tedarik zincirinde şunlar bulunabilir:

Açık kaynak kütüphaneler
Framework'ler
Package manager'lar
Build araçları
CI/CD sistemleri
Container image'ları
Artifact repository'leri
Git platformları
Cloud servisleri
Üçüncü taraf API'ler

Bunların herhangi birindeki güvenlik problemi uygulamanın bütün güvenliğini etkileyebilir.

Bu nedenle modern yazılım güvenliği artık sadece:

“Bizim yazdığımız kod güvenli mi?”

sorusunu sormaz.

Şu soruyu da sorar:

“Yazılımımızı oluşturan bütün bileşenler güvenli mi?”

2. Modern Yazılımlar Ne Kadar Açık Kaynak Kullanıyor?

Modern yazılım geliştirme ekosistemi büyük ölçüde açık kaynak bileşenlere dayanır.

Java geliştiricileri Maven veya Gradle kullanabilir.

JavaScript geliştiricileri npm üzerinden paket yükleyebilir.

Python projelerinde pip kullanılabilir.

.NET ekosisteminde NuGet paketleri tercih edilebilir.

PHP uygulamalarında Composer kullanılabilir.

Bir geliştirici tek komutla yüzlerce farklı kod bileşenini projesine dahil edebilir.

Örneğin:

npm install package-name

komutu yalnızca istediğiniz paketi yüklemeyebilir.

İlgili paketin ihtiyaç duyduğu başka paketleri de otomatik olarak indirebilir.

Bu zincir bazen onlarca hatta yüzlerce bağımlılıktan oluşabilir.

Sonuç olarak geliştiricinin projesine eklediği tek bir kütüphane aslında çok daha büyük bir yazılım ekosistemini beraberinde getirebilir.

3. Dependency Nedir?

Dependency, bir yazılımın çalışabilmek için ihtiyaç duyduğu harici yazılım bileşenidir.

Örneğin geliştirici JSON verisini işlemek için bir JSON parser kütüphanesi kullanabilir.

Bu durumda ilgili kütüphane uygulamanın dependency'si haline gelir.

Benzer şekilde:

loglama kütüphanesi,
authentication framework'ü,
database driver,
HTTP client,
image processing library

uygulamanın bağımlılıkları arasında olabilir.

Bu dependency'ler yazılım geliştirmeyi kolaylaştırır.

Ancak aynı zamanda yeni saldırı yüzeyleri oluşturabilir.

4. Direct Dependency Nedir?

Direct Dependency, geliştiricinin projeye doğrudan eklediği bileşendir.

Örneğin geliştirici proje dosyasına şu paketi ekleyebilir:

framework-x

Bu durumda framework-x doğrudan dependency'dir.

Geliştirici bu paketi seçmiştir.

Versiyonunu belirlemiştir.

Uygulama içerisinde doğrudan kullanmaktadır.

Ancak güvenlik riski yalnızca doğrudan eklenen paketlerden oluşmaz.

Asıl karmaşıklık burada başlar.

5. Transitive Dependency Nedir?

Transitive Dependency, doğrudan kullandığınız bir paketin ihtiyaç duyduğu başka dependency'leri ifade eder.

Örneğin:

Siz:

Package A

kullanıyor olabilirsiniz.

Package A ise:

Package B

Package C

kullanıyor olabilir.

Package C de:

Package D

kullanıyor olabilir.

Dolayısıyla gerçek dependency zinciri şu hale gelir:

Uygulama → A → B → C → D

Siz Package D'yi hiçbir zaman doğrudan seçmemiş olabilirsiniz.

Ancak uygulamanız içerisinde yine de bulunmaktadır.

Eğer Package D içerisinde kritik güvenlik açığı bulunursa uygulamanız etkilenebilir.

İşte bu nedenle transitive dependency yönetimi Software Supply Chain Security'nin en önemli konularından biridir.

6. Bir Dependency'de Güvenlik Açığı Bulunursa Ne Olur?

Üçüncü taraf bir bileşende güvenlik açığı tespit edildiğinde genellikle ilgili proje veya güvenlik araştırmacıları tarafından duyurulur.

Bu güvenlik açığına bir CVE atanabilir.

Örneğin belirli bir library'nin belirli sürüm aralığında Remote Code Execution problemi bulunabilir.

Saldırganlar güvenlik açığı kamuya açıklandıktan sonra savunmasız sistemleri taramaya başlayabilir.

Bu noktada kurumun hızla cevaplaması gereken soru şudur:

Bu kütüphaneyi kullanıyor muyuz?

Eğer kurumun yüzlerce uygulaması varsa bu sorunun manuel cevaplanması oldukça zor olabilir.

SBOM ve SCA tam olarak bu noktada değer kazanır.

7. CVE Nedir?

CVE, yani Common Vulnerabilities and Exposures, kamuya açıklanan güvenlik açıklarının standart şekilde tanımlanması için kullanılan sistemdir.

Belirli bir üründeki güvenlik açığına benzersiz bir CVE numarası atanabilir.

Örneğin:

CVE-YYYY-XXXXX

formatında bir kimlik bulunabilir.

Bu kimlik sayesinde farklı güvenlik sistemleri aynı güvenlik açığından bahsettiklerini anlayabilir.

SCA çözümleri kullanılan yazılım bileşenlerinin sürümlerini CVE veritabanlarıyla karşılaştırarak bilinen riskleri tespit etmeye çalışır.

8. SCA Nedir?

SCA, yani Software Composition Analysis, uygulama içerisindeki açık kaynak ve üçüncü taraf yazılım bileşenlerini analiz eden güvenlik yaklaşımıdır.

SCA'nın temel amacı:

Kullanılan bileşenleri tespit etmek,
Versiyonlarını belirlemek,
Bilinen güvenlik açıklarıyla eşleştirmek,
Riskli dependency'leri görünür hale getirmek,
Güncelleme veya remediation önerileri sağlamaktır.

Bu nedenle SCA, SAST'tan farklı bir perspektif sunar.

SAST geliştiricinin yazdığı kodu analiz eder.

SCA ise büyük ölçüde geliştiricinin yazmadığı kodu analiz eder.

9. SAST ve SCA Arasındaki Fark

Bu iki teknoloji sıklıkla karıştırılır.

Ancak amaçları farklıdır.

SAST

Kaynak kod içerisindeki güvenlik zayıflıklarını analiz eder.

Örneğin:

SQL Injection
XSS
Command Injection
Path Traversal
insecure coding pattern

gibi problemleri tespit etmeye çalışır.

SCA

Üçüncü taraf yazılım bileşenlerini analiz eder.

Örneğin:

kullanılan açık kaynak paketler,
versiyon bilgileri,
CVE'ler,
lisans riskleri,
dependency zincirleri

değerlendirilir.

Bu nedenle güçlü kod güvenliği modeli:

SAST + SCA

birlikte kullanmalıdır.

10. SCA Nasıl Çalışır?

SCA çözümleri farklı analiz yöntemleri kullanabilir.

En yaygın yöntemlerden biri package manifest dosyalarını analiz etmektir.

Örneğin:

package.json
package-lock.json
pom.xml
build.gradle
requirements.txt
Pipfile
composer.json
.csproj
packages.config

gibi dosyalar incelenebilir.

Bu dosyalarda uygulamanın hangi dependency'leri kullandığı ve versiyon bilgileri bulunabilir.

SCA çözümü bu bilgileri kendi vulnerability intelligence veritabanıyla karşılaştırır.

Sonuçta örneğin şu bilgi üretilebilir:

Package: example-library

Version: 2.1.4

Known Vulnerability: CVE-XXXX-XXXXX

Severity: High

Fixed Version: 2.1.8

Bu bilgi güvenlik ekibinin remediation sürecini hızlandırır.

11. Lock File Neden Önemlidir?

Package manager'lar çoğu zaman dependency versiyonlarını lock file içerisinde saklar.

Örneğin JavaScript ekosisteminde:

package-lock.json

veya:

yarn.lock

gibi dosyalar kullanılabilir.

Bu dosyalar uygulamanın gerçekten kullandığı kesin dependency versiyonlarını görünür hale getirir.

Çünkü manifest dosyasında:

library >= 2.0

gibi geniş versiyon tanımı bulunabilir.

Ancak production build sırasında gerçekten hangi sürümün yüklendiğini lock file gösterebilir.

SCA analizi için bu bilgi son derece değerlidir.

12. Dependency Tree Nedir?

Dependency Tree, uygulamadaki doğrudan ve dolaylı bağımlılıkların hiyerarşik görünümüdür.

Örneğin:

Application

→ Library A

→ Library B

→ Library C

→ Library D

gibi bir yapı olabilir.

Bu yapı güvenlik açısından önemli bir soruya cevap verir:

Riskli dependency uygulamaya nasıl geldi?

Örneğin kritik CVE bulunan Library D'yi doğrudan kullanmıyor olabilirsiniz.

Ancak Library B onu dependency olarak çekiyor olabilir.

Remediation yapmak için hangi üst paketin güncellenmesi gerektiğini dependency tree üzerinden anlayabilirsiniz.

13. Vulnerable Dependency Kullanmak Her Zaman Kritik midir?

Hayır.

Bir kütüphanenin kullandığınız sürümünde CVE bulunması otomatik olarak uygulamanızın istismar edilebilir olduğu anlamına gelmez.

Bu çok önemli bir ayrımdır.

Örneğin kütüphanenin güvenlik açığı yalnızca belirli bir fonksiyonda bulunuyor olabilir.

Uygulamanız o fonksiyonu hiç kullanmıyor olabilir.

Bu durumda teorik risk bulunmasına rağmen gerçek istismar edilebilirlik daha düşük olabilir.

Bu nedenle modern SCA yaklaşımında yalnızca CVE eşleştirmesi yeterli değildir.

Reachability Analysis önem kazanır.

14. SCA Reachability Analysis Nedir?

Reachability Analysis şu soruyu cevaplamaya çalışır:

Güvenlik açığı bulunan kod gerçekten uygulamanız tarafından kullanılabiliyor mu?

Örneğin bir library içerisinde 100 farklı fonksiyon olabilir.

Güvenlik açığı yalnızca bir fonksiyonda bulunuyordur.

Uygulamanız ise bu fonksiyonu hiç çağırmıyordur.

Bu durumda risk önceliği düşürülebilir.

Ancak uygulama ilgili zafiyetli fonksiyonu doğrudan kullanıyorsa risk yükselir.

Bu yaklaşım binlerce dependency bulgusu arasından gerçek riskleri ayıklamak açısından son derece değerlidir.

15. CVSS Tek Başına Yeterli midir?

Hayır.

SCA araçları çoğu zaman CVSS skorlarını kullanır.

CVSS güvenlik açığının teknik severity seviyesini anlamak için faydalıdır.

Ancak gerçek kurumsal risk yalnızca CVSS skoruyla belirlenemez.

Örneğin 9.8 CVSS skorlu bir vulnerability bulunabilir.

Ancak uygulama ilgili zafiyetli fonksiyonu hiç kullanmıyor olabilir.

Buna karşılık 7.5 skorlu başka bir güvenlik açığı internet-facing ve kritik ödeme uygulamasında aktif olarak kullanılabilir durumda olabilir.

Bu nedenle risk değerlendirmesinde:

CVSS + Reachability + Exposure + Business Criticality

birlikte değerlendirilmelidir.

16. Known Exploited Vulnerability Nedir?

Bazı güvenlik açıkları yalnızca teorik değildir.

Saldırganlar tarafından aktif olarak kullanılmaktadır.

Bu tür zafiyetler daha yüksek önceliğe sahip olmalıdır.

Bir dependency'de bilinen CVE bulunması ile saldırganların aktif olarak exploit ettiği CVE bulunması aynı risk değildir.

Modern vulnerability prioritization süreçlerinde exploit intelligence önemli hale gelmiştir.

Temel soru:

Bu açık gerçek dünyada aktif olarak kullanılıyor mu?

olmalıdır.

17. Exploit Availability Neden Önemlidir?

Bir güvenlik açığı için public exploit veya Proof of Concept yayımlandığında saldırının gerçekleştirilmesi kolaylaşabilir.

Saldırganın açığı sıfırdan araştırması gerekmez.

Bu nedenle remediation önceliği belirlenirken:

public exploit mevcut mu?
exploit kolay kullanılabilir mi?
otomatik exploit modülleri var mı?
internet üzerinde aktif exploitation gözleniyor mu?

gibi kriterler değerlendirilebilir.

18. Dependency Güncellemek Neden Her Zaman Kolay Değildir?

Teorik olarak çözüm basittir:

Riskli paketi güncelle.

Ancak pratikte işler daha karmaşıktır.

Yeni dependency versiyonu:

API değişikliği içerebilir,
uygulama ile uyumsuz olabilir,
başka dependency'leri bozabilir,
performans sorunu oluşturabilir,
yeni test ihtiyacı doğurabilir.

Özellikle eski uygulamalarda kritik dependency upgrade büyük yazılım projesine dönüşebilir.

Bu nedenle dependency management sürekli yapılmalıdır.

Yıllarca güncellenmeyen paketler security debt oluşturur.

19. Dependency Security Debt Nedir?

Dependency Security Debt, uygulamanın kullandığı eski, güncellenmeyen veya güvenlik riski taşıyan dependency'lerin zaman içerisinde birikmesidir.

Başlangıçta küçük görünen güncelleme işleri ertelendikçe daha büyük probleme dönüşür.

Örneğin uygulama framework'ün 5 yıl önceki sürümünü kullanıyor olabilir.

Bu sürüm artık desteklenmiyordur.

Framework'ü güncellemek için uygulamanın önemli bölümü değiştirilmelidir.

Sonuç olarak kurum güvenlik açığı bulunan eski sürümü kullanmaya devam etmek zorunda kalabilir.

Bu nedenle dependency güncellemeleri düzenli yazılım bakım sürecinin bir parçası olmalıdır.

20. End-of-Life Dependency Nedir?

Bir yazılım bileşeninin üreticisi veya topluluğu artık destek sağlamıyorsa bu bileşen End-of-Life, yani EOL olabilir.

EOL dependency ciddi güvenlik riski oluşturur.

Çünkü yeni güvenlik açığı tespit edilse bile patch yayınlanmayabilir.

Bu nedenle SCA yalnızca mevcut CVE'leri değil, kullanılan bileşenin yaşam döngüsünü de değerlendirmelidir.

Bir dependency şu anda CVE içermiyor olabilir.

Ancak 6 yıldır desteklenmiyorsa gelecekte ciddi risk yaratabilir.

21. Abandoned Open Source Project Riski

Açık kaynak projenin popüler olması her zaman aktif şekilde bakıldığı anlamına gelmez.

Bir proje yıllarca güncellenmemiş olabilir.

Maintainer projeyi bırakmış olabilir.

Security issue'lara cevap verilmiyor olabilir.

Bu durum kurumsal kullanım açısından risk oluşturur.

Dependency seçiminde şu sorular değerlendirilmelidir:

Proje aktif mi?
Son release ne zaman?
Security issue'lara cevap veriliyor mu?
Kaç maintainer var?
Kullanıcı topluluğu aktif mi?
Alternatifleri var mı?

Yani dependency güvenliği yalnızca CVE kontrolü değildir.

Projenin sürdürülebilirliği de güvenlik kriteridir.

22. Typosquatting Saldırısı Nedir?

Software Supply Chain saldırılarından biri Typosquatting yöntemidir.

Saldırgan popüler paketin adına çok benzeyen sahte bir paket yayınlar.

Örneğin gerçek paket:

secure-library

ise saldırgan:

secure-libary

gibi küçük yazım hatası içeren paket oluşturabilir.

Geliştirici yanlış paketi yüklediğinde zararlı kod sisteme girebilir.

Bu saldırıda uygulamanın kaynak kodunda klasik güvenlik açığı bulunmasına gerek yoktur.

Zararlı dependency doğrudan tedarik zincirine girmiştir.

23. Dependency Confusion Nedir?

Dependency Confusion, kurumun private/internal paket isimleriyle public package repository'lerde yayınlanan zararlı paketlerin karışması sonucunda ortaya çıkabilecek supply chain saldırısıdır.

Örneğin kurum internal olarak:

company-auth-library

isimli private paket kullanıyor olabilir.

Saldırgan aynı isimde public repository'ye paket yayınlayabilir.

Yanlış yapılandırılmış package manager public versiyonu tercih ederse zararlı paket build sürecine dahil olabilir.

Bu nedenle internal package repository güvenliği önemlidir.

24. Package Repository Güvenliği

Kurumların kullandığı package repository'ler kritik altyapıdır.

Örneğin:

npm registry
Maven repository
NuGet feed
PyPI
internal artifact repository

gibi sistemlerden paket indirilir.

Kurumsal ortamlarda doğrudan public repository erişimi yerine kontrollü internal proxy/repository kullanılabilir.

Böylece:

izin verilen paketler,
versiyonlar,
güvenlik politikaları,
checksum kontrolleri

daha merkezi şekilde yönetilebilir.

25. Package Integrity Nedir?

Bir paketin beklenen ve güvenilir içerik olup olmadığının doğrulanması önemlidir.

Package integrity kontrollerinde hash ve digital signature kullanılabilir.

Amaç indirdiğiniz paketin:

değiştirilmemiş,
manipüle edilmemiş,
güvenilir kaynaktan gelmiş

olduğunu doğrulamaktır.

Bu özellikle build pipeline güvenliğinde önemlidir.

26. Malicious Package Nedir?

Her risk bilinen CVE'den kaynaklanmaz.

Bazen paketin kendisi zararlı olabilir.

Saldırgan doğrudan malicious package yayımlayabilir.

Bu paket yüklenirken:

credential çalabilir,
environment variable okuyabilir,
filesystem tarayabilir,
dış sunucuya veri gönderebilir.

Bu nedenle sadece “pakette CVE var mı?” kontrolü yeterli değildir.

Package reputation ve davranış analizi de giderek önem kazanmaktadır.

27. Install Script Riski

Bazı package manager ekosistemlerinde paket yüklenirken otomatik script'ler çalıştırılabilir.

Örneğin npm paketlerinde install lifecycle script'leri bulunabilir.

Bu script'ler geliştiricinin veya CI/CD sisteminin yetkileriyle çalışabilir.

Zararlı paket bu mekanizmayı kullanarak:

environment variables,
SSH key,
cloud credential,
CI/CD token

gibi bilgileri toplamaya çalışabilir.

Dolayısıyla dependency kurulumu da güvenlik sınırının parçasıdır.

28. Build System Neden Supply Chain'in Parçasıdır?

Geliştiricinin kaynak kodu güvenli olabilir.

Dependency'ler de güvenli olabilir.

Ancak build sistemi ele geçirilmişse üretilen yazılım zararlı olabilir.

Örneğin saldırgan CI/CD pipeline'a erişerek build sırasında zararlı kod ekleyebilir.

Son kullanıcı kaynak kod repository'sinde bu kodu görmeyebilir.

Ancak production artifact zararlı hale gelmiştir.

Bu nedenle Software Supply Chain Security yalnızca dependency scanning değildir.

Build integrity de kritik bir bileşendir.

29. Artifact Nedir?

Artifact, build süreci sonunda ortaya çıkan dağıtılabilir yazılım çıktısıdır.

Örneğin:

JAR
WAR
DLL
executable
container image
mobile APK
package archive

birer artifact olabilir.

Güvenlik açısından şu sorular önemlidir:

Artifact kim tarafından üretildi?
Hangi kaynak koddan üretildi?
Build süreci güvenilir miydi?
Sonradan değiştirildi mi?

Bu sorular modern supply chain güvenliğinin temelidir.

30. Artifact Signing Nedir?

Artifact Signing, üretilen yazılım çıktısının dijital olarak imzalanmasıdır.

Amaç artifact'ın güvenilir kaynaktan geldiğini ve sonradan değiştirilmediğini doğrulamaktır.

Örneğin container image veya package imzalanabilir.

Deployment sistemi yalnızca güvenilir imzaya sahip artifact'ların production ortamına alınmasına izin verebilir.

Bu yaklaşım saldırganın pipeline dışından zararlı artifact yerleştirmesini zorlaştırır.

31. SBOM Nedir?

SBOM, yani Software Bill of Materials, bir yazılımı oluşturan bileşenlerin yapılandırılmış envanteridir.

Bunu üretim sektöründeki parça listesine benzetebiliriz.

Bir otomobil üreticisi aracın hangi parçalar kullanılarak üretildiğini bilir.

Benzer şekilde SBOM şunu cevaplar:

Bu yazılım hangi bileşenlerden oluşuyor?

Örneğin SBOM içerisinde:

Component Name
Version
Supplier
Package Identifier
Dependency Relationship
License

gibi bilgiler bulunabilir.

Bu yapı güvenlik görünürlüğü açısından son derece değerlidir.

32. SBOM Neden Önemlidir?

Kritik bir dependency güvenlik açığı yayınlandığını düşünelim.

Kurumun 500 farklı uygulaması var.

Yönetim şu soruyu soruyor:

Hangi uygulamalarımız bu kütüphaneyi kullanıyor?

SBOM yoksa ekipler repository'leri tek tek kontrol etmek zorunda kalabilir.

Bu saatler veya günler sürebilir.

SBOM mevcutsa merkezi sistem üzerinden hızlı şekilde:

Affected Applications

listesi çıkarılabilir.

Bu nedenle SBOM özellikle büyük güvenlik olaylarında Incident Response hızını artırır.

33. SBOM Bir Güvenlik Aracı mıdır?

SBOM tek başına güvenlik açığını engellemez.

Aslında SBOM bir görünürlük ve envanter mekanizmasıdır.

Size yazılımın içerisinde ne olduğunu söyler.

Bunun üzerine vulnerability intelligence eklendiğinde hangi bileşenlerin risk taşıdığı görülebilir.

Dolayısıyla:

SBOM + Vulnerability Management

birlikte değer üretir.

34. SBOM Formatları

SBOM oluşturmak için farklı standart formatlar kullanılabilir.

Bunların en bilinenleri arasında:

CycloneDX
SPDX

bulunur.

Bu formatların amacı farklı araçların ürettiği SBOM verilerinin daha kolay paylaşılabilmesini sağlamaktır.

Standart yapı kullanıldığında yazılım üreticisi, müşteri ve güvenlik platformları aynı bileşen envanterini okuyabilir.

35. CycloneDX Nedir?

CycloneDX özellikle software supply chain ve security use case'leri için geliştirilmiş SBOM formatlarından biridir.

Yazılım bileşenlerinin yanında dependency ilişkileri ve güvenlik açısından önemli farklı metadata'lar tutulabilir.

Application Security ve DevSecOps araçları tarafından yaygın şekilde desteklenebilir.

36. SPDX Nedir?

SPDX de yazılım bileşenleri ve lisans bilgilerini standart formatta ifade etmek için kullanılan önemli yapılardan biridir.

Özellikle açık kaynak lisans yönetimi açısından güçlü kullanımları bulunur.

Kurumsal SBOM stratejisinde hangi formatın kullanılacağı kullanılan araçlara ve iş ihtiyaçlarına göre belirlenebilir.

37. SBOM Ne Zaman Üretilmelidir?

SBOM'un manuel hazırlanması sürdürülebilir değildir.

Modern yaklaşım SBOM'u CI/CD pipeline içerisinde otomatik üretmektir.

Örneğin:

Source Code

↓

Dependency Resolution

↓

Build

↓

SCA

↓

SBOM Generation

↓

Artifact

şeklinde süreç oluşturulabilir.

Her release için ayrı SBOM üretilebilir.

Böylece hangi yazılım sürümünün hangi dependency'leri içerdiği net şekilde görülebilir.

38. SBOM Versiyonlama Neden Önemlidir?

Uygulamanın dependency'leri zaman içerisinde değişir.

Version 1.0 farklı kütüphaneler kullanabilir.

Version 2.0 farklı dependency setine sahip olabilir.

Dolayısıyla tek bir statik SBOM yeterli değildir.

Her release'in kendi SBOM'u bulunmalıdır.

Bu sayede güvenlik olayı sırasında production'daki gerçek versiyonun hangi bileşenleri içerdiği görülebilir.

39. SBOM ile VEX Arasındaki İlişki

Bir SBOM'da vulnerability bulunan bileşen görünmesi her zaman uygulamanın gerçekten etkilenmesi anlamına gelmez.

Bu noktada VEX – Vulnerability Exploitability eXchange gibi yaklaşımlar kullanılabilir.

VEX temel olarak yazılım üreticisinin belirli vulnerability için:

affected,
not affected,
fixed,
under investigation

gibi durum bilgisi sağlamasına yardımcı olabilir.

Bu, müşterilerin her CVE için gereksiz alarm yaşamasını azaltabilir.

40. SCA Lisans Risklerini de Bulabilir mi?

Evet.

SCA'nın önemli yeteneklerinden biri açık kaynak lisanslarının analizidir.

Bütün açık kaynak lisansları aynı değildir.

Bazı lisanslar kurumsal ürün kullanımı açısından farklı yükümlülükler getirebilir.

Örneğin kullanılan bileşenin lisansı:

ticari dağıtım,
kaynak kod paylaşımı,
attribution

gibi konularda yükümlülük oluşturabilir.

Bu nedenle SCA yalnızca Security değil aynı zamanda Open Source Governance amacıyla da kullanılabilir.

41. License Compliance Neden Güvenlik Ekibinin Konusu Olabilir?

Lisans yönetimi doğrudan siber saldırı olmayabilir.

Ancak Software Composition Analysis programının doğal parçasıdır.

Çünkü aynı dependency envanteri hem güvenlik hem de lisans risklerini gösterebilir.

Bu nedenle büyük kurumlarda AppSec, Legal ve Software Architecture ekipleri SCA platformlarını birlikte kullanabilir.

42. SCA CI/CD Pipeline'a Nasıl Entegre Edilir?

SCA modern DevSecOps süreçlerinde otomatik çalıştırılabilir.

Örneğin:

Commit

↓

Secret Scan

↓

SAST

↓

SCA

↓

Build

↓

Security Quality Gate

↓

Deploy

Kritik dependency açığı tespit edildiğinde pipeline politikaya göre durdurulabilir.

Ancak burada SAST'ta olduğu gibi risk bazlı Quality Gate gereklidir.

43. Her CVE Build'i Durdurmalı mı?

Hayır.

Aksi halde yazılım geliştirme süreçleri sürdürülemez hale gelir.

Quality Gate oluşturulurken örneğin şu kriterler birlikte kullanılabilir:

CVSS skoru,
exploit availability,
known exploitation,
reachability,
application criticality,
internet exposure.

Örneğin:

Critical + Reachable + Internet Facing

bir dependency vulnerability build'i durdurabilir.

Ancak:

Medium + Not Reachable + Internal Test

bulgusu backlog'a alınabilir.

44. SCA False Positive Üretebilir mi?

Evet.

SCA'nın False Positive yapısı SAST'tan biraz farklıdır.

Araç uygulamanızda package bulunduğunu tespit eder ve ilgili versiyonda CVE olduğunu gösterir.

Teknik olarak bu bilgi doğru olabilir.

Ancak uygulamanız zafiyetli kod yolunu kullanmıyor olabilir.

Bu nedenle vulnerability gerçek package içerisinde vardır fakat sizin uygulamanız açısından exploit edilebilir olmayabilir.

Reachability Analysis bu problemi azaltmayı amaçlar.

45. Container Image Scanning SCA'nın Bir Parçası mıdır?

Çoğu modern güvenlik programında container image içerisindeki paketler de analiz edilir.

Container image yalnızca uygulamanın dependency'lerini içermez.

Aynı zamanda işletim sistemi paketleri bulunabilir.

Örneğin base image içerisinde:

OpenSSL
glibc
curl
system libraries

gibi bileşenler olabilir.

Dolayısıyla container security açısından iki farklı katman vardır:

Application Dependencies

Operating System Packages

Her ikisi de taranmalıdır.

46. Base Image Riski

Geliştiriciler Dockerfile içerisinde örneğin:

FROM ubuntu:...

veya:

FROM node:...

gibi base image kullanabilir.

Bu image içerisinde yüzlerce paket olabilir.

Eğer base image uzun süredir güncellenmemişse çok sayıda bilinen CVE bulunabilir.

Bu nedenle container güvenliğinde:

minimal base image,
trusted registry,
düzenli update,
image scanning

kritik kontrollerdir.

47. Minimal Image Neden Önemlidir?

Container içerisinde ne kadar fazla paket bulunursa saldırı yüzeyi de o kadar artabilir.

Örneğin uygulamanın ihtiyaç duymadığı:

shell,
compiler,
network utility

gibi araçların production image içerisinde bulunması gerekmeyebilir.

Minimal image yaklaşımı yalnızca image boyutunu küçültmez.

Aynı zamanda saldırı yüzeyini de azaltabilir.

48. IaC Dependency Güvenliği

Software Supply Chain yalnızca uygulama package'larından oluşmaz.

Infrastructure as Code projeleri de modül ve provider kullanabilir.

Örneğin Terraform modülleri üçüncü taraf repository'lerden indirilebilir.

Bu nedenle kullanılan IaC modüllerinin:

kaynağı,
versiyonu,
bütünlüğü,
güvenilirliği

kontrol edilmelidir.

49. GitHub Action ve CI/CD Plugin Riski

CI/CD pipeline'larda üçüncü taraf action veya plugin kullanımı da dependency riskidir.

Bir build workflow'u dışarıdan action çalıştırabilir.

Bu action:

repository koduna,
CI/CD tokenlarına,
environment variable'lara

erişebilir.

Dolayısıyla third-party CI/CD action'lar da supply chain güvenlik değerlendirmesine alınmalıdır.

50. Version Pinning Nedir?

Version Pinning, kullanılan dependency veya CI/CD action'ın belirli sürüme sabitlenmesidir.

Örneğin:

library: 2.4.1

şeklinde sabit versiyon kullanmak beklenmeyen yeni sürümün otomatik olarak build'e girmesini engelleyebilir.

Ancak pinning'in dezavantajı güncellemelerin manuel yönetilmesidir.

Bu nedenle automated dependency update sistemleriyle birlikte kullanılabilir.

51. Automatic Dependency Update Güvenli midir?

Dependabot benzeri mekanizmalar yeni dependency sürümleri çıktığında otomatik Pull Request açabilir.

Bu yaklaşım security patch süreçlerini hızlandırabilir.

Ancak:

Yeni versiyon çıktı → otomatik production'a al

yaklaşımı her zaman güvenli değildir.

Yeni dependency test edilmelidir.

Unit test,

integration test,

security checks

çalıştırılmalıdır.

En iyi model otomatik update önerisi + kontrollü test + review şeklindedir.

52. Dependency Update SLA

Dependency güvenlik bulguları için remediation süreleri belirlenebilir.

Örneğin kurum risk modeline göre:

Critical: Çok kısa süre içerisinde

High: Öncelikli remediation

Medium: Planlı release

Low: Backlog

şeklinde süreç oluşturabilir.

Ancak active exploitation bulunan vulnerability için normal SLA beklenmemelidir.

Incident düzeyinde müdahale gerekebilir.

53. Zero-Day Dependency Açığı

Zero-Day, henüz patch'i bulunmayan veya yeni keşfedilmiş kritik güvenlik açığını ifade edebilir.

Dependency'de Zero-Day bulunduğunda güncelleme her zaman mümkün olmayabilir.

Bu durumda compensating controls uygulanabilir.

Örneğin:

zafiyetli fonksiyonu devre dışı bırakma,
WAF kuralı,
network restriction,
feature disable,
input blocking

gibi geçici korumalar kullanılabilir.

Ancak bunlar kalıcı patch'in yerine geçmemelidir.

54. Acil Dependency Olayında İlk Soru Ne Olmalıdır?

Kritik vulnerability duyurulduğunda panikle bütün sistemleri güncellemek yerine ilk olarak etki alanı belirlenmelidir.

Temel sorular:

Bu dependency'yi kullanıyor muyuz?
Hangi uygulamalarda?
Hangi versiyonlarda?
Production'da mı?
Zafiyetli fonksiyon reachable mı?
Sistem internet-facing mi?
Public exploit var mı?
Patch mevcut mu?

SBOM ve SCA bu soruların çok daha hızlı cevaplanmasını sağlar.

55. Software Asset Inventory Neden Gereklidir?

Dependency güvenliği, uygulama envanteri olmadan etkili şekilde yönetilemez.

Kurum şu bilgileri bilmelidir:

hangi uygulamalar var,
sahipleri kim,
production durumu,
iş kritikliği,
kullanılan teknolojiler,
dependency yapısı.

Bu nedenle Application Security programı CMDB veya Application Inventory ile entegre olabilir.

56. Dependency Owner Kimdir?

Bir vulnerability bulunduğunda en kritik operasyonel sorulardan biri şudur:

Kim düzeltecek?

Bunun cevabı önceden belli olmalıdır.

Her uygulama ve repository için:

Application Owner
Technical Owner
Security Owner

tanımlanabilir.

Böylece kritik SCA bulgusu doğrudan sorumlu ekibe atanabilir.

57. SCA Bulguları Geliştiriciye Nasıl Sunulmalıdır?

İyi bir SCA bulgusu sadece:

“Bu dependency vulnerable.”

dememelidir.

Şu bilgileri sunmalıdır:

package adı,
kullanılan sürüm,
CVE,
severity,
dependency path,
exploitability,
fixed version,
önerilen remediation.

Örneğin:

Vulnerable Package: Library X 1.2

Introduced Through: Framework Y 4.1

Fixed In: Library X 1.5

gibi bilgi geliştiricinin sorunu daha hızlı çözmesini sağlar.

58. Dependency Path Neden Önemlidir?

Riskli package sizin doğrudan dependency'niz olmayabilir.

Örneğin:

Your App

→ Framework A

→ Utility B

→ Vulnerable Library C

Bu durumda geliştirici Library C'yi doğrudan güncelleyemeyebilir.

Framework A'nın yeni versiyonuna geçmek gerekebilir.

SCA sisteminin dependency path göstermesi remediation sürecini kolaylaştırır.

59. Open Source Governance Nedir?

Open Source Governance, kurumun hangi açık kaynak bileşenlerin kullanılabileceğini ve nasıl yönetileceğini belirleyen süreçtir.

Örneğin kurum politikası şunları içerebilir:

kritik CVE bulunan paketler kullanılamaz,
EOL library kullanılamaz,
belirli lisanslar yasaktır,
yeni package eklemek review gerektirir,
package yalnızca approved repository'den indirilir.

Bu yaklaşım dependency riskini kod yazılmadan önce azaltabilir.

60. Approved Library Catalog

Büyük kurumlar geliştiricilerin her proje için rastgele package seçmesini istemeyebilir.

Bunun yerine approved library catalog oluşturulabilir.

Örneğin authentication için belirli framework,

logging için belirli library,

cryptography için belirli kütüphane

standartlaştırılabilir.

Bu yaklaşım hem güvenliği hem yazılım mimarisini iyileştirir.

61. Dependency'nin Popüler Olması Güvenli Olduğu Anlamına Gelir mi?

Hayır.

Milyonlarca kez indirilen package'da da kritik güvenlik açığı çıkabilir.

Popülerlik bazı olumlu sinyaller sağlayabilir ancak güvenlik garantisi değildir.

Değerlendirme yapılırken:

maintainer activity,
vulnerability history,
release frequency,
security process,
community size

gibi faktörler birlikte incelenmelidir.

62. Küçük Bir Dependency Büyük Risk Yaratabilir mi?

Evet.

Yazılım tedarik zincirinin önemli özelliklerinden biri budur.

Birkaç satır kod içeren küçük bir utility package milyonlarca uygulamanın dependency zincirinde bulunabilir.

Bu package ele geçirildiğinde çok geniş etki yaratabilir.

Dolayısıyla package boyutu güvenlik etkisinin göstergesi değildir.

63. Maintainer Account Ele Geçirilirse Ne Olur?

Açık kaynak projenin maintainer hesabı ele geçirilirse saldırgan zararlı yeni sürüm yayınlayabilir.

Eğer kurumlar dependency'leri otomatik olarak en son sürüme çekiyorsa zararlı paket build süreçlerine girebilir.

Bu nedenle version pinning, integrity verification ve controlled updates önemlidir.

64. Supply Chain Saldırısında SAST Yeterli Olur mu?

Her zaman değil.

Eğer zararlı dependency build sırasında indiriliyor ve source repository içerisinde bulunmuyorsa SAST bunu göremeyebilir.

Bu nedenle supply chain güvenliği farklı katmanlar gerektirir:

SCA

Package Integrity

Artifact Security

CI/CD Security

SBOM

Runtime Controls

Bu yapı tek bir tarama aracından daha kapsamlıdır.

65. SCA ve Secret Scanning Birlikte Neden Önemlidir?

Supply chain saldırganları bazen doğrudan dependency zafiyetini kullanmaz.

Ele geçirilmiş package içerisinde credential stealing kodu bulunabilir.

Bu nedenle SCA, Secret Security ve CI/CD güvenliği birbiriyle yakından ilişkilidir.

Modern AppSec şu üç temel soruya cevap vermelidir:

Kodumuz güvenli mi?

Kullandığımız kod güvenli mi?

Build ve release sürecimiz güvenli mi?

66. Kurumsal SCA Programı Nasıl Kurulur?

Pratik bir SCA programı aşamalı olarak kurulabilir.

Aşama 1 – Visibility

Bütün repository'ler taranır.

Dependency envanteri çıkarılır.

Aşama 2 – Risk Classification

Critical ve High riskli dependency'ler belirlenir.

Aşama 3 – CI/CD Integration

Yeni dependency'ler otomatik kontrol edilir.

Aşama 4 – Quality Gate

Belirli risk seviyelerinde build politikaları uygulanır.

Aşama 5 – SBOM

Her release için SBOM oluşturulur.

Aşama 6 – Continuous Monitoring

Yeni CVE çıktığında mevcut uygulamalar otomatik yeniden değerlendirilir.

Bu son aşama özellikle önemlidir.

67. Build Sonrası Neden Sürekli İzleme Gereklidir?

Bir dependency release tarihinde güvenli olabilir.

Altı ay sonra yeni vulnerability bulunabilir.

Uygulama kodunda hiçbir değişiklik olmamasına rağmen güvenlik durumu değişmiştir.

Bu nedenle yalnızca build sırasında SCA yapmak yeterli değildir.

Dependency'ler sürekli vulnerability intelligence ile karşılaştırılmalıdır.

Bu yaklaşım:

Continuous Software Composition Analysis

olarak düşünülebilir.

68. Yeni CVE Çıktığında Otomatik Alarm

İdeal sistemde yeni vulnerability yayımlandığında kurumun güvenlik platformu mevcut SBOM ve dependency inventory ile otomatik karşılaştırma yapar.

Örneğin:

Yeni kritik CVE yayınlandı.

Sistem otomatik olarak:

18 uygulama etkileniyor.

7'si production.

3'ü internet-facing.

şeklinde bilgi sağlayabilir.

Bu görünürlük olay müdahalesini ciddi şekilde hızlandırır.

69. SBOM Müşteriye Verilmeli mi?

Bu konu sözleşme, sektör ve güvenlik gereksinimlerine göre değişebilir.

Bazı müşteriler tedarikçiden SBOM talep edebilir.

Özellikle kritik altyapı ve regüle sektörlerde yazılımın hangi bileşenlerden oluştuğunun bilinmesi önem kazanabilir.

Ancak SBOM'un kendisi de yazılım mimarisi hakkında detaylı bilgi içerdiği için paylaşım politikaları dikkatli belirlenmelidir.

70. SBOM Hassas Bilgi midir?

SBOM doğrudan parola içermez ancak saldırgan açısından değerli reconnaissance bilgisi sağlayabilir.

Örneğin kullanılan:

framework,
package,
versiyon

bilgileri görülebilir.

Bu nedenle SBOM erişimi kurum politikalarına göre kontrol edilmelidir.

Müşteriye paylaşılacak SBOM ile iç kullanım SBOM'u farklı kapsamda olabilir.

71. Software Supply Chain Risk Yönetimi

Kurumsal supply chain güvenliği tek bir teknoloji projesi değildir.

Aşağıdaki katmanlar birlikte değerlendirilmelidir:

Kaynak Kod

SAST ve manuel analiz.

Secrets

Secret Scanning ve Vault.

Dependencies

SCA.

Build

CI/CD Security.

Artifact

Signing ve Integrity.

Inventory

SBOM.

Deployment

Policy Enforcement.

Monitoring

Continuous Vulnerability Intelligence.

Bu katmanların tamamı birlikte yazılım tedarik zincirini oluşturur.

72. SCA Kaynak Kod Analizinin Neresinde?

Kaynak kod analizi yalnızca geliştiricinin yazdığı kodu değerlendirmek olarak düşünülmemelidir.

Modern kod güvenliği üç temel katmanda ele alınabilir:

First-Party Code

Kurum geliştiricilerinin yazdığı kod.

Third-Party Code

Açık kaynak ve ticari dependency'ler.

Build & Runtime Components

Container, OS package ve deployment bileşenleri.

SAST ilk alanı,

SCA ikinci alanı,

container ve infrastructure scanning ise üçüncü alanı kapsar.

73. SCA ve SBOM Olmadan Modern AppSec Eksik Kalır

Bir uygulamanın yüzde 80'i üçüncü taraf kodlardan oluşuyorsa yalnızca kurumun yazdığı yüzde 20'yi analiz etmek yeterli değildir.

Bu nedenle modern Application Security programı şu kombinasyonu kullanmalıdır:

SAST → Kendi kodumuz

SCA → Kullandığımız kod

Secret Scanning → Kod içerisindeki erişim anahtarları

SBOM → Yazılımın tam bileşen envanteri

Bu dört yaklaşım birlikte kod güvenliğinin temel görünürlüğünü sağlar.

SecureSys SCA ve Software Supply Chain Güvenliği Yaklaşımı

SecureSys olarak kaynak kod güvenliğini yalnızca kurum geliştiricileri tarafından yazılan kodların analiz edilmesi şeklinde değerlendirmiyoruz.

Modern uygulamaların önemli bölümü üçüncü taraf ve açık kaynak bileşenlerden oluştuğu için bu dependency'lerin güvenlik riskleri de Application Security sürecinin ayrılmaz parçasıdır.

Proje kapsamına göre;

SAST, SCA, Secret Scanning, SBOM, Container Security ve CI/CD Security

katmanları birlikte değerlendirilebilir.

SCA çalışmalarında yalnızca:

“Bu dependency'de CVE var.”

demek yeterli değildir.

Gerçek risk değerlendirmesinde;

kullanılan versiyon,
dependency path,
reachability,
exploit availability,
internet exposure,
application criticality

gibi faktörler birlikte değerlendirilmelidir.

Aynı şekilde SBOM yalnızca bir envanter çıktısı olarak kalmamalıdır.

Yeni güvenlik açıkları ortaya çıktığında mevcut yazılım varlıklarının hızlı şekilde yeniden değerlendirilmesini sağlayacak yaşayan bir güvenlik verisine dönüştürülmelidir.

Çünkü modern yazılım güvenliğinde artık yalnızca:

“Hangi kodu yazdık?”

sorusu yeterli değildir.

Aynı zamanda:

“Hangi kodları sistemimize dahil ettik?”

sorusunun da cevabını bilmek gerekir.

Sık Sorulan Sorular

SCA nedir?

SCA, Software Composition Analysis ifadesinin kısaltmasıdır. Bir uygulamada kullanılan açık kaynak ve üçüncü taraf yazılım bileşenlerini tespit ederek bilinen güvenlik açıkları ve lisans riskleri açısından analiz eder.

SAST ile SCA arasındaki fark nedir?

SAST geliştirici tarafından yazılan kaynak kod içerisindeki güvenlik zayıflıklarını analiz eder. SCA ise üçüncü taraf dependency ve açık kaynak bileşenleri değerlendirir.

Dependency nedir?

Bir yazılımın çalışmak için ihtiyaç duyduğu harici kütüphane veya yazılım bileşenidir.

Transitive Dependency nedir?

Doğrudan kullandığınız bir dependency'nin kendi ihtiyaç duyduğu başka dependency'lerdir.

SBOM nedir?

SBOM, Software Bill of Materials ifadesinin kısaltmasıdır. Bir yazılımın hangi bileşenlerden ve versiyonlardan oluştuğunu gösteren yapılandırılmış yazılım envanteridir.

SBOM güvenlik açığını bulur mu?

Tek başına hayır. SBOM yazılım bileşenlerini görünür hale getirir. Vulnerability intelligence veya SCA ile birlikte kullanıldığında riskli bileşenler tespit edilebilir.

Bir dependency'de CVE bulunması uygulamanın kesinlikle açık olduğu anlamına gelir mi?

Her zaman değil. Güvenlik açığının bulunduğu kod yolunun uygulama tarafından kullanılıp kullanılmadığı gibi reachability faktörleri değerlendirilmelidir.

SCA CI/CD'ye entegre edilebilir mi?

Evet. Dependency analizi build ve Pull Request aşamalarında otomatik olarak çalıştırılabilir.

SCA lisans kontrolü yapabilir mi?

Birçok SCA çözümü açık kaynak lisanslarını da analiz ederek lisans uyumluluk riskleri hakkında bilgi sağlayabilir.

Container image'lar SCA ile taranabilir mi?

Evet. Container image içerisinde hem uygulama dependency'leri hem de işletim sistemi paketleri güvenlik açıkları açısından analiz edilebilir.

SBOM her release'te oluşturulmalı mı?

Tercihen evet. Çünkü kullanılan dependency ve versiyonlar her release'te değişebilir. Böylece production'daki gerçek yazılım bileşimi daha doğru takip edilir.

Açık kaynak kullanmak güvensiz midir?

Hayır. Açık kaynak yazılımlar modern yazılım ekosisteminin temel parçalarıdır. Risk, hangi bileşenin kullanıldığının bilinmemesi ve dependency'lerin güvenlik yaşam döngüsünün yönetilmemesidir.