Devraldığınız Bir Laravel Kod Tabanını Nasıl Denetlersiniz

Birçok işletme, bir Laravel kod tabanını kasten devralmaz. Bir geliştirici ayrılır, bir ajans ilişkisi sona erer, bir şirket satın alınır ya da bir freelancer sessiz kalır. Her nasıl olursa olsun, sonuç aynıdır: şimdi, belki de bir daha konuşmayacağınız birisi tarafından yapılmış çalışma uygulamanız var ve içinde neler olduğunu net bir şekilde göremiyorsunuz.

Bu durum alışılmadık değildir. Dijital ajanslar, proje bazlı işlerde yıllık %42 ortalama müşteri kaybı yaşarken, sürekli ilişkilerde %18 kayıp yaşamaktadır. Proje bazlı ilişkilerin ortalama müşteri ömrü sadece 24 aydır. Ayrıca, Birleşik Krallık’taki işletmelerin %81’i, BT ve teknoloji becerileri eksikliğinden olumsuz etkilendiğini bildirmektedir. Devralınan kod tabanı senaryosu kenar durumu değil — geliştirici sürekliliği, ajans ilişkileri ve proje devamlılığı nadiren örtüşen bir pazarda varsayılan bir sonuçtur.

Karşılaştığınız soru denetim yapıp yapmamaktır. Doğru bir şekilde denetim yapmanın yolu nedir — gerçek riskleri kosmetik gürültüden ayırt etmek ve araçların aslında ne söylediğini anlamak.

Bu makale, her iki tarafı da kapsamaktadır. Eğer teknik bir lider iseniz, denetim araç takımını, her aracın bulduğu ve kaçırdığı şeyleri, ve “iyi”nin somut ölçütlerde ne anlama geldiğini açıklayacaktır. Eğer PHP okumayan bir yönetici ya da kurucu iseniz, kendinizin gerçekleştirebileceği teknik olmayan bir kontrol listesi alacak ve profesyonel bir inceleme talep etmeden önce profesyonel sonuçların ne anlama geldiğini yorumlamak için bir çerçeve elde edeceksiniz.

Kodu Açmadan Kontrol Edebileceğiniz Şeylerle Başlayın

Teknik bir işletme sahibi iseniz, bir geliştiricinin size bir sorun olup olmadığını söylemesini beklemeniz gerekmiyor. Hemen şimdi doğrulayabileceğiniz, hiçbir maliyeti olmayan ve bir saatten az sürede yapılabilecek şeyler var.

Alan Adına Sahip misiniz?

Birleşik Krallık alan adları (.co.uk ve .uk) Nominet tarafından yönetilmektedir, sahipliğinizi birkaç dakika içinde WHOIS sorgulaması ile doğrulayabilirsiniz. Risk gerçektir: alan adları, ajanslar veya geliştiriciler tarafından sıklıkla kendi bilgileriyle kaydedilmektedir, bu da bir anlaşmazlık durumunda Nominet’in çözüm sürecinin yaklaşık on hafta sürmesi ve £200–£750+KDV masraf gerektirmesi demektir. 2001’den bu yana, bu süreç aracılığıyla 16.000’den fazla alan adı anlaşmazlığı çözülmüş ve bunların büyük çoğunluğu şikayetçiye transfer edilmiştir. Ancak önleme, anlaşmazlık çözümünden çok daha ucuzdur.

Git Deposu Erişiminiz Var mı?

Kod tabanı bir versiyon kontrol sisteminde — GitHub, GitLab veya Bitbucket — yer almalıdır ve hesap sizin şirketinize ait olmalıdır, ayrılan bir bireye değil. Eğer depoya erişiminiz yoksa, değişiklik geçmişini göremez, yeni bir geliştiriciye erişim veremez ve kod üzerinde gerçek bir kontrole sahip olamazsınız.

Sunucu ve Hosting Kimlik Bilgilerine Sahip misiniz?

Hosting paneline giriş yapabiliyor musunuz? SSL sertifikasını kimin kontrol ettiğini biliyor musunuz? Üçüncü taraf hizmet hesapları — Stripe, Mailgun, AWS, uygulamanın kullandığı her neyse — şirket e-posta adresleriyle mi yoksa birinin kişisel hesabıyla mı kaydedilmiştir?

Son Dağıtım Ne Zaman Yapıldı?

Eğer kimse size uygulamanın en son ne zaman güncellendiğini söyleyemiyorsa, bu kendi başına bir veri noktasıdır. Altı aydır dağıtılmamış bir uygulama, tahmin edilebilir hızda yamanmamış güvenlik açıkları biriktirir.

