Statyczna analiza kodu w celu zapewnienia bezpieczeństwa: jak SAST radzi sobie z 10 największymi lukami w zabezpieczeniach OWASP

Lukom w zabezpieczeniach łatwiej zapobiegać niż je naprawiać. Błąd typu SQL injection wykryty podczas przeglądu kodu zajmuje kilka minut. Ten sam błąd wykryty po naruszeniu bezpieczeństwa wymaga tygodni reakcji na incydent, dochodzenia regulacyjnego i działań naprawczych, a także wszelkich danych, które zostały w międzyczasie wykradzione. Statyczna analiza kodu to dyscyplina polegająca na wykrywaniu tych problemów przed uruchomieniem kodu, poprzez badanie struktury kodu źródłowego, przepływu danych i wzorców pod kątem znanych sygnatur luk. Stosowana systematycznie, przekształca ona bezpieczeństwo z praktyki reaktywnej w wbudowaną właściwość procesu programistycznego.

Lista OWASP Top 10 to autorytatywny katalog najpoważniejszych zagrożeń bezpieczeństwa aplikacji internetowych, aktualizowany przez Open Web Application Security Project w oparciu o rzeczywiste dane o podatnościach w tysiącach aplikacji. Każdy element na liście jest wykrywalny, w różnym stopniu, przez narzędzia do analizy statycznej. Niniejszy przewodnik mapuje każdą kategorię OWASP na to, co można znaleźć za pomocą analizy statycznej, przedstawia podatny na ataki wzorzec kodu i jego bezpieczny odpowiednik oraz wyjaśnia, które narzędzia stosują każdą z technik.

Czym jest statyczne testowanie bezpieczeństwa aplikacji (SAST)?

Statyczne testy bezpieczeństwa aplikacji (SAST) analizują kod źródłowy, kod bajtowy lub binarny bez uruchamiania programu. Analiza bada przepływ danych przez aplikację, do których wrażliwych pod względem bezpieczeństwa operacji dane te docierają oraz czy jakakolwiek ścieżka z zewnętrznego źródła danych (dane wejściowe użytkownika, parametry HTTP, zawartość pliku, zmienne środowiskowe) prowadzi do niebezpiecznej operacji (zapytanie do bazy danych, polecenie systemowe, dane wyjściowe HTML, funkcja kryptograficzna) bez odpowiedniej walidacji lub oczyszczania.

SAST to jedna warstwa kompleksowego programu bezpieczeństwa aplikacji. Aby zrozumieć, gdzie się znajduje, należy porównać ją z alternatywami:

Podejście	Kiedy to działa	Co znajduje	Czego mu brakuje
SAST (statyczny)	Przed wykonaniem, w kodzie źródłowym	Luki na poziomie kodu, wzorce wstrzyknięć, nadużycia kryptograficzne, zakodowane na stałe sekrety	Luki w zabezpieczeniach występujące tylko w czasie wykonywania, problemy z konfiguracją podczas wdrażania
DAST (dynamiczny)	Przeciwko działającej aplikacji	Zachowanie w czasie wykonywania, błędy uwierzytelniania, problemy z konfiguracją serwera	Wzorce na poziomie kodu nie zostały wyzwolone podczas testowania
SCA (Analiza składu oprogramowania)	W zależności się manifestuje	Znane CVE w bibliotekach innych firm	Luki w kodzie niestandardowym
IAST (interaktywny)	Podczas wykonywania testu z użyciem instrumentów	Przepływy danych w czasie wykonywania z wysoką dokładnością	Wymaga uruchomienia aplikacji, wolniejsze sprzężenie zwrotne

SAST zapewnia najwcześniejszą informację zwrotną, działając na kodzie, który nie został jeszcze wdrożony, w procesie CI/CD, a nawet w środowisku IDE, zanim luka w zabezpieczeniach dotrze do środowiska testowego. Ta wczesna dostępność stanowi jego podstawową wartość bezpieczeństwa.

Jakie rodzaje zagrożeń można ograniczyć za pomocą statycznej analizy kodu?

To jedno z najczęściej wyszukiwanych pytań dotyczących SAST. Odpowiedź bezpośrednia:

Statyczna analiza kodu może łagodzić zagrożenia, które manifestują się we wzorcach kodu źródłowego : luki w zabezpieczeniach (SQL, polecenia, XSS), nadużycia kryptograficzne, zakodowane na stałe dane uwierzytelniające, niepewne implementacje uwierzytelniania, wadliwa kontrola dostępu w logice kodu oraz błędy integralności danych. Nie jest ona jednak w stanie łagodzić zagrożeń wynikających z konfiguracji środowiska wykonawczego, topologii sieci ani konfiguracji infrastruktury, które wymagają DAST, testów penetracyjnych lub skanowania bezpieczeństwa infrastruktury.

Analiza statyczna a analiza dynamiczna w kontekście OWASP

Analiza dynamiczna (DAST) i analiza statyczna (SAST) wykrywają różne podzbiory luk w zabezpieczeniach OWASP. Żadna z nich nie obejmuje wszystkich luk. OWASP Web Security Testing Guide (WSTG) to metodologia testowania dynamicznego; narzędzia SAST, takie jak CodeQL, Semgrep i SonarQube, odnoszą się do warstwy kodu źródłowego.

Kategoria OWASP Top 10	Zasięg SAST	Zasięg DAST
Uszkodzona kontrola dostępu	Częściowe luki w logice kodu	Dobre, testowanie zachowania w czasie wykonywania
Awarie kryptograficzne	Silne wykrywanie algorytmiczne	Słaby, trudny do zaobserwowania z zewnątrz
Wtrysk	Silna analiza skażeń	Mocne, aktywne testy ładunku
Niebezpieczny projekt	Częściowe wykrywanie wzorców	Słaby, wymaga wiedzy projektowej
Błędna konfiguracja zabezpieczeń	Częściowa konfiguracja w kodzie	Mocne testy w warunkach rzeczywistych
Wrażliwe komponenty	Słaby, SCA jest lepszy	Słaby, SCA jest lepszy
Niepowodzenia uwierzytelniania	Częściowe, zakodowane na stałe dane uwierzytelniające, słabe wzorce	Silne testy sesji i uwierzytelniania
Błędy integralności danych	Częściowe wzorce deserializacji	Słaby, trudny do wykrycia z zewnątrz
Rejestrowanie błędów	Częściowe, brakujące oświadczenia dziennika	Słaba, trudna do zaobserwowania nieobecność
SSRF	Silne, zanieczyszczające wywołanie HTTP	Silne, aktywne testowanie żądań

Wniosek: SAST i DAST uzupełniają się. Aby uzyskać maksymalny zasięg OWASP, należy uruchomić oba. W przypadku zespołów z ograniczonym budżetem, zaczynających od zera, należy najpierw uruchomić SAST – zapewnia on najszybszą informację zwrotną od programistów i najszerszy zasięg wstrzyknięć.

OWASP Top 10: Co odkrywa analiza statyczna i jak

A01, Złamana kontrola dostępu

Złamana kontrola dostępu to największe ryzyko OWASP. Analiza statyczna uwzględnia przejawy na poziomie kodu: brak kontroli autoryzacji funkcji i punktów końcowych, odwołania do obiektów, które ujawniają wewnętrzne identyfikatory bez walidacji, oraz zakodowane na stałe przypisania ról, które omijają zamierzone struktury uprawnień.

Co wykrywa analiza statyczna: Metody obsługujące wrażliwe operacje bez odpowiadającego im sprawdzania autoryzacji; bezpośrednie odwołania do obiektów, w których identyfikator obiektu pochodzi z danych wprowadzonych przez użytkownika bez sprawdzania dostępu; wzorce wymuszonego przeglądania, w których sprawdzany jest stan uwierzytelnienia, ale własność obiektu nie.

Jawa

// Vulnerable: no ownership check -- any authenticated user can access any order
@GetMapping("/orders/{orderId}")
public Order getOrder(@PathVariable Long orderId) {
    return orderRepository.findById(orderId).orElseThrow();
}

// Secure: verify the order belongs to the requesting user
@GetMapping("/orders/{orderId}")
public Order getOrder(@PathVariable Long orderId,
                      @AuthenticationPrincipal UserDetails user) {
    Order order = orderRepository.findById(orderId).orElseThrow();
    if (!order.getOwnerId().equals(user.getUserId())) {
        throw new AccessDeniedException("Order does not belong to requesting user");
    }
    return order;
}

Czego nie wykryje analiza statyczna: Błędy kontroli dostępu w czasie wykonywania, w których logika jest poprawna, ale dane wykorzystywane do podjęcia decyzji są zagrożone. W takich przypadkach niezbędne są testy DAST i testy penetracyjne.

