> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/dependency-confusion-nedir-paket-yoneticileri-saldirisi*

---

# Dependency Confusion Nedir? Paket Yöneticisi Saldırısı Nasıl Olur?

*Yayın Tarihi: 2026-08-17 14:00:01*

Dependency confusion, bir kurumun yalnız özel paket deposunda bulunduğunu düşündüğü dahili paket adıyla public registry üzerinde başka bir paket yayımlanması ve build sisteminin yanlış kaynaktaki paketi seçmesiyle ortaya çıkan yazılım tedarik zinciri saldırısıdır. Saldırganın hedefi, geliştirici veya CI/CD ortamına güvenilen bir bağımlılık gibi girerek paket kurulumu, test veya build sırasında kod çalıştırmaktır.
Sorun yalnızca zararlı paketin public registry'de bulunması değildir. Gerçek risk; aynı paket adının birden fazla kaynakta çözümlenebilmesi, package manager'ın kaynak önceliğinin açıkça sınırlandırılmaması, sürüm kurallarının geniş bırakılması ve iç paket adlarının dışarı sızmasıyla oluşur. Bu yazı, genel yazılım tedarik zinciri güvenliğini tekrar etmek yerine dependency confusion saldırısının hangi koşullarda gerçekleştiğini ve paket kaynağının nasıl kesinleştirileceğini açıklar.

**Kısa tanım:** Dependency confusion saldırısında saldırgan, kurum içi paketle aynı adı taşıyan bir paketi public registry'de yayımlar. Paket yöneticisi yanlış yapılandırma nedeniyle public paketi seçerse zararlı kod geliştirici cihazında veya CI/CD ortamında çalışabilir.

## Dependency confusion saldırısının oluşması için hangi koşullar gerekir?

OWASP, dependency confusion tekniğini public repository'de dahili paket adıyla zararlı paket yayımlayarak istemcinin özel paket yerine saldırganın paketini indirmesini sağlama girişimi olarak tanımlar  [OWASP Dependency Chain Abuse](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-03-Dependency-Chain-Abuse). Bunun gerçekleşebilmesi için genellikle birkaç koşul aynı anda bulunur.

- **Dahili paket adı öğrenilir.** İsim; public kaynak kod, hata mesajı, log, istemci paketi, dokümantasyon, JavaScript source map, build çıktısı veya yanlışlıkla yayımlanan manifest üzerinden görülebilir.

- **Aynı ad public registry'de kullanılabilir durumdadır.** Paket adı veya namespace saldırgan tarafından kaydedilebilir.

- **Proje birden fazla paket kaynağına erişir.** Özel registry ile public registry aynı restore veya install işleminde aday kaynak haline gelir.

- **Kaynak eşleştirmesi kesin değildir.** İç paketlerin yalnızca özel kaynaktan çözümleneceğini belirleyen scope, source mapping, mirror veya allowlist bulunmaz.

- **Çözümleme davranışı public paketi seçebilir.** Bazı ekosistemlerde sürüm önceliği, bazı durumlarda kaynak sırası, cache veya istemci davranışı etkili olabilir.

- **Paket kurulumu güvenilen ortamda gerçekleşir.** Geliştirici cihazı veya CI runner paketi indirir ve paket build, kurulum ya da çalıştırma sürecine dahil olur.

Dependency confusion, “public registry tehlikelidir” problemi değildir. Asıl problem, aynı paket kimliğinin hangi kaynaktan gelmesi gerektiğinin build sistemi tarafından kesin ve doğrulanabilir biçimde sınırlandırılmamasıdır.

Her package manager aynı çözümleme algoritmasını kullanmaz. “Saldırgan mutlaka daha yüksek sürüm numarası yayımlar ve her araç onu seçer” şeklindeki açıklama bütün ekosistemler için doğru değildir. Güvenlik değerlendirmesi kullanılan aracın gerçek repository, index, scope, cache ve sürüm seçim davranışına göre yapılmalıdır.

## Dependency confusion saldırısı adım adım nasıl ilerler?

Aşağıdaki örnek gerçek bir kurum veya aktif paket adı içermez. Bir üretim şirketinin yalnız kendi registry'sinde tuttuğu **acme-order-rules** adlı dahili paket kullandığını varsayalım. Paket, sipariş kurallarını ortak projeler arasında paylaşmaktadır.