Yedeklemeler Çalışıyor mu?

Sadece “yedeklemeler var mı” değil — en son doğrulanmış geri yükleme ne zaman yapıldı? Hiç test edilmemiş bir yedekleme bir hipotezdır, güvenlik ağı değil.

Herhangi Bir Belgelenme Var mı?

Bir README dosyası, dağıtım talimatları, mimari diyagramlar — herhangi bir şey. Yeni bir projeye katılan geliştiricilerin %78’i, bilinmeyen bir kod tabanında gezinmenin zor olduğunu veya çok zor olduğunu bildirmektedir. Belgelendirme sorunları genellikle mühendislik kapasitesinin %15–25’ini tüketmektedir. Eğer hiç belgelendirme yoksa, işe alacağınız ilk geliştirici, önceki geliştiricinin bildiklerini anlamak için ilk haftalarını (ve paranızı) harcayacaktır.

Bu kontrollerin hiçbiri teknik bilgi gerektirmemektedir. Hepsi, devraldığınız varlığın durumuna dair materyal bir şey anlatmaktadır. Eğer bu kontrol listelerindekilerden birkaçının cevabı “hayır” ya da “bilmiyorum” ise, profesyonel bir denetimin değerinin ne kadar olup olmadığını belirlemiş olursunuz.

Altı ayda bir dağıtım yapılmamış bir uygulama, tahmin edilebilir hızda yamanmamış güvenlik açıkları biriktirir. Hiç test edilmemiş bir yedekleme bir hipotezdir, güvenlik ağı değil.

Denetim Araç Takımı: Her Araç Aslında Ne Bulur ve Neyi Kaçırır

Kapsamlı bir Laravel denetimi birden fazla araç kullanır çünkü tek bir araç her şeyi kapsamaz. Her bir araç, kod sağlığının bir boyutunu inceler. Her bir aracın ne yaptığını — ve neyi kontrol etmediğini — anlamak, denetim bulgularını akıllıca okumak ile bir sayı yığını tarafından bunalmış olmak arasındaki farktır.

Statik Analiz: PHPStan ve Larastan

PHPStan, kodunuzu çalıştırmadan analiz eder, tür hatalarını, tanımsız yöntemleri, erişilemeyen kodları ve argüman uyumsuzluklarını arar. 0’dan 9’a kadar olan seviye skalasında çalışır ve her seviye, daha sıkı kontrol sağlar:

Düzey 0–2 temel hataları yakalar: bilinmeyen sınıflar, yanlış argüman sayıları, muhtemelen tanımsız değişkenler. Düzey 3 dönüş türü kontrolü ekler. Düzey 5, argüman türü doğrulaması ekler. Düzey 6 eksik tür ipuçlarını işaretler. Düzeyler 8 ve 9 ise, katı nullability ve karışık tür güvenliği sağlar.

Larastan, Laravel için özel olarak PHPStan’ı genişleterek, Laravel’in güçlü ama statik analizi zorlaştıran “büyü” unsurlarını çözer — Eloquent modelleri, Facades, servis konteyneri, sorgu oluşturucular ve koleksiyon yöntemleri düzgün tür çıkarımı alır.

Pratikte: hata sayıları genellikle aynı kod tabanında düzey 5 ile düzey 8 arasında iki katına çıkar. Varsayılan Larastan yapılandırması düzey 5’te başlar. Üretim kod tabanlarının % kaçının düzey 5 veya üzerinde geçtiğine dair yayımlanmış veri yoktur, ancak anekdot olarak, çoğu devralınan uygulama düzey 0 ile başlar ve yukarı çıkar. Ödeme işleme sisteminde düzey 8’de PHPStan’ı tanıtarak yakalanan hataların üretim olaylarına yol açacağı bildirilmiştir.

Kontrol etmediği şeyler: tasarım kokuları, kod stili, güvenlik açıkları veya çalışma zamanı davranışı. PHPStan, kodun teknik olarak doğru olup olmadığını söyler. Ne kadar iyi tasarlandığı konusunda bilgi vermez.

Kod Stili: Laravel Pint

Laravel Pint, 9.21 sürümünden itibaren her yeni Laravel uygulamasında varsayılan olarak uygulanmıştır ve PHP-CS-Fixer’a dayanan tutarlı biçimlendirmeyi zorlar. Sorunları otomatik olarak düzeltir — süslü yerleştirme, dizi sözdizimi, birleştirme aralığı, ad alanı ithalatları, tür beyanları — sadece bildirimde bulunmakla kalmaz.

