Hazır Çözüm mü, Özel Yazılım mı? Güvenlik Verisiyle Karar Çerçevesi

Kısa özet: Hazır bir CMS, SaaS ürünü veya eklenti tabanlı sistem daha hızlı ve düşük başlangıç maliyetiyle devreye alınabilir. Özel yazılım ise işletmeye özgü süreçlerde daha fazla kontrol sağlar. Fakat güvenlik açısından belirleyici olan çözümün hazır veya özel olması değil; bileşenlerin kim tarafından seçildiği, izlendiği, güncellendiği ve gerektiğinde değiştirilebildiğidir.

Kısa doğrudan cevap

Hazır çözüm; standart bir ihtiyacın hızlı, öngörülebilir ve düşük başlangıç maliyetiyle karşılanması gerektiğinde doğru tercihtir. Özel yazılım ise süreç işletmenin rekabet avantajını oluşturuyorsa, yoğun entegrasyon gerektiriyorsa veya hazır ürün işletmeyi kendi çalışma biçimine zorluyorsa anlamlı hale gelir. Güvenlik açısından hazır çözüm otomatik olarak güvensiz, özel yazılım da otomatik olarak güvenli değildir. Temmuz 2026'da CISA, aktif olarak istismar edildiği doğrulanan dört Joomla eklenti açığını KEV kataloğuna ekledi. Ancak bu örnek, bütün hazır sistemlerin güvensiz olduğunu değil; eklenti envanteri ve hızlı yama süreci bulunmayan sistemlerin ciddi bir operasyonel risk taşıdığını gösteriyor.

Temmuz 2026'da ne oldu?

CISA, 7 Temmuz 2026 tarihinde JoomShaper SP Page Builder ve Joomlack Page Builder CK açıklarını; 10 Temmuz 2026 tarihinde ise iCagenda ve Balbooa Forms açıklarını Known Exploited Vulnerabilities, yani KEV kataloğuna ekledi. KEV'e eklenme, açığın yalnızca teorik olarak mümkün olduğu değil, gerçek saldırılarda kullanıldığına ilişkin kanıt bulunduğu anlamına geliyor. Dört açık da Joomla çekirdeğinden değil, üçüncü taraf eklentilerden kaynaklanıyordu.

NVD kayıtları, Page Builder CK ve Balbooa Forms açıklarının oturum açmamış bir saldırganın çalıştırılabilir dosya yüklemesine izin verdiğini; iCagenda ve SP Page Builder açıklarının da PHP kodu yüklenmesi ve çalıştırılmasıyla sonuçlanabildiğini belirtiyor. Bu tablo iki nedenle önemli:

• Açıklar doğrudan temel CMS çekirdeğinde değil, sistemi genişleten bileşenlerde ortaya çıktı.
• Saldırı için işletmenin özel olarak hedeflenmesi gerekmiyordu; internete açık, savunmasız sürüm çalıştıran sistemler otomatik taramalara yakalanabiliyordu.

Buradan “hazır sistem kullanmayın” sonucu çıkmaz. Doğru sonuç şudur: Bir hazır sistemde kurduğunuz her eklenti, yalnızca yeni bir özellik değil; takip edilmesi gereken yeni bir yazılım tedarikçisi ve bakım taahhüdüdür.

CISA KEV nedir ve karar sürecinde neden önemlidir?

CISA Known Exploited Vulnerabilities kataloğu, gerçek saldırılarda kullanıldığı doğrulanan güvenlik açıklarını içerir. Bir açığın yüksek CVSS puanına sahip olması, tek başına aktif saldırı altında olduğunu göstermez. KEV'e eklenmesi ise saldırı önceliğinin teorik puandan operasyonel gerçeğe geçtiğini gösteren daha güçlü bir sinyaldir. CISA, KEV açıklarının güvenlik açığı yönetiminde öncelikli olarak ele alınmasını öneriyor. Bu nedenle hazır çözüm değerlendirilirken yalnızca şu soruya bakılmamalıdır: Ürün güvenli mi? Daha doğru sorular şunlardır:

• Ürünün ve eklentilerin güvenlik duyuruları kim tarafından izleniyor?
• Kullanılan her bileşenin sürümü biliniyor mu?
• Aktif istismar edilen bir açık duyurulduğunda kaç saat veya gün içinde aksiyon alınabiliyor?
• Güncelleme çıktıktan sonra sistemin gerçekten düzeldiği nasıl doğrulanıyor?
• Yama yoksa eklenti kaldırılabiliyor mu?
• Eklenti kaldırıldığında iş süreci devam edebiliyor mu?

Hazır çözüm ve özel yazılım arasındaki gerçek fark nedir?

Hazır çözüm ile özel yazılım arasındaki fark çoğu zaman “hazır kod” ve “sıfırdan yazılmış kod” şeklinde anlatılır. Bu ayrım eksiktir. Modern özel yazılımlar da framework, kütüphane, açık kaynak paket, bulut hizmeti, kimlik doğrulama servisi ve üçüncü taraf API kullanır. Yani özel yazılım da tamamen işletmeye ait koddan oluşmaz. Asıl fark, aşağıdaki dört alandadır:

Hazır çözümde riskin önemli bölümü, birbirinden bağımsız sağlayıcıların yazılımına ve güncelleme temposuna bağlıdır. Özel yazılımda ise risk daha doğrudan sizin geliştirme, test ve bakım kapasitenize bağlıdır. Bu nedenle doğru soru “hangisi daha güvenli?” değil: Hangi modelin bakım sorumluluğunu işletmeniz daha gerçekçi biçimde yönetebilir?

Hazır çözüm hangi durumlarda doğru karardır?

1. İhtiyaç standartsa

Kurumsal tanıtım sitesi, basit içerik yönetimi, standart e-ticaret, randevu takvimi, form toplama veya bilinen bir CRM süreci için piyasada olgun bir ürün bulunuyorsa sıfırdan yazılım geliştirmek gereksiz olabilir. Hazır çözümün burada sağladığı temel avantajlar:

• Daha kısa devreye alma süresi
• Daha düşük ilk yatırım
• Önceden test edilmiş temel işlevler
• Hazır yönetim paneli
• Yaygın dokümantasyon
• Geniş kullanıcı ve geliştirici topluluğu

2. Süre kritikse

Bir kampanya, ürün doğrulama veya MVP çalışması birkaç hafta içinde başlatılacaksa hazır çözüm doğru başlangıç olabilir. Ancak hızlı başlangıç kararı, sistemin kalıcı mimarisi olarak görülmemelidir. MVP aşamasında doğru olan bir araç, kullanıcı sayısı ve entegrasyon ihtiyacı arttığında kısıtlayıcı hale gelebilir.

3. İşletmenin ayırabileceği teknik kaynak sınırlıysa

Özel yazılım yalnızca geliştirme bütçesi değil, sürekli bakım kapasitesi gerektirir. İç teknik ekibi ve düzenli bakım bütçesi olmayan bir işletme için olgun ve desteklenen bir hazır ürün daha güvenli bir tercih olabilir.

4. Süreç rekabet avantajı taşımıyorsa

İletişim formu, standart blog, temel dosya yönetimi veya basit e-posta aboneliği işletmenin rekabet avantajı değildir. Bu alanlarda özel yazılım geliştirmek, bütçeyi asıl farklılaşma sağlayan süreçlerden uzaklaştırabilir.

Özel yazılım hangi durumlarda doğru karardır?

1. Süreç işletmenin rekabet avantajıysa

Bir lojistik şirketinin fiyatlama algoritması, rezervasyon işletmesinin kapasite yönetimi, üretim şirketinin teklif motoru veya SaaS ürününün temel iş akışı standart bir eklentiyle yürütülüyorsa işletme zamanla ürünün sınırlarına göre çalışmaya başlar. İş süreci şirketin farklılaşmasını sağlıyorsa, yazılımın da o sürece göre tasarlanması gerekir.

2. Yoğun entegrasyon gerekiyorsa

Aşağıdaki yapıların birlikte çalışması gerekiyorsa özel yazılım daha anlamlı hale gelebilir:

• ERP
• CRM
• Muhasebe
• Ödeme
• Rezervasyon
• Mobil uygulama
• Müşteri portalı
• Tedarikçi sistemi
• Operasyon paneli
• Raporlama altyapısı

Hazır sistemlerde her entegrasyon yeni bir eklenti, ara servis veya özel müdahale gerektirebilir. Belirli bir noktadan sonra hazır çözümün hızlı başlangıç avantajı, entegrasyon karmaşıklığı nedeniyle kaybolur.

3. Veri modeli işletmeye özgüyse

Hazır ürünler, geniş bir kullanıcı kitlesine hitap etmek için genel veri modelleri kullanır. İşletmenin verisi standart müşteri, sipariş, ürün ve randevu tablolarına sığmıyorsa sistem sürekli özel alanlar ve eklentilerle genişletilir. Bu durum üç probleme yol açabilir:

• Raporlama zorlaşır.
• Veri tutarlılığı bozulur.
• Üründen çıkış maliyeti yükselir.

4. Rol ve yetki yapısı karmaşıksa

Çok sayıda kullanıcı rolü, departman, müşteri organizasyonu, bayi, tedarikçi veya alt hesap içeren sistemlerde hazır rol modelleri yetersiz kalabilir.

5. Yüksek ölçek veya işlem hacmi varsa

Hazır ürünler yüksek trafik kaldırabilir; ancak performans sorunu çoğu zaman ürünün kendisinden değil, eklenti kombinasyonları ve özelleştirme katmanlarından çıkar. Ölçek büyüdükçe şu konularda daha fazla kontrol gerekebilir:

• Önbellek
• Kuyruk sistemi
• Veri tabanı sorguları
• Arka plan görevleri
• Dosya işleme
• API limitleri
• Çok kiracılı mimari
• Gözlemlenebilirlik

6. Ürünün uzun vadeli yol haritası kontrol edilmek isteniyorsa

Hazır bir ürün, kullandığınız özelliği kaldırabilir, fiyatlandırmayı değiştirebilir veya entegrasyon yöntemini sonlandırabilir. Özel yazılımda bütün bağımlılıklar ortadan kalkmaz; ancak işletme kritik iş mantığının yol haritası üzerinde daha fazla söz sahibi olur.

Güvenlik açısından hazır çözüm neden riskli hale gelebilir?

Hazır sistemlerde temel risk, kullanılan bileşenlerin sayısıyla bakım kapasitesinin birbirinden kopmasıdır. Örnek bir kurumsal CMS aşağıdaki bileşenleri içerebilir:

• CMS çekirdeği
• Tema veya template
• Sayfa oluşturucu
• Form eklentisi
• SEO eklentisi
• Güvenlik eklentisi
• Önbellek eklentisi
• Çok dilli yapı
• E-ticaret modülü
• Ödeme modülü
• Yedekleme eklentisi
• Analitik entegrasyonu
• Çerez yönetimi
• Görsel optimizasyonu

Bu sistem dışarıdan tek bir web sitesi gibi görünür; fakat bakım açısından birbirinden bağımsız çok sayıda yazılım ürününden oluşur. OWASP, istemci ve sunucu tarafındaki bileşenlerin ve bağımlılıklarının sürümleriyle birlikte sürekli envanterinin tutulmasını, CVE ve NVD gibi kaynakların izlenmesini ve mümkünse bu sürecin yazılım bileşen analizi araçlarıyla otomatikleştirilmesini öneriyor. Joomla'nın resmî Vulnerable Extensions List sayfası da yaması bulunmayan savunmasız eklentilerin kaldırılmasını; yama bulunan sürümlerin ise güncellenmesini öneriyor. Dolayısıyla eklenti sayısı yalnızca teknik bir ayrıntı değildir. Her eklenti:

• Ayrı bir güncelleme kanalı
• Ayrı bir güvenlik duyurusu
• Ayrı bir lisans
• Ayrı bir uyumluluk ihtimali
• Ayrı bir terk edilme riski
• Ayrı bir tedarikçi bağımlılığı

oluşturur.

Özel yazılım neden otomatik olarak güvenli değildir?

Özel yazılım, gereksiz özellikleri ve eklentileri azaltarak saldırı yüzeyini daraltabilir. Ancak bu avantaj yalnızca düzenli bakım ve güvenli geliştirme süreçleri varsa geçerlidir. Kötü yönetilen özel yazılım şu riskleri taşıyabilir:

• Güvenlik incelemesi yapılmadan üretime alınan kod
• Güncellenmeyen framework ve paketler
• Tek geliştiriciye bağımlılık
• Test kapsamının bulunmaması
• Dokümantasyon eksikliği
• Yetki modelinin yanlış kurulması
• Güvenlik loglarının tutulmaması
• Yedekleme ve geri alma planının bulunmaması
• Geliştirme ekibi ayrıldığında bakım yapılamaması

NIST Secure Software Development Framework, güvenli geliştirme uygulamalarının yazılım yaşam döngüsünün tamamına entegre edilmesini ve yazılım satın alan kuruluşların da tedarikçilerle güvenlik gereksinimlerini açık biçimde konuşmasını öneriyor. Çerçeve yalnızca özel geliştirilmiş ürünlere değil; yazılım geliştiren ve satın alan tüm kuruluşlara uygulanabilecek ortak bir dil sunuyor. Bu nedenle özel yazılım kararı verilirken yalnızca “kaynak kod bize ait olacak mı?” sorusu sorulmamalıdır. Şunlar da sorulmalıdır:

• Kod kim tarafından gözden geçirilecek?
• Bağımlılıklar nasıl izlenecek?
• Kritik güvenlik güncellemesi kaç günde uygulanacak?
• Test ortamı var mı?
• Geri alma prosedürü var mı?
• Geliştirme ekibi değişirse proje devredilebilir mi?
• Teknik dokümantasyon teslim edilecek mi?
• Yönetici hesaplarının ve sırların güvenliği nasıl sağlanacak?

En doğru yaklaşım çoğu zaman melez modeldir

Hazır çözüm ve özel yazılım birbirini dışlayan iki seçenek değildir. Bir sistem şu şekilde tasarlanabilir:

Bu yaklaşımda rekabet avantajı taşımayan altyapı bileşenleri hazır kullanılır; işletmeyi farklılaştıran iş mantığı ise özel geliştirilir. Melez modelin avantajı, her şeyi sıfırdan yazma maliyetinden kaçınırken kritik süreçlerde kontrolü korumasıdır.

Başlangıç maliyeti yerine toplam sahip olma maliyetine bakın

Hazır çözüm genellikle başlangıçta daha ucuzdur. Ancak karar yalnızca ilk kurulum teklifine göre verilirse uzun vadeli maliyet görünmez.

Hazır çözümün maliyet kalemleri

• Tema veya ürün lisansı
• Eklenti lisansları
• Hosting
• Kurulum
• Özelleştirme
• Entegrasyon
• Periyodik güncelleme
• Güncelleme sonrası regresyon testi
• Eklenti çakışmaları
• Güvenlik müdahalesi
• Performans optimizasyonu
• Ürün değişikliği veya veri taşıma

Özel yazılımın maliyet kalemleri

• Analiz ve ürün tasarımı
• Kullanıcı deneyimi
• Yazılım geliştirme
• Test
• Cloud altyapısı
• İzleme ve loglama
• Güvenlik kontrolleri
• Bakım
• Sürüm yükseltmeleri
• Dokümantasyon
• Ekip veya tedarikçi değişimi
• Ölçeklendirme

Üç yıllık değerlendirme modeli

Rakamları tahmin etmek yerine şu formülü kullanın: Toplam sahip olma maliyeti = İlk yatırım+ 36 aylık lisans ve altyapı

• bakım ve güncelleme
• entegrasyon geliştirme
• çalışanların manuel işlem süresi
• kesinti ve hata maliyeti
• sistemden çıkış veya veri taşıma maliyeti

Hazır bir sistem ilk ay daha ucuz olabilir; fakat çalışanlar her gün sistemin izin vermediği işlemleri Excel veya mesajlaşma uygulamalarında tamamlıyorsa, yazılımın görünmeyen maliyeti büyür. Özel yazılım ilk aşamada daha pahalı olabilir; ancak her özel süreç otomatikleştirildiğinde yatırımın operasyonel karşılığı oluşur.

Hazır çözüm ve özel yazılım karar matrisi

Her başlığı 1 ile 5 arasında puanlayın.

Sonuçların yorumlanması

• Çoğu başlık 1–2 ise: Hazır çözüm daha doğru olabilir.
• Çoğu başlık 4–5 ise: Özel yazılım değerlendirilmelidir.
• Sonuçlar karışıksa: Melez mimari daha gerçekçi olabilir.
• Teknik bakım kapasitesi 1 ise: Özel yazılım kararı yeniden değerlendirilmelidir.
• Süreç özgünlüğü 5, fakat bütçe ve bakım kapasitesi düşükse: Önce sınırlı bir MVP tasarlanmalıdır.

Karar vermeden önce sorulması gereken 15 soru

İş ihtiyacı

• Süreç gerçekten işletmeye özgü mü?
• Hazır ürün işin yüzde kaçını doğrudan karşılıyor?
• Karşılamadığı bölüm rekabet avantajı mı, yalnızca tercih mi?
• Kullanıcı sayısı ve işlem hacmi üç yılda ne kadar büyüyebilir?
• Sistem olmadan yürütülen manuel adımlar hangileri?

Teknik yapı

• Kaç farklı sisteme entegrasyon gerekiyor?
• Veriler dışarı aktarılabiliyor mu?
• Ürün API sunuyor mu?
• Yetki modeli ihtiyacı karşılıyor mu?
• Hazır sistemin eklenti sayısı kaç olacak?

Bakım ve güvenlik

• Bileşen envanterini kim tutacak?
• Güvenlik güncellemelerini kim izleyecek?
• Kritik yama süresi sözleşmede yazıyor mu?
• Yama bulunmazsa bileşen kaldırılabilir mi?
• Güncelleme sonrası test sorumluluğu kimde?

Hazır çözüm satın alırken kontrol listesi

• Ürünün aktif olarak desteklendiği doğrulandı mı?
• Son güvenlik güncellemesinin tarihi kontrol edildi mi?
• Kullanılacak bütün eklentiler listelendi mi?
• Eklentilerin geliştiricileri ve lisansları belli mi?
• Resmî güvenlik duyuru kanallarına abonelik sağlandı mı?
• Otomatik güncelleme ve manuel onay politikası belirlendi mi?
• Test veya staging ortamı var mı?
• Güncelleme sonrası regresyon testi tanımlı mı?
• Veri dışa aktarımı test edildi mi?
• API limitleri ve entegrasyon sınırları incelendi mi?
• Ürün bırakılırsa veri taşıma yöntemi belli mi?
• Bakım sorumluluğu sözleşmede açıkça yazıldı mı?

Özel yazılım yaptırırken kontrol listesi

• İş gereksinimleri ürün özelliklerinden ayrıldı mı?
• MVP kapsamı net mi?
• Kaynak kod sahipliği ve erişimi tanımlandı mı?
• Teknik dokümantasyon teslim kapsamına alındı mı?
• Kullanılan framework ve bağımlılık envanteri tutulacak mı?
• Test ortamı oluşturulacak mı?
• Otomatik test kapsamı tanımlandı mı?
• Loglama ve hata izleme kurulacak mı?
• Yedekleme ve geri alma prosedürü var mı?
• Güvenlik güncellemeleri için SLA tanımlı mı?
• Bakım bütçesi ilk yıldan ayrıldı mı?
• Tedarikçi değişiminde devir süreci tanımlandı mı?

Kimler hazır çözümü tercih etmeli?

• Hızlı biçimde yayına çıkması gereken küçük işletmeler
• Standart kurumsal web sitesi ihtiyacı olan şirketler
• Basit e-ticaret veya randevu sistemi arayanlar
• Teknik bakım için sınırlı bütçesi bulunan işletmeler
• Ürün doğrulama aşamasındaki girişimler
• Süreçleri piyasadaki standart ürünlerle büyük ölçüde uyumlu olanlar

Kimler özel yazılımı değerlendirmeli?

• Operasyonu standart ürünlere sığmayan şirketler
• Çok sayıda sistem entegrasyonu bulunan işletmeler
• SaaS veya dijital ürün geliştiren girişimler
• Özgün fiyatlama, teklif veya rezervasyon motoru kullananlar
• Bayi, tedarikçi ve müşteri rollerini tek sistemde yönetenler
• Yüksek işlem hacmi veya özel performans gereksinimi bulunanlar
• Veri modeli ve raporlama ihtiyacı işletmeye özgü olanlar
• Ürün yol haritası üzerinde tam kontrol isteyenler

Kimler özel yazılım için henüz hazır değildir?

• Düzenli bakım bütçesi ayıramayanlar
• Karar verici veya ürün sahibi belirlemeyenler
• Süreçlerini henüz tanımlayamayanlar
• Her talebi ilk sürüme eklemek isteyenler
• Yazılımı tek seferlik yatırım olarak görenler
• Tedarikçi değişiminde proje sahipliği üstlenemeyenler

InoviqLab değerlendirmesi

Bu bölüm InoviqLab'ın yorumudur; doğrulanmış güvenlik kayıtlarından ve resmî kaynaklardan ayrıdır. Sahada en sık karşılaşılan hata, hazır çözüm ile özel yazılım kararının teknoloji tercihi olarak verilmesi. Oysa bu karar öncelikle işletmenin bakım ve değişim kapasitesiyle ilgilidir. Bakım kapasitesi olmayan bir şirket için özel yazılım, ilk yıl etkileyici fakat üçüncü yıl güncellenemeyen bir sisteme dönüşebilir. Aynı şekilde eklenti envanterini yönetemeyen bir şirket için hazır CMS, başlangıçta hızlı fakat zamanla kontrol edilemeyen bir bileşen ağına dönüşebilir. İkinci hata, eklenti sayısını yalnızca özellik sayısı olarak görmek. Bir form eklentisi eklemek birkaç dakikalık iştir; fakat o eklentiyi üç yıl boyunca sürüm, lisans, uyumluluk ve güvenlik açısından takip etmek ayrı bir operasyonel sorumluluktur. Satın alma kararında ilk kurulum süresi değil, bakım ömrü değerlendirilmelidir. Üçüncü hata, “özel yazılımda eklenti yoktur” varsayımıdır. Modern özel yazılımlar da açık kaynak paketler ve bulut servisleri kullanır. Fark, bağımlılıkların görünür biçimde seçilmesi ve mimari kararların merkezi olarak yönetilebilmesidir. Envanter ve güvenlik güncellemesi yapılmıyorsa, özel yazılım da aynı bileşen risklerini taşır. InoviqLab açısından doğru yaklaşım çoğu zaman melezdir:

• İçerik yönetimi, e-posta ve ödeme gibi standart katmanlar olgun ürünlerle çözülür.
• İşletmenin rekabet avantajını oluşturan operasyon, entegrasyon ve raporlama katmanları özel geliştirilir.
• Bütün hazır ve özel bileşenler tek bir teknoloji envanterinde izlenir.
• Bakım, yama ve sürüm yükseltme sorumlulukları sözleşmede açıkça tanımlanır.

Bu model, hem gereksiz geliştirme maliyetini hem de kontrolsüz eklenti bağımlılığını azaltır.

Sonuç

Hazır çözüm ile özel yazılım arasında evrensel bir kazanan yoktur. Hazır çözüm, standart ihtiyaçlarda hızlı ve ekonomik bir başlangıç sağlar. Özel yazılım, işletmeye özgü süreçlerde kontrol ve esneklik sunar. Güvenlik açısından ise iki modelin başarısı aynı temele dayanır:

• Bileşen envanteri
• Düzenli güncelleme
• Güvenlik duyurularının takibi
• Test ortamı
• Yama sonrası doğrulama
• Açık bakım sorumluluğu
• Veri taşınabilirliği
• Sürdürülebilir teknik ekip

Temmuz 2026'da aktif istismar edilen Joomla eklenti açıkları, hazır sistemlerin kullanılmaması gerektiğini göstermiyor. Asıl gösterdiği şey, “kuruldu ve bitti” anlayışının artık geçerli olmadığıdır. Doğru soru şudur: İşletmemiz hangi sistemin bakım sorumluluğunu, maliyetini ve değişim hızını uzun vadede daha iyi yönetebilir? Bu sorunun cevabı hazır çözümse hazır çözüm; özel yazılımsa özel yazılım; çoğu işletme için ise kontrollü bir melez mimari tercih edilmelidir.