PNPM ile transitif bağımlılıkları yükseltin: Güvenlik açıklarını bir şeyleri bozmadan düzeltin

Günümüzde, güvenlik açıkları yazılım geliştirmede yaygın bir sorundur. Neyse ki, bağımlılıklarımızı güncel tutmamıza yardımcı olan GitHub Dependabot gibi araçlara sahibiz, bu araçlar otomatik tespit ve çekme istekleri ile yardımcı olur.

Ancak, her zaman beklendiği gibi çalışmazlar. Bazı bağımlılıklar transitif olduğu için, bu araçlar için yükseltme zor bir görev olabilir, çünkü değişikliklerin etkisini bilmezler ve çakışmalar olduğunda hangi kararı vereceklerini kestiremezler. Bu gibi durumları manuel olarak ele almamız gerekir.

Çalışmayan yöntemler#

• pnpm up gibi resmi komutlar pnpm-lock.yaml dosyanızı bozabilir. Yazım zamanı itibarıyla hala açık olan bir sorun mevcuttur.
• Hedef transitif bağımlılığa sahip doğrudan bağımlılığın en son sürümünü yüklemek işe yaramayabilir. Doğrudan bağımlılık sürüm tanımlamalarını yükseltmediyse, transitif bağımlılık çözülüp pnpm-lock.yaml dosyasında kilitlendiği için yükseltilmez.

Çözüm#

PNPM'deki overrides alanı, bazı sürüm çözümlemelerini geçersiz kılmanıza olanak tanıyan güçlü bir özelliktir. Transitif bağımlılıkları yükseltmek ve eklediğiniz değişikliği minimumda tutmak için bu özelliği kullanacağız.

Yukarıdaki Dependabot uyarısını bir örnek olarak ele alalım. Bize follow-redirects paketinin bir güvenlik açığı olduğunu ve yamalanmış sürümün 1.15.6 olduğunu söylüyor. Ancak, doğrudan bağımlılık olan gatsby, axios kullanır ve bu da [email protected]'e bağımlıdır.

Adım 1: Transitif bağımlılığı bulun#

Transitif bağımlılığı bulmanın birçok yolu vardır, ancak en basitini öneririm: pnpm-lock.yaml dosyasını arayın.

"pnpm why" nasıl olur?

pnpm why <package> komutu gerçekten faydalıdır. Ancak, bu durumda kafanızı karıştırabilir. Örneğin, pnpm why follow-redirects komutunu çalıştırdığımda, sonuçların bir kısmı şöyledir:

Aslında, pnpm-lock.yaml dosyasında follow-redirects için tek bir çözümleme vardır. pnpm why komutu, aynı paketin aynı sürümüne bağlı olan birden çok yolu gösterebilir.

Adım 2: Overrides ekleyin#

pnpm-lock.yaml dosyasında yalnızca bir çözümleme varsa en kolay durum budur. Overrides'ı doğrudan package.json dosyasına ekleyebilirsiniz:

Bir çalışma alanındaysanız, overrides'ı çalışma alanının kök package.json dosyasına eklemelisiniz.

Adım 3: Değişiklikleri uygulayın#

Değişiklikleri uygulamak için pnpm install komutunu çalıştırın. pnpm-lock.yaml dosyasında follow-redirects paketinin en az değişiklikle 1.15.6 sürümüne yükseltildiğini görebiliriz.

Şimdi package.json dosyasındaki overrides alanını temiz tutmak için kaldırabilirsiniz. Ardından, overrides alanı olmadan değişikliklerin uygulanabilir olup olmadığını doğrulamak için pnpm install komutunu tekrar çalıştırın.

Sorun giderme#

Yukarıdaki adımlar ideal durumdur. İşler her zaman beklenildiği gibi gitmeyebilir. Sorun gidermeye yönelik bazı ipuçları şunlardır:

"Overrides" alanını kaldırdıktan sonra sürüm geri alınır#

Bu, bağımlı paketin sabit bir sürüme veya hedef sürümü içermeyen bir aralığa sahip olduğu zaman meydana gelebilir. Bu durumda olup olmadığını kontrol etmek için bağımlı paket olan axiosun package.json dosyasını kontrol edin.

Eğer öyleyse, bağımlı paket sürüm tanımlamalarını yükseltinceye kadar package.json dosyasındaki overrides alanını korumanız gerekir.

Transitif bağımlılık için birden fazla çözümleme mevcut#

Proje büyüdükçe, pnpm-lock.yaml dosyasında aynı paket için birden fazla çözümleme bulunabilir. Örneğin, foo adında aynı paketin iki ana sürümü olabilir:

Güvenlik açığı raporu, [email protected]'da bir güvenlik sorunu olduğunu ve bunun 1.0.1'de düzeltildiğini, [email protected]'un etkilenmediğini gösterir. foo'ya basitçe bir override ekleyemeyiz:

• Eğer "foo": "^1.0.1" şeklinde bir override eklersek, [email protected] 1.0.1'e düşürülür. Bu, [email protected]'un bağımlı paketlerde kullanılan bazı yeni özelliklere sahip olabileceği için projeyi bozabilir.
• Eğer "foo": "^2.0.0" şeklinde bir override eklersek, [email protected] 2.0.0'a yükseltilir. Bu, projeyi bozabilir çünkü [email protected]'un bazı kırıcı değişiklikler yapmış olabileceği anlamına gelir.

Varsayarak ki foo Semantik Sürümlemeyi takip eder, şöyle bir override ekleyebiliriz:

Bu, yalnızca [email protected]'ı 1.0.1'e yükseltecek ve [email protected]'u olduğu gibi bırakacaktır.

Sonuç#

PNPM transitif bağımlılıkların doğrudan yükseltilmesini destekleyene kadar, overrides alanı şeyleri bozmadan güvenlik açıklarını düzeltmek için iyi bir geçici çözümdür. Bu makalenin size bu durumları daha verimli bir şekilde ele almanıza yardımcı olmasını umuyorum. Logto'da, bağımlılıklarımızı güncel ve güvenli tutmak için bu yöntemi kullanıyoruz.