Stil, estetiğin ötesinde önemlidir. 2,2 milyon satir kodu analiz eden bir araştırma, daha iyi okunabilirliğin daha az hatayla doğrudan ilişkili olduğunu ortaya koymuştur. Ayrı bir araştırma, 54 açık kaynak projesi ve 112.266 taahhüt üzerinde, kod analizi araçlarının mevcut olmasının olumlu bir kalite etkisi yarattığını bulmuştur. Mekanizma basittir: düzensiz biçimlendirme kodu daha zor okunabilir hale getirir, zor okuma, inceleme sırasında kaçırılan hata olasılığını artırır ve kaçırılan hatalar, üretim sorunlarına dönüşür.

Kontrol etmediği şeyler: hatalar, türler, güvenlik veya mantık hataları. Pint, kodun tutarlı bir şekilde biçimlendirilmesini sağlar. Çalıştığını söylemez.

Bağımlılık Taraması: Composer Audit ve NPM Audit

composer audit, Composer’ın 2.4 sürümünden beri, PHP bağımlılıklarını Packagist Güvenlik İlanları veritabanıyla karşılaştırarak denetler. Composer 2.7’den itibaren, terkedilmiş paketleri de işaretler — bakıcıları tarafından terk edilmiş projeleri.

PHP ekos sistemi bağlamında: Uygulama bağımlılıklarının %80’i 1 yıldan fazla güncellenmemektedir. Ancak %95 oranında bir zayıf bileşen kullanıldığında, düzeltme versiyonu zaten mevcuttur. “Bir yamanın mevcut olduğu” ile “yamayı uygulamak” arasındaki fark, gerçek dünyada çoğu riskin bulunduğu yer.

Ön yüz tarafında, npm audit, JavaScript bağımlılıklarını GitHub İlan Veritabanıyla kontrol eder. NPM ekosistemi daha keskin bir tehdit altındadır: 2025 yılında tanımlanan açık kaynak kötü amaçlı yazılımların %99’undan fazlası NPM üzerinde yer aldı ve bu yıl 454.600 yeni kötü amaçlı paket tespit edilmiştir. Toplamda, tüm ekosistemlerde 1.2 milyondan fazla bilinen kötü amaçlı paket bulunmaktadır.

Her iki aracın kontrol etmediği şeyler: kaynak kodu güvenlik açıkları, mantıksal hatalar, yapılandırma hataları veya sıfırıncı gün istismarları. Şu anda bilinen paketlerde bilinen sorunları yakalarlar. Özelleştirilmiş kodunuzu incelemezler.

Kapsamlı Tarama: SonarQube

SonarQube’un Community Sürümü, PHP 5.0’dan 8.4’e kadar, Laravel ve Symfony’nin dahil olduğu 270’ten fazla yerleşik statik analiz kuralını kapsar. Altı boyutta metrikler üretir: hatalar, güvenlik açıkları, kod kokuları, güvenlik sıcak noktaları, test kapsamı (harici raporlardan içe aktarılan) ve kod çoğaltması.

SonarQube’un varsayılan kalite kapısı, yeni kod için sıfır yeni hata, sıfır yeni güvenlik açığı, tüm güvenlik sıcak noktalarının gözden geçirilmesi, yeni kodda %80 veya üzeri kod kapsamı ve yeni kodda %3 veya daha az çoğaltma gerektirir. Araç doğru hata pozitifleri için %80’den fazla güvenlik açığı tespit etme yeteneğine sahiptir.

Kontrol etmediği şeyler: çalışma zamanı davranışı, altyapı yapılandırması veya Laravel’e özel kalıplar.

Laravel’e Özgü Denetim: Enlightn

Enlightn, Laravel uygulamalarını denetlemek için özel olarak oluşturulmuş tek araçtır. Açık kaynak versiyonu 66-67 otomatik kontrol gerçekleştirmekte; Pro versiyonu 131 kontrol gerçekleştirmektedir. Kontroller, performans, güvenlik ve güvenilirlik kategorilerini kapsamaktadır ve genel araçların göz ardı ettiği Laravel’e özgü endişeleri kapsar: rota ve ayar önbellekleme, N+1 sorguları, middleware kalabalığı, CSRF yapılandırması, çerez güvenliği gibi.

Kontrol etmediği şeyler: Laravel’e özgü kalıplar dışındaki genel PHP sorunları.

Tasarım Kalitesi: PHPMD