A02, Awarie kryptograficzne

Słabe szyfrowanie można niezawodnie wykryć za pomocą analizy statycznej, ponieważ podatne wzorce, takie jak MD5, SHA-1, DES, tryb ECB i zakodowane na stałe klucze, można zidentyfikować leksykalnie w kodzie źródłowym.

pyton

# Vulnerable: MD5 for password hashing (broken algorithm)
import hashlib
password_hash = hashlib.md5(password.encode()).hexdigest()

# Vulnerable: hardcoded encryption key
KEY = b"mysecretkey12345"
cipher = AES.new(KEY, AES.MODE_ECB)  # ECB mode also vulnerable

# Secure: bcrypt for passwords, environment-sourced keys
import bcrypt, os
password_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

# Secure: AES-GCM with environment-sourced key
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
key = os.environ["ENCRYPTION_KEY"].encode()
aesgcm = AESGCM(key)

Flaga reguł analizy statycznej: MD5/SHA-1 dla celów bezpieczeństwa, tryb DES/3DES/RC4/ECB, zakodowane na stałe klucze kryptograficzne i sekrety, HTTP zamiast HTTPS do przesyłania danych wrażliwych oraz wyłączona weryfikacja certyfikatu (verify=False w żądaniach Pythona, setHostnameVerifier(ALLOW_ALL_HOSTNAME_VERIFIER) w Javie).

A03, Wtrysk

Wstrzyknięcie, SQL, polecenie systemu operacyjnego, LDAP, XSS, wstrzykiwanie szablonów to kategoria, w której międzyproceduralna analiza skażeń przynosi największe korzyści. Luka wymaga śledzenia niezaufanych danych wejściowych od źródła poprzez wywołania funkcji do niebezpiecznego ujścia.

javascript

// Vulnerable: direct string interpolation in SQL (SQL injection)
app.get('/users', async (req, res) => {
    const name = req.query.name;
    const result = await db.query(`SELECT * FROM users WHERE name = '${name}'`);
    res.json(result.rows);
});

// Secure: parameterized query
app.get('/users', async (req, res) => {
    const name = req.query.name;
    const result = await db.query('SELECT * FROM users WHERE name = $1', [name]);
    res.json(result.rows);
});

php

// Vulnerable: unescaped output (XSS)
echo "Welcome, " . $_GET['username'];

// Secure: context-appropriate escaping
echo "Welcome, " . htmlspecialchars($_GET['username'], ENT_QUOTES, 'UTF-8');

csharp

// Vulnerable: command injection in C#
var process = new Process();
process.StartInfo.FileName = "cmd.exe";
process.StartInfo.Arguments = "/c " + userInput;
process.Start();

// Secure: avoid shell interpretation, validate and whitelist inputs
var allowedCommands = new HashSet<string> { "report", "export" };
if (!allowedCommands.Contains(userInput))
    throw new ArgumentException("Invalid command");

Narzędzia wykonujące międzyproceduralną analizę skażeń pod kątem wstrzyknięć: CodeQL (najbardziej precyzyjny), Semgrep z trybem skażenia, Snyk Code, SonarQube z regułami bezpieczeństwa.

A04, Niebezpieczny projekt

Niezabezpieczony projekt to najtrudniejsza kategoria OWASP do analizy statycznej, ponieważ dotyczy decyzji architektonicznych, a nie wzorców kodu. Analiza statyczna może sygnalizować następujące symptomy:

Brak logiki ograniczającej przepustowość w punktach końcowych uwierzytelniania, brak blokady konta po nieudanych próbach, logika biznesowa pomijająca kroki walidacji oraz funkcje wykonujące operacje uprzywilejowane bez rejestrowania audytu. Można je wykryć jako brakujące wzorce, a analiza statyczna raportuje to, czego brakuje, a nie to, co jest obecne.

Niektóre narzędzia SAST obsługują niestandardowe reguły, które mogą kodować wymagania projektowe dotyczące bezpieczeństwa organizacji: każda metoda kontrolera musi wywołać funkcję autoryzacji, każdy zapis do bazy danych musi być poprzedzony walidacją danych wejściowych, a każde wywołanie zewnętrznego interfejsu API musi korzystać z limitu czasu. Te niestandardowe reguły przekształcają wymagania projektowe w egzekwowalne ograniczenia kodu.

A05, Nieprawidłowa konfiguracja zabezpieczeń

