Mobil Uygulama Sızma Testi: Kapsam, Süre ve Rapor Rehberi

Mobil uygulama sızma testi, çoğu ekipte "web testinin mobil sürümü" olarak bütçeleniyor ve tam olarak bu yüzden yanlış sonuç veriyor. Bir mobil uygulama üç ayrı saldırı yüzeyinden oluşuyor: kontrol etmediğiniz bir cihazda çalışan istemci, o cihazda kalan yerel veri, ve uygulamanın konuştuğu sunucu tarafı. Üçünü ayrı ayrı test etmeden alınan rapor, genellikle yalnızca üçüncü yüzeyi anlatıyor ve iki yüzeyi sessizce kapsam dışında bırakıyor.

Bu rehber, satın alma tarafındaki soruya cevap veriyor: kapsam nasıl yazılır, hangi test hangi bulguyu üretir, ne kadar sürer, raporda neyi görmek gerekir, ve hangi bulgu gerçekten risk taşır. Ürün adı ya da sağlayıcı sıralaması yok; çünkü mobil testin kalitesi araçtan değil, kapsam kararlarından geliyor.

Baştan bir uyarı: mobil uygulamalarda istemci tarafındaki kontrollerin hiçbiri güvenlik sınırı değil. Kök tespiti, jailbreak kontrolü, kod karartma, sertifika sabitleme - hepsi saldırganın maliyetini artırır, erişimini engellemez. Yetki kontrolünün tek gerçek yeri sunucu. OWASP MASVS de bunu açıkça söylüyor: kimlik doğrulama ve yetkilendirme mekanizmalarının uygulanması uzak uç noktada olmalı. Bir raporda "pinning var" cümlesi bir bulgu değil, bir gecikme.

Kapsam: MASVS profilleri ve ne anlama geldikleri

Mobil testin ortak dili OWASP MASVS (Mobile Application Security Verification Standard) ve ona bağlı MASTG test rehberi. MASVS kontrol listesini veriyor, MASTG her kontrolün nasıl test edileceğini. Sözleşmeye yazılması gereken şey "MASVS'e uygun test" değil, hangi test profilinin seçildiği.

Üç profil var. MAS-L1, tüm uygulamalar için önerilen temel seviye: depolama, kriptografi, kimlik doğrulama, ağ iletişimi, platform etkileşimi ve kod kalitesi kontrollerinin standart hâli. MAS-L2, cihazın ele geçirilmiş varsayıldığı savunma derinliği seviyesi; sağlık ve finans gibi hassas veri taşıyan uygulamalar için. MAS-R ise tersine mühendislik ve kurcalamaya karşı dayanıklılık: kod karartma, bütünlük kontrolü, hata ayıklama engelleme.

Profil seçimi bütçeyi doğrudan belirliyor, çünkü R seviyesi ayrı bir iş kalemi. Bir e-ticaret uygulaması için L1 genellikle yeterliyken, ödeme akışı barındıran bir uygulamada L2 beklenir; bankacılık benzeri bir uygulamada R de eklenir. Kapsam yazarken "L2 + R" ifadesinin yanına hangi kontrollerin kapsam dışı bırakıldığını da yazmak gerekiyor - aksi hâlde rapor geldiğinde tartışma profil üzerinden değil, beklenti üzerinden çıkıyor.

MASVS kategorisi	Neyi kapsıyor	Tipik bulgu
STORAGE	Cihazda saklanan veri, yedekler, günlükler	Düz metin parola, yedekte okunabilir veritabanı, günlükte oturum belirteci
CRYPTO	Anahtar üretimi, saklama, kullanılan algoritmalar	Sabit anahtar, ECB modu, zayıf rastgelelik
AUTH	Oturum, biyometri, uzak uç noktada yetki	İstemcide yetki kararı, süresiz belirteç, biyometri sonrası yeniden kimlik doğrulama yokluğu
NETWORK	TLS yapılandırması, sabitleme, trafiğin açığa çıkması	Sabitleme yok, ATS istisnası, hassas veri sorgu dizesinde
PLATFORM	Bileşenler, izinler, derin bağlantılar, WebView	Dışa açık bileşen, doğrulanmamış derin bağlantı, WebView içinde JavaScript köprüsü
CODE	Girdi doğrulama, bellek, hata yönetimi, bağımlılıklar	Hata ayıklama bayrağı açık, eski kütüphane, yığın izi sızıntısı
RESILIENCE	Kurcalama ve tersine mühendislik direnci	Kök tespiti yok, bütünlük kontrolü yok, kolayca yamalanabilir
PRIVACY	Veri minimizasyonu, izinler, üçüncü taraf SDK'lar	Gereksiz izin, analitik SDK'ya kimlik sızıntısı

Trafik yakalama ve sertifika sabitleme: sözleşmede karara bağlanması gereken madde

Mobil testin ilk teknik engeli, uygulamanın trafiğini araya girerek okumak. Sunucu sertifikasını doğrulayan ve sertifikayı uygulamanın içine gömen bir uygulama, vekil sunucu kullanılarak okunamıyor. Bu iyi bir savunma, ama testin ilk adımını bloke ediyor. Çözüm iki tanesi: test için sabitlemesi kapalı bir derleme almak, ya da sabitlemeyi cihaz üzerinde dinamik olarak atlatmak.

İkinci yol, yani Frida veya objection ile atlatma, raporun gerçekçiliği açısından daha değerli. Çünkü sabitlemenin atlatılabildiğini göstermek, "sabitleme var" ifadesinin ne kadar koruduğunu ölçüyor. Ama bu iş, sözleşmede açıkça izin verilmeden yapılmamalı: sabitlemeyi atlatmak için cihaza kod enjekte ediliyor, bazı kuruluşlar bunu test kapsamı dışında sayıyor, bazıları ise üretim imzalı derlemede bunu bir olay olarak görüyor. Doğru yazım şu: "sertifika sabitlemesi, test cihazında dinamik enstrümantasyon ile atlatılabilir; atlatma yöntemi ve süresi raporda belgelenir". Bu cümle yoksa, testin ilk günü tartışmayla geçiyor.

Sabitlemenin atlatılabilmesi tek başına bir zafiyet değil; ama şu üç durumda gerçek bir bulgu oluyor. Birincisi, sabitleme yalnızca birkaç alan adına uygulanmışsa ve uygulama diğer uç noktalarla da hassas veri taşıyorsa. İkincisi, atlatma sonrası trafikte oturum belirteci veya kişisel veri açık metin halinde görünüyorsa. Üçüncüsü, sabitleme atlatıldıktan sonra sunucu tarafında hiçbir anormallik sinyali üretilmiyorsa - yani saldırganın araya girmesi tespit edilemiyorsa.

Test	Nasıl yapılır	Bulgu sayılan durum
TLS yapılandırması	Vekil sunucu ile bağlantı, protokol ve şifre süiti listesi	TLS 1.0/1.1 kabulü, zayıf süit, sertifika doğrulama hatasının yutulması
Sertifika sabitleme	Dinamik enstrümantasyon ile atlatma denemesi	Hiç sabitleme yok; ya da sabitleme yalnızca bir alan adında
Hassas veri konumu	Trafikte URL, başlık ve gövde incelemesi	Belirteç sorgu dizesinde, parola gövdede düz metin, PII günlüğe yazılıyor
Sunucu tarafı tespit	Aynı hesaptan iki farklı cihaz/parmak izi ile eşzamanlı istek	Uyarı, oturum sonlandırma veya adım artırma yok

Cihazda kalan veri: en sık bulunan gerçek zafiyet

Pratikte en çok bulgu üreten kategori depolama, çünkü geliştirme hızı ile veri hijyeni ters orantılı. Bir oturum belirteci hata ayıklama için günlüğe yazılır ve derlemede kalır; bir kullanıcı profili önbelleğe alınır ve yedeklemeye dahil olur; bir ekran görüntüsü koruması yalnızca bir ekranda uygulanır, diğerlerinde uygulama arka plana geçtiğinde içerik sistem tarafından saklanır.

Android tarafında bakılan yerler net: uygulama veri dizini, allowBackup bayrağı, dışa açık dosya sağlayıcıları, network_security_config içindeki güven çapaları, WebView önbelleği, pano kullanımı, ve üçüncü taraf SDK'ların kendi veri dizinleri. iOS tarafında Keychain erişilebilirlik sınıfları belirleyici: kSecAttrAccessibleWhenUnlocked ile saklanan bir öğe, cihaz kilitliyken okunamaz; ama kSecAttrAccessibleAlways ile saklanan aynı öğe yedeklemede ve cihaz kilidi açılmadan erişilebilir. Aynı veri, iki farklı sınıf, iki farklı risk.

Bu kategoride bir bulgunun gerçek risk taşıyıp taşımadığı, verinin ne olduğuna ve cihazın kimin elinde olduğuna bağlı. Kayıp bir telefonda okunabilen bir oturum belirteci, tam bir hesap devralması demek; kaybolan telefonda okunabilen bir kullanıcı adı ise düşük etkili. Raporun bu ayrımı yapması gerekiyor, çünkü "cihazda düz metin veri var" cümlesi tek başına bir eylem maddesi üretmiyor.

Yüzey	Android	iOS	Test
Kimlik bilgisi deposu	Keystore, EncryptedSharedPreferences	Keychain, erişilebilirlik sınıfı	Dosya sistemi incelemesi, cihaz yedeği
Yedekleme	allowBackup, bulut yedeği	iTunes/iCloud yedeği	Yedek al, içeriği ara
Günlükler	logcat, dosya günlükleri	os_log, konsol çıktısı	Akışları topla, belirteç ara
Ekran koruması	FLAG_SECURE	Ekran yakalama algılama	Arka plana al, görev değiştiriciyi incele
Pano	ClipboardManager	UIPasteboard	Kopyala, başka uygulamada oku
Dışa açık bileşenler	exported activity/service/receiver/provider	URL şemaları, uzantılar	Manifest ve Info.plist incelemesi, çağrı denemesi

Platform bileşenleri ve derin bağlantılar: dışarıdan çağrılabilen kapılar

Mobil uygulamanın web uygulamasında karşılığı olmayan saldırı yüzeyi, işletim sisteminin uygulamaya açtığı kapılar. Android'de dışa açık (exported) bir etkinlik, servis, alıcı veya içerik sağlayıcı, başka bir uygulama tarafından çağrılabilir. iOS'ta kayıtlı URL şemaları ve paylaşım uzantıları aynı işlevi görür. Bir uygulama, kendi kullanıcı arayüzünde hiç göstermediği bir yeteneği bu kapılar üzerinden sunabilir.

Test bu yüzden iki adımlı: manifest ve Info.plist üzerinden dışa açık yüzeyi listelemek, sonra her yüzeyi kötü niyetli bir çağrıyla denemek. Tipik bulgular şunlar: doğrulama yapmadan parametre kabul eden bir etkinlik, oturum kontrolü olmayan bir içerik sağlayıcı, hedef bileşeni çağıran parametre ile belirlenebilen bir yönlendirme, ve derin bağlantı üzerinden gelen bir belirtecin doğrulanmadan kabul edilmesi.

Derin bağlantılar ayrıca hesap devralma zincirinin parçası olabiliyor: bir parola sıfırlama bağlantısı, uygulama tarafından doğrulanmadan işlenirse, saldırgan kendi hazırladığı bağlantıyla kurbanın oturumunu kendi cihazına bağlayabilir. Bu nedenle bağlantı ile gelen her parametre, sunucu tarafında tek kullanımlık ve hedef hesapla eşleşmiş olarak doğrulanmalı.

Yüzey	Test	Bulgu
Dışa açık etkinlik	adb veya özel bir uygulama ile çağrı, parametre enjeksiyonu	Doğrulanmamış parametre, oturum kontrolü yokluğu
İçerik sağlayıcı	Diğer uygulamadan sorgu, yol geçişi denemesi	Yetkisiz okuma, dosya yolu geçişi
Derin bağlantı	Sahte bağlantı ile uygulamayı açma, parametre değiştirme	Belirteç doğrulanmadan kabul, açık yönlendirme
WebView	Yerel köprü arayüzü çağrısı, dosya şeması erişimi	JavaScript köprüsü ile yerel yetenek çağrısı
İzinler	İzin setini amaca göre karşılaştırma	Gereksiz konum, kişi, depolama izni - gizlilik bulgusu

WebView kalemi ayrı duruyor, çünkü mobil uygulamada web içeriği göstermek neredeyse her uygulamada var ve yerel köprü arayüzü eklemek kolay. Köprü açıksa, yüklenen her sayfa - reklam ağı dahil - yerel yetenekleri çağırabilir. Bu, uygulamanın kendi kodundaki en ciddi zafiyetlerden biri olabiliyor ve genellikle test edilmeden yayına çıkıyor.

Sunucu tarafı: mobil uygulamanın gerçek güvenlik sınırı

İstemci tarafındaki tüm bulguların toplamı, sunucu tarafındaki tek bir yetkilendirme hatasının yanında küçük kalıyor. Mobil uygulamalar API tüketiyor ve API'lerde en yaygın ciddi hata, nesne düzeyinde yetkilendirme eksikliği: istemci bir kayıt kimliği gönderiyor, sunucu o kaydın istekte bulunan kullanıcıya ait olup olmadığını kontrol etmeden döndürüyor. Uygulamada bu hata görünmez, çünkü arayüz yalnızca kendi kayıtlarınızı listeliyor; ama istek elle değiştirildiğinde başka bir kullanıcının verisi geliyor.

Bu nedenle mobil test, API testinden ayrı düşünülemez. Aynı uygulama için yapılan testte iki farklı kapsam var: cihazdaki istemci davranışı ve API'nin yetki modeli. İkincisi için gereken şey, rollerin ve nesnelerin bir matrisi: kaç rol var, her rol hangi nesneye hangi işlemi yapabiliyor, ve bu matris testte tek tek deneniyor mu. Üç rollü bir uygulamada beş nesne türü varsa, denenecek kombinasyon sayısı on beş; bu, bir günlük iş.

API testi	Ne aranır	Nasıl denenir
Nesne düzeyinde yetki	Kimliği değiştirince veri geliyor mu	İki hesapla aynı istek, kimlik alanı değiştirilir
İşlev düzeyinde yetki	Düşük rollü kullanıcı yönetici uç noktasını çağırabiliyor mu	Rol matrisi üzerinden her uç nokta denenir
Belirteç ömrü ve yenileme	Eski belirteç hâlâ geçerli mi, yenileme döndürülebilir mi	Çıkış sonrası istek, yenileme tekrar kullanımı
Hız sınırı	Parola denemesi ve doğrulama kodu sınırsız mı	Otomatik istek, yanıt farkı ölçümü
İş mantığı	Negatif tutar, tekrar kullanılan kupon, atlanan adım	Akışın adımlarını sırayla atlamak
Toplu atama	İstemcinin göndermediği alan gövdeye eklenince kabul ediliyor mu	Kayıt güncelleme isteğine fazladan alan ekleme

İş mantığı satırı, otomatik araçların en çok kaçırdığı yer ve manuel testin asıl değeri burada ortaya çıkıyor. Bir kupon kodunun aynı sepette iki kez uygulanması, bir iade akışının yarım bırakılıp yeniden başlatılması, bir abonelik yükseltmesinin ödeme adımı atlanarak tamamlanması - bunlar tarayıcı ya da mobil araç taramasıyla bulunmuyor, akışı anlayan birinin denemesiyle bulunuyor. Bu yüzden "otomatik tarama + rapor" paketleri mobilde dar kapsamlı kalıyor; otomasyon yalnızca tekrarlayan kontrolleri hızlandırıyor.

Süre ve efor: bir mobil testin gün hesabı

Mobil test fiyatlaması, çoğu teklifte "uygulama başına" bir sayı olarak veriliyor ve bu, kapsam farklarını gizliyor. Aşağıdaki model, gerçek bir kapsamı gün gün açıyor: iki platform (Android + iOS), 40 API uç noktası, üç rol, MAS-L2 + R profili, ve bir yeniden test.

İş kalemi	Gün	Neye bağlı
Kapsam, izin ve ortam hazırlığı	1	Test hesapları, test derlemesi, cihaz seti
Statik analiz (iki platform)	1,5	Kod karartma, bileşen sayısı
Dinamik test - Android	3	Ekran sayısı, SDK sayısı
Dinamik test - iOS	3	Aynı
API yetki ve iş mantığı	3	Uç nokta sayısı, rol sayısı
Dayanıklılık (R profili)	1,5	Karartma, bütünlük, kök tespiti
Rapor ve bulgu doğrulama	1,5	Bulgu sayısı, kanıt standardı
Yeniden test	1	Düzeltilen bulgu sayısı

Toplam on dört buçuk iş günü. Aynı uygulama tek platform olsaydı ve API kapsamı olmasaydı, süre altı güne inerdi; iki platformlu ama API'siz bir test ise sekiz buçuk gün. Bu fark, "uygulama başına sabit fiyat" teklifinin neden karşılaştırılamaz olduğunu gösteriyor: iki teklif aynı sayıyı söylerken biri altı, diğeri on dört günlük iş kapsıyor olabilir.

Teklifi okurken sorulacak üç soru var. Birincisi: kaç platform, hangi cihaz sürümleri? İkincisi: API kapsamı var mı, kaç uç nokta ve kaç rol üzerinden? Üçüncüsü: yeniden test dahil mi, kaç tur? Bu üç cevap yoksa fiyat bir bilgi taşımıyor. Aynı mantık, hizmeti satın alan tarafın iç bütçe çıkarırken de geçerli; sızma testi fiyatlarının nasıl belirlendiği yazısı bu kalemleri genel çerçevede açıyor, buradaki fark mobilin kendi efor kalemleri.

Kapsam dışı kalanlar: sözleşmede açıkça yazılması gerekenler

Bir mobil test sözleşmesinde en çok tartışma yaratan şey, testin neyi kapsamadığı. Bunların baştan yazılması, hem satın alan hem test eden için koruma; sonradan çıkan bir bulgu "kapsam dışıydı" cümlesiyle kapanmamalı, çünkü o cümle riski ortadan kaldırmıyor, yalnızca sorumluluğu kaydırıyor.

Kapsam dışı	Neden	Nasıl kapatılır
Üçüncü taraf SDK'ların sunucuları	Yetkiniz yok, sağlayıcı sorumluluğunda	SDK envanteri ve izin listesi ayrı bir gizlilik incelemesi
Mağaza hesabı ve dağıtım hattı	Farklı bir yetki alanı	İmza anahtarı yönetimi ve CI erişimi ayrı denetim
Sunucu altyapısı ve ağ	Ayrı kapsam, ayrı izin	Altyapı testi veya bulut yapılandırma denetimi
Ödeme kartı verisi işleme	PCI DSS kapsamı	Ödeme sağlayıcısının uyumluluk beyanı
Sosyal mühendislik	İnsan odaklı, ayrı yöntem	Ayrı bir farkındalık ve oltalama programı
Kaynak kodu incelemesi	Statik analizden farklı efor	Kod incelemesi kalemi olarak eklenir

Bu tabloyu teklifin ekinde görmek, satın alan için bir kalite işareti. Kapsam dışı listesi olmayan teklifler genellikle iki uçtan birinde: ya her şeyi kapsadığını ima ediyor - ki bu doğru olamaz - ya da sınırları hiç düşünmemiş. İkisi de proje sırasında sürtünme üretiyor.

Sızma testi, güvenlik değerlendirmesi ve otomatik tarama arasındaki fark

Aynı uygulama için üç farklı hizmet satın alınabiliyor ve üçü farklı soruları cevaplıyor. Karıştırıldıklarında iki sonuç çıkıyor: ya bir güvenlik değerlendirmesi "test yapıldı" diye kapatılıyor, ya da bir sızma testinden olgunluk değerlendirmesi bekleniyor.

Sızma testi, belirli bir süre içinde gerçek bir saldırganın yapacağı işi yapıyor: zincir kuruyor, bir bulguyu diğerine bağlıyor, en sonunda ne kadar ileri gidebildiğini gösteriyor. Çıktısı bulgu listesi ve kanıt. Güvenlik değerlendirmesi ise daha geniş bir çerçeve: mimari, süreç, yapılandırma ve kontrollerin olgunluğunu ölçüyor, bulgu üretmekten çok yol haritası çıkarıyor. Otomatik tarama ise yalnızca bilinen desenleri arıyor; hızlı, ucuz ve tekrarlanabilir, ama iş mantığı ve yetki zinciri gibi konularda sessiz.

Hizmet	Cevapladığı soru	Çıktı	Süre
Otomatik tarama	Bilinen zayıf desenler var mı	Araç raporu, yüksek gürültü	Saatler
Güvenlik değerlendirmesi	Kontroller yeterli mi, olgunluk nerede	Olgunluk değerlendirmesi, yol haritası	3-5 gün
Sızma testi	Gerçekten ne kadar ileri gidilebilir	Zincirlenmiş bulgular, kanıt, önem derecesi	6-14 gün
Kod incelemesi	Kaynakta hangi hata var	Satır düzeyinde bulgu, düzeltme önerisi	5-10 gün

Bu tablodaki en pahalı hata, otomatik taramayı sızma testi yerine koymak. Bir tarama aracı, ekranda görünmeyen bir yetki hatasını bulamıyor; çünkü araç isteği sizin oturumunuzla gönderiyor ve sunucunun döndürdüğü veriyi "başarılı yanıt" olarak işaretliyor. Aynı isteği başka bir kullanıcının kimliğiyle göndermek, bir insanın kararı. İki saatlik bir tarama ile iki günlük bir manuel API testi arasındaki fark tam olarak bu.

Doğru sıralama genellikle şu: sürüm öncesi otomatik tarama, yılda bir güvenlik değerlendirmesi, kritik sürümlerde sızma testi, ve yüksek riskli bileşenlerde kod incelemesi. Bu sıralamanın bütçesi, tek seferlik büyük bir testten daha düşük ve yıl boyunca daha fazla bilgi üretiyor. Bir kuruluşun yıllık güvenlik takvimini bu dört kalem üzerine kurması, tek bir "yıllık test" satırından daha savunulabilir; olay sonrası süreç de bu takvimin parçası olmalı, olay müdahale planı bu bağlantıyı kuruyor.

Rapor: kanıt standardı ve yeniden test

Bir mobil test raporunun değeri, bulgu sayısıyla değil, her bulgunun yeniden üretilebilir olmasıyla ölçülür. Yeniden üretilebilir bulgu, uygulamanın hangi sürümünde, hangi cihazda, hangi adımlarla ortaya çıktığını ve neyin yanlış gittiğini gösteren bir kanıt zinciri demek: istek ve yanıt, ekran görüntüsü veya ekran kaydı, gerekliyse enstrümantasyon betiği.

Raporun ikinci kalitesi, bulguları MASVS kategorileriyle eşlemesi ve her bulguya bir önem derecesi vermesi. CVSS taban puanı faydalı ama tek başına yetersiz, çünkü aynı teknik zafiyetin mobildeki etkisi bağlama göre değişiyor: kayıp bir cihazda okunabilen oturum belirteci ile internete açık bir uç noktadan sızan aynı belirteç, aynı puanı alabilir ama farklı aciliyet taşır.

Üçüncü kalite, düzeltme önerisinin uygulanabilir olması. "Güvenli depolama kullanın" cümlesi bir öneri değil; "oturum belirtecini Keystore destekli EncryptedSharedPreferences içine taşıyın, yenileme belirtecini ayrı tutun, çıkışta her ikisini de silin" cümlesi bir öneri. Bu ayrım, raporun geliştirici tarafından ne kadar kullanılabildiğini belirliyor ve çoğu zaman testin gerçek getirisi buradan geliyor.

Yeniden test ise kapanışın şartı. Düzeltilen bulguların gerçekten düzeldiğini doğrulamak, yeni bir bulgu eklemeden yalnızca eski bulgular üzerinden ilerlemek demek; yeni bir sürümde yeni yüzeyler açıldıysa bu ayrı bir test turu. Sözleşmede "bir yeniden test turu dahil" yazıyorsa, bu turun kapsamı da yazılmalı: hangi bulgular, hangi sürüm, hangi süre içinde.

Yetkilendirme: testin hukuki çerçevesi

Mobil test, yetkisiz yapıldığında suç; yetkili yapıldığında bile sınırları aşarsa yine suç. Türk Ceza Kanunu'nun 243. maddesi bilişim sistemine girme fiilini düzenliyor ve izin sınırını aşan erişim bu kapsama girebiliyor. Bu yüzden izin, "test yapabilirsiniz" cümlesi değil; sistem, zaman aralığı, test hesapları ve yöntem sınırlarını içeren yazılı bir kapsam olmalı.

Mobilde bu kapsamın dört özel kalemi var. Birincisi, uygulamanın hangi sürümü ve hangi ortamı test ediliyor: üretim, hazırlık (staging) veya ikisi. İkincisi, hangi hesaplar kullanılacak ve bu hesaplar gerçek kullanıcı verisine erişecek mi. Üçüncüsü, cihaz tarafında kod enstrümantasyonu ve sabitleme atlatma izni var mı. Dördüncüsü, test sırasında elde edilen verinin nasıl saklanacağı ve ne zaman silineceği.

İkinci kalem, KVKK tarafındaki asıl riski taşıyor. Test ortamı gerçek kullanıcı verisinin kopyasıysa, test sırasında o veriye erişmek işleme fiili demek ve 6698 sayılı Kanun'un 12. maddesi devreye giriyor: verilerin hukuka aykırı işlenmesini ve erişilmesini önlemek, muhafazasını sağlamak veri sorumlusunun yükümlülüğü. Doğru uygulama, test ortamında anonimleştirilmiş veri kullanmak, test hesaplarını gerçek kullanıcılardan ayrı tutmak ve test sırasında toplanan kanıtları (istek/yanıt kayıtları, ekran görüntüleri) kişisel veri içermeyecek biçimde maskelemek. Kanıt dosyaları çoğu zaman bulgudan daha fazla veri taşıyor ve bu dosyalar test bitince paylaşılan klasörlerde kalıyor. Kanıt yönetiminin çerçevesi KVKK teknik tedbirler rehberinde ayrıntılı.

Üçüncü bir hukuki ayrıntı mağaza tarafı: bir uygulamayı mağaza politikalarını test etmek için tersine mühendislikle incelemek, kendi uygulamanız için sorun değil; üçüncü taraf bir uygulama için izin meselesi. Kurumsal tarafta tedarikçiye test yaptırırken bu sınırların sözleşmede yazılması, hem sizi hem tedarikçiyi koruyor; tedarikçi risk rehberi bu maddelerin sözleşmeye nasıl yazılacağını anlatıyor.

İç ekip mi, dış ekip mi: karar ölçütleri

Bu sorunun cevabı bütçe değil, bağımsızlık ve süreklilik dengesi. İç ekip uygulamayı tanıyor, hızlı çalışıyor ve bulguları doğrudan geliştiriciyle konuşabiliyor; ama aynı ekibin yazdığı kodu test etmesi, bilinen kör noktaları tekrar etme riski taşıyor. Dış ekip taze bir bakış getiriyor ve raporun bağımsızlığı denetim açısından değerli; ama uygulamayı öğrenme süresi maliyete giriyor.

Pratikte işleyen model ikisini birleştiriyor: tekrarlayan kontrolleri (statik analiz, bağımlılık taraması, yapılandırma denetimi) iç ekip otomatikleştiriyor, yılda bir veya sürüm atlamalarında bağımsız bir ekip manuel test yapıyor. Bu ayrım, testin sürekliliğini sağlarken bağımsızlığı da koruyor. Regresyon testleri ve sürekli kontrol fikri, red team değerlendirmesinin ölçüm protokolünde daha geniş çerçevede ele alınıyor; mobil test bunun dar ama derin bir dilimi.

Bir de süreklilik kalemi var: mobil uygulamalar iki haftada bir sürüm çıkarıyor. Yılda bir yapılan bir test, yılın geri kalanında ne olduğunu söylemiyor. Bu yüzden testi bir etkinlik değil, sürüm döngüsüne bağlı bir kontrol olarak kurmak gerekiyor: her büyük sürümde otomatik kontroller, yılda bir bağımsız manuel test, ve her yeni üçüncü taraf SDK eklendiğinde gizlilik incelemesi.

Kapanış: on maddelik kontrol listesi

Mobil uygulama testini satın alırken veya planlarken sırasıyla şunlar: test profilini (L1, L2, R) yaz; kapsam dışı listesini teklifin ekinde iste; platform, cihaz sürümü ve API uç nokta sayısını netleştir; sertifika sabitleme atlatma iznini açıkça yaz; test ortamının anonimleştirilmiş olduğunu doğrula; rol ve nesne matrisini test öncesi paylaş; raporda MASVS eşlemesi ve yeniden üretilebilir kanıt iste; yeniden test turunu ve kapsamını sözleşmeye ekle; test kanıtlarının imha tarihini belirle; ve bulguları sürüm döngüsüne bağla.

Bu on maddenin ortak noktası şu: mobil testin kalitesi, aracın ne kadar iyi olduğunda değil, kapsamın ne kadar dürüst yazıldığında. Kapsamı dar yazılmış bir test, bulgu üretmese bile güven vermiyor; kapsamı açık yazılmış bir test, ürettiği her bulguyla düzeltilebilir bir yol haritası bırakıyor.

Uygulamanızın sunucu tarafı ayrı bir başlık: yetkilendirme modeli, hız sınırları ve belirteç yönetimi mobil testin içinde yalnızca yüzeysel olarak görülüyor. API tarafının ayrıntılı test çerçevesi API güvenlik testi rehberinde, olay sonrası süreç ise olay müdahale planı yazısında. Kasa ve parola tarafındaki tamamlayıcı kontrol listesi de parola yöneticisi risk modelinde.