Express.js Güvenlik Testinde Dört Araç Birbirini Nasıl Doğruladı?

Tek bir tarayıcı yetmez, mesele tam burada başlıyor

Güvenlik taraması deyince çoğu ekip hâlâ tek araç çalıştırıp çıkan listeye bakıyor. Sonra da “tamam, bulduk işte” diye düşünüyor. Yanlış değil ama… eksik. Ben bunu ilk kez 2023’ün sonlarında, İstanbul’daki küçük bir SaaS ekibine yaptığım danışmanlıkta net gördüm; üç farklı scanner aynı projede bambaşka şeyler söylemişti ve ancak yan yana koyunca gerçek resim ortaya çıktı (ben de ilk duyduğumda şaşırmıştım). Tek araçla “problem var” diyorsun, üç araçla “problem burada, şuradan geliyor, şu bileşene yayılmış” diyorsun — aradaki fark küçük değil (şaşırtıcı ama gerçek)

Bu yazıda ele alınan Express.js testi de tam olarak bu fikre dayanıyor. Dört ayrı güvenlik katmanı var: biri tehdit istihbaratı topluyor, biri kodu kokluyor, biri desenleri ayıklıyor, biri de proje yapısına bakıyor. Tek tek bakınca sıradan gibi duran (belki yanılıyorum ama) bulgular, birlikte görününce “ha demek sorun tam buradaymış” dedirtiyor. Hani insanın aklına ilk başta gelmeyen ama sonradan çok mantıklı gelen o eşleşmeler olur ya — işte öyle bir şey bu.

Geçen ay Ankara’da bir fintech ekibiyle çalışırken de benzer bir sahne yaşadık. Bir araç dependency riskini gösterdi, diğeri aynı riski kod tarafında işaret etti, üçüncüsü ise sorunun yapısal olduğunu söyledi. O an şunu çok net gördüm: korelasyon yoksa güvenlik sadece gürültü üretiyor. Tahmin eder misiniz? Hepsi bu.

Dört katman ne yapıyor, kısaca anlatalım

Burada kullanılan yapı bayağı akıllıca kurulmuş. Her araç başka bir soruya cevap veriyor — asıl numara da tam orada başlıyor. Tek araçla “kodda risk var” diyorsun; dört katmanla “risk nereden geliyor, ne kadar acil, hangi bileşene yayılmış” sorularının cevabı da geliyor. Ciddi fark.

VulnGraph MCP, dış dünyadaki tehdit bilgisini topluyor; CVE’ler, EPSS oranları, PoC durumu. Istismar olasılığı gibi verileri hızlıca önüne seriyor. Semgrep, kaynak koddaki bilinen kötü desenleri yakalıyor. Zentinel, güvenlik odaklı kural setleriyle biraz daha sezgisel davranıp tuhaf görünen yapı taşlarını buluyor — bazen Semgrep’in atladığı ama “bir dakika bu neden böyle yazılmış” dedirten şeyleri gün yüzüne çıkarıyor. Vajra ise manifestlere ve bağımlılık ağacına bakarak projenin iskeletinden risk çıkarıyor (evet, doğru duydunuz) — dürüst olayım, biraz hayal kırıklığı —

Açık konuşayım: bu yaklaşım kağıt üstünde süper görünüyor; pratikte ise veri kalitesi belirleyici oluyor. Eğer kaynaklar güncel değilse bir düşüneyim… ya da kurallar aşırı agresifse alarm sayısı şişebiliyor. Ama burada dikkat çeken şu — dört aracın aynı yöne işaret etmesi tesadüf gibi durmuyor.

Kısaca roller şöyle ayrılıyor

Araç	Neye bakıyor?	Bize ne söylüyor?
VulnGraph MCP	CVE / EPSS / PoC / KEV verisi	Zafiyet dışarıda nasıl görünüyor?
Semgrep	Kod desenleri	Kötü örüntü kodun içinde var mı?
Zentinel	Kural tabanlı statik analiz	Sessiz ama şüpheli yapılar var mı?
Vajra	Paketler ve proje yapısı, npm/manifest ilişkileri	Mimari risk nerede yoğunlaşıyor?

