İşlem İçi Analiz ve İşlemler Arası Analiz: Bu Fark Bulgularınızı Nasıl Belirliyor?

SQL enjeksiyonu güvenlik açığı bulunan bir JavaScript dosyasında ESLint çalıştırdığınızda, dosya temiz bir şekilde geçer. Aynı kod tabanında CodeQL çalıştırdığınızda ise, enjeksiyonu tam dosya, satır ve veri akışı yoluyla işaretler. Her ikisi de statik analiz araçlarıdır. Her ikisi de aynı kaynak kodunu çalıştırmadan inceler. Buldukları arasındaki fark, kural yapılandırması veya dil desteğiyle ilgili değil, her aracın ne kadar ileriye baktığıyla ilgili temel bir farktır. ESLint, her seferinde bir fonksiyonu inceler ve bu sınır içinde gördüklerini rapor eder. CodeQL ise, tehlikeli bir şeye ulaşana kadar fonksiyon çağrıları, modüller ve tüm çağrı grafiği boyunca verileri takip eder.

Bu ayrım, yani prosedür içi ve prosedürler arası analiz, farklı statik analiz araçlarının neden farklı şeyler bulduğunu anlamak için en önemli teknik kavramdır. Bir linter'ın bir kod tabanına temiz rapor verirken, daha gelişmiş bir aracın aynı kodda kritik güvenlik açıkları bulmasının nedenini açıklar. Güvenlik SAST araçlarının çalıştırılmasının neden pahalı olduğunu açıklar. "Hızlı" araçların yanlış negatif oranının, "yavaş" araçların yanlış negatif oranından yapısal olarak neden daha yüksek olduğunu açıklar. Ve bu, kurumsal ekiplerin herhangi bir statik analiz araç zincirini değerlendirmeden önce anlaması gereken kavramdır.

İşlem İçi Analiz Nedir?

İşlem içi analiz, bir fonksiyonun, metodun veya prosedürün içinde neler olup bittiğini, o fonksiyonun diğer fonksiyonları çağırdığı veya onlardan çağrıldığı durumları dikkate almadan inceler. Analiz sınırı, fonksiyon sınırıdır. İşlem içi bir araç bir fonksiyon çağrısına ulaştığında durur, çağrıyı takip etmez ve çağrılan fonksiyonun aldığı verilerle ne yaptığını bilmez.

İşlem içi analizin tipik örnekleri, tek bir fonksiyon içindeki kod denetimi ve temel veri akışıdır:

piton

def process_input(user_data):
    # Intraprocedural analysis sees: user_data used here
    query = "SELECT * FROM users WHERE id = " + user_data  # flagged: string concat in SQL
    return query

SQL sorgularında dize birleştirmeyi işaretleyen basit bir kural, tehlikeli desen tek bir fonksiyon içinde görülebildiği için prosedür içi olarak işe yarar. Ancak kod yapısını biraz değiştirin:

piton

def get_user_id(request):
    return request.args.get("id")  # untrusted input

def build_query(user_id):
    return "SELECT * FROM users WHERE id = " + user_id  # looks safe in isolation

def handle_request(request):
    uid = get_user_id(request)
    query = build_query(uid)    # vulnerability spans three functions
    db.execute(query)

Şimdi, bozuk verilerin kaynağı (request.args.get("id")) tehlikeli lavabodan farklı bir işlevdedir (db.execute(query)Hiçbir tek fonksiyon, prosedür içi bir aracın güvenlik açığını tespit etmesi için yeterli bilgi içermez. get_user_id Gayet iyi görünüyor, sadece gelen isteği okuyor. build_query Gayet iyi görünüyor, bir parametre alıyor ve bir dize oluşturuyor. handle_request Her şey yolunda görünüyor, fonksiyonları çağırıyor ve bir sorgu çalıştırıyor. SQL enjeksiyonu gerçek, istismar edilebilir ve fonksiyon sınırlarını aşmayan hiçbir araç tarafından görülemez.

İşlem İçi Analizin İyi Olduğu Alanlar Nelerdir?

İşlem içi araçlar çok hızlıdır. Her fonksiyonu bağımsız olarak analiz ettikleri için, kod tabanı boyutuyla doğrusal olarak ölçeklenirler; bir milyon satırlık bir kod tabanını analiz etmenin maliyeti, on bin satırlık bir kod tabanını analiz etmenin maliyetiyle orantılı olarak aynıdır. Bu hız, onları aşağıdakiler için ideal kılar:

• Ön taahhüt kancaları bir saniyeden kısa sürede çalışan
• IDE satır içi geri bildirim bir geliştirici yazarken
• CI/CD kalite kontrolleri her çekme isteğinde
• Stil ve geleneklerin uygulanması (adlandırma, biçimlendirme, karmaşıklık ölçütleri)
• Yerel değişkenlerin yanlış kullanımı (Kullanılmayan değişkenler, tanımlanmamış referanslar, bariz tip hataları)
• Döngüsel karmaşıklık ve yöntem uzunluğutamamen fonksiyon içi metrikler

Bu kategorideki araçlar arasında ESLint, Pylint, Clippy (Rust), golangci-lint, Checkstyle ve çoğu linter yer almaktadır. Bunlar, tespit edebildikleri problem türleri için vazgeçilmez ve değerli araçlardır. Sınırlamaları yapısal olup, kalite eksikliğinden kaynaklanmamaktadır.

İşlemler Arası Analiz Nedir?

İşlemler arası (tüm programı kapsayan) analiz, genellikle en güçlü ve en çok kaynak tüketen analiz türüdür. İşlemler arası analiz, kontrol akış grafiklerini bir çağrı grafiğinden gelen fonksiyon çağrı ve dönüş kenarlarıyla zenginleştirir. Analiz, fonksiyon özetleri oluşturarak aynı fonksiyonları birçok kez tekrar ziyaret etmekten kaçınabilir.

İşlem içi analiz fonksiyon sınırlarında dururken, işlemler arası analiz bu sınırları aşar. Hangi fonksiyonların hangilerini çağırdığını gösteren bir çağrı grafiği oluşturur, ardından bu grafiğin kenarları boyunca veri akışını, kontrol akışını veya kirliliği izler. İşlemler arası bir araç bir fonksiyon çağrısıyla karşılaştığında, çağrıyı çağrılan fonksiyona kadar takip eder veya çağrılan fonksiyonun davranışının önceden hesaplanmış bir özetini kullanır ve analizi diğer tarafta sürdürür.

Yukarıdaki üç SQL enjeksiyon fonksiyonu basit bir örnektir. Gerçek prosedürler arası analiz şunları ele alır:

• Çoklu atlamalı veri akışı: Tehlikeli bir hedef noktasına ulaşmadan önce beş işlevden geçen güvenilmeyen girdi
• Dönüş değeri kirliliği: Bir fonksiyon hatalı veri döndürüyor; çağıranlar bu hatalı dönüş değerini güvenli olmayan işlemlerde kullanıyor.
• Alana duyarlı kirlilik: Bir nesne alanında saklanan ve daha sonra farklı bir fonksiyonda alınacak olan güvenilmeyen veriler.
• Koşullu yayılım: Kirlilik yalnızca belirli yürütme yolları boyunca akar; bu durum, analizin statik olarak modellemesi gereken çalışma zamanı koşullarına bağlıdır.

Java

// Interprocedural vulnerability: three-hop taint flow
public class UserController {
    public String handleRequest(HttpServletRequest request) {
        String userId = request.getParameter("id");    // source: untrusted input
        User user = userService.getUser(userId);       // taint flows through call
        return generateReport(user);                   // taint reaches sink
    }
}

public class UserService {
    public User getUser(String id) {
        // id is tainted -- passed to repository
        return userRepository.findByRawId(id);         // taint propagates
    }
}

public class UserRepository {
    public User findByRawId(String id) {
        String query = "SELECT * FROM users WHERE id = " + id;  // sink: SQL injection
        return db.execute(query);
    }
}

İşlem içi bir araç, inceleme UserRepository.findByRawId izole halde bir parametre görüyor id SQL sorgusuna birleştirilmiş. Bu potansiyel olarak güvensiz görünüyor, ancak araç bunun nerede olduğunu bilemez. id Verinin kaynağı, dahili koddan gelen güvenilir ve doğrulanmış bir değer olabilir. Bu nedenle, prosedür içi bir araç ya bunu olası bir sorun olarak işaretler (kod tabanındaki her parametreli ancak yapılandırılmış sorguda yanlış pozitifler üretir) ya da görmezden gelir (gerçek güvenlik açıklarında yanlış negatifler üretir). Prosedürler arası kirlilik analizi, güvenilmeyen verilerin fonksiyonlar aracılığıyla hassas işlemlere akıp akmadığını tespit eder. Verileri şuradan izler: request.getParameter("id") içinden userService.getUser(), Sayesinde userRepository.findByRawId()e db.execute(query)Bu sayede, kirlilik akış yolunun tam olarak belirlendiği, yanlış pozitif veya yanlış negatif sonuç vermeyen hassas bir bulgu elde edilir.

Analizin Üç Düzeyi: Pratik Bir Spektrum

Gerçek dünya statik analiz araçları, tamamen işlem içi olanlardan tamamen işlemler arası olanlara kadar uzanan bir yelpazede yer alır. Her aracın nerede konumlandığını anlamak, hem neyi bulduğunu hem de neyi gözden kaçırdığını açıklar.

Analiz Seviyesi	kapsam	Gördükleri	Neyi Eksik Bırakıyor?	Montaj Ekipmanı
Sözcüksel / sözdizimsel	Bireysel belirteçler ve sözdizimi	Biçimlendirme, adlandırma, temel sözdizimi	Her şey anlamsal	Daha güzel, rustfmt, gofmt
İşlem içi	Tek fonksiyon	Yerel veri akışı, karmaşıklık, fonksiyon içindeki kontrol akışı	Fonksiyonlar arası güvenlik açıkları, mimari sorunlar	ESLint, Pylint, Clippy, golangci-lint
Sığ işlem arası	Çağrı derinliğinin bir seviyesi	Doğrudan arayan-aranan ilişkileri	Derin çoklu atlama akışları	Bazı Semgrep kuralları, temel SAST kuralları
Tam prosedürler arası	Tam çağrı grafiği geçişi	Çoklu atlama kirlilik akışları, bağlam duyarlı analiz	Çalışma zamanı polimorfizmi (kısmi), yansıtıcı çağrılar	CodeQL, Facebook Infer, SMART TS XL
Bütün program / anlamsal	Programın tam anlamı	Resmi olarak ispatlanabilir özellikler	Çok büyük kod tabanlarında ölçeklenebilirlik	Infer, Kani (Rust), biçimsel doğrulama araçları

İşlemler arası analiz, nispeten yüksek potansiyel etkinliğe ve nispeten düşük potansiyel performansa sahiptir. Zengin program modeli sayesinde, yanlış negatif ve yanlış pozitif sonuçlara daha az eğilimlidir ve nispeten daha yüksek etkinliğe sahiptir. İşlemler arası analiz, performans sınırlaması nedeniyle geliştirici hızını düşürebileceğinden, CI/CD ortamları için en uygun yöntem değildir. Bu nedenle, işlemler arası analiz genellikle sunucu çiftliklerinde veya özel araçlarda çalışan özel bir hizmet olarak sunulmaktadır.

Prosedürler Arası Analiz Nasıl Çalışır: Üç Temel Yaklaşım

1. Özete Dayalı Analiz

Analiz, fonksiyon özetleri (bazen modeller olarak da adlandırılır) oluşturarak aynı fonksiyonları birçok kez tekrar ziyaret etmekten kaçınabilir. Bir özet, bir fonksiyonun davranışını kompakt bir biçimde yakalar: bu girdi kümesi ve bu kirlilik özellikleri verildiğinde, fonksiyon bu çıktı kümesini ve bu kirlilik özelliklerini üretir. Bir çağırıcı fonksiyonu çağırdığında, analiz fonksiyon gövdesini sıfırdan yeniden analiz etmek yerine özeti örneklendirir.

Özet tabanlı analiz, prosedürler arası analizi büyük ölçekte uygulanabilir kılan şeydir. Özetler olmadan, bir kütüphaneyi çağıran bir fonksiyonu analiz etmek, kütüphanenin çağırdığı her fonksiyon da dahil olmak üzere, kütüphanenin tamamını kaynak kodundan özyinelemeli olarak analiz etmeyi gerektirir. Özetlerle, kütüphane fonksiyonları bir kez önceden analiz edilir ve özetleri her çağrıda yeniden kullanılır.

2. Çağrı Dizisi Yaklaşımı (Bağlama Duyarlı Analiz)

Bağlama duyarlı analiz, aynı fonksiyonun farklı çağrı noktaları arasında ayrım yapar. Eğer sanitize(input) Bir yerde güvenilir verilerle, başka bir yerde güvenilmeyen verilerle yapılan çağrılarda, bağlama duyarlı analiz, tüm çağrı noktaları için en kötü senaryoyu varsaymak yerine, her çağrı noktası için farklı sonuçlar üretir. Bu, bağlama duyarsız analize kıyasla yanlış pozitifleri önemli ölçüde azaltır.

IFDS (Prosedürler Arası, Sonlu, Dağıtıcı, Alt Küme) çerçevesi bunu bir grafik erişilebilirlik problemi olarak biçimlendirir. IFDS çerçevesinde, kirlilik akışı sonlu bir olgular alanı üzerinde dağıtıcı fonksiyonlarla tanımlanır ve prosedürler arası yayılım grafik erişilebilirliğine indirgenir. Bu formülasyon, IFDS analizlerini hem hassas hem de algoritmik olarak verimli hale getirir; FlowDroid (Android için) ve çeşitli CodeQL sorguları gibi araçlar dahili olarak IFDS kullanır.

3. Çağrı Grafiği Oluşturma

Her prosedürler arası analiz bir çağrı grafiği gerektirir: düğümlerin fonksiyonları, kenarların ise çağrıları temsil ettiği yönlendirilmiş grafik. Çağrı grafiğinin kendisini oluşturmak zorlu kararlar almayı gerektirir:

Statik dağıtım (Java sanal olmayan çağrıları, C fonksiyon çağrıları, Python modül düzeyindeki çağrılar): modellemesi kolay, f() aramalar f.

Dinamik dağıtım (Java sanal metotları, Python duck-typed çağrıları): Belirli bir çağrı noktasında hangi metot uygulamalarının gerçekten çağrılabileceğini belirlemek için sınıf hiyerarşisi analizi (CHA) veya daha hassas çağrı grafiği oluşturma algoritmaları (RTA, VTA) gerektirir.

Yansımalı çağrılar ve fonksiyon işaretçileri : en zor durumlar. Araçlar ya aşırı yaklaşıklık yapmalıdır (herhangi bir eşleşen fonksiyonun çağrılabileceğini varsayarak yanlış pozitif sonuçlar üretir) ya da eksik yaklaşıklık yapmalıdır (bazı çağrı yollarını atlayarak yanlış negatif sonuçlar üretir).

Çağrı grafiğinin hassasiyeti, prosedürler arası analizin hassasiyetini doğrudan belirler. Çok fazla kenar içeren (aşırı yaklaştırma) bir çağrı grafiği yanlış pozitif sonuçlar üretirken, kenar içermeyen bir grafik yanlış negatif sonuçlar üretir.

İşlemler Arası Analizin, İşlem İçi Analizin Bulamadığı Bulguları Nelerdir?

Güvenlik Açıkları (Kirlilik Analizi)

OWASP Top 10 güvenlik açıklarının büyük çoğunluğunun güvenilir bir şekilde tespit edilebilmesi için prosedürler arası kirlilik analizine ihtiyaç duyulmaktadır:

• SQL enjeksiyonuGüvenilmeyen girdiler, birden fazla işlev aracılığıyla veritabanı sorgusuna akar.
• XSSGüvenilmeyen HTML, işleme fonksiyonlarından geçerek bir çıktı bağlamına akar.
• Komut enjeksiyonuKullanıcı tarafından kontrol edilen verilere ulaşılıyor. exec() or system() aracı fonksiyonlar aracılığıyla
• Yol geçişiKullanıcı girdisinden türetilen dosya yolları, dosya sistemi işlemlerine ulaşır.
• SSRFKullanıcı tarafından kontrol edilen URL'ler HTTP istemci çağrılarına yönlendirilir.

piton

# Intraprocedural tool: sees no issue in any individual function
# Interprocedural tool: traces the full taint path and reports SSRF

def get_target_url(request):
    return request.json().get("url")              # source: attacker-controlled

def fetch_resource(url):
    return requests.get(url)                      # sink: SSRF

def api_endpoint(request):
    target = get_target_url(request)
    data = fetch_resource(target)                 # full path: source -> sink
    return data

Boş İşaretçi ve Bellek Güvenliği Sorunları

Facebook Infer, null güvenlik analizi için standart prosedürler arası araçtır. Fonksiyonların ön koşullarını ve son koşullarını keşfetmek için prosedürler arası akıl yürütmenin bir biçimi olan çift yönlü çıkarımı kullanır ve ardından çağıranların bu ön koşulları karşılayıp karşılamadığını kontrol eder. Bir fonksiyonun belirli koşullar altında null döndürebileceğini bilmeyi gerektiren bir null referanssızlaştırma, prosedür içi araçlar için görünmezdir.

Java

// Intraprocedural tool: no issue in either function
// Infer: finds that processResult() can receive null from fetchData()

String fetchData(boolean condition) {
    if (condition) return getData();
    return null;                    // can return null
}

void processResult(String result) {
    System.out.println(result.length());  // NPE if result is null
}

void run() {
    String data = fetchData(false);   // passes false: fetchData returns null
    processResult(data);              // null dereference
}

Ücretsiz Kullanım Sonrası ve Kaynak Sızıntıları

C ve C++'da, kullanım sonrası serbest bırakma hataları sıklıkla bir fonksiyonda ayrılan ve başka bir fonksiyonda serbest bırakılan bellekle ilgilidir; üçüncü bir fonksiyon ise bu belleğe bir referans tutar. Tek bir fonksiyon analizi bu tür hataları tespit edemez. Fonksiyonlar arası analiz, kontrol akışı bütünlüğünü analiz eder: fonksiyon çağrılarının beklenen kalıpları izlediğinden emin olarak istismarları önler.

Mimari Bağlantı ve Bağımlılık İhlalleri

Güvenlik ve doğruluktan öte, prosedürler arası analiz, mimari analize de uygulanır: hangi bileşenler hangisini çağırır, hangi bağımlılıklar tanımlanmış katman sınırlarını ihlal eder ve hangi değişiklikler çağrı grafiği boyunca yayılır. Bu, prosedürler arası analizin, gibi araçların uygulama alanıdır. SMART TS XL Kurumsal kod tabanlarına uygulanabilir; bir fonksiyondaki değişikliğin tüm çağrı grafiği boyunca nasıl yayıldığını izleyerek gerçek etki kapsamını belirler.

İşlemler Arası Analize İhtiyaç Duyduğunuzda

Her proje tam kapsamlı prosedürler arası analiz gerektirmez. Karar, neyi bulmaya çalıştığınıza ve onu kaçırmanın maliyetine bağlıdır.

Aşağıdaki durumlarda prosedürler arası analize ihtiyacınız vardır:

• Güvenlik öncelikli bir konudur ve enjeksiyon, XSS veya SSRF güvenlik açıklarını güvenilir bir şekilde bulmanız gerekir.
• İş mantığının birçok fonksiyon ve modülü kapsadığı eski veya kurumsal bir kod tabanını analiz ediyorsunuz.
• Bir fonksiyonun yeniden yapılandırılmasından önce etki analizi yapmanız gerekir; bir fonksiyon değiştiğinde nelerin etkileneceğini anlamanız şarttır.
• Titizlik gerektiren uyumluluk veya denetim analizi yürütüyorsunuz.
• Bir kod tabanını taşıyorsunuz veya modernize ediyorsunuz ve bileşenler arası bağımlılıkları anlamanız gerekiyor.

İşlem içi analiz şu durumlarda yeterlidir:

• Amaç, stilin uygulanmasını, geleneklere uyulmasını ve bariz yerel hataların tespit edilmesini sağlamaktır.
• Geliştirme döngüsüne entegre edilmiş hızlı geri bildirimlere ihtiyacınız var (ön taahhüt, IDE, PR başına sürekli entegrasyon).
• Kod tabanı yeterince küçük olduğundan geliştiriciler tüm çağrı ilişkilerini biliyor.
• Güvenlik farklı bir katmanda (doğrulama çerçevesi, tip sistemi) sağlanır ve fonksiyonlar arası güvenlik açığı riski düşüktür.

Çoğu ekip için pratik cevap: ikisini de kullanın. İşlem içi araçlar (ESLint, Pylint, Clippy) hızlı geri bildirim için her commit'te çalışır. İşlemler arası araçlar (CodeQL, Infer, Semgrep ve taint kuralları) kapsamlı analiz için pull request'lerde veya gecelik bir programda çalışır. İki katman birbirini tamamlayıcıdır, rekabetçi değildir.

İşlemler Arası Analiz Araçları: Her Biri Neleri Kapsar?

araç	Analiz Yaklaşımı	Diller	Birincil Kullanım Örneği
KodQL	Tamamen prosedürler arası, IFDS tabanlı	C/C++, Java, JS/TS, Python, Go, Ruby	Güvenlik açığı tespiti
Facebook Çıkarımı	Çift taraflı kaçırma, işlem arası	Java, C, C++, Objective-C	Sıfır güvenliği, bellek sızıntıları, yarış koşulları
Semgrep (taint modu)	Yüzeysel işlem içi kirlenme	30+ dil	Veri akışıyla güvenlik modeli eşleştirme
Snyk Kodu	ML tabanlı prosedürler arası	Java, JS/TS, Python, C#	Geliştirici dostu geri bildirimle güvenlik
Polyspace	Soyut yorumlama	C, C++, Ada	Güvenlik açısından kritik, gömülü sistemler
Frama-Cı	Tam prosedürler arası + resmi	C	Resmi doğrulama, güvenlik sertifikası
SMART TS XL	Diller arası, sistemler arası	COBOL, JCL, Java, Python, RPG, SQL	Kurumsal etki analizi, bağımlılık haritalaması

Dil Sınırları Arasında Prosedürler Arası Analiz

Standart prosedürler arası araçlar tek bir dil içinde çalışır. Bir Java kod tabanındaki CodeQL sorgusu, Java fonksiyon çağrıları aracılığıyla kirliliği izler ancak Java kodu bir COBOL programını çağırdığında veya bir JCL toplu işi tarafından yazılan bir veri kümesinden okuma yaptığında durur. Bu sınır, kurumsal ölçekli analiz araçlarının tek dilli araçların ele alamayacağı bir sorunla karşılaştığı noktadır.

SMART TS XL'S statik kod analizi Kurumsal ortamdaki her dil arasında eş zamanlı olarak prosedürler arası bağımlılık analizi gerçekleştirir. Bir Java servisi, başka bir JCL işinin doldurduğu bir DB2 tablosundan okuyan bir COBOL programını çağırdığında, SMART TS XL Bu zinciri izler ve onu birleşik bir bağımlılık modeli olarak temsil eder. etki analizi Bu özellik daha sonra bu diller arası çağrı grafiğini kullanarak şu soruyu yanıtlar: Eğer bu COBOL programı değişirse, hangi Java servisleri, hangi JCL işleri ve hangi alt kademe tüketiciler etkilenir?

Bu, işlevsel ölçekten ziyade mimari ölçekte uygulanan prosedürler arası bir sorundur; aynı ilke (sınır noktalarında durmak yerine bağımlılık grafiğini sınırlar boyunca takip etmek), bireysel programlara değil, tüm kurumsal sisteme uygulanır. Kod görselleştirme ve bağımlılık haritalama bağlamında incelendiğinde , tam bağımlılık yapısını görünür kılmak, bir değişikliğin neyi etkileyeceğini anlamayı iddia eden herhangi bir analiz için ön koşuldur.

Faaliyet gösteren kuruluşlar için miras modernizasyonuçağrı grafiği SMART TS XL Diller arası bağlantılar, tek bir dil içindeki prosedürler arası çağrı grafiğiyle aynı amaca hizmet eder: her şeyin nasıl bağlandığının haritasıdır ve bu olmadan, etki, risk veya geçiş dizisine ilişkin herhangi bir analiz, kanıtlardan ziyade varsayımlara dayanır.

Yanlış Pozitif ve Yanlış Negatif Arasındaki Denge

İşlemler arası analizin her yerde kullanılmamasının nedeni, kimsenin bunu düşünmemiş olması değil, hassasiyet ve performansın birbiriyle çelişmesidir. Bir milyon satırlık bir kod tabanının tam bağlam duyarlı işlemler arası analizi saatler veya günler sürebilir. Aynı kod tabanı ESLint tarafından saniyeler içinde analiz edilir. Bu performans farkı yapısaldır: işlemler arası analiz, yalnızca kod tabanının boyutuyla değil, çağrı grafiğinin karmaşıklığıyla da artar.

Yatırımın faydası, ölçülebilir derecede düşük yanlış pozitif ve yanlış negatif oranlarıdır:

• Yanlış pozitifler (Bir şeyin yanlış olduğunu iddia eden ancak aslında yanlış olmayan araçlar): İşlem içi araçlar, arayanlardan gelen bağlamı bilmeden şüpheli bir desenin gerçekten tehlikeli olup olmadığını belirleyemedikleri için çok daha fazla yanlış pozitif sonuç üretirler. Birleştirilmiş bir dize içeren bir SQL sorgusu gören işlem içi bir araç, dizenin kullanıcı girdisinden mi yoksa güvenilir bir iç kaynaktan mı geldiğini bilemez.
• Yanlış negatifler (Gerçek güvenlik açıklarını tespit edemeyen araçlar): İşlem içi araçlar, fonksiyon sınırlarını aşan güvenlik açıklarını tespit edemedikleri için çok daha fazla yanlış negatif sonuç üretirler; bu da güvenlik açısından önemli analizler için gerçek güvenlik açıklarının büyük çoğunluğunu oluşturur.

Her analiz düzeyini ne zaman kullanacağınızı seçme ve her ikisini de katmanlı bir araç zincirinde birleştirme disiplini, güvenlik mühendisliğini sadece onay kutusu uyumluluğundan ayıran şeydir. Linter'ınızın temiz sonuçlar verdiğini bilmek, güvenlik durumunuz hakkında size çok az şey söyler. Ancak, prosedürler arası kirlilik analizinizin, harici girdi kaynaklarından uygulamanızdaki hassas hedeflere giden her yolu izlediğini ve doğrulanmamış bir akış bulamadığını bilmek, size çok daha fazla bilgi verir.