1. GİRİŞ

Modern yazılım projeleri birden çok üçüncü taraf kütüphane ve paket kullanır; bu bağımlılıklar geliştirmenin hızını ve verimliliğini artırırken tedarik zinciri (software supply chain) risklerini de beraberinde getirir. "Dependency scanning" (bağımlılık taraması) bu riskleri keşfetmek, takip etmek ve yönetmek için uygulanan süreçler, araçlar ve politikaların bütünüdür. Bir proje hangi paketleri, hangi sürümlerini ve transitif (dolaylı) bağımlılıklarını kullandığını bilmediğinde güvenlik, lisans uyumluluğu ve stabilite sorunları kaçınılmaz hale gelir.

Neden bugün önemli?

• Supply chain saldırıları (SolarWinds, npm audit problem örnekleri) yazılımın tedarik zincirinin hedef alındığını gösterdi — bağımlılıkları kontrol etmek artık zorunlu.
• Kritik güvenlik açıkları (CVE) hızla yayılabiliyor; otomatik tarama ve hızlı remediation süreçleri işletmeler için hayati.
• Regülasyonlar ve müşteri talepleri SBOM ve dependency visibility istemeye başladı; bu da process ve otomasyon gerektiriyor.

Kimler için önemli?

• Geliştiriciler ve takım liderleri — güvenli ve stabil bağımlılık yönetimi için
• DevOps/SRE ekipleri — CI/CD ve runtime risklerini takip etmek için
• Güvenlik mühendisleri — SCA (Software Composition Analysis) ile bulguları değerlendirmek için
• Uyumluluk ve hukuk ekipleri — lisans ve tedarik zinciri uyumluluğu için

2. KAVRAMSAL TEMELLER

2.1 Bağımlılık taraması nedir?

Bağımlılık taraması, bir projenin doğrudan ve transitif bağımlılıklarını listeleyen, bu bileşenlerin bilinen güvenlik açıkları (CVE), lisans uyumluluğu ve sürüm ömrü gibi meta bilgileri sorgulayan otomatik süreçtir. Bu süreç SBOM (Software Bill of Materials) üretimi ile yakından ilişkilidir; SBOM, hangi bileşenlerin kullanıldığını ve bunların hangi sürümler olduğunu kayıt altına alır.

2.2 Temel terimler

• SCA (Software Composition Analysis): Üçüncü taraf bileşenleri tarayan, CVE veritabanları ve vulnerability feeds ile karşılaştıran sınıf araçlar.
• SBOM: Yazılımın içerdiği bileşen listesini sağlayan belge ve formatlar (CycloneDX, SPDX).
• Transitive dependency: Bir kütüphanenin ihtiyaç duyduğu başka kütüphaneler (dolaylı bağımlılıklar).
• Vulnerability feed: NVD, vendor advisory ve commercial feeds gibi kaynaklardan gelen CVE ve advisory akışları.
• Dependency graph: Projedeki bileşenlerin birbirine olan bağımlılıklarını gösteren grafik temsil.

3. NASIL ÇALIŞIR?

3.1 Mimari — SCA aracının bileşenleri

İyi bir dependency scanning mimarisi şu bileşenleri içerir:

• Collector/Parser: Projede kullanılan package manifest'lerini (package.json, pom.xml, requirements.txt, go.mod vb.) ve lock dosyalarını okur; container image seviyesinde ise image manifest ve layer'ları inceler.
• Dependency resolver: Transitif bağımlılıkları çözerek dependency graph oluşturur.
• Vulnerability matcher: Her bileşeni vulnerability feed ile eşleştirir; versiyon aralıklarına göre eşleşmeyi yapar.
• Risk scoring: CVSS, exploit maturity, asset criticality ve kullanım bağlamına göre risk puanı hesaplar.
• Reporting & CI integration: PR yorumları, dashboard, alerting ve otomatik ticket/patch PR oluşturma mekanizmaları.

3.2 SBOM üretimi ve tüketimi

SBOM, dependency scanning sürecinin hem girdisi hem de çıktısıdır. Build aşamasında SBOM üretilir ve arşivlenir; bu SBOM daha sonra vulnerability scanning, license compliance ve incident response için kullanılır. Popüler formatlar CycloneDX ve SPDX'tir; bu formatlar makine tarafından okunabilir ve standardize edilmiştir.

3.3 Vulnerability feeds ve matching

SCA araçları genellikle NVD (National Vulnerability Database) gibi açık kaynak beslemelere bağlanır. Bununla birlikte vendor advisory'ler, GitHub Advisory Database ve ticari threat feed'leri daha güncel ve doğrulanmış bilgiler sağlayabilir. Matching sürecinde package name normalization (farklı adlandırma varyasyonları), version range parsing ve semver uyumluluğu konuları kilit önemdedir.

