PHP krizinden çıkardığım ders: Güvenlik ortak sorumluluk

PHP’de yaşananlar, yazılım geliştiren ve sunucu yöneten herkesin sorumluluğunu yeniden düşünmesini gerektiriyor. Bir uygulamayı çalışır hâlde yayına aldığımızda, o sistemin bakımını ve insanların bize emanet ettiği verilerin güvenliğini de üstleniyoruz. Güvenliği, proje teslim edildikten sonra ihtiyaç olursa bakılacak bir iş gibi ele almanın bedelini kullanıcılar ödüyor.

OpenAI, Calif ve Wiz gibi ekiplerin bu açıkların araştırılmasındaki katkıları değerli. Yapay zekânın güvenlik çalışmalarını hızlandırması da önemli bir gelişme. Ancak bu olayın açıklanma sürecinde ciddi koordinasyon sorunları yaşandığı da PHP Foundation’ın süreç değerlendirmesinde açıkça anlatılıyor.

Örneğin PHP Foundation’ın aktardığına göre Calif, saldırının çalıştığını gösteren bir videoyu yanlışlıkla yayımladı. Video sonradan silinse de kopyaları dolaşıma girdi. Chainguard ise güvenlik düzeltmesini içeren hazır imajları, ortak açıklama saatinden altı saatten fazla önce yayımladı. Böylece düzeltmenin incelenmesi mümkün hâle gelirken diğer dağıtımların kullanıcıları hâlâ güncellemeyi bekliyordu.

Benim burada beklediğim, açığı bulan ve düzeltmeyi dağıtan kurumların sürecin tamamını sahiplenmesi. Bir güvenlik araştırmasının başarısı, çalışan bir saldırı videosu göstermekle ölçülemez. Hazırlanan düzeltmenin insanlara güvenli ve uygulanabilir biçimde ulaşması da o çalışmanın parçası. Bu ölçekte bir olayda yanlışlıkla yapılan bir paylaşımın bile ciddi sonuçları olabileceğini hesaba katmak zorundayız.

Amazon / AWS’nin bulguları da zamanın ne kadar önemli olduğunu gösteriyor. AWS, 21 Ekim’deki kamuya açıklamadan önce, 17 Ekim’e uzanan bir saldırı girişimi tespit ettiğini bildiriyor. Bu, incelemeye yalnızca duyuru tarihinden başlamanın eksik kalabileceği anlamına geliyor. Ancak bu gözlemden hareketle ilk girişimin Calif’in veya Chainguard’ın paylaşımlarından kaynaklandığını söyleyemeyiz. Tarihleri ve kanıtları birbirine karıştırmadan konuşmak gerekiyor.

PHP Foundation’ın kendi tarafındaki gecikmeyi de değerlendirmesine katmasını önemli buluyorum. Vakıf; karar alma sürecindeki sorunları, sınırlı uzman sayısını ve kaynak eksikliğini anlatıyor. Böyle kritik bir altyapıda zor kararların aylarca sürüncemede kalmasını önleyecek bir yapı kurulması gerekiyor.

Burada şirketlerin ve kamu kurumlarının da kendine sorması gereken sorular var. PHP üzerinden hizmet sunuyoruz, ticaret yapıyoruz, gelir elde ediyoruz. Peki bu altyapının bakımına, güvenlik araştırmalarına ve uzman yetiştirilmesine ne kadar katkı sağlıyoruz? Açık kaynak kullanırken lisans maliyetinden tasarruf ediyorsak bunun bir bölümünü o ekosistemin sürdürülebilmesine ayırmayı da konuşmalıyız. Sürekli güvenlik bekleyip güvenliği sağlayacak insanlara bütçe ayırmamak sürdürülebilir bir yaklaşım değil.

Sistem yöneten biri olarak benim görmek istediğim cevap da somut: Hangi uygulama, hangi sunucuda, hangi PHP sürümüyle çalışıyor? Düzeltme gerçekten çalışan servise ulaştı mı? Konteyner kullanılıyorsa yeni imaj dağıtıldı mı? Güncellemeden sonra uygulama kontrol edildi mi? Geçmişte bir saldırı yaşanmış olabileceği araştırıldı mı? Yalnızca güncelleme komutunun başarıyla bitmesi, bütün bu soruları cevaplamıyor.

Teknik bilgiyi aktarırken de doğru yönlendirmek gerekiyor. Bu iki açık için düzeltmeler PHP 8.2.35, 8.3.36, 8.4.27 ve 8.5.12 sürümlerinde yayımlandı. Kullanılan dala uygun sürüm veya dağıtım sağlayıcısının düzeltmeyi taşıdığı paket doğrulanmalı. Herkese tek bir sürüm numarası söylemek, farklı sistemlerin durumunu anlatmaya yetmiyor.

Son kullanıcıdan telefonuna PHP güncellemesi yüklemesini bekleyemeyiz. Ama hizmet aldığı şirketin verilerini nasıl koruduğunu sorgulaması son derece doğal. O güveni korumak; geliştiricinin, sistem yöneticisinin, hizmet sağlayıcının ve bütçeye karar veren yönetimin ortak sorumluluğu.

Kapak ve Türkçe spiker videosu yapay zekâyla üretilmiş temsili içeriklerdir.