Nieprawidłowa konfiguracja zabezpieczeń w kodzie obejmuje: wyłączone funkcje zabezpieczeń, dozwolone nagłówki CORS, brakujące nagłówki odpowiedzi zabezpieczeń, włączony tryb debugowania w środowisku produkcyjnym oraz rozbudowane komunikaty o błędach ujawniające ślady stosu.

pyton

# Vulnerable: Flask debug mode enables interactive debugger in production
app = Flask(__name__)
app.run(debug=True)  # exposes console access if error occurs

# Vulnerable: overly permissive CORS
from flask_cors import CORS
CORS(app, origins="*")  # allows any origin

# Secure: environment-controlled debug, restricted CORS
import os
debug_mode = os.environ.get("FLASK_DEBUG", "false").lower() == "true"
CORS(app, origins=os.environ.get("ALLOWED_ORIGINS", "").split(","))
app.run(debug=debug_mode)

Flaga reguł analizy statycznej: tryb debugowania ustawiony na True w źródle, symbole wieloznaczne CORS, brakujące nagłówki zabezpieczeń w konfiguracjach odpowiedzi HTTP, wyłączona weryfikacja certyfikatu SSL i domyślne poświadczenia w plikach konfiguracyjnych.

A06, Komponenty podatne na ataki i przestarzałe

Do tej kategorii odnosi się przede wszystkim analiza składu oprogramowania (SCA), a nie tradycyjne skanowanie SAST. package.json, pom.xml, requirements.txti podobne manifesty przeciwko bazom danych podatności (National Vulnerability Database, GitHub Advisory Database).

SAST przyczynia się do poprawy bezpieczeństwa poprzez identyfikację przestarzałych sposobów korzystania z interfejsu API, wywołań funkcji bibliotecznych, które zostały zastąpione z powodu luk w zabezpieczeniach, lub bezpośredniego użycia podatnych na ataki wzorców, których nawet najnowsze biblioteki nie zalecają już.

Narzędzia specjalnie dla A06: npm audit, pip-audit, snyk test, OWASP Dependency-Check, GitHub Dependabot i Mend (dawniej WhiteSource).

A07, Błędy identyfikacji i uwierzytelniania

Analiza statyczna pozwala wykryć antywzorce uwierzytelniania na poziomie kodu: hasła zakodowane na stałe, słabą walidację haseł, tokeny sesji generowane z losowością niekryptograficzną, brak unieważnienia sesji przy wylogowywaniu oraz implementacje JWT akceptujące none algorytm.

javascript

// Vulnerable: JWT accepting 'none' algorithm -- allows signature bypass
const decoded = jwt.verify(token, secret, { algorithms: ['HS256', 'none'] });

// Vulnerable: hardcoded admin credentials
if (username === 'admin' && password === 'admin123') {
    grantAccess();
}

// Secure: algorithm whitelist, no hardcoded credentials
const decoded = jwt.verify(token, process.env.JWT_SECRET, {
    algorithms: ['HS256']  // explicit allowlist only
});

csharp

// Vulnerable: weak random for session token generation in C#
var sessionToken = new Random().Next().ToString();

// Secure: cryptographically secure random
using var rng = RandomNumberGenerator.Create();
var bytes = new byte[32];
rng.GetBytes(bytes);
var sessionToken = Convert.ToBase64String(bytes);

A08, Awarie oprogramowania i integralności danych

Ta kategoria obejmuje niebezpieczną deserializację i niezweryfikowane aktualizacje oprogramowania. Analiza statyczna wykrywa: Java ObjectInputStream deserializacja danych z niezaufanych źródeł, Python pickle.loads() na danych zewnętrznych, PHP unserialize() z danymi wprowadzanymi przez użytkownika oraz parserami YAML korzystającymi z niebezpiecznych ładowarek.

pyton

# Vulnerable: pickle deserialization of untrusted data
import pickle
data = pickle.loads(request.data)  # arbitrary code execution risk

# Vulnerable: unsafe YAML loader
import yaml
config = yaml.load(user_input)  # yaml.load without Loader is unsafe

# Secure: safe alternatives
import json
data = json.loads(request.data)  # JSON cannot execute code

import yaml
config = yaml.safe_load(user_input)  # safe_load disables arbitrary object creation

A09, Awarie rejestrowania i monitorowania zabezpieczeń