PHP Mess Detector, PHPStan’ın kasıtlı olarak göz ardı ettiği boyutları incelemektedir: döngüsel karmaşıklık, NPath karmaşıklığı, nesneler arasındaki bağlılık, aşırı uzun metod ve sınıf uzunlukları, isimlendirme kuralları, kullanılmayan kod ve miras derinliği. Varsayılan döngüsel karmaşıklık eşiği 10’dur — Thomas McCabe’ın 1976’daki önerisi ve Carnegie Mellon’daki Yazılım Mühendisliği Enstitüsü tarafından onaylanan eşik.

Kontrol etmediği şeyler: tür doğruluğu, güvenlik açıkları veya biçimlendirme.

Otomatik Yeniden Yapılandırma: Rector

Rector, PHP’yi soyut sözdizim ağaçlarına çözer, dönüşüm kurallarını uygular ve değiştirilmiş kodu yeniden oluşturur. Toplamda 824 kural ve 100’den fazla Laravel’e özel dönüşüm sağlayan rector-laravel paketi ile, sürüm güncellemelerini otomatikleştirebilir, geçersiz kılınan kalıpları modernize edebilir ve tutarlılığı zorlayabilirsiniz. Birleşik Krallık’taki resmi bir Laravel ortağı, orta büyüklükte bir uygulama için 20–40 saatlik manuel yükseltme işinin, Rector tarafından dakikalar içinde kısmen otomatik hale getirilebileceğini bildirmektedir.

Kritik uyarı: Rector kodu dönüştürür — anlamsal doğruluğu doğrulamaz. Bir test paketi olmadan, otomatik yeniden yapılandırma gizlice hatalar ekleyebilir. Bu güçlü bir araçtır, bir güvenlik ağı değildir.

Yukarıdaki Listeden Neler Eksik

Kapsamlı bir denetim ayrıca Psalm (Vimeo’nun statik analiz aracı, SQL enjeksiyonu ve XSS tespiti için PHPStan’ın doğal olarak eksik olan kirletme analizini ekler), PHPCPD (tekrarlanan kod bloklarını tanımlamak için kopyala-yapıştır tespiti), Deptrac (mimari sınırları zorlamak için bağımlılık kurallarının ihlal edilmediğinden emin olmak) ve OWASP ZAP için dinamik uygulama güvenlik testleri yapar — çalışma zamanındaki güvenlik açıklarını bulur ki bu, statik araçların göremediği şeylerdir.

“İyi”nin Ne Göründüğüne Dair: Sağlıklı Bir Kod Tabanı için Ölçütler

Denetim araçları sayılar üretir. Ölçüt olmadan bu sayılar anlamsızdır. İşte yayımlanan verilere göre sınırların nerede olduğu:

Test Kapsamı

Martin Fowler’ın sıkça alıntılanan kılavuzuna göre: %80 ila %90 aralığı hedeflenmeli ve %100 iddiasında olan bir şeye şüpheyle yaklaşılmalıdır. Google’ın iç araştırmaları, %60’ın kabul edilebilir, %75’in takdire şayan, %90’ın ise mükemmel olduğunu daha ayrıntılı bir şekilde göstermektedir. SonarQube’un varsayılan kalite kapısı, yeni kodda %80 kapsam gerektirir. Laravel çerçevesinin kendisi yaklaşık %76 satır kapsamına sahiptir, yoğun kullanılan temel sınıflar (Sorgu Oluşturucu, Yönlendirici) %90’ın üzerindedir.

JetBrains Geliştirici Ekosistemi anketi, PHP geliştiricilerinin %31’inin hiç test yazmadığını bulmuştur. Tek geliştirici veya küçük ajans tarafından oluşturulmuş özel iş uygulamaları için, sıfır test kapsamı bulmak yaygındır. %40–60 arası bir kapsama sahip olmak saygındır. %80+ bulmak gerçekten iyidir.

Google’ın test blogu bunu net bir şekilde ifade eder: Kapsamı artırmanın belirli bir noktadan sonra getirileri logaritmik olup, %30’dan %70’e taşımak gerçek değer kazanımının olduğu yerdir. Eğer devraldığınız bir kod tabanı %0 ise, hedef %90 değil; öncelikle kritik yolları, kimlik doğrulama, ödemeler, veri mutasyonları gibi kaplamaktır.

Kod Çoğaltma

