CMS, Framework ve Kütüphanelerinizi Güncel Tutma Rehberi

Var olduğunu bilmediğiniz şeyi koruyamazsınız. Uygulamanızın bağlı olduğu her yazılım bileşeninin eksiksiz bir kataloğunu oluşturarak başlayın. Bu; CMS çekirdeğini, temaları, eklentileri, sunucu tarafı framework'leri, ön yüz kütüphanelerini ve geçişli bağımlılıkları (bağımlılıklarınızın bağımlılıklarını) kapsar.

• CMS platformunuzu ve tam sürümünü listeleyin (ör. WordPress 6.4.3, Drupal 10.2.1, Joomla 5.0.2).
• Node.js paketlerini ve sürümlerini listelemek için npm list --depth=0 veya yarn list komutunu çalıştırın.
• Composer tarafından yönetilen tüm PHP paketlerini listelemek için composer show komutunu çalıştırın.
• Python bağımlılıkları için pip list komutunu çalıştırın ya da requirements.txt / Pipfile.lock dosyasını inceleyin.
• Ruby Gem'leri için bundle list komutunu çalıştırın veya Gemfile.lock dosyasını inceleyin.
• Sunucu tarafı yazılım sürümlerini belgeleyin: web sunucusu (Apache, Nginx), PHP sürümü, Node çalışma zamanı, veritabanı motoru.
• CDN üzerinden veya satır içi script etiketleriyle yüklenen tüm üçüncü taraf JavaScript kütüphanelerini kaydedin.
• Zaman içindeki değişikliklerin izlenebilmesi için bu envanteri sürüm kontrolünde saklayın.

Neye sahip olduğunuzu bilmek, yalnızca bir şeyin ne zaman açık hale geldiğini de bildiğinizde işe yarar. Popüler yazılımlardaki açıklıklar genellikle bir yama yayımlandıktan saatler içinde kamuoyuyla paylaşılır; bu da saldırganlara yama uygulanmamış sistemleri istismar etmek için dar bir pencere açar. Bu pencereyi kapatmak için proaktif izleme yapmanız gerekir.

• CMS'iniz için resmi güvenlik danışmanlıklarına abone olun (ör. WordPress Güvenlik Sürümleri, Drupal Güvenlik Danışmanlıkları, Joomla Güvenlik Duyuruları).
• Yığınınızı etkileyen CVE'ler için NIST Ulusal Açıklık Veritabanı (NVD)'nı izleyin.
• Node.js bağımlılıklarındaki bilinen açıklıkları kontrol etmek için npm audit komutunu kullanın.
• PHP paketleri için composer audit (Composer 2.4+) veya local-php-security-checker aracını kullanın.
• Python paketleri için pip-audit veya safety check komutunu kullanın.
• Ruby Gem'leri için bundle exec bundler-audit komutunu kullanın.
• Kodunuz bu platformlarda barındırılıyorsa GitHub Dependabot veya GitLab Bağımlılık Taramasını etkinleştirin.
• Paket yöneticinizde veya bir bağımlılık izleme hizmetinde uyarılar ayarlayarak otomatik bildirim alın. Sensagraph, canlı sitenizi sürekli tarayarak güncel olmayan veya açık yazılım bileşenlerini tespit eder.

Yazılı bir politika olmadan güncellemeler tutarsız biçimde yapılır ya da hiç yapılmaz. Bir politika belirsizliği ortadan kaldırır: her ekip üyesi neyin güncellenmesi gerektiğini, ne kadar hızlı ve kimin sorumlu olduğunu bilir. Zaman çizelgelerinizi risk ciddiyetine göre özelleştirin.

• Güncelleme kategorilerini tanımlayın: kritik güvenlik yamaları (24–48 saat içinde uygula), yüksek ciddiyet yamaları (7 gün içinde uygula), küçük/orta yamalar (30 gün içinde uygula), özellik sürümleri (üç ayda bir veya gerektiğinde planlanmış).
• Her uygulama için güncellemeleri izlemekten ve uygulamaktan sorumlu bir kişi belirleyin.
• Güncelleme prosedürünü belgeleyin, böylece herhangi bir ekip üyesi uygulayabilsin.
• Herhangi bir güncelleme üretime geçmeden önce QA veya kıdemli bir geliştirici onayı alın.
• Üçüncü taraf yönetilen hizmetleri ve CMS eklentilerini/temalarını politikaya açıkça dahil edin; bunlar sıklıkla gözden kaçırılır.
• Politikayı en az yılda bir gözden geçirin ve güncelleyin.

Manuel kontroller hataya açıktır ve teslim tarihi baskısı altında kolayca atlanır. Otomatik bağımlılık denetimlerini CI/CD hattınıza entegre etmek, her kod gönderimi ve her derlemenin üretim ortamına ulaşmadan önce açık bağımlılıklar için kontrol edilmesini sağlar.

• CI adımı olarak npm audit --audit-level=high ekleyin; yüksek veya kritik açıklıklar bulunursa derlemeyi başarısız olarak işaretleyin.
• PHP projeleri için CI adımı olarak composer audit veya local-php-security-checker ekleyin.
• Python projeleri için CI adımı olarak pip-audit veya safety check --full-report ekleyin.
• Ruby CI hattınızda bundler-audit kullanın.
• Bağımlılık güncellemeleri için otomatik olarak çekme isteği açmak üzere Dependabot (GitHub) veya Renovate Bot'u yapılandırın.
• Tekrarlanabilir derlemeler sağlamak ve sessiz sürüm kaymasını önlemek için lock dosyalarında (package-lock.json, composer.lock, Pipfile.lock, Gemfile.lock) tam bağımlılık sürümlerini sabitleyin.
• Docker temel imajlarını, konteyner derleme hattınızın bir parçası olarak docker scout veya trivy gibi araçlarla bilinen CVE'ler için tarayın.

Güncellemeleri test etmeden doğrudan üretime uygulamak, kesintilerin yaygın bir nedenidir. Üretimi yansıtan bir hazırlık ortamı, bir güncellemenin kullanıcılarınızı etkilemeden önce işlevselliği bozmadığını doğrulamanızı sağlar.

• Üretime mümkün olduğunca yakın bir hazırlık ortamı oluşturun (aynı PHP/Node/Python sürümü, aynı web sunucusu yapılandırması, aynı veritabanı motoru ve sürümü).
• Tüm güncellemeleri önce hazırlık ortamına uygulayın ve tam otomatik test paketinizi (birim, entegrasyon ve uçtan uca testler) çalıştırın.
• Güncellemeleri uyguladıktan sonra kritik kullanıcı yolculuklarını (giriş, ödeme, form gönderimi, API uç noktaları) manuel olarak test edin.
• Güncellemenin getirdiği yeni hataları veya uyarıları görmek için uygulama loglarını inceleyin.
• CMS'inizde bir hazırlık eklentisi veya dağıtım iş akışı varsa kullanın (ör. WordPress için WP Staging, Drupal için Acquia Cloud).
• Test sırasında keşfedilen uyumluluk sorunlarını belgeleyin ve üretime geçmeden önce çözün.

İyi test edilmiş güncellemeler bile ortam farklılıkları veya uç durum verileri nedeniyle zaman zaman üretimde sorun çıkarabilir. Disiplinli bir dağıtım prosedürü, bir şeyler ters gittiğinde hasarı en aza indirir.

• Herhangi bir güncelleme uygulamadan hemen önce veritabanınızın ve dosya sisteminizin tam yedeğini alın — yedeğin geri yüklenebilir olduğunu doğrulayın.
• Güncelleme süreci sırasında veri bozulmasını önlemek için güncellemeleri uygulamadan önce CMS'inizde bakım modunu etkinleştirin.
• Geri dönüş gerekirse kullanıcı etkisini azaltmak için güncellemeleri düşük trafikli bir zaman diliminde uygulayın.
• CMS platformları için: manuel dosya değiştirme yerine yerleşik güncelleyicileri kullanın (WordPress Panosu, Drupal'ın drush updb'si, Joomla Güncelleme Yöneticisi).
• Kod ile yönetilen bağımlılıklar için: lock dosyanızı güncelleyin (npm install, composer update), sürüm kontrolüne işleyin ve standart hattınız aracılığıyla dağıtın.
• Dağıtımdan hemen sonra anomaliler için izleme panolarınızı, hata loglarınızı ve çalışma süresi uyarılarınızı kontrol edin.
• Bir geri dönüş planınızı hazır tutun: yedekten nasıl geri yükleyeceğinizi veya bir dağıtımı dakikalar içinde nasıl geri alacağınızı tam olarak bilin.

Her pasif eklenti, kullanılmayan tema veya terk edilmiş kütüphane gereksiz bir saldırı yüzeyidir. Saldırganlar, örneğin devre dışı bırakılmış ancak hâlâ kurulu WordPress eklentilerindeki açıklıkları düzenli olarak istismar eder; çünkü kullanılmasa bile kod disk üzerinde varlığını sürdürür.

• Tüm kurulu CMS eklentilerini ve temalarını denetleyin; aktif olarak kullanılmayanları tamamen kaldırın (yalnızca devre dışı bırakmak değil, silin).
• Kullanılmayan npm paketlerini kaldırın: npm prune komutunu çalıştırın ve artık ihtiyaç duyulmayan girişleri package.json'dan silin.
• Kullanılmayan Composer paketlerini kaldırın: artık ihtiyaç duyulmayan paketler için composer remove vendor/package komutunu çalıştırın.
• Terk edilmiş kütüphaneleri (2+ yıldır commit yok, CVE'lere yanıt yok) aktif olarak desteklenen alternatiflerle değiştirin.
• Aynı işlevi yerine getiren çakışan kütüphaneleri (ör. iki tarih biçimlendirme kütüphanesi) birleştirerek yüzey alanını azaltın.
• HTML şablonlarınızdan kullanılmayan CDN yüklü script'leri inceleyin ve kaldırın.

Düşük riskli, iyi test edilmiş güncellemeler için — özellikle CMS küçük sürümleri ve güvenlik yamaları — otomatik güncellemeleri etkinleştirmek, her seferinde manuel müdahale gerektirmeden açıklık duyurusu ile yama uygulaması arasındaki süreyi kısaltır.

• WordPress'te küçük ve güvenlik sürümleri için otomatik arka plan güncellemelerini etkinleştirin: wp-config.php dosyasına define('WP_AUTO_UPDATE_CORE', 'minor'); ekleyin veya bunu yöneten bir yönetilen barındırma planı kullanın.
• Güvendiğiniz ve güçlü bir güncelleme geçmişine sahip WordPress eklentileri için otomatik güncellemeleri etkinleştirin.
• Drupal'da yalnızca güvenlik güncellemeleri için drupal/automatic_updates modülünü kullanmayı değerlendirin.
• CI kontrollerini geçen yama düzeyindeki bağımlılık güncellemelerini otomatik olarak birleştirmek için Dependabot'u yapılandırın.
• Otomatik güncelleme bildirimlerinin izlenen bir e-posta adresine veya Slack kanalına gönderildiğinden emin olun, böylece her zaman neyin değiştiğinden haberdar olun.
• Olası kırılma değişiklikleri nedeniyle manuel test gerektiren büyük sürüm yükseltmeleri için otomatik güncellemeleri ETKİNLEŞTİRMEYİN.

Güncelleme sürecinin kendisi bile bir saldırı vektörü olabilir. Meşru bir pakete kötü amaçlı kodun enjekte edildiği tedarik zinciri saldırıları giderek yaygınlaşmaktadır. Yüklediğiniz şeyin bütünlüğünü doğrulamak için adımlar atın.

• Eklentileri, temaları ve paketleri yalnızca resmi depolardan (WordPress.org, Packagist, npm, PyPI) veya güvenilir satıcılardan yükleyin.
• Mümkün olduğunda CMS çekirdek sürümleri için GPG imzalarını doğrulayın (Drupal ve Joomla imzalı sürüm arşivleri yayımlar).
• CI ortamlarında lock dosyanızda belirtilen tam sürümleri yüklemek için npm install yerine npm ci kullanın.
• CDN'den yüklenen JavaScript veya CSS için <script> ve <link> etiketlerinize integrity ve crossorigin öznitelikleri ekleyerek Alt Kaynak Bütünlüğü'nü (SRI) etkinleştirin.
• Projenize eklemeden önce yeni veya tanıdık olmayan paketleri şüpheli kod açısından denetleyin (bakıcı geçmişini, indirme sayılarını ve kaynak kodu kontrol edin).
• Yazım hatası riski taşıyan paket adlarını yüklemekten kaçının (ör. lodash ile lodahs) — yükleme komutlarını çalıştırmadan önce paket adlarını iki kez kontrol edin.

Yazılımı güncel tutmak tek seferlik bir görev değil, süregelen bir operasyonel süreçtir. Her gün yeni açıklıklar duyurulmaktadır ve sürekli izlemeyi düzenli iş akışınıza dahil etmediğiniz sürece yığınınız geride kalacaktır.

• Yazılım envanterinizin tamamını mevcut en güncel sürümlere karşı gözden geçirmek için aylık yinelenen bir gözden geçirme planlayın.
• Büyük bileşenlerin ömür sonu (EOL) tarihleri için takvim hatırlatıcıları ayarlayın veya uyarıları otomatikleştirin (ör. PHP sürümü EOL tarihleri, Node.js LTS bitiş tarihleri).
• Bağımlılık denetim komutlarını (npm audit, composer audit, pip-audit) en az haftalık veya önemli her bağımlılık değişikliğinden sonra yeniden çalıştırın.
• Güncelleme politikanızı ve CI/CD güvenlik kontrollerinizi mevcut yığınınızı kapsadığından emin olmak için üç ayda bir gözden geçirin.
• Güvenlik açıklıkları için ortalama yama sürenizi (MTTP) bir KPI olarak takip edin ve zamanla azaltmayı hedefleyin.
• Canlı uygulamanızın sürekli otomatik taranmasını kullanarak sürüm ifşalarını ve güncel olmayan bileşenleri ortaya çıktıkça yakalayın — Sensagraph, tespit edilen yazılım yığınınızdaki yeni açıklanan güvenlik açıkları için sitenizi 7/24 izler.