Błędy rejestrowania są wykrywane przez analizę statyczną jako brakujące wzorce: operacje wrażliwe, zdarzenia uwierzytelniania, decyzje kontroli dostępu, modyfikacje danych, które są realizowane bez towarzyszących im instrukcji rejestrowania. Reguły analizy statycznej mogą wymagać, aby określone wywołania funkcji zawsze występowały jednocześnie z wywołaniami rejestrowania audytu.

Jakie flagi wykrywa analiza statyczna: rejestrowanie haseł lub tokenów (rejestrowanie poufnych danych również stanowi lukę w zabezpieczeniach), obsługa wyjątków, która po cichu przechwytuje błędy bez rejestrowania, oraz bloki catch, które rejestrują surowy komunikat wyjątku (mogący zawierać poufne dane).

Jawa

// Vulnerable: swallowed exception, no logging
try {
    authenticateUser(username, password);
} catch (Exception e) {
    // silent failure -- no log, no audit trail
}

// Vulnerable: logging sensitive data
log.info("User logged in with password: " + password);

// Secure: log the event, not the credential
try {
    authenticateUser(username, password);
    auditLog.info("Authentication success for user: {}", username);
} catch (AuthenticationException e) {
    auditLog.warn("Authentication failure for user: {}", username);
    throw e;  // do not swallow
}

A10, Fałszowanie żądań po stronie serwera (SSRF)

SSRF stanowi silny argument za międzyproceduralną analizą skażeń. Luka wymaga śledzenia danych wprowadzanych przez użytkownika aż do żądania HTTP, często poprzez wiele wywołań funkcji. Narzędzie analizujące tylko pojedyncze funkcje nie jest w stanie wykryć SSRF, gdy konstrukcja adresu URL i wywołanie HTTP znajdują się w różnych funkcjach.

pyton

# Vulnerable: user-controlled URL in HTTP request (SSRF)
import requests

def fetch_resource(url):
    return requests.get(url).content  # no validation

def api_endpoint(request):
    target = request.json().get("url")    # attacker controls this
    return fetch_resource(target)          # SSRF across function boundary

# Secure: allowlist validation before making the request
from urllib.parse import urlparse

ALLOWED_HOSTS = {"api.internal.example.com", "cdn.example.com"}

def fetch_resource(url: str) -> bytes:
    parsed = urlparse(url)
    if parsed.hostname not in ALLOWED_HOSTS:
        raise ValueError(f"URL host not allowed: {parsed.hostname}")
    return requests.get(url, timeout=5).content

Narzędzia do analizy kodu statycznego dla bezpieczeństwa OWASP

Poniższa tabela przedstawia mapowanie głównych narzędzi SAST na kategorie OWASP, które są przez nie najskuteczniej obsługiwane:

Narzędzie	Języki podstawowe	Mocne strony OWASP	Podejście
KodQL	Java, JS/TS, Python, C/C++, Go, Ruby	Wtrysk A03, A10 SSRF (głębokie skażenie)	Analiza semantyczna międzyproceduralna
Semgrep	30+ języków	A03, A02, A07 (tryb wzorca + skażenia)	Dopasowywanie wzorców + płytkie skazy
Kod Snyka	Java, JS/TS, Python, C#	A03, A07, A08	Analiza skażeń oparta na uczeniu maszynowym
SoundQube	30+ języków	A02, A03, A05, A07, A09	Regułowy + przepływ danych
Sprawdźmarks	30+ języków	Pełne pokrycie OWASP	Zanieczyszczenie międzyproceduralne
Verakod	Java, .NET, JS, PHP	Pełne pokrycie OWASP	Analiza kodu bajtowego i skażenia
OWASP ZAP	Niezależny od języka	A01, A05, A07 (czas wykonania)	DAST, testowanie dynamiczne
SMART TS XL	COBOL, JCL, Java, Python, RPG, SQL	Zakażenie międzyjęzykowe, ryzyko uzależnienia	Struktura międzyjęzykowa + skaza

W jaki sposób SMART TS XL Zajmuje się bezpieczeństwem w bazach kodu przedsiębiorstw

Programy bezpieczeństwa przedsiębiorstw stoją przed wyzwaniem, którego nie są w stanie rozwiązać jednojęzyczne narzędzia SAST: powierzchnia ataku obejmuje wiele języków. Aplikacja internetowa może przyjmować dane wejściowe użytkownika w JavaScript, przetwarzać je w Javie, a następnie przekazywać przez kolejkę komunikatów do programu COBOL, który wykonuje kod SQL w bazie danych DB2. Luka w zabezpieczeniach związana z wstrzykiwaniem ataków występuje na granicy czterech języków. Żaden skaner języka nie jest w stanie zobaczyć całej ścieżki skażenia.