SonarQube’un varsayılan eşiği: yeni kod üzerinde %3 veya daha az çoğaltılmış satır. Endüstri kılavuzları, geçmiş kod tabanları için daha hoşgörülü: %5’in altında optimum, %5-10 kabul edilebilir, %10’un üzerinde dikkat etmek gerektirir.

Döngüsel Karmaşıklık

McCabe’ın 1976’daki önerisi — metod seviyesi için üst sınır 10 — hala endüstri standardıdır. Carnegie Mellon’daki Yazılım Mühendisliği Enstitüsü, 1–10’u basit ve düşük risk, 11–20’yi orta, 21–50’yi karmaşık ve yüksek risk, 50’nin üzerindekileri ise etkili bir şekilde test edilemez olarak sınıflandırmaktadır.

Pratikte, devralınan bir Laravel kod tabanı 10’un üzerindeki yöntemleri içerecektir. Soru, hangi noktada olduğudur. Ödeme işlemlerini yöneten bir denetleyici eylemindeki yüksek karmaşıklık bir kırmızı bayraktır. Bir kerelik veri göçü betiğindeki yüksek karmaşıklık değil.

Bağımlılık Tazeliği

Uygulama bağımlılıklarının %80’i 1 yıldan fazla güncellenmemektedir. Her zaman bağımlılıkların %100’ünün güncel olmasını beklemek gerçekçi değildir. İyi yönetilen bir uygulama, kritik bağımlılıklar için yalnızca bir küçük sürüm geride kalmayı hedeflemeli ve düzenli (aylık veya üç aylık) kontrol ve güncellemeler yapmalıdır.

Kırmızı Bayraklar, Amber Bayraklar ve Kosmetik Gürültü

Otomatik bir araç tarafından işaretlenen her şey eşit öneme sahip değildir. Denetim sonuçlarını okumadaki en önemli beceri, bulguların aciliyet derecelerini ayırt etmektir — hemen harekete geçilmesi gereken bulgular ile bekleyebilecekleri, bunları oluşturan ve zarar vermeyen gürültüden ayırmak.

Kırmızı Bayraklar: Hemen Harekete Geçmeniz Gerekenler

Bunlar her şeyden önce hareket etmeyi gerektirir. Güvenlik açığı, veri kaybı riski veya üretim istikrarsızlığı temsil ederler.

Bir .env dosyası, bir tarayıcıdan erişilebilir — veritabanı kimlik bilgileri, API anahtarları ve uygulamanın şifreleme anahtarı içermektedir. Üretimde APP_DEBUG değerinin true olarak ayarlanması — bir hata tetiklendiğinde tam yığın izlerini, ortam değişkenlerini ve veritabanı sorgularını herhangi bir kullanıcıya açar. Sadece düz metin biçiminde girilen kimlik bilgileri, Git deposuna gömülmüştür. Kullanıcı girdisinin ham dize birleştirilmesiyle oluşturulmuş SQL sorguları. Kimlik doğrulama aracısı bulunmayan admin yolları. Yedekleme yok ya da doğrulama yapılmamış geri yükleme yeteneği. Eloquent modelleri, $fillable veya $guarded özelliklerine sahip değil — her veritabanı sütununu kütlesel atamaya açar. Formlarda CSRF koruması eksik. Veritabanı bütünlüğü ve referans bütünlüğü varsayan uygulama mantığı için veri tabanı kısıtlamaları eksik.

Bir denetim ki gerçek bir devralınan Laravel kod tabanını belgeliyor, CSRF saldırılarına duyarlı formlar, PSR standardizasyonu eksiklikleri, eksik ad alanları, binlerce satır uzunluğundaki sınıflar, eksik polymorfizm gösteren 30’dan fazla switch ifadesi ve bağımlılık enjekte etmenin olmaması gibi sorunları içermiştir.

Amber Bayraklar: Teknik Borç, Acil Tehlike Değil

Güncel ama hala desteklenen bağımlılıklar. Düşük test kapsamı ( %20’nin altında). Tutarsız kod stili ve isimlendirme kuralları. CI/CD hattı yok — manuel dağıtımlar. Yapılandırılmamış loglama. N+1 sorgu sorunları. Aşırı büyük sınıflar ve yöntemler. TODO notları, karşılık gelen backlog maddeleri olmaksızın.

Bunlar yarın bir üretim olayına neden olmazlar. Ancak, bir sonraki geliştiricinin yavaş hareket etmesine, hatalar yapmasına ve size daha fazla maliyete neden olacaklardır.

Kosmetik Bulgular: Öncelikle Bunları Gözardı Edin

Laravel yapılandırma dosyalarında yorumlanmış kod — bu, çerçeve ile birlikte varsayılan olarak gelir. Genel olmayan kodda PSR biçimlendirme ihlalleri. Zaten tam tür ipuçlarına sahip olan yöntemlerde eksik doküman blokları. Hizmet sağlayıcıları veya yapılandırma sınıfları üzerinde küçük karmaşıklık uyarıları.

Bunun önemi, uyarı yorgunluğunun gerçek ve belgelenmiş olduğudur. Bir güvenlik ekibinin %70’i yanlış pozitif uyarılar araştırmakta harcanmaktadır. Şirketlerin %33’ü, tam olarak siber saldırılara yanıt vermekte geç kalmışlardır çünkü ekipler yanlış pozitifler ile meşguldü. Her yanlış pozitif, ortalama 32 dakika araştırma süresi gerektirir. Gürültünün sinyali boğmasına izin verirseniz, denetim bütçenizi kozmetik düzeltmelere harcayacakken .env dosyası kamuya açık kalır.

Yetenekli Bir Profesyonel Denetim Gerçekte Neleri Kapsar

Eğer teknik olmayan kontrol listesi ve otomatik araçlar ilk iki katmanı oluşturuyorsa, profesyonel bir uzman inceleme, üçüncü ve en değerli katmandır. Deneyimli bir Laravel denetim uzmanı yukarıda listelenen araçları çalıştırmakla kalmaz, sonuçları bağlam içinde yorumlar, araçların göremediği boyutları inceler ve sizlere ne yapmanız gerektiğini, hangi sırayla yapmanız gerektiğini ve nedenini belirtir.

Yayımlanan en kapsamlı Laravel denetim metodolojisi, ABD merkezli bir Resmi Laravel Ortağından (Ravenna Interactive) gelmektedir ve yedi temel kategoriyi kapsamaktadır: mimari ve sınırlamalar (iş kurallarının nerede yaşadığı, kopyalanan mantık, sıkı bağlılık, “Tanrısal nesneler”); güvenlik (yetkilendirme doğruluğu, çoklu kiracı izolasyonu, hassas veri yönetimi); veri bütünlüğü ve eşzamanlılık (eksik veritabanı kısıtlamaları, riskli okuma-sonra-yazma sekansları, idempotent olmayan ödeme işleyicileri); performans ve ölçeklenebilirlik (N+1 sorguları, dizinleme stratejisi, HTTP isteklerindeki senkron işler, kuyruk tasarımı); test stratejisi ve değişiklik güvenliği (kapsama riski taşıyan yollar — faturalandırma, izinler, durum geçişleri); bağımlılık ve tedarik zinciri riski (güncel olmayan paketler, bilinen CVE’ler, sabitleme stratejisi, sürüm yaşam döngüsü); dağıtım, çalışma zamanı ve gözlemlenebilirlik (çevresel karşıtlık, geri dönüş planları, göç güvenliği, loglama kalitesi, kuyruk izleme).

OWASP Top 10, Laravel’e özel olarak anlamak için özellikle önemlidir. Laravel’in varsayılan ayarları, enjeksiyon (Eloquent PDO parametre bağlama kullanır), XSS (Blade’in {{ }} varsayılan olarak otomatik olarak kaçar), CSRF (varsayılan olarak etkinleştirilen middleware) ve kriptografik hatalar (yerleşik bcrypt/Argon2 hashleme) açısından güçlüdür. Ancak, Laravel, kötü erişim kontrolü (Kapılar ve Politikalar vardır ama uygulanmadıkça zorlanmaz), güvenlik kötü yapılandırmaları (APP_DEBUG=true varsayılan olarak gelir), tedarik zinciri hataları (içinde yüklü bağımlılık zafiyeti taraması yoktur), güvensiz tasarımlar (hiçbir çerçeve tehdit modelinin eksikliğini düzeltmez) ve loglama ve alarm (Monolog içerir ama asgari yapılandırmayı gerektirir) için geliştirici eylemi gerektirir. En üstteki üç OWASP kategorisi, bir uzman Laravel güvenlik denetçisi olan Stephen Rees-Carter’a göre, “Laravel uygulamalarını denetlerken sıkça bulduğum yaygın zayıflıklar”dır.

Sayılarla karşılaştırıldığında, yüzlerce güvenlik incelemesi yapmış bir uzman, süreçlerini şu şekilde tanımlıyor: öncelikle güvenlik açıklarını kontrol et, ardından yapılan kod incelemesi bulgularını kullanarak bilgiye dayalı bir penetrasyon testi yap, ardından yaygın alan kontrolleri ile devam et, sürekli bir diyalog oluşturarak.

