Yapay Zekâ ile Tersine Mühendislik Çağında Yazılımınızı Nasıl Korursunuz? 10 Pratik Önlem

Kısaca: Bir uygulamanın kullanıcının cihazına veya tarayıcısına giden her parçası, yani paketlenmiş JavaScript, mobil uygulama paketi (APK/IPA), masaüstü (Electron) uygulaması ve ağ trafiği, incelenebilir. REA gibi yapay zekâ destekli tersine mühendislik araçları bu incelemeyi hızlandırıyor (REA nedir?). Bu bir “yazılım korunamaz” anlamına gelmez; doğru yerde konumlandırma demektir: gizli anahtarlar, fiyat/iş kuralları ve lisans kontrolleri sunucuda durmalı; istemcide yalnızca açığa çıkması sorun olmayan şeyler bulunmalı. Kod gizleme (obfuscation) incelemeyi zorlaştırır ve yavaşlatır ama engellemez. Bu yazıda 10 pratik önlemi ve her birinin sınırlarını veriyoruz. Bilgiler genel mühendislik ilkelerine ve 23 Ekim 2026 itibarıyla yayımlanmış kaynaklara dayanır.

Son güncelleme: 23 Ekim 2026

Temel ilke: İstemciye giden her şey okunabilir

Tarayıcınıza gelen JavaScript, telefonunuza kurulan uygulama paketi ya da bilgisayarınıza indirilen masaüstü programı kullanıcının kontrolündedir. REA'nın resmî deposu da bu sınıfları hedef olarak sayıyor: JavaScript/Electron uygulamaları, .NET, Android APK'ları, web siteleri ve yerel ikili dosyalar. Bağımsız bir testte araç, bir Electron uygulamasının içindeki iletişim kanallarını saniyeler içinde, doğru konumlarıyla listeledi (test özeti). Yani soru “okunabilir mi?” değil, “okunduğunda ne zarar verir?”

10 pratik önlem

1. Gizli anahtarları istemciye koymayın

API anahtarları, veritabanı şifreleri, ödeme sağlayıcının gizli anahtarları, yapay zekâ servislerinin anahtarları asla tarayıcı kodunda, mobil uygulamada ya da masaüstü paketinde bulunmamalı. Bunlar sunucuda tutulmalı; istemci yalnızca sizin sunucunuzla konuşmalı. (“Herkese açık” olarak tasarlanmış anahtarlar, örneğin yalnızca belirli alan adlarına kısıtlanmış harita anahtarları, ayrı bir kategori; yine de kısıtlanmaları gerekir.)

2. İş kurallarını ve fiyat hesabını sunucuda çalıştırın

İndirim hesabı, komisyon oranı, yetki kararı, kota ve lisans doğrulaması istemcide yapılırsa kullanıcı tarafından değiştirilebilir ya da atlanabilir. Karar sunucuda verilmeli; istemci yalnızca sonucu göstermeli. Bu, özellikle SaaS ürünlerinde ödeme/plan sınırları için kritik.

3. Yetkilendirmeyi her API çağrısında sunucuda doğrulayın

Bir butonu gizlemek yetkilendirme değildir. Her istekte “bu kullanıcı bunu yapabilir mi?” kontrolü sunucuda olmalı. İstemci kodunu inceleyen biri tüm uç noktaları (API yollarını) görür; korunmayan bir uç nokta doğrudan çağrılabilir. Ayrıntılar için web uygulaması güvenliği rehberimize bakın.

4. API'lere hız sınırı ve kötüye kullanım koruması ekleyin

Uygulamanızın içini anlayan biri API'nizi otomatik olarak çağırabilir. Hız sınırlama, anormal kullanım tespiti, kimlik doğrulama ve gerekirse bot koruması, toplu veri çekme ve kötüye kullanımı zorlaştırır.

5. Kod gizlemeyi (obfuscation) gerçekçi beklentiyle kullanın

Kod küçültme (minify) ve gizleme, değişken adlarını anlamsızlaştırır ve incelemeyi yavaşlatır. Ama kararlı bir analizcinin işini imkânsız kılmaz; özellikle araçlar davranışı izleyip ilgili kod yollarını bulabiliyorsa. Gizlemeyi “tek koruma” değil, ek bir engel olarak değerlendirin. Ayrıca kaynak haritalarını (source map) üretim ortamında herkese açık yayınlamayın.

6. Hassas algoritmayı mümkünse sunucuya taşıyın

Rekabet avantajınız bir hesaplama algoritması ya da modelse, onu istemciye göndermek yerine API olarak sunun. Kullanıcıya sonuç gider, yöntem sunucuda kalır.

7. Mobil ve masaüstü uygulamalarda bütünlük ve lisans kontrollerini katmanlayın

Uygulama imzalama, bütünlük kontrolleri, sertifika sabitleme gibi önlemler değiştirilmiş kopyaların çalışmasını zorlaştırabilir; ancak kararlı bir saldırgan karşısında tek başına yeterli olmaz. Lisans doğrulamasını sunucu tarafında tutun ve anormal kullanımı (aynı lisansın çok sayıda cihazda çalışması gibi) izleyin.

8. Bağımlılıklarınızı ve yayın sürecinizi güvene alın

Uygulamanız pek çok açık kaynak bileşen içerir. Saldırgan, sizin yazdığınız koda değil bağımlılıklara saldırabilir. Bu hafta yaşanan LiteLLM tedarik zinciri saldırısı bunu gösterdi. Sürüm sabitleme, envanter ve yayın sürecinin korunması bu işin parçası.

9. Hukuki korumayı ihmal etmeyin

Teknik önlemler hukuki korumanın yerini tutmaz, onu tamamlar. Kullanım koşullarında ve lisans sözleşmelerinde tersine mühendisliği, kopyalamayı ve yeniden dağıtımı düzenleyin; müşterilerle ve yazılım tedarikçileriyle sözleşmede kaynak kod ve fikri mülkiyet hükümlerini netleştirin (sözleşme kontrol listemiz). Hangi inceleme biçimlerinin yasal olabileceği ülkeye ve sözleşmeye göre değişir: yasal sınırlar yazımıza bakın ve bir hukukçuya danışın.

10. “Kopyalanırsa ne olur?” senaryosunu önceden düşünün

İstemci tarafı özellikler (arayüz, akışlar) taklit edilebilir. Gerçek rekabet avantajınız genellikle veri, marka, müşteri ilişkisi, hız ve sürekli geliştirmededir. Kritik varlıklarınızı (veri, model, iş mantığı) sunucuda koruyun ve ürünü hızlı geliştirmeye odaklanın. Bir olay yaşarsanız (sızıntı, kopya ürün) ne yapacağınızı önceden yazın: kimler bilgilendirilecek, hangi anahtarlar yenilenecek, hukuki adım ne olacak.

Hızlı kontrol listesi

• İstemci paketlerinde (JS, APK/IPA, masaüstü) gizli anahtar yok
• Fiyat, yetki, kota ve lisans kararları sunucuda
• Her API çağrısında sunucu tarafı yetkilendirme
• Hız sınırı ve kötüye kullanım izleme var
• Üretimde source map herkese açık değil
• Hassas algoritma/model sunucuda
• Lisans doğrulama sunucuda, anormal kullanım izleniyor
• Bağımlılık envanteri ve sürüm sabitleme var
• Kullanım koşulları/sözleşmede tersine mühendislik ve kopyalama hükümleri var
• Sızıntı/kopya senaryosu için olay planı yazılı

Aktaş Digital ile güvenli mimari

Yeni projelerde hangi mantığın istemcide, hangisinin sunucuda duracağını mimari aşamasında netleştiriyoruz; mevcut uygulamalar için de gizli anahtar, yetkilendirme ve API güvenliği incelemesi yapılabilir. Projenizi anlatıp kapsam ve maliyet dökümü almak için teklif formumuzu kullanabilirsiniz. İlgili hizmetlerimiz: web çözümleri, SaaS platform geliştirme ve yapay zekâ çözümleri.

Sık Sorulan Sorular

Kod gizleme uygulamamı tamamen korur mu?

Hayır. Gizleme incelemeyi zorlaştırır ve yavaşlatır, ama kararlı bir analizciyi durdurmaz. Gerçek koruma, hassas mantığın ve anahtarların istemciye hiç gitmemesidir.

Web sitemin JavaScript kodunu herkes görebilir mi?

Evet; tarayıcıya gönderilen JavaScript kullanıcı tarafından okunabilir. Bu yüzden gizli bilgiler ve kritik kararlar sunucuda olmalı.

Mobil uygulamamdaki API anahtarı güvenli mi?

Uygulama paketine gömülü anahtarlar çıkarılabilir kabul edilmelidir. Gizli anahtarları sunucuda tutun; istemcide kullanmanız gereken anahtarları kapsam ve kota açısından kısıtlayın.

Yapay zekâ araçları bu riski büyüttü mü?

İncelemeyi hızlandırıyor ve daha az uzmanlıkla başlatılabilir hale getiriyor; ama temel risk aynı: istemciye giden her şey okunabilir. Bu yüzden yukarıdaki ilkeler yapay zekâdan önce de geçerliydi, şimdi daha önemli.

Rakibim uygulamamı kopyalarsa ne yapabilirim?

Durum ülkeye, sözleşmelere ve neyin kopyalandığına göre değişir. Kanıtları saklayın ve bir hukukçuya danışın. Önleyici olarak kullanım koşulları ve lisans hükümlerinizi gözden geçirin.

Sonuç

Yapay zekâ destekli tersine mühendislik araçları, “kimse bakmaz” varsayımını geçersiz kılıyor. Çözüm paranoya değil, doğru konumlandırma: gizli olması gereken her şey sunucuda, istemcide yalnızca açığa çıkması zararsız olanlar. Bugün yapabileceğiniz ilk iş: yazılım ekibinizden, uygulamanızın istemci paketlerinde gizli anahtar ve iş kuralı bulunup bulunmadığını kontrol etmesini ve sonucu yazılı olarak paylaşmasını istemek.