Vercel ve Context.ai Olayı: AI SaaS Güvenliği

Olay Zaman Çizelgesi

20 Nisan 2026'da Vercel, iç sistemlerine yetkisiz erişimi içeren bir güvenlik olayını duyurdu. Resmi açıklamasına göre olay, bir Vercel çalışanının kullandığı üçüncü parti bir yapay zeka aracı olan Context.ai'ın ele geçirilmesinden kaynaklandı. Vercel'in açıklamasına göre saldırganlar, bu ihlali kullanarak OAuth aracılığıyla çalışanın Google Workspace hesabını ele geçirdi ve ardından bazı iç ortamlara ile hassas olmayan ortam değişkenlerine (environment variables) erişim sağladı.

Olay etrafındaki kamusal tartışma kısa sürede tek bir SaaS ihlalinin ötesine geçti ve geliştirici altyapılarını etkileyen daha geniş bir tedarik zinciri (supply-chain) saldırı modeli olarak okunmaya başladı.

Gerçekte Ne Biliyoruz?

Vercel'in yayımladığı bültene göre:

• İlk erişim (foothold), üçüncü parti bir yapay zeka aracını içeren bir uzlaşmayla bağlantılıydı;
• Saldırganlar, Google Workspace üzerinden OAuth bağlantılı erişimi kullanarak yanal hareket (lateral movement) sağladı;
• Vercel'in ana altyapısı değil, hedef alınan bir çalışanın izole edilmiş ortamı (environment) etkilendi.

Bu Olay Neden Vercel'den Çok Daha Önemli?

Vercel bu olayı hızlıca tespit edip izole etti. Ancak bu olayın asıl gösterdiği şey, kurumsal SaaS güvenliğinin artık yapay zeka araçları tarafından tamamen delindiğidir.

Geleneksel güvenlik testlerinde biz genellikle uygulamanın kendisine odaklanırız. Namun, modern kurumlarda "Shadow AI" ve OAuth ile bağlanan üçüncü parti botlar en zayıf halkanız haline gelmiştir. Geliştiriciler verimlilik aracı olarak AI asistanları kullanırken, bu asistanlara şirketinizin Google Workspace, GitHub veya Slack ortamlarına okuma/yazma yetkileri (OAuth token) veriyorlar. Bu araçların sunucuları veya veri tabanları ele geçirildiğinde, saldırgan doğrudan sizin kurumsal kimliğinize erişim elde eder.

Yeni Güvenlik Dersi

1. Yapay Zeka Bir Arka Kapıdır (Backdoor): Çalışanlarınızın yetkilendirdiği AI araçları (özellikle context veya memory okumak için e-postalara ve kod depolarına erişim isteyenler) artık saldırganların en sevdiği arka kapıdır.
2. OAuth Kapsamları Tehlikeli Bir Seviyede: "Yalnızca okuma" yetkisine sahip bir AI aracının token'ı çalındığında, saldırganlar tüm kurumsal veri setinize sızabilir. Vercel olayında yaşanan tam olarak buydu.
3. Tedarik Zinciri Artık Sadece Kütüphaneler Değil: Geçmişte npm veya PyPI kütüphanelerinden korkardık. Bugün, "Tedarik Zinciri" dediğimiz şey, sisteminize API anahtarı ile bağlanan yapay zeka araçlarının bütünüdür.

Ekipler Ne Yapmalı?

1. AI Entegrasyonlarını İzole Edin: Üçüncü parti AI botlarına asla ana Workspace hesapları üzerinden "Full Access" (Tam Erişim) vermeyin.
2. Düzenli Sızma Testi: Artık sadece uygulamanızın kodunu değil, uygulamanıza bağlı AI ajanlarının ve third-party servislerin OAuth yetkilerini de test ettirin. Eresus Security olarak biz, Red Team operasyonlarımızda tam olarak bu saldırı yollarını kurguluyoruz.
3. "Shadow AI" Avına Çıkın: Ekibinizin şirketin kodunu veya iç verilerini hangi third-party AI araçlarına beslediğini düzenli olarak denetleyin.

Kapanış Düşüncesi: Vercel olayı bir istisna değil. Yapay zekanın geliştirici iş akışlarına entegrasyonu arttıkça, bu tür "yanal yapay zeka saldırıları" önümüzdeki yılların en popüler siber güvenlik sorunu olacak.

Temel Değerlendirme

Vercel ve Context.ai Olayı: AI SaaS Güvenliği konusu yalnızca teknik bir ayrıntı değildir; yanlış ele alındığında veri sızıntısı, yetki aşımı, operasyon kesintisi veya regülasyon riski doğurur. En doğru yaklaşım, varlıkları ve kullanıcı rollerini netleştirip gerçek saldırı yolunu kanıtla test etmek, ardından düzeltmeyi ölçülebilir retest kriterine bağlamaktır.

Neden Kritik?

• Saldırganlar çoğu zaman en zayıf teknik kontrolü değil, en zayıf varsayımı hedefler.
• Otomatik taramalar bilinen kalıpları yakalayabilir ama iş etkisini ve zincirleme saldırı yolunu tek başına göstermez.
• Güvenlik çıktısı geliştirici, yönetici ve uyum ekibi tarafından aynı şekilde anlaşılmıyorsa aksiyona dönüşmez.

Pratik Senaryo

Bir ekip sistemi güvenli kabul eder çünkü login çalışır, pipeline yeşildir veya model beklenen cevabı üretir. Ancak saldırgan aynı akışta farklı kullanıcı, farklı tenant, farklı dosya veya farklı token ile deneme yaptığında tasarımın sakladığı gerçek risk ortaya çıkar. Bu yüzden testler mutlu yol yerine kötüye kullanım senaryolarıyla yazılmalıdır.