Ne Kadar Sürede Tamamlanır ve Maliyeti Nedir?

Tipik bir Laravel uygulaması için — 50 ila 200 model, 10.000 ila 50.000 satır kod — farklı ajans kaynaklarından yayımlanan konsensüs, kapsamlı bir denetim için iki ila üç hafta olarak belirlenmiştir. Bu süreç, yaklaşık olarak şu şekilde dağılmıştır: onboarding ve oryantasyon (1-2. gün), otomatik taramalar ve başlangıçta manuel inceleme (3-7. gün), mimaride, güvenlikte ve performansta derin dalışlar (8-12. gün), rapor yazma ile öncelikli öneriler (13-15. gün).

Otomatik tarama tek başına — PHPStan, Enlightn, SonarQube, composer audit, npm audit ve PHPMD’yi çalıştırmak — saatler, günler değil, saatler alır. Kalan zamanı sürecin uzman yorumu alır: yanlış pozitiflerin triage edilmesi, iş etkisinin değerlendirilmesi, bağlamdaki mimari kararların değerlendirilmesi ve teknik olmayan bir paydaşın harekete geçebilmesi için bir rapor oluşturulması.

Küresel olarak, yalnızca üç firma Laravel denetim hizmetleri için kesin fiyatlar yayımlar. ABD merkezli bir uzman, video yürüyüşler için $2,500 ve yazılı raporlar için $3,500 ücret talep etmekte, 3-5 iş günü içinde sonuç vermektedir. Birkaç faktör, bir flat $2,500 ücretle uygulama boyutuna bakmaksızın yapılacak detaylı denetim fiyatıdır. Vibe-Code denetim firması, ücretsiz ilk değerlendirmeler sunmakta ve tam dönüşümleri $10,000-$20,000’dır. Birleşik Krallık’ta hiçbir ajans, Laravel kod denetimi için sabit fiyat yayımlamamaktadır. İncelenen her Birleşik Krallık firması — Birmingham, Southampton ve Edinburgh’daki Resmi ve Platin Laravel Ortakları dahil — fiyat vermeden önce bir danışma gerektirir.

Belgelendirme Açığı: Var Olması Gereken Ancak Genellikle Olmayan

Taylor Otwell, Laravel’ın yaratıcısı, 2025 yılında Maintainable.fm podcast’inde belgelendirme sorununu tam olarak çerçevelendiriyor: “En iyi yaşlanan Laravel uygulamaları, çok zeki olmayanlardır — çünkü zeki geliştirici her zaman gider.” “Zeka”yı bir kod kokusu olarak nitelendirip, “karmaşıklık katedralleri”nden bahsetmiştir.

Laravel’in konvansiyon-üstü-yapı tasarımı burada yardımcı olmalıdır. Geliştiriciler çerçevenin normlarına uyduğunda — varsayılan klasör yapısı, Eloquent kalıpları, standart yönlendirme — bir devralınan kod tabanı, sonraki geliştirici için önemli ölçüde daha kolay anlaşılabilir hale gelir çünkü diğerleri nelerin nerede olması gerektiğini bilir. State of Laravel anketini yöneten Christoph Rumpel, Mart 2026’daki konuşmasında bunu doğrudan ifade etmektedir: “Laravel’in ihtiyaca göre tasarımı – bazı insanların eleştirdiği şey – aslında en büyük gücü.” Laravel Shift’in yaratıcısı Jason McCreary, 20,000’den fazla Laravel uygulamasını güncelledi ve sürekli olarak “Varsayılan klasör yapısını koruyun.” demektedir. Öze uygun yapı oluşturan geliştiricilerin “sonunda pişman olduklarını” bildirmektedir.

Ancak konvansiyon-üstü-yapı yalnızca kurallara uyulduğunda işe yarar. Uymadıklarında — özel klasör yapıları, ham SQL ile Eloquent’i atlamak, gereksiz soyutlama katmanları, çerçeve kalıplarından saparak “zekice” kalıplar oluşturmak — devralınan kod tabanı, bir çerçevesiz uygulamadan daha anlaşılmaz hale gelir çünkü sonraki geliştirici normları beklerken sapmalar bulur.

Her özel iş uygulaması için var olması gereken belgeler:

Kurulum talimatları ve mimari inceleme ile bir README. Dağıtım prosedürleri — “üretime dağıt” değil, gerçek komutlar, sırayla, çevresel değişkenlerin belgelendiği şekilde. En azından bağlam ve konteyner düzeylerini kapsayan mimari diyagramlar. İş mantığı kararlarının açıklaması — sadece “ne değil, neden.” Tüm kimlik bilgilerini, API anahtarlarını ve üçüncü taraf hizmet hesaplarını içeren bir kayıt. Bilinen teknik borç ve mimari riskler. Bilinen hatalar ve geçici çözüm önerileri.

Pratikte, çoğu devralınan kod tabanı bunların hiçbirine sahip değildir. Kuruluşların yalnızca %58’i etkin bir şekilde belge tutmaktadır ve geliştiricilerin %73’ü, mevcut kod ile çalışırken en büyük engelinin kötü veya eksik belgelendirme olduğunu bildirmektedir. Kuruluşların ne kadar belgelerinin yeterli olduğunu düşündüğü ile geliştiricilerin fikir birliği içinde değer vermesi arasında 15 yüzde puanlık bir fark, başlı başına bir bulgu olmaktadır.

Denetim Eylem Noktası Olarak

Bir denetim bakım değildir. Bu, neyi onarmanız gerektiğini, hangi sırayla, sürekli bakımın akıllıca olup olmadığını veya bunun yerine daha temel bir işin gerekip gerekmediğini belirten bir tek seferlik değerlendirmedir.

Yukarıda belirtilen aciliyet çerçevesi, sıralama mantığı sağlar. Kırmızı bayraklar önce onarılır. Amber, gri öncesinde. Denetiminiz, kod tabanının önemli bir çalışmayı — büyük bir sürüm yükseltmesi, mimari yeniden yapılandırma, güvenlik güçlendirmesi — gerektirdiğini gösteriyorsa, bu ayrı bir projedir; bakım ilişkisi değil. Temel sorunları müdahale bütçesinin içinde düzeltmeye çalışmak, bakım sözleşmelerinin başarısız olmasına yol açar.

Kritik sorunlar çözüldüğünde ve uygulama sürdürülebilir bir duruma getirildiğinde, ekonomi tamamen değişir. Aylık £450 tutarında bir bakım sözleşmesi, yıllık £5,400’dır. Bu, Birleşik Krallık’ta bir KOBİ için ortalama bir siber saldırının maliyetinin altında, bir acil durum düzeltme projesinin bir kesiri ve tam bir yeniden yapılandırmanın yaklaşık ellide biri kadar bir maliyet gerektiren bir durumdur.

Sonraki Adımlar

Buraya kadar okuduysanız, iki durumdasınız.

Teknik bir lider olarak, hangi araçları çalıştırmanız gerektiği, hangi ölçütleri ölçmeniz gerektiği ve bulguları aciliyet derecesine göre nasıl sınıflandıracağınız hakkında net bir fikre sahipsiniz. Araçlar ücretsizdir. Otomatik bir düzey için zaman yatırımı — PHPStan, Enlightn, composer audit, npm audit, PHPMD ve SonarQube taraması — tek bir öğleden sonradır. O öğleden sonradaki öğrenim, devraldığınız kod tabanının temelde sağlam olup olmadığını, belirli bir düzeltmeye ihtiyaç duyup duymadığını ya da daha ciddi müdahale gerektirip gerektirmediğini gösterecektir.

Ya da teknik olmayan bir işletme sahibiyseniz, bugün uygulayabileceğiniz bir kontrol listeniz, profesyonel bir denetimin kapsaması gerekenleri anlamak için bir çerçeve ve işi yaptıracağınız kişilere bilgi sahibi bir tartışma yapmanız için gerekli olan terminolojiye sahipsiniz. Kırmızı bir bayrağın neye benzediğini biliyorsunuz, kozmetik gürültünün ne olduğunu biliyorsunuz. Ne tür belgelerin var olması gerektiğini ve genellikle olmadığını biliyorsunuz.

Hangi durumda olursanız olun, denetim ilk adımdır. Denetim sonrası ne olacağı — hedefe yönelik düzeltmeler, kapsamlı bir proje veya yapılandırılmış sürekli destek — tamamen bulguların neyi ortaya çıkardığına bağlıdır.

Ben Anatoly Silko, Rocking Tech‘in kurucusuyum — üretim Laravel platformları inşa eden ve sürdüren Birleşik Krallık merkezli bir ajans. Eğer devraldığınız bir kod tabanını merak ediyorsanız, bu makalenin orijinal versiyonu sonraki adımlar hakkında daha fazla ayrıntıya sahiptir.