npm 2FA Bypass Token Kısıtlamaları: Yeni Kurallar
npm ekosisteminde tedarik zinciri güvenliğini doğrudan etkileyen bir değişiklik yürürlüğe girdi. Artık iki faktörlü kimlik doğrulamayı (2FA) atlamak üzere yapılandırılmış npm granular access token‘ları (GAT’ler), hesap, organizasyon ve paket yönetimi kapsamındaki hassas işlemleri gerçekleştiremiyor. Bu tür işlemler, kullanıcının etkileşimli bir 2FA doğrulamasından geçmesini zorunlu kılacak şekilde kısıtlandı. Böylece npm kayıt defteri üzerindeki en büyük kimlik bilgisi tabanlı saldırı yüzeylerinden biri kapanmış oldu.
Bu yazıda değişikliğin kapsamını, hangi işlemlerin etkilendiğini, hangi token türlerinin bu düzenlemenin dışında kaldığını ve otomatik yayın (publish) akışlarını sürdüren ekiplerin nasıl hazırlanması gerektiğini ele alıyoruz.
Değişiklik kimleri kapsıyor?
Kısıtlama yalnızca npm granular access token‘larını etkiliyor. Aşağıdaki token türleri bu değişiklikten etkilenmiyor:
- GitHub personal access token (PAT)
- GitHub App token
- GitHub Actions içindeki
GITHUB_TOKEN
Yani değişiklik GitHub tarafındaki genel kimlik doğrulama akışlarını doğrudan bozmuyor; odak noktası npm registry üzerinde 2FA’yı atlayan tokenlar. Bu ayrım önemli, çünkü otomasyon boru hatlarında birden fazla token türü bir arada kullanılıyor olabilir.
Artık etkileşimli 2FA isteyen işlemler
2FA’yı atlayan bir GAT ile daha önce yapılabilen bazı hassas yönetim işlemleri, bu değişiklik sonrasında yalnızca web arayüzü ya da CLI üzerinden etkileşimli bir 2FA çağrısıyla tamamlanabiliyor. Bu işlemler şunlar:
- Token oluşturma veya silme
- Paket erişimini, bakımcılarını (maintainers) ya da trusted publishing yapılandırmasını değiştirme
- Organizasyon veya takım üyeliklerini ve paket yetkilendirmelerini yönetme
Değişikliğin gerekçesi net: Sızdırılmış bir 2FA-bypass token, saldırganın eline geçtiğinde yalnızca sınırlı bir işlemi değil; hesabı ele geçirmek, yeni tokenlar üretmek, bakımcı eklemek veya paket yayın hakları vermek gibi zincirleme adımları da mümkün kılıyordu. Kısacası, “2FA’yı atlayan bir token, aynı zamanda hesabı yöneten bir token olmamalı” ilkesi bu düzenlemenin özünü oluşturuyor.
Ekiplerin nasıl hazırlanması gerekiyor?
Değişiklik yürürlükte olduğu için, listelenen hassas yönetim işlemlerini otomasyon üzerinden 2FA-bypass tokenlarla yapmaya çalışan senaryolar başarısız olacak. Önerilen yaklaşım şu:
- Bu işlemleri artık 2FA-bypass tokenlarla değil, etkileşimli olarak (web arayüzü veya CLI) 2FA doğrulaması eşliğinde yapın.
- Otomasyon boru hatlarındaki adımları gözden geçirip yönetim işlemlerini kullanıcıya bağlı etkileşimli akışlara taşıyın.
Sırada ne var? Doğrudan yayın yetkisinin kaldırılması
GitHub, değişikliğin devamında 2FA-bypass tokenların doğrudan yayın (direct publish) yeteneğini de kaldırmayı planlıyor. Bu adımdan sonra söz konusu tokenların yayın yüzeyi iki işlemle sınırlanacak:
- Özel (private) paketleri okuma
- Yayını hazırlama, yani staging a publish
Hazırlanan yayın, bir bakımcı tarafından 2FA doğrulamasıyla onaylanacak. Böylece otomasyonun tek başına paketi yayınlamasının önüne geçiliyor; yayın son adımda insan onayına bağlanıyor.
Bu güncelleme için hedeflenen zaman dilimi Ocak 2027. Otomatik yayın akışlarını sürdüren ekiplerin bu tarihe kadar iki alternatiften birine geçmesi öneriliyor:
- Trusted publishing (OIDC): Kimlik bilgisi tabanlı statik tokenlar yerine OIDC üzerinden kısa ömürlü kimlik doğrulama kullanan modern bir yaklaşım.
- Staged publishing: Yayının önce hazırlanıp, ardından 2FA doğrulaması olan bir bakımcı tarafından onaylanmasına dayanan akış.
Önceki duyurunun devamı
Bu değişiklik, GitHub’ın daha önce duyurduğu GAT 2FA-bypass deprecation sürecinin devamı niteliğinde. Tek başına ele alınan bir kısıtlama değil, npm tarafında 2FA-bypass tokenlarını kademeli olarak daha dar bir kullanım alanına sıkıştıran bütünsel bir planın parçası. Yönetim işlemlerinin kısıtlanması ilk aşama, doğrudan yayın yeteneğinin kaldırılması ise sıradaki aşama.
Sorular ve engellenen akışlar
Mevcut iş akışınızın bu değişiklikten etkileneceğini düşünüyorsanız veya belirli bir senaryonun engellenip engellenmeyeceği konusunda sorularınız varsa, GitHub topluluk tartışmasında geri bildirim bırakmak mümkün. Hem ekiplerin karşılaştığı gerçek dünya senaryolarını GitHub tarafına iletmek hem de benzer sorunlarla karşılaşan diğer bakımcılarla ortak çözüm aramak için işlevli bir kanal.
Kısaca değerlendirme
2FA-bypass tokenların yönetim işlemlerinden ayrıştırılması, npm registry üzerinde uzun süredir tartışılan bir tedarik zinciri güvenliği açığını kapatıyor. Bir tokenın yayın sürecini kolaylaştırırken aynı zamanda hesabı, organizasyonu ve paket yetkilerini tek başına yönetebilmesi, kimlik bilgisi sızıntısı senaryolarında saldırganın manevra alanını çok büyütüyordu. Yeni düzenlemeyle bu tokenların kapsamı daraltılıyor, yayın için ise trusted publishing (OIDC) ve staged publishing gibi daha güvenli mekanizmalara yönlendirme yapılıyor.
Kısa vadeli görev: Hassas yönetim işlemlerini etkileşimli 2FA akışlarına taşımak. Orta vadeli görev: Ocak 2027 hedefinden önce otomatik yayın süreçlerini trusted publishing ya da staged publishing modellerine geçirmek.
Kaynaklar ve İleri Okuma
- Restricting npm bypass-2FA granular access tokens (Orijinal duyuru)
- npm install-time security ve GAT bypass-2FA deprecation duyurusu
- npm Trusted Publishers dokümantasyonu
- npm Staged Publishing dokümantasyonu
- GitHub Community tartışması
- GitHub Changelog RSS
- Innersource Security Advisories GA: Kurum İçi Zafiyet Yönetimi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments