FOSRES Nedir? Açık Kaynak Güvenlik Eğitimi İçin Yeni Bir Yol

Bir güvenlik yazısı görüp “tamam, bu yine teoride güzel duruyor. Pratikte ne olacak?” diye düşünmeyeli uzun zaman olmadı (ben de ilk duyduğumda şaşırmıştım). Geçen ay İstanbul’da bir toplantıda tam da bu cümleyi kuran iki farklı ekip gördüm: biri startup tarafında, diğeri kurumsal tarafta çalışıyordu. İkisinin ortak derdi aynıydı; güvenliği öğrenmek isteyen çok kişi var, ama elini kirletecek, hata yapacak ve sonra o hatayı düzeltecek alan bulmak zor.

İşte FOSRES’i ilginç yapan şey de biraz bu (yanlış duymadınız). Free and Open Source Security Research fikri, kağıt üstünde sıradan bir eğitim projesi gibi dursa da aslında daha sert bir iddia taşıyor: “Güvenliği okuyarak değil, bozup düzelterek öğreneceksin.” Açık konuşayım — ben böyle projeleri severim. Çünkü saldırı yüzeyi dediğimiz şey kitapta başka, gerçek hayatta bambaşka görünüyor. Hele web, bulut ve AI güvenliği bir aradaysa… orada işler biraz karışıyor.

Bunu biraz açayım.

FOSRES Tam Olarak Ne Yapmaya Çalışıyor?

Tanveer Salim’in anlattığı çerçeveye göre FOSRES; geleceğin Security Engineer’larını yetiştirmeyi hedefleyen açık kaynaklı bir araştırma. Uygulama projesi. Bana biraz eski usul laboratuvar derslerini hatırlattı, açıkçası. Hani tahtada anlatılan SQL injection örneğiyle yetinmezsiniz ya — girersiniz sisteme, parametrelerle oynarsınız, sonra neden patladığını kendi gözünüzle görürsünüz. İşin aslı şu ki güvenlik biraz da böyle öğreniliyor. Tahmin eder misiniz? Başka türlü değil.

Proje üç ana kola ayrılıyor: web güvenliği, cloud security ve AI security. Şu an web kısmı önde gidiyor gibi duruyor ama AWS üzerinde secure deployment tarafını da ihmal etmiyorlar. Bence burası kıymetli —. Çoğu insan sızma testi ile dağıtımı ayrı şeyler sanıyor; halbuki kötü yapılandırılmış bir S3 bucket ya da gevşek bir IAM policy, bazen direkt veri sızıntısına dönüşüyor. Küçük fark, büyük sonuç.

Evet, doğru duydunuz.

Benzer yaklaşımı 2023 sonbaharında Ankara’daki küçük bir SaaS ekibinde de görmüştüm. Orada geliştiriciler harika kod yazıyordu ama auth katmanı “idare eder” seviyedeydi. Sonra bir rate limit eksikliği yüzünden deneme-yanılma saldırıları başladı. O gün şunu net anladılar: güvenlik sonradan eklenen etiket değil, ürünün omurgası.

Neden Eğitim Projesi Olarak İlgi Çekiyor?

Çünkü klasik kurs mantığından farklı davranıyor. Size sadece “şu açıktır” demiyor; “git bunu düzelt” diyor. Bayağı önemli fark var burada. Bir şeyi gerçekten öğrendiğiniz an, genelde kırdığınız andır zaten.

Araya gireyim: Bence FOSRES’in en iyi taraflarından biri de bu zihniyet değişimi yaratması — öğrenci rolünden çıkıp denetçi rolüne geçiyorsunuz, kod okuma refleksi gelişiyor, log bakma alışkanlığı oturuyor ve en önemlisi sistem tasarımındaki zayıflıkları erken fark etmeye başlıyorsunuz. Bunların hepsi birden gelmiyor tabii, ama süreç içinde birikerek geliyor. Bu da fena değil.

“Güvenlik öğrenmenin en hızlı yolu bazen okumak değil; bozuk sistemi bulup neden bozuk olduğunu anlamaktır.”

Hangi Konuların Üzerine Gidiliyor?

FOSRES’in web güvenliği listesine baktığımda klasik ama hala can yakan başlıkların özellikle seçildiğini görüyorum: broken authentication/authorization, SQL injection, XSS, SSRF, IDOR… Liste uzayıp gidiyor. Dürüst olayım — buna hiç şaşırmadım. Çünkü sektörde yıllardır en çok para kaybettiren açıkların büyük bölümü hala bunlar. Değişmiyor. Tahmin eder misiniz? Sadece görünürlüğü azalıyor. Bu konuyla ilgili Apple ile Samsung Arasındaki Veri Savaşı: Antitröst Dosyasında Yeni Perde yazımıza da göz atmanızı tavsiye ederim.

Kategori	Sorun Tipi	Neden Önemli?
Web Security	XSS / SQL Injection / IDOR	Kullanıcı verisi ve yetki sınırları kolayca delinilebilir
Cloud Security	IAM yanlışları / misconfiguration	Küçük hata büyük veri sızıntısına dönebilir
AI Security	(Şimdilik belirlenmemiş)	Pozitif sinyal var ama alan henüz pişme aşamasında
Süreç Güvenliği	Loglama / rate limiting / API key yönetimi	Saldırı tespiti için temel katman burasıdır

Küçük bir startup için bu liste nasıl görünür? Genelde tek ekip her şeye yetişmeye çalışır — dolayısıyla auth bug’larıyla cloud misconfig’ler birbirine karışır gider (ciddiyim). Kurumsal tarafta ise sorun başka yere kayar; kontrol sayısı artar ama insan faktörü bitmez.

Büyük kurumlarda durum daha mı iyi? Kağıt üstünde evet gibi durur. Pratikte göreceğiz. Politikalar ağırlaşınca hızlı düzeltme zorlaşabiliyor. Bir de şu var: listede XXE ya da command injection gibi eski dostlarımızın hala yer alması bence bilinçli tercih. Maalesef bunlar modası geçen sorunlar değil; sadece manşetten düşüyorlar. JavaScript’te Async Mantığı: Event Loop’u Gerçekten Anlamak yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Agentforce Script: Salesforce’un AI Ajanlarına Getirdiği Fren Pedalı yazımıza da göz atmanızı tavsiye ederim.

Eğitim Mantığı Nerede Güçlü Kalıyor?

Açık söyleyeyim — Claude Code’un burada resmi ajan olarak seçilmesini ilginç buldum, ama saçma da bulmadım tam olarak. Çünkü yapay zekayla hız kazanırken kaliteyi korumak zorundasınız; yoksa kısa sürede teknik borca gömülüyorsunuz, hem de farkında bile olmadan. Ben geçen mart ayında Berlin’de yaptığım kısa danışmanlıkta tam bunu yaşadım: ekip birkaç saat içinde çalışan prototip çıkardı, ama kimse edge case test etmemişti. Sonra login akışı ilk gerçek kullanıcı dalgasında sendeledi. Hız mı? Evet. Güvenlik mi? Hayır.

FOSRES’in akıllıca tarafı şu olabilir: AI’ı işleri hızlandırmak için kullanırken insanı denetçi konumunda tutuyor olması. Neyse uzatmayalım — güvenlikte otomasyon güzel şeydir, ama son sözü otomasyon söylememeli.

Ajan Seçimi Neden Önemli?

Tanveer’in Mistral’i daha mahremiyet odaklı görmesi veya GLM-5’i performans açısından tartması boş laf değil — önceki deneyimlerin izini taşıyor, yöntemsel olarak. Burada asıl mesele hangi modelin “en zeki” olduğu değil; hangi modelle ne kadar risk alındığıdır. Kurumsal müşteri verisiyle çalışan biriyseniz mahremiyet çizgisi çok önem kazanıyor. Açık kaynak araştırma projesinde ise üretkenlik ile gizlilik arasında dengeli yürümek gerekiyor. İkisi aynı şey değil.

Dikkat Çeken Eksikler de Var mı?

Evet var. Hem de iyi ki var diyebilirim belki — çünkü proje henüz başlangıç aşamasında olduğu için bazı alanlar bilerek belirsiz bırakılmış durumda. AI Security için “To Be Determined” ifadesi mesela beni düşündürdü. Oraya dokunmadan kapsam genişletmek istemeleri mantıklı geliyor, ama kullanıcı beklentisini biraz havada bırakabiliyor.

Neresi Hayal Kırıklığı Yaratabilir?

• AWS dışındaki bulut sağlayıcıları şimdilik yok gibi duruyor;
• Bazı konular listelenmiş ama laboratuvar senaryolarının detayları henüz netleşmemiş; — ciddi fark yaratıyor
• GDPR uyumu hedeflenmiş olsa bile bunun teknik karşılığını görmek lazım;
• Ana eğitim akışı olgunlaşmadan fazla konu eklenirse karmaşa çıkabilir.

Yani, Kağıt üstünde süper duran projeler bazen uygulamada yavaş kalabiliyor (ki bu çoğu kişinin gözünden kaçıyor). Hele bir de security lab işlerinde her şey küçük farklarla şekilleniyor: yanlış bucket policy, eksik CSRF koruması, zayıf session yönetimi… Birkaç satırlık hata bütün emeği bozabiliyor. Ben kendi not defterime şunu yazmışım: “iyi proje = kontrollü kapsam + tekrar edilebilir lab + temiz geri bildirim.” Bu formül kulağa sıkıcı geliyor olabilir,. Işe yarıyor. Hatta bayağı iyi çalışıyor. Cybersecurity Bitmiyor, Şekil Değiştiriyor: Asıl Hikâye yazımızda da bu konuya değinmiştik. MCP Patladı: 97 Milyon İndirimin Arkasındaki Hikâye yazımızda da bu konuya değinmiştik.

Böyle Bir Proje Kim İçin Gerçekten Faydalı?

Eğer junior seviyedeyseniz FOSRES sizi rahat ettirmez. Zaten amaç da o değil galiba. Burada rahat etmek yerine zorlanırsınız ve işinizi sorgulamaya başlarsınız. Bu kötü mü? Değil. Hatta gerekli.

Mid-level geliştiriciyseniz, özellikle backend veya DevOps tarafındaysanız, proje size ciddi katkı verebilir (şaşırtıcı ama gerçek). Çünkü siz artık yalnızca feature çıkaran kişi değilsiniz; production sorumluluğunu taşımaya başlamışsınızdır. One-time token ile session cookie arasındaki farktan tutun, IAM policy’nin niye tehlikeli olduğuna kadar birçok şeyi yeniden düşünürsünüz (kendi tecrübem). Bazen bildiklerinizi yeniden düşünmek, yeni şey öğrenmekten daha değerli oluyor.

Enterprise takımındaysanız benim önerim şu olur: FOSRES’i birebir eğitim olarak değil, iç hack-lab formatında değerlendirin. Mesela haftanın belirli günlerinde ekip üyelerine kasıtlı açık verilmiş mini servisler koyun. İnsanlar sadece çözüm üretmesin, raporlasın da; hatta root cause analizi yazsın. Böylece bilgi kalmaz, refleks olur.

Koddan Örnek Bir Zihin Egzersizi

// Basit görünen login akışlarında kontrol edilmesi gerekenler
if (!rateLimitOk(userIp)) {
throw new Error("Too many requests");
}
if (!csrfTokenValid(request)) {
throw new Error("CSRF failed");
}
if (!passwordPolicyMet(password)) {
throw new Error("Weak password");
}
// Asıl soru şu:
// Bu kontroller nerede uygulanıyor?
// Controller'da mı?
// Middleware'de mi?
// Yoksa sadece frontend'de mi?
// Cevap yanlış yerdeyse sistem kırılır.
}

Sektöre Düşen Mesaj Ne?

Güvenlik eğitimi tek seferde tamamlanan paket işi değil — sürekli tekrar istiyor. Project-based yaklaşım burada daha doğal duruyor (şaşırtıcı ama gerçek). Tanveer’in fikri, bana sevimsiz gelen o sonsuz sunum-slayt döngüsünü kırmaya çalışıyormuş gibi geldi. Hazır içerikten ziyade audit challenge mantığı kurmuş olması fena değil, hatta bayağı işe yarar.

Geçenlerde Kadıköy’de kahve içerken tanıştığım bir cloud engineer bana şunu söyledi: “En çok öğrendiğim gün, prod ortamda yanlış IAM role yüzünden erişimin patladığı gündü.” Doğru. İşte böylesi anlar öğretir, not almak yetmez. Hani ne farkı var diyorsunuz, değil mi? Aynısını FOSRES tarzı platformlar planlıyorsa, sektör adına iyi haber derim.

Bir dakika, şunu da ekleyeyim: AI araçlarını kullanmak artık opsiyonel lüks olmaktan çıktı. Ama körlemesine kullanırsanız hız kazandığınızı sanıp temizlikten kaybedersiniz. En azından benim son iki testimde sonuç böyleydi — biri martta İzmir’de yapılan bağımsız demo ortamında, diğeri haziran başında uzaktan erişilen staging sunucusunda. İkisi de aynı dersi verdi: hızlı kod, yavaş düşünme ile birleşince problem oluyor.

Sıkça Sorulan Sorular

Neyse…

.Fosres nedir ?

А