3.4 Transitive bağımlılıklar ve neden tehlikeli?

Doğrudan kullandığınız bir kütüphane küçük bir helper dependency kullanıyor olabilir; bu helper bağımlılık da başka paketlere bağlıdır. Bu zincirin derinliği arttıkça kontrol zorlaşır ve sizin doğrudan yazmadığınız kod bir güvenlik açığı içeriyorsa projeniz riske girer. Transitif bağımlılıkların farkında olmak, minimality (gereksiz paketleri kaldırma) ve dependency pinning ile kontrolü artırır.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Büyük ölçekli örnekler

Büyük teknoloji firmaları dependency scanning'i çok katmanlı olarak uygular: developer lokalinde hızlı SCA uyarıları, PR seviyesinde daha detaylı taramalar ve CI/CD'de tam taramalar. Ayrıca SBOM'ları merkezi bir envantere gönderip tedarik zinciri risk skorlaması yaparlar. Netflix, Google gibi firmalar kendi internal pipeline'larına SCA entegrasyonları yerleştirerek otomatik patch PR'leri ve canary deploy süreçleri uygular.

4.2 Finans, sağlık ve regüle sektörler

Bu sektörlerde bağımlılık yönetimi uyumluluk odaklıdır. Lisans uyumluluğu, veri paylaşımı ile ilgili kütüphanelerin incelenmesi ve SBOM arşivleme gereksinimleri öne çıkar. Ayrıca kritik bileşenlerde vendor support ve long‑term support (LTS) sürümleri tercih edilir.

4.3 Açık kaynak ve girişimler

GitHub, OSS‑Fuzz ve Dependabot örnekleri, açık kaynak ekosisteminde bağımlılık risklerini azaltmaya yönelik pratikler sunar. Dependabot otomatik upgrade PR'leri oluşturur; OSS‑Fuzz ise sürekli fuzzing ile açık kaynak kütüphanelerindeki bellek hatalarını tespit eder. Bu tür servislerin kullanımını entegre eden organizasyonlar riskleri daha hızlı yönetir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Proaktif risk tespiti: CVE'ler ve advisory'ler hızla tespit edilerek zamanında müdahale sağlanır.
• Uyumluluk ve izlenebilirlik: SBOM ve raporlarla hangi bileşenin nerede kullanıldığı izlenebilir.
• Otomasyon: CI/CD entegrasyonu ile geliştiriciye erken geri bildirim ve otomatik remediation imkânı.

Sınırlamalar

• False positive/negative: İsim eşleşmelerindeki farklılıklar veya versiyon aralığı hataları yanlış sonuç üretebilir.
• Coverage: Binary-only dependency veya inlined code gibi durumlar bazen tespit dışı kalır.
• Feed kalitesi: Yetersiz veya gecikmeli vulnerability feed'leri riskleri gizleyebilir; commercial feed'ler maliyetlidir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 CI/CD entegrasyonu

• Pre‑merge: PR açıldığında hızlı SCA ve license check çalıştırın — geliştiriciye anlık geribildirim verin.
• Build: Full dependency graph ve SBOM üretimini build aşamasında zorunlu kılın; tarama sonuçlarını arşive edin.
• Post‑build: Eğer kritik CVE varsa pipeline'ı fail edecek veya otomatik patch PR döngüsü başlatacak mekanizmalar kurun.

7.2 Policy ve risk yönetimi

• Risk‑based policy: Kritik asset'lerde sıfır tolerans, düşük risk modüllerde ise belirli SLA'lar ile patch planı uygulayın.
• Whitelist / blacklist: Güvenilir vendor'lar ve onaylı LTS sürümleri için beyaz liste politikaları belirleyin.
• License compliance: Otomatik lisans taraması ve uyumsuz lisanslara karşı bloklama mekanizması kurun.

7.3 Operasyon ve otomasyon

• Automatic remediation: Güvenli yükseltme mümkünse patch PR oluşturun ve testleri tetikleyin.
• Notification & triage: Yeni high severity finding geldiğinde SOC/DevSecOps ekibini otomatik bilgilendirin ve triage sürecini hızlandırın.
• SBOM yönetimi: Üretilen SBOM'ları merkezi envantere gönderin ve işletme çapında sorgulanabilir hale getirin.

8. SIK YAPILAN HATALAR

• Sadece doğrudan bağımlılıkları taramak; transitif bağımlılıkları göz ardı etmek — çoğu zayıflık transitif bağımlılıklarda bulunur.
• Tooling'e aşırı güvenmek ve manuel triage süreçlerini ihmal etmek — geliştirici takımı için doğrulama ve bağlam sağlanmalı.
• SBOM üretimini pipeline'da zorunlu kılmamak; izlenebilirlik kaybı yaşanabilir.
• Vulnerability feed ve advisory'leri güncellememek — besleme gecikmeleri riskleri gizleyebilir.

