Küçük ekiplerde bağımlılık ve güvenlik güncellemeleri: Kütüphaneler eskimeden

Bugün yazılan bir uygulamanın kodunun büyük kısmı ekibin kendi yazdığı satırlar değil, açık kaynak bağımlılıklardır: web çatısı, veritabanı sürücüsü, kimlik doğrulama kütüphanesi ve onların bağımlılıkları. Bu kütüphaneler zamanla eskir, güvenlik açıkları yayımlanır ve bir gün "küçük bir güncelleme" koca bir yeniden yazıma dönüşür. Bu yazıda küçük ekiplerin bağımlılıklarını yorulmadan güncel ve güvenli tutması için sade bir düzen öneriyoruz.

Küçük ekiplerde tablo genelde şöyledir: Proje iki yıl önce kurulmuştur, o günden beri kimse sürümlere dokunmamıştır, çünkü "çalışıyor". Sonra bir güvenlik açığı duyurulur ya da barındırma ortamı eski çalışma zamanı sürümünü desteklemeyi bırakır. Aynı anda onlarca paketi birden güncellemek zorunda kalınır ve her şey birlikte kırılır.

Neden düzenli güncelleme?

• Güvenlik: Bilinen açıkların çoğu, yamalı sürüm yayımlandıktan sonra istismar edilir. Güncel olmayan paket, kapısı açık bırakılmış bir depodur.
• Küçük adımlar kolaydır: Ayda bir yapılan küçük güncelleme dakikalar sürer; iki yılda bir yapılan toplu güncelleme haftalar sürebilir.
• Destek süresi: Çalışma zamanları (Node.js, Python, PHP vb.) ve çatıların belirli bir destek ömrü vardır. Süresi dolan sürüm artık güvenlik yaması almaz.
• İşe alım ve devir: Güncel bir proje, yeni gelen geliştiricinin de hızlı adapte olmasını sağlar.

1. Temel: kilit dosyası ve tekrarlanabilir kurulum

Her ortamda aynı sürümlerin kurulduğundan emin olmadan güncelleme yönetilemez.

• Kilit dosyasını (package-lock.json, pnpm-lock.yaml, poetry.lock, composer.lock vb.) depoya ekleyin.
• CI'da ve sunucuda kilit dosyasına sadık kurulum yapın (ör. npm ci).
• Docker imajlarında taban imajı da bir bağımlılıktır; latest yerine belirli bir sürüm etiketi kullanın.

2. Envanter: neye bağımlısınız?

İlk adım, hangi projede hangi paketlerin hangi sürümde olduğunu görmektir. Paket yöneticilerinin "eskimiş paketler" komutları (ör. npm outdated, pip list --outdated) ile bir başlangıç listesi çıkarın. Daha ileri gitmek isteyen ekipler her derlemede bir yazılım malzeme listesi (SBOM) üretebilir; hangi sürümün nerede kullanıldığı soruları saniyeler içinde yanıtlanır.

3. Otomatik güncelleme PR'ları

Güncellemeyi hatırlamaya değil, sisteme bırakın. Dependabot veya Renovate gibi araçlar yeni sürüm çıktığında otomatik pull request açar.

Gürültüyü yönetmek için:

• Güncellemeleri haftalık ya da aylık toplu PR olarak gruplayın.
• Yama (patch) ve küçük (minor) sürümleri bir grupta, büyük (major) sürümleri ayrı PR'larda tutun.
• Testleri geçen yama güncellemelerinde otomatik birleştirmeyi düşünün; büyük sürümler her zaman insan incelemesinden geçsin.

Bu PR'ların güvenle birleştirilebilmesi, sağlam bir CI/CD hattına ve anlamlı testlere bağlıdır. Test yoksa otomatik güncelleme yalnızca kırılmaları hızlandırır.

4. Güvenlik taraması

Bilinen açıkları tarayan araçlar ücretsiz ve kurulumu kolaydır:

• Paket yöneticisinin kendi denetim komutu (ör. npm audit, pip-audit)
• Depo barındırma platformunun güvenlik uyarıları
• Container imajları için imaj tarayıcılar (ör. Trivy)

Hepsini CI'a ekleyip her alarmda derlemeyi durdurmak ilk günden yorucu olabilir. Pratik yaklaşım:

Önem	Tepki
Kritik / yüksek, canlıda erişilebilir kodda	Aynı gün ya da ertesi gün yamalanır
Orta	Bir sonraki bakım gününde
Düşük ya da yalnızca geliştirme bağımlılığında	Düzenli güncelleme akışında

Her uyarı gerçek bir risk değildir; açık kodun yalnızca geliştirme araçlarında mı yoksa canlıda çalışan yolda mı olduğuna bakmak önceliklendirmeyi kolaylaştırır.

5. Sürüm politikası: ne zaman, nasıl?

Basit, yazılı bir politika tartışmaları azaltır:

• Yama sürümleri: Haftalık otomatik PR, testler geçerse birleştir.
• Küçük sürümler: Aylık bakım gününde topluca.
• Büyük sürümler: Değişiklik notları okunur, ayrı dalda denenir, staging'de doğrulanır.
• Çalışma zamanı ve taban imaj: Destek bitiş tarihleri takvime yazılır; bitişten en az birkaç ay önce geçiş planlanır.

Büyük sürüm geçişlerini canlıya dokunmadan denemek için staging ortamı en ucuz sigortadır.

6. Yeni bağımlılık eklerken

En iyi güncelleme, hiç eklenmemiş gereksiz paketin güncellemesidir. Yeni bir kütüphane eklemeden önce kısaca bakın:

• Son sürüm ne zaman çıktı, bakımı aktif mi?
• Kaç kişi kullanıyor, sorunlar yanıtlanıyor mu?
• Lisansı projenize uygun mu?
• Birkaç satırla kendiniz yazabileceğiniz bir iş için mi ekleniyor?

Paket adlarını dikkatle yazın; popüler paketlere benzeyen sahte paketler (typosquatting) gerçek bir tehdittir. Kütüphanelerin kullandığı API anahtarlarını ve parolaları da güvenle saklamak gerekir; bunu secret ve erişim yönetimi yazımızda anlattık.

7. Güncelleme sonrası: izleyin ve geri dönebilin

Testler her şeyi yakalamaz. Güncellenmiş sürüm canlıya çıktıktan sonra hata oranına ve yanıt sürelerine bakın. Bunun için temel gözlemlenebilirlik ve tek komutla bir önceki sürüme dönebilme yeteneği yeterlidir. Bir güncelleme canlıda sorun çıkarırsa olay müdahalesi akışınız devreye girer: önce geri alın, sonra inceleyin.

Aylık bakım rutini (30–60 dakika)

• Bekleyen otomatik güncelleme PR'larını incele ve birleştir
• Güvenlik tarama sonuçlarını önem sırasına göre gözden geçir
• Büyük sürüm güncellemeleri için bir sonraki ayın planını yap
• Çalışma zamanı ve taban imaj destek tarihlerini kontrol et
• Kullanılmayan bağımlılıkları kaldır

SSS

Her güncellemeyi hemen almak doğru mu?
Hayır. Yama sürümleri ve kritik güvenlik düzeltmeleri hızlı alınmalı; büyük sürümler ise birkaç hafta bekleyip ilk hataları ayıklanmış hâliyle, staging'de denenerek alınabilir.

Otomatik güncelleme PR'ları ekibi boğmaz mı?
Gruplama ve takvimle boğmaz. Haftada bir toplu PR, onlarca küçük PR'dan çok daha yönetilebilirdir.

Eski bir projede nereden başlamalı?
Önce kilit dosyasını ve CI'daki testleri sağlamlaştırın, sonra güvenlik açığı olan paketlerden başlayın. Büyük sürüm atlamalarını tek seferde değil, adım adım yapın.

TW Bilişim bu konuda ne yapıyor?
Küçük ekiplerin projelerine otomatik güncelleme PR'ları, CI'da güvenlik taraması, staging ve geri alma akışı kuruyor; eskimiş projelerde güncelleme yol haritasını ekiple birlikte çıkarıyoruz.

Sonuç

Bağımlılık yönetimi, bir kerelik büyük bir proje değil, küçük ve düzenli bir alışkanlıktır. Kilit dosyası, otomatik güncelleme PR'ları, CI'da güvenlik taraması, yazılı bir sürüm politikası ve aylık kısa bir bakım günü, küçük bir ekibin de kütüphanelerini güncel ve güvenli tutmasını sağlar.

Projelerinizin bağımlılık ve güvenlik güncellemelerini düzene sokmak için destek isterseniz: iletişim veya [email protected].