SMART TS XL'S statyczna analiza kodu obejmuje jednocześnie wszystkie języki w tym łańcuchu. Gdy niezaufane dane wejściowe przepływają z modułu obsługi API JavaScript przez usługę Java do programu COBOL, który konstruuje dynamiczne zapytanie SQL, SMART TS XL śledzi ścieżkę przez cały wykres wywołań międzyjęzykowych, to samo międzyproceduralne śledzenie skażeń, które CodeQL stosuje w Javie, stosowane łącznie w Javie, COBOL i SQL.

Funkcja mapowania zależności aplikacji zapewnia istotny z punktu widzenia bezpieczeństwa widok, który pokazuje, które komponenty systemu wchodzą w interakcje z danymi wejściowymi z zewnątrz, które z nich docierają do operacji uprzywilejowanych, oraz jak faktycznie wygląda cała powierzchnia ataku systemu. Ten architektoniczny widok bezpieczeństwa stanowi podstawę modelowania zagrożeń – nie da się modelować zagrożeń dla systemu, którego struktury się nie rozumie.

Funkcja analizy wpływu służy programom naprawy bezpieczeństwa: gdy w komponencie zostanie wykryta luka w zabezpieczeniach, analiza wpływu identyfikuje wszystkie pozostałe komponenty zależne od podatnego komponentu, precyzyjnie określając zakres działań naprawczych przed wprowadzeniem jakichkolwiek zmian w kodzie. W przypadku dużych, starszych baz kodu, gdzie program COBOL z luką w zabezpieczeniach jest uwzględniany w setkach innych programów, znajomość pełnego zakresu działań naprawczych przed ich rozpoczęciem stanowi różnicę między zarządzaną poprawką a incydentem kaskadowym.

Dla organizacji zarządzających modernizacja dziedziczna W przypadku programów analiza bezpieczeństwa starszej bazy kodu jest warunkiem wstępnym, a nie dodatkiem. Migracja podatnych programów COBOL do Javy powoduje powstawanie podatnych na ataki programów Java. SMART TS XLAnaliza bezpieczeństwa firmy gwarantuje, że luki zostaną zidentyfikowane i naprawione w ramach procesu modernizacji, a nie odkryte w migrowanym systemie.

Integracja SAST z cyklem życia rozwoju

Statyczna analiza bezpieczeństwa przynosi największe korzyści, gdy jest przeprowadzana w momencie podejmowania decyzji, gdy kod jest pisany i sprawdzany, a nie po jego wdrożeniu.

W IDE: SonarLint, rozszerzenia IDE Snyk i rozszerzenie VS CodeQL ujawniają wyniki w trakcie pisania kodu przez programistów. Flaga SQL injection, która pojawia się w momencie, gdy programista wpisze podatny wzorzec, kosztuje sekundy, aby ją naprawić.

W przypadku żądań ściągnięcia: SAST zintegrowany z GitHub Actions, GitLab CI lub Jenkinsem uruchamia się przy każdym żądaniu ściągnięcia i publikuje wyniki w postaci komentarzy do przeglądu kodu. Programista widzi wynik w kontekście, obok kodu, który go spowodował.

Jako bramka jakości: Model bramki jakości SonarQube blokuje scalanie w przypadku wprowadzenia nowych, krytycznych punktów bezpieczeństwa. Dzięki temu bezpieczeństwo nie jest opcjonalnym etapem przeglądu, lecz wymogiem strukturalnym procesu scalania.

Zgodnie z harmonogramem: Głęboka analiza międzyproceduralna, CodeQL, Checkmarx, pełne zestawy reguł Semgrep jest zazwyczaj zbyt wolna do wykonywania poszczególnych zatwierdzeń, ale jest uruchamiana co noc lub co tydzień na gałęzi głównej, wykrywając luki w zabezpieczeniach, których wykrycie wymaga pełnej analizy grafu wywołań.

Warstwowe podejście, szybkie reguły oparte na wzorcach w środowisku IDE i zatwierdzeniach, dogłębna analiza zanieczyszczeń w żądaniach ściągnięcia i w trybie nocnym zapewniają zarówno natychmiastowość potrzebną programistom, jak i dokładność wymaganą przez programy zabezpieczające.