Yanlış Bilinenler

• “Araç taradı, kritik yok” güvenlik onayı değildir.
• “İç sistem, saldırgan erişemez” varsayımı modern saldırı zincirlerinde zayıftır.
• “Bu sadece teknik borç” denilen konu çoğu zaman müşteri verisi veya production erişimiyle birleşir.

Karar Tablosu

| Durum | Risk seviyesi | Önerilen aksiyon | | --- | --- | --- | | Demo veya izole test ortamı | Düşük-Orta | Mimari kararları ve veri akışını belgeleyin | | Staging production verisine yakın | Orta-Yüksek | Yetki, log ve abuse testlerini ekleyin | | Production veya müşteri verisi | Yüksek | Profesyonel assessment, remediation ve retest planlayın |

Kontrol Listesi

• Hangi veri modele veya retrieval katmanına giriyor?
• Kullanıcı yetkisi retrieval sonucuna uygulanıyor mu?
• Tool çağrıları insan onayı veya policy kontrolünden geçiyor mu?
• Prompt, cevap ve hata loglarında hassas veri maskeleniyor mu?
• Model/prompt değiştiğinde regresyon testi koşuyor mu?

Ne Zaman Profesyonel Destek Gerekir?

Sistem gerçek müşteri verisine, kurum içi dokümana, harici tool çağrılarına veya otomatik karar akışına bağlıysa profesyonel AI security assessment gerekir.

Eresus Yaklaşımı

Eresus Security bulguları yalnızca başlık olarak raporlamaz. Her bulgu için tekrar üretilebilir kanıt, iş etkisi, önerilen düzeltme, sorumlu ekip ve retest koşulu yazılır.

Eresus Security, AI uygulamalarında veri sınırı, tool kullanımı, RAG erişimi, oturum yönetimi ve üretim öncesi abuse senaryolarını birlikte test eder. Canlıya çıkmadan önce kısa bir AI Security Review ile riskleri kanıta bağlayabiliriz.

Uygulama Planı

1. Kapsamı Netleştir

• Etkilenen varlıkları, kullanıcı rollerini ve veri sınıflarını çıkarın.
• Normal kullanıcı akışıyla saldırgan akışını ayrı ayrı yazın.
• Hariç tutulan sistemleri ve test sınırlarını açıkça belirtin.

2. Kanıt Üret

• Bulguyu tek ekran görüntüsüne değil, tekrar üretilebilir adımlara bağlayın.
• Etkiyi teknik hata ve iş sonucu olarak ayrı açıklayın.
• Log, request ID, test hesabı ve zaman bilgisini not edin.

3. Retest Kriterini Belirle

• Düzeltmenin ne zaman tamam sayılacağını önceden yazın.
• Aynı sınıf hatanın başka endpoint veya akışlarda olup olmadığını kontrol edin.
• Bulguyu kapatmadan önce negatif test senaryosunu yeniden çalıştırın.

Sık Sorulan Sorular

Vercel ve Context.ai Olayı: AI SaaS Güvenliği için ilk adım nedir?

İlk adım sistemin hangi veriye, hangi kimlikle ve hangi iş akışı üzerinden eriştiğini çıkarmaktır. Araç seçimi bundan sonra anlamlı hale gelir.

Otomatik araçlar bu riski tamamen yakalar mı?

Hayır. Otomatik araçlar başlangıç için faydalıdır, fakat yetki sınırı, iş mantığı, zincirleme etki ve gerçek istismar kanıtı manuel analiz gerektirir.

Bu çalışma çıktısı nasıl aksiyona dönüşür?

Her bulgu bir remediation sahibi, öncelik, iş etkisi ve retest kriteriyle yazıldığında doğrudan güvenlik backlog’una veya sprint planına girebilir.

Eresus bu konuda nasıl destek olur?

Eresus Security kapsam çıkarma, teknik test, kanıt üretimi, remediation danışmanlığı ve retest aşamalarını tek çalışma akışında destekler.

Raporlama ve İç Link Stratejisi

• Yazı ilgili hub sayfasına bağlanmalı ve okuyucuya bir sonraki teknik adımı göstermelidir.
• Aynı pillar içindeki en az iki destekleyici bloga bağlantı verilmelidir.
• Hizmet CTA’sı genel iletişim çağrısı gibi değil, okuyucunun karar anına uygun şekilde yazılmalıdır.
• Raporlama dili teknik kanıt, iş etkisi ve düzeltme önceliğini aynı yerde göstermelidir.

Retest Kapanış Kriteri

Bir bulgu yalnızca düzeltme yapıldı diye kapanmış sayılmaz. Aynı saldırı adımı tekrar denendiğinde başarısız olmalı, loglarda beklenen kayıt oluşmalı ve benzer akışlarda aynı sınıf hata bulunmamalıdır. Bu yaklaşım içeriği sadece bilgilendirici olmaktan çıkarıp uygulamaya dönük hale getirir.

Ek Kontrol Soruları

• Bu risk hangi varlıkları etkiliyor?
• Hangi kullanıcı rolleri bu akışa erişebiliyor?
• Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
• Bulgunun müşteri verisine etkisi var mı?
• Loglardan olayın izi sürülebiliyor mu?
• Düzeltme sonrası retest nasıl yapılacak?
• Geçici önlem ile kalıcı çözüm ayrıldı mı?
• İş etkisi teknik ekibin dışında da anlaşılır mı?
• Benzer hata için önleyici kontrol eklenebilir mi?
• Ekip bu kontrolü release sürecine bağlayabilir mi?
• Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
• Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?