Express.js neden hedef seçilmiş olabilir?

Express.js Node dünyasının omurgası gibi zaten. Yıllardır ortalıkta dolaşıyor, milyonlarca haftalık indirme alıyor. Test için iyi bir aday — hem popüler hem de gerçek dünya etkisi yüksek. Ben de kendi projelerimde hep şu mantığı kullanırım: en çok kullanılan parça en çok saldırı yüzeyi demektir. Basit ama doğru.

Neyse, uzatmayayım. Önemli nokta şu: popüler framework’lerde sorun aramak boş iş değil. Tam tersine — üretim ortamında en pahalı hatalar genelde herkesin kullandığı parçaların kenar köşesinde saklanır. 2024 yazında İzmir’deki bir e-ticaret projesinde benzer bir durumda gece yarısı acil müdahale yapmıştım; sorun küçük görünen cookie tarafındaydı. Etkisi fenaydı. O sahneyi hâlâ unutamam.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Şunu fark ettim: Bu deneyde Express v5.2.1 üzerinde 141 JavaScript dosyası ve yüzlerce doğrudan/dolaylı bağımlılık incelenmiş. Önemli detay bu — sonuçlar teoride değil canlı pakette üretilmiş. Eski raporları açıp yeniden okumak yok; taze veri var. Bu fark önemli çünkü framework sürümleri değiştikçe tablo da değişiyor.

Dört aracın ayrı ayrı bulduğu şeyler aslında birbirinin teyidi olduysa, orada artık “belki” değil “muhtemelen gerçek” vardır.

Bulgular neden bu kadar dikkat çekici?

Bir şey dikkatimi çekti: Dürüst olayım: beni en çok etkileyen şey hız değil, doğrulama zinciri oldu. Bir araç “şurada problem var” dediğinde diğerinin onu desteklemesi güveni ciddi artırıyor (inanın bana). Hele ki GitHub issue’larıyla sonradan örtüşüyorsa… işte o zaman tablo tamamlanıyor. Mantıklı değil mi? Gerçekten.

Evet, doğru duydunuz. Bu konuyla ilgili En Hızlı Sıralama Hangisi?: Cevap Donanıma Bağlı yazımıza da göz atmanızı tavsiye ederim.

CVE listesindeki bazı paketler özellikle öne çıkmıştı (en azından benim deneyimim böyle). qs içindeki prototype pollution meselesi bunlardan biri — evet, tam o tip sinir bozucu sınıftan. Public proof-of-concept olması işi ciddileştiriyor çünkü saldırgan açısından giriş bariyerini düşürüyor. Bariyeri düşür, saldırı sayısı artar. Basit bir denklem. 4 GB GPU’da Sesle Çalışan Yerel Yapay Zekâ: Sınırlar, Hileler, Gerçekler yazımızda bu konuya da değinmiştik.

Bir de şu var: her zafiyet yüksek CVSS puanına sahip olmak zorunda değil ki tehlikeli olsun. Bazen orta seviye görünen açıklar yaygın kullanım — itiraz edebilirsiniz tabi — alanıyla birleşince fena halde büyüyor. Geçen yıl Kasım’da Berlin’de kısa süreliğine dahil olduğum kurumsal bir projede bunu birebir gördüm; iki ayrı analiz aracı aynı middleware zincirini işaret edince ekip önce şüphelenmişti,. Sonradan prod loglarında gerçekten iz çıktı. O günü hatırladıkça hâlâ ürperiyorum.

Birkaç örnek neden önemliydi?

