Bağımlılık (Dependency) Nedir?
Kısa tanım
Bağımlılık (dependency), bir yazılım projesinin çalışmak veya derlenmek için kullandığı, çoğunlukla başkaları tarafından geliştirilmiş kütüphane, framework ya da araçtır. Bağımlılıklar npm, pip veya Composer gibi bir paket yöneticisiyle kurulur; izin verilen sürüm aralıkları bir manifest dosyasında, gerçekte kurulan kesin sürümler ise lockfile'da tutulur. Her bağımlılık geliştirmeyi hızlandırır, ama güncelleme, lisans ve güvenlik sorumluluğunu da projeye taşır.
Diğer adları: dependency, paket yöneticisi, package manager, npm paketi, lockfile, üçüncü taraf kütüphane

Doğrudan ve dolaylı bağımlılıklar
Bir projeye bilerek eklediğiniz paketler doğrudan bağımlılıklardır: bir tarih kütüphanesi, bir form doğrulama aracı, bir framework. Ancak bu paketlerin de kendi bağımlılıkları vardır, onların da başkaları. Bu zincirdeki paketlere dolaylı (transitive) bağımlılık denir. Modern bir JavaScript projesinde package.json'da birkaç düzine satır görünürken node_modules klasöründe yüzlerce paket bulunması bu yüzden olağandır.
Pratik sonucu şudur: kodunuzun büyük kısmını siz yazmamış olabilirsiniz. Bir dolaylı bağımlılıktaki hata, performans sorunu ya da güvenlik açığı, adını hiç duymadığınız bir paket üzerinden doğrudan uygulamanıza ulaşır.
Paket yöneticisi, manifest ve lockfile
Bağımlılıkları elle indirip kopyalamak yerine her ekosistemin bir paket yöneticisi vardır: JavaScript'te npm, pnpm veya Yarn; Python'da pip, Poetry veya uv; PHP'de Composer. Hepsinde iki dosya öne çıkar:
- Manifest (ör.
package.json,composer.json): Hangi paketin hangi sürüm aralığında kabul edildiğini söyler. - Lockfile (ör.
package-lock.json,composer.lock): O aralıklar çözüldüğünde gerçekte hangi sürümlerin kurulduğunu, dolaylı bağımlılıklar dahil, eksiksiz kaydeder.
"dependencies": {
"react": "^19.1.0",
"zod": "~3.24.2"
}Semantik sürümlemede ^19.1.0, 19.x serisindeki daha yeni minor ve patch sürümlerine izin verir; ~3.24.2 ise yalnızca 3.24.x patch sürümlerine. Aralık tanımı esneklik sağlar, ama iki geliştiricinin farklı günlerde farklı sürümler kurmasına da yol açar. Lockfile bu belirsizliği kapatır. npm belgeleri package-lock.json'ın repository'ye commit edilmesi gerektiğini açıkça belirtir; dosyadaki integrity alanı da her paketin özet değerini tutarak indirilen dosyanın değişmediğini doğrular. CI ortamında npm install yerine npm ci kullanmak, lockfile ile manifest uyuşmadığında kurulumu sessizce güncellemek yerine hatayla durdurur.
Tedarik zinciri riski
OWASP Top 10'un 2025 sürümünde “Software Supply Chain Failures” (yazılım tedarik zinciri hataları) üçüncü sıradadır; OWASP Top 10 listesinde bu konunun bu kadar yukarıda olması, bağımlılıkların artık başlı başına bir saldırı yüzeyi sayıldığını gösterir. Riskin yaygın biçimleri:
- Bilinen bir güvenlik açığı bulunan eski bir sürümün güncellenmeden kullanılması.
- Bakımı bırakılmış, açıkları artık kapatılmayan paketler.
- Popüler bir paketin adına çok benzeyen sahte paketlerin (typosquatting) yanlışlıkla kurulması.
- Bakımcı hesabının ele geçirilmesiyle meşru bir pakete zararlı bir sürüm yayımlanması.
Savunma tarafında temel hijyen şunlardan oluşur: lockfile'ı commit etmek ve CI'da kilitli kurulum yapmak; npm audit gibi bilinen açık taramalarını CI/CD hattına eklemek; Dependabot veya Renovate gibi araçların açtığı güncelleme isteklerini okumadan birleştirmemek; npm audit signatures ile registry imzalarını ve sağlanan provenance bilgisini doğrulamak; CI'daki yayın token'larına yalnızca gereken yetkiyi vermek.
Yeni bir paket eklemeden önce
- Gerçekten gerekli mi? On satırlık bir yardımcı fonksiyon için yeni bir paket ve onun bağımlılık ağacı eklemek çoğu zaman kötü bir takastır.
- Bakımı sürüyor mu? Son sürüm tarihi, açık sorunlara verilen yanıtlar ve bakımcı sayısı fikir verir.
- Lisansı uygun mu? Açık kaynak lisansların bir kısmı, dağıttığınız yazılım için ek yükümlülükler getirir.
- Bedeli ne? Tarayıcıya giden bir paket JavaScript paketinizi büyütür; sunucu tarafında ise kurulum süresini ve saldırı yüzeyini artırır.
Güncel tutmanın ritmi
Bağımlılıkları yıllarca güncellememek, sonunda birkaç major sürüm atlayan ve her şeyi aynı anda kıran bir “büyük güncelleme” projesine dönüşür. Bu, teknik borçun en ölçülebilir biçimlerinden biridir. Küçük ve düzenli güncellemeler, otomatik testlerle birlikte yapıldığında çok daha az risk taşır: patch sürümleri sık, minor sürümler düzenli aralıklarla, major sürümler ise değişiklik notları okunarak ve ayrı bir iş olarak planlanır.