AşamaNormal beklentiDependency confusion riski

ManifestUygulama acme-order-rules paketini talep eder.Manifest paket adını belirtir ancak kaynağı kesin biçimde sınırlandırmaz.
Kaynak yapılandırmasıİç paket özel registry'den, açık kaynak paket public registry'den gelir.Package manager iki kaynağı da aynı paket adı için sorgular.
Public paketPublic registry'de bu dahili ad bulunmamalıdır.Saldırgan aynı adla paket yayımlar.
Çözümlemeİstemci özel kaynaktaki onaylı sürümü seçer.Sürüm, kaynak veya istemci davranışı public paketi aday haline getirir.
KurulumDoğrulanmış iç paket build'e dahil edilir.Public paket geliştirici cihazında veya CI runner'da kurulur.
EtkiBuild beklenen kodla devam eder.Paket; erişebildiği dosya, token, ortam değişkeni veya build çıktısını kötüye kullanmaya çalışabilir.

Bu senaryoda saldırganın özel registry hesabına erişmesi gerekmez. Kurumun dışarı açık package resolution davranışını kullanır. CI/CD ortamları özellikle değerlidir; çünkü registry token'ı, kaynak kod, deployment secret'ları ve artefakt yayınlama yetkileri aynı runner üzerinde bulunabilir. Bu nedenle dependency confusion kontrolü yalnız geliştirici bilgisayarında değil, temiz CI ortamında da test edilmelidir.

## Dependency confusion, typosquatting ve dependency hijacking farkı

Bu teknikler paket yöneticileri üzerinden ilerleyebilse de saldırı ön koşulları farklıdır. Doğru sınıflandırma hangi kontrolün uygulanacağını belirler.

TeknikSaldırgan ne yapar?Kullanıcı neden yanlış paketi alır?Temel savunma

Dependency confusionDahili paketle aynı adı public registry'de kullanır.İç ve dış kaynak arasında kesin paket-kaynak eşleştirmesi yoktur.Namespace, source mapping, tek giriş noktası ve source allowlist
TyposquattingPopüler public pakete benzeyen yazım hatalı isim seçer.Geliştirici paketin adını yanlış yazar veya yanıltıcı adı fark etmez.Review, onaylı paket listesi ve isim doğrulaması
Dependency hijackingMeşru paketin maintainer veya publish hesabını ele geçirir.Doğru paket adının yeni sürümü zararlı hale gelmiştir.Yayın hesabı güvenliği, imza, sürüm inceleme ve hızlı geri alma
Repojacking veya namespace takeoverBoşa düşen repository, organizasyon veya paket kimliğini devralır.Eski güven ilişkisi yeni sahibin kaynağına yönelir.Sahiplik yaşam döngüsü ve değişmez kaynak referansı

Dependency confusion'da paket adı yanlış yazılmış değildir; kurum kendi dahili paket adını doğru kullanmaktadır. Hata, o adın hangi registry'ye ait olduğunun kesinleştirilmemesidir. Bu nedenle yalnız paket adlarını manuel incelemek yeterli olmaz.

## Paket yöneticileri kaynakları nasıl karıştırabilir?

### Python ve pip

pip dokümantasyonu, özel paketleri ana index'e ek bir index üzerinden aramak için **--extra-index-url** seçeneğinin kullanılmasını dependency confusion açısından güvenli bulmadığını açıkça belirtir. Public index'te aynı ada sahip paket bulunursa istemci özel paket yerine onu seçebilir  [pip install Dokümantasyonu](https://pip.pypa.io/en/stable/cli/pip_install/).
Buradaki kritik ayrım, public ve private index'i tek aday havuzuna eklemek yerine iç paketlerin hangi kontrollü kaynaktan çözümleneceğini mimari olarak belirlemektir. Kurumsal proxy repository kullanmak, yalnız onaylı paketleri içeri alan tek index sunmak veya build bazında kesin index tanımlamak değerlendirilebilir. Seçilen çözümün transit bağımlılıklar ve developer override'ları üzerinde de geçerli olması gerekir.

### NuGet

NuGet, varsayılan durumda ihtiyaç duyduğu paketi bulmak için yapılandırılmış kaynakları arayabilir. Microsoft, paket birden fazla kaynakta bulunduğunda hangi kaynaktan indirileceğinin deterministik olmayabileceğini ve Package Source Mapping ile paketlerin aranacağı kaynakların filtrelenebileceğini belirtir  [NuGet Package Source Mapping](https://learn.microsoft.com/en-us/nuget/consume-packages/package-source-mapping).
Source Mapping; şirket prefix'ine sahip paketlerin yalnız private feed'den, diğer paketlerin yalnız onaylı public veya proxy kaynaktan gelmesini sağlayacak desenler tanımlayabilir. Üst dizin veya kullanıcı seviyesindeki yapılandırmanın yeni kaynak eklemesini önlemek için repository içindeki nuget.config dosyası ve kaynak temizleme davranışı ayrıca kontrol edilmelidir.

### npm

npm scope'ları, aynı kısa paket adını farklı kullanıcı veya organizasyon namespace'lerinde ayırır. Örneğin **@acme/order-rules** biçimindeki paket, **@acme** scope'una bağlıdır. npm dokümantasyonu bir scope'un ayrı registry ile ilişkilendirilebildiğini ve o scope altındaki install isteklerinin tanımlanan registry'ye gönderildiğini açıklar  [npm Scope Dokümantasyonu](https://docs.npmjs.com/cli/v11/using-npm/scope/).
Dahili paketleri unscoped genel isimlerle tutmak yerine kuruluşa ait scope kullanmak ve scope'u private registry'ye bağlamak güçlü bir namespace sınırı oluşturur. Yine de .npmrc dosyalarının repository, kullanıcı ve CI seviyelerinde nasıl birleştiği; token'ın yalnız doğru host'a gönderilip gönderilmediği ve scope dışı paketlerin hangi kaynaktan geldiği doğrulanmalıdır.

### Maven ve benzeri repository tabanlı yapılar

Maven, repository erişimini merkezi bir mirror veya repository manager üzerinden yönlendirebilir. Apache Maven dokümantasyonu, settings.xml içinde repository için mirror tanımlanabileceğini ve repository isteklerinin bu kaynağa yönlendirilebileceğini gösterir  [Apache Maven Repository Mirrors](https://maven.apache.org/guides/mini/guide-mirror-settings.html).
Kurumsal repository manager, public ve private paketlerin tek kontrollü giriş noktasından çözülmesini sağlayabilir. Ancak yalnız mirror kullanmak yeterli değildir; group ID ve artefakt politikaları, upstream izinleri, cache davranışı ve dahili namespace'in public kaynaktan gelmesini engelleyen kurallar tanımlanmalıdır.

## Ekosisteme göre temel koruma matrisi

EkosistemRiskli yapıÖnerilen kontrolDoğrulama sorusu

Python / pipPrivate index'i public index'e extra index olarak eklemekKontrollü tek index veya paket kaynağını kesin sınırlandıran kurumsal proxyİç paket adı public index'te varsa build hangi kaynağı seçiyor?
NuGetTüm paketler için birden fazla kaynağı serbest bırakmakPackage Source Mapping ve repository seviyesinde kaynak yapılandırmasıHer package pattern yalnız beklenen feed ile eşleşiyor mu?
npmUnscoped dahili paket adı ve belirsiz registry ayarıOrganizasyon scope'u ve scope-registry eşleştirmesi@company kapsamındaki her install yalnız private registry'ye mi gidiyor?
MavenProjelerin doğrudan farklı public ve private repository'lere erişmesiKurumsal mirror/repository manager ve namespace politikasıDahili group ID public upstream'den çözümlenebiliyor mu?
Tüm ekosistemlerCI ile geliştirici cihazında farklı source config kullanılmasıVersion control altında merkezi config ve build-time policyTemiz runner, yerel cache olmadan aynı kaynağı seçiyor mu?

## Sürüm sabitleme ve lock dosyası tek başına yeterli mi?

Lock dosyası ve kesin sürüm kullanımı saldırı yüzeyini azaltır; ancak dependency confusion problemini tek başına çözmez. Lock dosyası yanlış kaynaktan alınan pakete göre oluşturulmuş olabilir, dosya güncelleme botu public paketi seçebilir veya yeni bir ortam eksik kaynak metadata'sıyla aynı isim ve sürümü başka kaynaktan indirebilir.

- Lock dosyası version control içinde tutulmalıdır.

- Lock dosyası değişikliği bağımsız review gerektirmelidir.

- Paket bütünlüğü için desteklenen ekosistemlerde hash veya checksum doğrulanmalıdır.

- Lock kaydı paket adını ve sürümünü sabitlese bile kaynağın beklenen registry olduğu doğrulanmalıdır.

- CI, lock dosyasını değiştirmeden ve yeni bağımlılık çözümlemeden restore yapmalıdır.

- Yeni paket veya kaynak ekleyen değişiklikler ayrı güvenlik kontrolünden geçmelidir.

**Karar kuralı:** Paket kaynağı belirsizse yalnız sürümü sabitlemek yeterli değildir. “Hangi paket?” sorusu ad ve sürümün yanında registry, namespace, digest veya doğrulanabilir kaynak bilgisiyle cevaplanmalıdır.

## Dahili paket adları nasıl korunmalıdır?

Dahili paket adı tek başına secret değildir; güvenlik yalnız ismin gizli kalmasına bağlanmamalıdır. Buna rağmen gereksiz sızıntı saldırganın hedef listesini kolaylaştırabilir. Manifest, log, hata sayfası ve istemci bundle'larında hangi paket bilgilerinin dışarı çıktığı kontrol edilmelidir.

- Dahili paketlerde kuruluşa ait açık ve benzersiz namespace kullanın.

- İç package prefix'lerini public registry kaynaklarından engelleyin.

- Public repository'ye yüklenen örnek config ve lock dosyalarını inceleyin.

- Build loglarında private registry URL'si, paket adı ve token sızıntısını azaltın.

- İstemciye gönderilen JavaScript source map ve hata telemetrisini erişim politikasına göre yönetin.

- Public registry'de dahili namespace ve kritik paket adları için izleme yapın.

Public registry'de paket adını “yer tutucu paket” ile kapatmak bazı kuruluşların uyguladığı ek bir önlem olabilir; fakat ana savunma olarak görülmemelidir. Her ekosistemde isim sahipliği kalıcı olmayabilir, yeni paket adları ortaya çıkar ve kaynak çözümleme hatası devam eder. Asıl kontrol, build'in dahili paketi public kaynaktan kabul etmemesidir.

## Kurumsal proxy ve tek paket giriş noktası nasıl çalışır?

Public ve private registry'lere her proje ve geliştirici cihazından doğrudan erişmek yerine merkezi artifact proxy kullanmak, kaynak politikasını tek yerde uygulamayı kolaylaştırır. Proxy; public paketleri cache'leyebilir, zararlı veya onaysız paketleri engelleyebilir, dahili namespace'leri yalnız private hosted repository'den sunabilir ve bütün indirmeleri audit log'a kaydedebilir.

- Geliştirici ve CI ortamlarının yalnız kurumsal proxy'ye erişmesine izin verin.

- Proxy üzerinde private ve public upstream'leri ayrı repository olarak yönetin.

- Dahili namespace'i public upstream için blocklist veya exclusive routing ile kapatın.

- Yeni paketlerin otomatik upstream indirilmesini risk politikasına göre sınırlayın.

- Package name, version, hash, kaynak ve indiren build bilgisini loglayın.

- CI ağ politikasında public registry'lere doğrudan çıkışı engelleyin.

- Proxy yöneticisi ve paket publish yetkilerini geliştirici restore yetkisinden ayırın.

Bu mimari, [özel yazılım projelerinde](/ozel-web-yazilim-hizmeti) farklı ekiplerin aynı paket politikasını kullanmasını sağlar. Yalnızca dokümana “private feed kullanın” yazmak yerine policy'nin network ve repository katmanında uygulanması gerekir.

## CI/CD ortamında dependency confusion nasıl test edilir?

Testin amacı zararlı paket yayımlamak değil, build'in beklenmeyen kaynağa ulaşamadığını kanıtlamaktır. Testler kontrollü dahili isimler, sahte local registry veya policy simülasyonu ile izole ortamda yapılabilir.

- Temiz ve cache'siz runner üzerinde restore işlemini çalıştırın.

- Her indirilen paketin registry kaynağını build log veya proxy audit kaydından doğrulayın.

- İç paket için private feed erişimi kapatıldığında build'in public kaynağa düşmek yerine başarısız olduğunu test edin.

- Public registry'de aynı ad varmış gibi simüle edildiğinde source policy'nin isteği engellediğini doğrulayın.

- Repository config'i olmayan kullanıcı seviyesi ayarların build'e kaynak ekleyip ekleyemediğini kontrol edin.

- Lock dosyası değiştiğinde yeni package source veya checksum farkını güvenlik kapısında gösterin.

- CI runner'ın kurumsal proxy dışında public registry'ye çıkamadığını network seviyesinde test edin.

Güvenli başarısızlık davranışı şudur: Private paket kaynağı erişilemiyorsa build durur. Public registry'de aynı isim bulunduğu için sessizce başka pakete geçmez.

## Dependency confusion şüphesinde ne yapılmalıdır?

- **Build ve yayınları durdurun.** Şüpheli paketi içeren yeni artefaktların üretilmesini ve dağıtılmasını engelleyin.

- **Kurulan paketin kaynağını doğrulayın.** Registry logu, lock dosyası, cache, hash ve build kayıtlarını inceleyin.

- **Etkilenen ortamı karantinaya alın.** Geliştirici cihazı veya runner üzerinde paket kodunun çalışmış olabileceğini varsayın.

- **Kimlik bilgilerini döndürün.** Runner'ın erişebildiği registry, source control, cloud ve deployment token'larını risk kapsamına göre yenileyin.

- **Artefaktları belirleyin.** Şüpheli build'den çıkan container, binary ve paketleri digest veya sürüm üzerinden listeleyin.

- **Temiz ortamda yeniden build yapın.** Kaynak politikası düzeltildikten sonra doğrulanmış paketlerle yeni artefakt üretin.

- **Kök nedeni giderin.** Yalnız public paketi silmek yerine source mapping, scope veya proxy politikasını kalıcı olarak düzeltin.

- **İzleme ekleyin.** Dahili adların public registry'de görülmesi ve yeni kaynak tanımlanması için alarm oluşturun.

## Dependency confusion önleme kontrol listesi

- Dahili paketler kuruluşa ait benzersiz namespace veya scope kullanıyor mu?

- Her iç paket yalnız belirlenmiş private registry ile eşleştiriliyor mu?

- Package manager birden fazla kaynağı aynı paket için serbestçe arayabiliyor mu?

- pip yapılandırmasında private paketler için riskli extra-index davranışı bulunuyor mu?

- NuGet projelerinde Package Source Mapping uygulanıyor mu?

- npm scope'ları doğru private registry'ye bağlı mı?

- Maven ve benzeri sistemlerde tüm trafik kontrollü mirror üzerinden mi geçiyor?

- Repository içindeki source config, kullanıcı ve sistem config'lerinin beklenmeyen kaynak eklemesini önlüyor mu?

- Lock dosyaları ve checksum değişiklikleri review ediliyor mu?

- CI runner'lar public registry'lere doğrudan erişebiliyor mu?

- Private feed erişilemediğinde build güvenli biçimde başarısız oluyor mu?

- Yeni dependency ve source eklenmesi ayrı onay gerektiriyor mu?

- Package restore logları kaynak bilgisiyle merkezi olarak tutuluyor mu?

- Dahili paket adlarının public registry'de görünmesi izleniyor mu?

- Bağımlılık ve registry yapılandırmaları düzenli [yazılım bakım sürecinde](/web-sitesi-bakim-hizmeti) yeniden denetleniyor mu?

## Sonuç: Paket adı kadar kaynağı da doğrulayın

Dependency confusion, dahili paket adıyla public registry'de başka paket bulunması ve build sisteminin kaynak sınırını doğru uygulamamasıyla gerçekleşir. Tehlike yalnız yüksek sürüm numarasından doğmaz; package manager'ın index, feed, scope, source order ve cache davranışına bağlıdır. Bu nedenle koruma kullanılan ekosistemin gerçek çözümleme modeline göre kurulmalıdır.
Güvenli yapı; benzersiz namespace, paket-kaynak eşleştirmesi, merkezi artifact proxy, lock ve hash doğrulaması, public registry'lere sınırlı ağ erişimi ve cache'siz CI testlerini birlikte kullanır. Private feed erişilemediğinde build'in durması, public kaynağa sessizce geçmesinden daha güvenlidir. Paket politikaları [yazılım geliştirme sürecinin](/yazilim-gelistirme) otomatik ve zorunlu bir parçası olmalıdır.

## Paket ve bağımlılık altyapınızı birlikte inceleyelim

Private registry, package manager yapılandırması, CI/CD restore akışı ve dependency policy'nizdeki karışıklık risklerini teknik bir aksiyon planına dönüştürebiliriz.
[Teknik Altyapımı Değerlendir](/iletisim)

## Sıkça Sorulan Sorular

### Dependency confusion saldırısı yalnız yüksek sürüm numarasıyla mı gerçekleşir?

Hayır. Daha yüksek public sürüm bazı package manager ve yapılandırmalarda seçim üzerinde etkili olabilir; ancak kaynak çözümleme davranışı ekosisteme göre değişir. Source sırası, index birleştirme, scope, cache, lock dosyası ve istemci sürümü de sonucu etkileyebilir. Bu nedenle savunma yalnız private pakete çok yüksek sürüm vermek olmamalıdır. Dahili paket adı belirli private registry ile kesin olarak eşleştirilmeli ve public kaynak o namespace için aday olmamalıdır.

### Lock dosyası dependency confusion saldırısını tamamen önler mi?

Lock dosyası sürüm değişimini ve beklenmeyen yeniden çözümlemeyi azaltır, ancak tek başına tam koruma sağlamaz. Lock dosyası yanlış kaynaktan seçilen paketle oluşturulmuş olabilir veya farklı ortam aynı ad ve sürümü başka registry'den çekebilir. Güvenli kullanım için lock dosyası review edilmeli, desteklenen ekosistemlerde hash doğrulanmalı ve paket kaynağı source mapping, scope ya da proxy politikasıyla sınırlandırılmalıdır.

### npm scope kullanmak dependency confusion riskini azaltır mı?

Evet. Kuruluşa ait @company/package biçimindeki scope, dahili paketleri genel unscoped isimlerden ayırır. npm scope'u belirli private registry ile ilişkilendirildiğinde bu scope altındaki install istekleri ilgili kaynağa yönlendirilir. Yine de repository, kullanıcı ve CI seviyesindeki .npmrc dosyaları birlikte kontrol edilmeli; token'ın yalnız doğru registry'ye gönderildiği ve scope dışı package source davranışının beklenen şekilde çalıştığı test edilmelidir.

### pip --extra-index-url kullanımı neden riskli olabilir?

pip'in resmî dokümantasyonu, private paketleri ana index'e ek bir index üzerinden aramak için --extra-index-url kullanımını dependency confusion açısından güvenli bulmaz. Public index'te aynı adla paket bulunduğunda istemci private paket yerine public paketi seçebilir. Daha güvenli mimari; kurumsal proxy üzerinden tek kontrollü index sunmak veya iç paketlerin yalnız belirlenmiş kaynaktan çözümlenmesini sağlamaktır. Seçilen yapı temiz CI ortamında test edilmelidir.

### Public registry'de dahili paket adını rezerve etmek yeterli midir?

Hayır. İsim rezervasyonu ek bir savunma katmanı olabilir; ancak temel kaynak çözümleme hatasını düzeltmez. Yeni dahili paketler ortaya çıkabilir, namespace sahipliği değişebilir veya farklı registry'lerde aynı sorun devam edebilir. Ana kontrol, build sisteminin iç paketleri yalnız private registry'den kabul etmesi ve o kaynak erişilemediğinde güvenli biçimde başarısız olmasıdır. Public kaynak aynı namespace için hiçbir zaman otomatik fallback olmamalıdır.

### Dependency confusion şüphesinde hangi token'lar yenilenmelidir?

Şüpheli paket geliştirici cihazında veya CI runner'da çalıştıysa o ortamın erişebildiği kimlik bilgileri risk kapsamında değerlendirilmelidir. Private registry token'ları, source control erişimleri, cloud ve deployment kimlikleri, artefakt publish yetkileri ve ortam değişkenleri incelenmelidir. Yenileme kapsamı log ve çalışma zamanı analiziyle belirlenir; yalnız package token'ını değiştirmek yeterli olmayabilir. Etkilenen build artefaktları ayrıca bulunmalı ve temiz ortamda yeniden üretilmelidir.

> Orijinal Kaynak: https://www.webioo.com.tr/blog/dependency-confusion-nedir-paket-yoneticileri-saldirisi