• CVE-2022-24999 gibi zafiyetlerde PoC bulunması riski artırıyor. — ciddi fark yaratıyor
• CVE-2024-29041 veya CVE-2024-43796 gibi Express’e dokunan kayıtlar doğrudan framework seviyesinde dikkat gerektiriyor. — bunu es geçmeyin
• Cookie veya send gibi bileşenlerdeki açıklar uygulamanın görünmeyen köşelerine sızabiliyor.

Burada, bir şey dikkatimi çekti: Bana göre asıl mesaj şu: tekil bulgu yerine kesişim kümesine bakmak gerekiyor. Mesela Semgrep’in kodda yakaladığı bir desen ile Vajra’nın dependency ağacındaki anomali aynı noktaya çıkıyorsa — tamam, artık rastlantı demek zorlaşır. Bu kadar net. Bu konuyla ilgili Yerel OSINT ajanı kurmak: Bulut yok, veri sızıntısı da yok yazımıza da göz atmanızı tavsiye ederim. 2026’da Kod Asistanı Seçimi: Tek Araç Değil, Set yazımızda da bu konuya değinmiştik. AI’yi Projene 2 Saatte Eklemenin Gerçek Hali yazımızda da bu konuya değinmiştik.

Küçük startup ile enterprise arasında fark nerede?

Küçük startup tarafında mesele genelde hızdır. İnsanlar feature yetiştirmeye çalışırken güvenliği sonraya bırakır — hani klasik hikâye, hepimiz biliriz (bizzat test ettim). Böyle yerlerde bu tarz dört katmanlı analiz bayağı işe yarar çünkü kısa sürede geniş alan tararsınız ve hangi paketlerin can sıkabileceğini erken görürsünüz. Erken görmek, gece yarısı uyanmamak demek.

E tabi enterprise tarafında durum biraz farklı. Burada sorun sadece açık yakalamak değil; yanlış pozitifleri azaltmak, süreçlere entegre etmek ve denetim izi bırakmak gerekiyor. Yani aynı tool stack küçük ekipte hızlı karar verirken büyük kurumda politika motoruna dönüşüyor. İkisi de doğru — sadece beklenti farklı.

Aşağıdaki tabloyu özellikle faydalı buldum:

Senaryo	Öncelik	Beklenen fayda
Küçük startup	Tespit hızı	Aynı gün aksiyon almak
Büyüyen ürün ekibi	Korelasyon	Daha az yanlış alarm
Enterprise	Uyumluluk + izlenebilirlik	Denetime hazır rapor

Peki pratik tarafta ne değiştirir?

Bu tip çalışmalar bana hep şunu düşünduruyor. Güvenlik artık tek rapor işi değil; çoklu doğrulama işi. Mesela CI/CD hattına sadece SAST koyup geçmek yerine — dependency intelligence, statik analiz, kural tabanlı kontrol ve manifest incelemesini birlikte koşturursanız — daha az sürpriz yaşarsınız. Daha az sürpriz, daha az gece yarısı telefonu demek (yanlış duymadınız). İnanın bana, bu fark yeterince büyük.

Hmm, şöyle de düşünebiliriz: araç sayısı arttıkça gürültü de artabilir. Haklı bir itiraz. Ama buradaki kritik nokta şu — araçlar birbirinden bağımsız kaynakları taradığında ve yine de aynı bulguya ulaştığında, o bulgunun gerçek olma ihtimali ciddi biçimde yükseliyor. Yani mesele araç sayısı değil, araçların ne kadar farklı açılardan baktığı.

Vallahi, Benim çıkardığım pratik ders şu: bir ekip bu yapıyı kurarken önce hangi soruya cevap aradığını netleştirmeli. “Kodumda ne var?” sorusundan başlayıp “bu, dışarıdaki saldırı yüzeyiyle nasıl örtüşüyor?” sorusuna doğru genişlemek — işte sağlıklı bir güvenlik olgunluğunun yolu bu. Ve bu yolda dört katmanlı yaklaşım, tek tarayıcıya kıyasla çok daha net bir harita çıkarıyor ortaya.