9. GELECEK TRENDLER

9.1 AI ve türev bazlı önceliklendirme

Makine öğrenmesi, vulnerability prioritization ve exploit likelihood prediction için kullanılacak; SBOM ve runtime telemetry birleşimi ile hangi açıkların gerçekten risk oluşturduğunu tahmin etmek daha mümkün olacak.

9.2 SBOM'un regülasyonlaştırılması

Hükümetler ve regülatörler SBOM taleplerini artıracak; tedarik zinciri sorumluluğu ve zorunlu SBOM sunumu bazı sektörlerde standart hale gelebilir.

9.3 Runtime validation ve provenance

Sadece build zamanı değil, runtime'da da dependency provenance doğrulama (imza doğrulama, digest check) yaygınlaşacak; supply chain assurance (sigstore, in‑toto) çözümleri entegrasyonlu hale gelecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Dependency scanning'e nasıl başlamalıyım?

   Önce mevcut proje için SBOM oluşturun (CycloneDX veya SPDX). Ardından açık kaynak SCA araçlarından (Trivy, OWASP Dependency‑Check) biri ile CI'de baseline tarama yapın; sonuçları triage edin ve otomatik PR/patch süreçleri kurun.

2. 2. Transitif bağımlılıkları nasıl görebilirim?

   Dependency graph üreten araçları kullanın (Maven/Gradle dependency:tree, npm ls, go mod graph). SCA araçları genellikle transitif bağımlılık çözümünü otomatik yapar ve graph verisini sunar.

3. 3. SBOM hangi formatı seçmeliyim?

   CycloneDX ve SPDX en yaygın formatlardır. CycloneDX genellikle uygulama güvenliği odaklı meta veri sağlarken SPDX lisans odaklı bilgiyi daha ayrıntılı sunar. Her ikisinden birini veya ikisini birlikte kullanmak faydalıdır.

4. 4. Dependabot yeterli midir?

   Dependabot iyi bir başlangıçtır ancak genellikle vulnerability feed integrasyonu, risk scoring ve enterprise policy enforcement gibi gelişmiş ihtiyaçları karşılamada sınırlı kalabilir. Büyük organizasyonlar commercial SCA çözümleri tercih edebilir.

5. 5. False positive'leri nasıl azaltırım?

   Package name normalization, version range doğruluğu, contextual evidence (SBOM, runtime usage) ve manuel triage ile false positive oranını azaltabilirsiniz. Ayrıca araç bazlı white/blacklist ve custom mappings oluşturun.

6. 6. Hangi metrikleri takip etmeliyim?

   Open high severity vuln count, time to remediate, SBOM coverage, number of critical packages, transitive depth distribution ve patch PR success rate gibi metrikler izlenmelidir.

7. 7. Otomatik remediation güvenli midir?

   Otomatik upgrade PR'leri çoğu zaman faydalıdır ancak risk taşır; test suite kapsamı ve canary deploy stratejileri olmadan otomatik yükseltmeler prod hatasına neden olabilir. Bu yüzden otomatik PR + insan onayı veya automated test gating en iyi yaklaşımdır.

8. 8. Küçük ekipler için ilk 3 adım nedir?

   1) SBOM üretin; 2) Repository'ye SCA (örn. Trivy/Dependabot) ekleyin; 3) Critical vulns için alerting ve basit patch PR mekanizması kurun.

Anahtar Kavramlar

• SCA: Üçüncü taraf bileşen taraması ve vulnerability eşleştirme.
• SBOM: Yazılım parça listesi — hangi bileşenler, sürümleri ve meta verileri içerir.
• Transitive dependency: Dolaylı olarak projeye dahil edilen paketler.
• Vulnerability feed: CVE ve advisory akışları.
• Provenance: Artefaktın kaynağı ve nasıl üretildiğine dair kanıt.

Öğrenme Yol Haritası

1. 0–1 ay: Proje package manifest'lerini ve lock dosyalarını öğrenin; temel dependency graph çıkarma komutlarını kullanın.
2. 1–3 ay: SCA araçları (Trivy, OWASP Dependency‑Check, Snyk) ile deney yapın; SBOM üretimi ve basit CI entegrasyonlarını uygulayın.
3. 3–6 ay: Vulnerability feed'lerini, CVSS skorlarını ve risk prioritization yaklaşımlarını öğrenin; otomatik patch PR ve triage süreci kurun.
4. 6–12 ay: Advanced topics: provenance (sigstore, in‑toto), AI‑based prioritization, enterprise scale SBOM envanteri ve multi‑repo orchestration projelerinde deneyim kazanın.