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 dayaniyor. 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 yanilı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 ölür 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ü işe 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 mısınız? 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 açıl, 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 işe 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 işe 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	Mimarı 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ı açıl müdahale yapmıştım; sorun küçük görünen cookie tarafındaydı. Etkisi fenaydı. O sahneyi hâlâ unutamam.

Ş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 önü 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 tıp sınır 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 hâlde 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 Hâli 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 tıp ç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.

Sıkça Sorulan Sorular

Tek bir güvenlik aracı kullanmak neden yetmiyor?

Çünkü her araç farklı bir “bakış açısı” ile çalışıyor: biri tehdit istihbaratına bakar, diğeri koddaki desenleri yakalar, bir diğeri de proje yapısını yorumlar. Tek araçla sadece “risk var” görürsün; diğer araçlar aynı riskin nereden geldiğini ve nasıl yayıldığını daha net gösterebilir. Benim gördüğüm en büyük fark, korelasyon olunca gürültünün azalması.

Dört araçla çalışmak bulguları mı artırır, yoksa doğruluğu mu?

Asıl mesele doğruluğu artırmak. Elbette toplam alarm sayısı artabilir ama önemli olan, farklı araçların aynı noktayı bağımsız biçimde işaret etmesi. Bu yaklaşım, “tesadüf mü, gerçek zafiyet mi?” sorusunu yanitlamaya yarıyor. Özellikle Express.js gibi hızlı gelişen projelerde bu korelasyon çok değerli oluyor.

VulnGraph, Semgrep ve diğerleri hangi sorulara cevap veriyor?

VulnGraph gibi araçlar genelde dış dünyadaki sinyalleri (CVE/EPSS/PoC gibi) öne çıkarır; Semgrep işe kaynak koddaki bilinen kötü desenleri yakalar. Diğer katmanlar da yapı/manifest/dependency ağacı gibi “neden bu hâle gelmiş” tarafını anlamaya yardım eder. Dört katman birlikte olunca “etki nerede, kök neden ne” daha hızlı bulunuyor.

Alarm sayısı şişerse bu yaklaşım hâlâ işe yarar mı?

Yarar, ama veri kalitesi ve kural hassasiyeti belirleyici. Kaynaklar güncel değilse veya kurallar çok agresifse yanlış pozitif artabilir. Ben genelde bu durumda ilk etapta “birden fazla aracın aynı bileşeni işaretlemesi” şartını filtre olarak kullanıyorum; böylece gürültüyü daha hızlı eleyebiliyoruz.

Express.js güvenlik testinde pratik olarak neyi hedeflemek lazım?

Hedef, sadece zafiyeti bulmak değil; zafiyetin hangi route/handler üzerinden tetiklendiğini ve hangi dependency veya kod parçasına dayandığını anlamak. Dış istihbarat + kod analizi + proje yapısı birleşince düzeltme planı daha net çıkıyor. Sonuçta “ne var?” kadar “nasıl düzelteceğiz ve etkiyi nasıl azaltacağız?” sorusuna da cevap veriyor.

Kaynaklar ve İleri Okuma

Azure Güvenlik Dokümantasyonu

Microsoft Defender for Cloud

Semgrep Resmî Site

Semgrep GitHub Deposu