Directory Traversal: A HTTP sebezhetőség jelentése és a támadás működése

A modern webalkalmazások világában a Directory Traversal sebezhetőség olyan komoly biztonsági rést jelent, amely lehetővé teszi a támadók számára, hogy jogosulatlanul hozzáférjenek a szerver fájlrendszeréhez. Ez a támadási módszer alapvetően kihasználja a webszerverek és alkalmazások hiányos input validációját, amikor a felhasználói bemeneteket dolgozzák fel.

Minden webfejlesztőnek és rendszergazdának szembe kell néznie azzal a ténnyel, hogy az alkalmazások biztonsága csak olyan erős, mint a leggyengébb láncszem. A Directory Traversal támadások éppen ezt a gyenge pontot célozzák meg, amikor a fejlesztők nem megfelelően szűrik vagy validálják a bejövő kéréseket. A probléma súlyosságát jelzi, hogy az OWASP Top 10 listáján is szerepel, mint az egyik leggyakoribb webes sebezhetőség.

Az alábbi részletes elemzés bemutatja a Directory Traversal támadások minden aspektusát – a technikai háttértől kezdve a gyakorlati védekezési stratégiákig. Megismerheted a különböző támadási technikákat, a sebezhetőségek felderítési módszereit, valamint azokat a konkrét lépéseket, amelyekkel hatékonyan védekezhetsz ezen fenyegetések ellen.

Mi a Directory Traversal sebezhetőség?

A Directory Traversal (más néven Path Traversal vagy Dot-Dot-Slash támadás) egy olyan webes sebezhetőség, amely lehetővé teszi a támadók számára, hogy a webszerver gyökérkönyvtárán kívüli fájlokhoz és mappákhoz férjenek hozzá. Ez a biztonsági rés akkor keletkezik, amikor egy webalkalmazás nem megfelelően validálja a felhasználói bemeneteket, különösen a fájlútvonalakat.

A sebezhetőség lényege abban rejlik, hogy a támadók speciális karakterszekvenciákat használnak – mint például a ../ vagy ..\ – hogy "feljebb navigáljanak" a könyvtárstruktúrában. Ezzel megkerülhetik az alkalmazás által beállított korlátozásokat és hozzáférhetnek olyan fájlokhoz, amelyekhez normál körülmények között nem lenne jogosultságuk.

A Directory Traversal támadások különösen veszélyesek, mert lehetővé teszik érzékeny rendszerfájlok olvasását, konfigurációs fájlok megszerzését, vagy akár forráskód ellopását. Gyakran ez a kiindulópont más, súlyosabb támadásokhoz.

A támadás működési mechanizmusa

Alapvető működési elv

A Directory Traversal támadások alapja a relatív fájlútvonalak manipulálása. Amikor egy webalkalmazás fájlokat szolgál ki vagy dolgoz fel, gyakran használja a felhasználó által megadott paramétereket az útvonal összeállításához. Ha ezt nem megfelelően validálják, a támadó képes lehet kilépni a tervezett könyvtárból.

Egy tipikus sebezhető alkalmazás például így működhet:

http://example.com/download.php?file=document.pdf

A szerver ezt így dolgozza fel:

/var/www/html/files/ + document.pdf

Tipikus támadási szekvenciák

A támadók különféle technikákat alkalmaznak a könyvtárstruktúra megkerülésére:

• Egyszerű dot-dot-slash: ../../../etc/passwd
• URL kódolt változatok: %2e%2e%2f (../)
• Double URL encoding: %252e%252e%252f
• Unicode kódolás: ..%c0%af vagy ..%ef%bc%8f
• Mixed encoding: ..%2f vagy .%2e/

Ezek a szekvenciák mind ugyanazt a célt szolgálják: feljebb navigálni a könyvtárstruktúrában, hogy elérjék a tiltott területeket.

Támadási célpontok

A Directory Traversal támadások leggyakoribb célpontjai:

• Rendszerfájlok: /etc/passwd, /etc/shadow, C:\Windows\System32\drivers\etc\hosts
• Konfigurációs fájlok: .htaccess, web.config, config.php
• Log fájlok: access.log, error.log, alkalmazás-specifikus naplók
• Backup fájlok: .bak, .old, .backup kiterjesztésű fájlok
• Forráskód: .php, .jsp, .asp fájlok
• Adatbázis fájlok: SQLite, Access adatbázisok

Hogyan működik a gyakorlatban a Directory Traversal támadás?

Felderítési fázis

A támadók először megpróbálják azonosítani a potenciálisan sebezhető paramétereket. Keresik azokat a funkciókat, amelyek fájlneveket vagy útvonalakat fogadnak el bemeneti paraméterként.

Gyakori sebezhető funkciók:

• Fájl letöltési lehetőségek
• Kép megjelenítő scriptek
• Sablon betöltő rendszerek
• Include/require műveletek
• Fájl feltöltési funkciók

Tesztelési módszerek

A támadók különböző payload-okat próbálnak ki, hogy megállapítsák a sebezhetőség meglétét:

1. Alapvető tesztek: ../, ..\\, ....//
2. Kódolt változatok: %2e%2e%2f, %2e%2e%5c
3. Hosszú láncolatok: ../../../../../../../etc/passwd
4. OS-specifikus tesztek: Windows és Linux specifikus útvonalak

Operációs rendszer	Tipikus célpontok	Szeparátor
Linux/Unix	/etc/passwd, /etc/shadow, /var/log/	/
Windows	C:\Windows\System32\config\SAM, C:\boot.ini	\ vagy /

Automatizált eszközök

A támadók gyakran használnak automatizált eszközöket a sebezhetőségek felderítésére:

• Burp Suite: Professional web security testing platform
• OWASP ZAP: Ingyenes biztonsági tesztelő eszköz
• Nikto: Web server scanner
• DirBuster: Directory and file brute forcer
• Custom scriptek: Python, Bash alapú automatizált tesztelők

Milyen károkat okozhat a Directory Traversal?

Információ kiszivárgás

A Directory Traversal támadások leggyakoribb következménye az érzékeny információk kiszivárgása. A támadók hozzáférhetnek olyan fájlokhoz, amelyek kritikus adatokat tartalmaznak.

"A Directory Traversal sebezhetőségek gyakran szolgálnak kiindulópontként összetettebb támadásláncokhoz, ahol az első lépés mindig az információgyűjtés."

Tipikus kiszivárgó információk:

• Felhasználói hitelesítő adatok
• Adatbázis kapcsolódási stringek
• API kulcsok és tokenek
• Üzleti logika és forráskód
• Rendszerkonfigurációk

Rendszerszintű hozzáférés

Súlyosabb esetekben a Directory Traversal vezethet teljes rendszerszintű kompromittálódáshoz. Ha a támadó hozzáfér olyan fájlokhoz, amelyek további sebezhetőségeket tárnak fel, vagy végrehajtható kódot tartalmaznak.

Adatvédelmi következmények

A GDPR és más adatvédelmi szabályozások értelmében a Directory Traversal támadások komoly jogi következményekkel járhatnak:

• Jelentős pénzbírságok
• Jogi felelősségre vonás
• Reputációs károk
• Ügyfélbizalom elvesztése

Mely rendszerek a legveszélyeztetettebbek?

Webalkalmazás típusok

Bizonyos típusú webalkalmazások különösen ki vannak téve a Directory Traversal támadásoknak:

Tartalomkezelő rendszerek (CMS):

• WordPress pluginek
• Drupal modulok
• Joomla komponensek

E-kereskedelmi platformok:

• Egyedi fejlesztésű webshopok
• Harmadik féltől származó e-commerce megoldások

Fájlkezelő alkalmazások:

• Online fájlmegosztók
• Dokumentumkezelő rendszerek
• Backup és archívum kezelők

Programozási nyelvek és keretrendszerek

Nyelv/Framework	Kockázati szint	Gyakori hibák
PHP	Magas	include(), require() rossz használata
Java	Közepes	Servlet path manipulation
.NET	Közepes	Server.MapPath() hibás alkalmazása
Node.js	Magas	fs.readFile() validáció nélkül
Python	Közepes	open() függvény nem biztonságos használata

Infrastrukturális szempontok

Bizonyos infrastrukturális konfigurációk növelik a kockázatokat:

• Régi webszerver verziók
• Hibás jogosultságkezelés
• Nem megfelelő chroot jail konfiguráció
• Hiányos WAF (Web Application Firewall) szabályok

Hogyan lehet felismerni a Directory Traversal támadásokat?

Log elemzés és monitoring

A Directory Traversal támadások felismerése érdekében folyamatosan monitorozni kell a webszerver naplóit. Gyanús minták keresése kritikus fontosságú a korai felismeréshez.

Gyanús URL minták a naplókban:

• Többszörös ../ szekvenciák
• URL kódolt traversal karakterek
• Rendszerfájlok elérési kísérletei
• Szokatlanul hosszú útvonalak

"A hatékony log monitoring nem csak a támadások felismeréséről szól, hanem a megelőzésről is – a korai észlelés megakadályozhatja a súlyosabb károkat."

Automatizált észlelési rendszerek

Modern biztonsági megoldások képesek valós időben észlelni a Directory Traversal kísérleteket:

Web Application Firewall (WAF) szabályok:

• Pattern matching a bejövő kérésekben
• Anomália detektálás
• Reputation-based blokkolás

SIEM rendszerek:

• Korrelációs szabályok
• Viselkedési elemzés
• Threat intelligence integráció

Manuális tesztelési módszerek

A biztonsági szakemberek különféle manuális technikákat alkalmaznak a sebezhetőségek felderítésére:

1. Parameter fuzzing: Különböző payload-ok tesztelése
2. Response analysis: A szerver válaszainak elemzése
3. Error message analysis: Hibaüzenetek információtartalmának vizsgálata
4. Time-based testing: Válaszidő alapú elemzések

Hogyan védekezhetünk a Directory Traversal támadások ellen?

Input validáció és szanitizálás

A legfontosabb védekezési mechanizmus a megfelelő input validáció implementálása. Minden felhasználói bemenetet alaposan ellenőrizni kell, mielőtt azt fájlútvonal összeállításához használnánk.

Whitelist alapú megközelítés:

• Csak előre definiált fájlnevek engedélyezése
• Karakterkészlet korlátozása
• Fájlkiterjesztés ellenőrzés

Blacklist alapú szűrés (kevésbé ajánlott):

• ../ és ..\\ szekvenciák blokkolása
• Kódolt változatok felismerése
• Null byte injection megakadályozása

Biztonságos fájlkezelési gyakorlatok

"A biztonságos programozás nem csak a támadások elleni védekezésről szól, hanem a helyes architektúrális döntésekről is."

Chroot jail használata:

• Alkalmazás izolálása saját könyvtárstruktúrába
• Rendszerfájlok elérésének megakadályozása
• Sandbox környezet kialakítása

Abszolút útvonalak használata:

• Relatív útvonalak kerülése
• Canonical path normalizáció
• Path resolution ellenőrzés

Webszerver konfiguráció

A webszerver megfelelő konfigurálása kritikus fontosságú a Directory Traversal támadások megelőzésében:

Apache HTTP Server:

# Directory Traversal védelem
<Directory "/var/www/html">
    AllowOverride None
    Options -Indexes -Includes
</Directory>

# Szimbolikus linkek tiltása
Options -FollowSymLinks

Nginx konfiguráció:

# Path normalizáció
location ~ /\. {
    deny all;
}

# Backup fájlok elrejtése
location ~* \.(bak|backup|old)$ {
    deny all;
}

Alkalmazásszintű védelem

Programozási nyelvek specifikus megoldásai:

PHP esetében:

// Biztonságos fájl include
$allowed_files = ['page1.php', 'page2.php', 'contact.php'];
$file = $_GET['page'];

if (in_array($file, $allowed_files)) {
    include $file;
} else {
    // Hibakezlés
}

Java esetében:

// Path traversal ellenőrzés
File file = new File(baseDir, userInput);
String canonicalPath = file.getCanonicalPath();
if (!canonicalPath.startsWith(baseDir.getCanonicalPath())) {
    throw new SecurityException("Directory traversal attempt");
}

Milyen eszközökkel lehet tesztelni a Directory Traversal sebezhetőségeket?

Penetrációs tesztelő eszközök

A biztonsági szakemberek számos eszközt használnak a Directory Traversal sebezhetőségek felderítésére és tesztelésére.

Burp Suite Professional:

• Automatizált scanner
• Manual testing támogatás
• Intruder modul payload generáláshoz
• Repeater funkció kézi teszteléshez

OWASP ZAP (Zed Attack Proxy):

• Ingyenes és nyílt forráskódú
• Automatikus sebezhetőség keresés
• Manual proxy funkciók
• Scripting támogatás

Specializált Directory Traversal eszközök

DotDotPwn:

• Perl alapú traversal fuzzer
• Többféle protokoll támogatás
• Testreszabható payload-ok
• Részletes jelentések

PathTraverser:

• Python alapú eszköz
• Batch tesztelési lehetőségek
• Custom wordlist támogatás
• Integration más eszközökkel

Saját fejlesztésű tesztelő scriptek

Gyakran szükség van egyedi tesztelő scriptek fejlesztésére:

Python példa:

import requests

payloads = [
    "../../../etc/passwd",
    "..\\..\\..\\windows\\system32\\drivers\\etc\\hosts",
    "%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd"
]

for payload in payloads:
    url = f"http://target.com/download.php?file={payload}"
    response = requests.get(url)
    if "root:" in response.text:
        print(f"Vulnerable: {payload}")

"A hatékony biztonsági tesztelés nem csak az automatizált eszközök használatáról szól, hanem a kreatív, manuális megközelítésekről is."

Mik a leggyakoribb hibák a Directory Traversal elleni védekezésben?

Nem megfelelő input validáció

A fejlesztők gyakran elkövetik azt a hibát, hogy csak a legnyilvánvalóbb támadási mintákat szűrik ki, de figyelmen kívül hagyják a kódolt vagy obfuszkált változatokat.

Gyakori hibák:

• Csak ../ szűrése, de ..\\ engedélyezése
• URL dekódolás után történő validáció
• Case-sensitive szűrés használata
• Rekurzív szűrés hiánya

Félreértett biztonsági modellek

Sok fejlesztő téves feltételezésekkel él a fájlrendszer biztonságával kapcsolatban:

• "Obscurity by security": Rejtett könyvtárak használata védelem helyett
• Jogosultságkezelés elhanyagolása: Túl engedékeny fájlrendszer jogosultságok
• Trusted input assumption: Belső rendszerektől érkező input validációjának elhagyása

Konfigurációs hibák

"A legjobb kód sem véd meg a rossz konfigurációtól – a biztonság holisztikus megközelítést igényel."

Webszerver hibák:

• Default konfigurációk használata
• Verbose error messages engedélyezése
• Directory listing engedélyezése
• Backup fájlok hozzáférhetősége

Tesztelési hiányosságok

Számos szervezet nem végez megfelelő biztonsági tesztelést:

• Csak happy path tesztelés
• Automatizált tesztek hiánya
• Penetrációs tesztelés elhanyagolása
• Code review folyamatok hiánya

Hogyan épül fel egy hatékony Directory Traversal védelem?

Többrétegű biztonsági modell

A hatékony védelem többrétegű megközelítést igényel, ahol minden szint külön védelmi mechanizmusokat implementál.

Alkalmazási réteg:

• Input validáció és szanitizálás
• Output encoding
• Biztonságos API-k használata
• Error handling

Webszerver réteg:

• Megfelelő konfiguráció
• Access control listák
• Virtual hosting beállítások
• Security headers

Operációs rendszer réteg:

• Fájlrendszer jogosultságok
• Chroot jail környezetek
• SELinux/AppArmor policies
• System monitoring

Fejlesztési életciklus integráció

Secure Development Lifecycle (SDL):

1. Tervezési fázis: Threat modeling
2. Fejlesztési fázis: Secure coding guidelines
3. Tesztelési fázis: Security testing
4. Deployment fázis: Security configuration
5. Karbantartási fázis: Continuous monitoring

Monitoring és incidenskezelés

"A proaktív monitoring nem csak a támadások észleléséről szól, hanem a rendszer általános biztonsági állapotának fenntartásáról is."

Real-time monitoring:

• Log aggregáció és elemzés
• Anomália detektálás
• Automated response mechanizmusok
• Threat intelligence integráció

Incident response:

• Készültségi tervek
• Kommunikációs protokollok
• Forensic capabilities
• Recovery procedures

Directory Traversal a különböző technológiákban

PHP alapú alkalmazások

A PHP alkalmazások különösen veszélyeztetettek a Directory Traversal támadásokkal szemben, főként az include(), require(), és fájlkezelő függvények miatt.

Tipikus sebezhető kód:

$page = $_GET['page'];
include($page . '.php');

Biztonságos megoldás:

$allowed_pages = ['home', 'about', 'contact'];
$page = $_GET['page'];

if (in_array($page, $allowed_pages)) {
    include($page . '.php');
} else {
    include('error.php');
}

Java webalkalmazások

Java környezetben a java.io.File osztály használata során kell különös figyelmet fordítani a path normalizációra.

Servlet példa:

public void doGet(HttpServletRequest request, HttpServletResponse response) {
    String filename = request.getParameter("file");
    File file = new File("/safe/directory/", filename);
    
    try {
        String canonicalPath = file.getCanonicalPath();
        if (!canonicalPath.startsWith("/safe/directory/")) {
            throw new SecurityException("Access denied");
        }
        // Biztonságos fájl olvasás
    } catch (IOException e) {
        // Error handling
    }
}

.NET alkalmazások

A .NET Framework és .NET Core alkalmazásokban a Path.GetFullPath() és Path.Combine() metódusok helyes használata kritikus.

ASP.NET Core példa:

public IActionResult DownloadFile(string fileName)
{
    var basePath = Path.Combine(Directory.GetCurrentDirectory(), "Files");
    var fullPath = Path.Combine(basePath, fileName);
    
    if (!fullPath.StartsWith(basePath))
    {
        return BadRequest("Invalid file path");
    }
    
    if (System.IO.File.Exists(fullPath))
    {
        return PhysicalFile(fullPath, "application/octet-stream");
    }
    
    return NotFound();
}

"A különböző programozási nyelvek eltérő kihívásokat jelentenek a Directory Traversal elleni védekezésben, de az alapelvek mindenütt ugyanazok: validáció, normalizáció és hozzáférés-vezérlés."

Jogi és megfelelőségi szempontok

Szabályozási környezet

A Directory Traversal sebezhetőségek komoly jogi következményekkel járhatnak, különösen a szigorú adatvédelmi szabályozások korában.

GDPR követelmények:

• Adatvédelmi impact assessment (DPIA)
• Privacy by design elvek
• Breach notification kötelezettségek
• Technical and organizational measures (TOMs)

PCI DSS megfelelőség:

• Regular security testing
• Secure coding practices
• Network segmentation
• Access control measures

Iparági standardok

Különböző iparágakban specifikus biztonsági követelmények vonatkoznak a webalkalmazásokra:

Egészségügy (HIPAA):

• Protected Health Information (PHI) védelme
• Audit trail követelmények
• Access controls
• Encryption standards

Pénzügyi szektor:

• SOX compliance
• Basel III requirements
• Open Banking security standards
• Anti-money laundering (AML) controls

Fejlett Directory Traversal technikák és védelem

Bypass technikák

A támadók folyamatosan fejlesztik technikáikat a védelmi mechanizmusok megkerülésére.

Double encoding:

%252e%252e%252f → %2e%2e%2f → ../

Unicode normalization:

..%c0%af → ../ (UTF-8 overlong encoding)

Null byte injection:

../../../etc/passwd%00.jpg

Fejlett védelmi technikák

Content Security Policy (CSP):

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'

HTTP Security Headers:

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubDomains

Web Application Firewall (WAF) szabályok:

SecRule ARGS "@detectSQLi" \
    "id:1001,\
    phase:2,\
    block,\
    msg:'SQL Injection Attack Detected',\
    logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}'"

"A fejlett támadási technikák elleni védelem folyamatos tanulást és adaptációt igényel – a biztonság sosem lehet statikus állapot."

Gyakorlati megvalósítási útmutató

Fejlesztési checklist

Kód szintű ellenőrzések:

• Input validáció implementálva minden file parameter esetén
• Whitelist alapú fájlnév ellenőrzés
• Path normalizáció és canonical path ellenőrzés
• Proper error handling implementálva
• Security headers beállítva

Konfiguráció szintű ellenőrzések:

• Webszerver default konfigurációk felülvizsgálva
• Directory listing letiltva
• Backup fájlok hozzáférhetetlenek
• Proper file permissions beállítva
• Logging és monitoring konfigurálva

Tesztelési metodológia

Automatizált tesztelés:

1. SAST (Static Application Security Testing) eszközök
2. DAST (Dynamic Application Security Testing) scannerek
3. IAST (Interactive Application Security Testing) megoldások
4. Dependency scanning tools

Manuális tesztelés:

1. Penetration testing
2. Code review
3. Architecture review
4. Configuration assessment

Jövőbeli trendek és kihívások

Emerging technológiák

Cloud native alkalmazások:

• Container security
• Serverless architectures
• Microservices challenges
• API security

AI és Machine Learning:

• Automated attack detection
• Behavioral analysis
• Anomaly detection improvements
• False positive reduction

Új támadási vektorok

A technológia fejlődésével új támadási felületek jelennek meg:

GraphQL sebezhetőségek:

• Query complexity attacks
• Introspection abuse
• Authorization bypass

API-first architectures:

• REST API vulnerabilities
• JSON manipulation
• OAuth/JWT weaknesses

"A jövő biztonsági kihívásai nem csak új technológiákból erednek, hanem a meglévő problémák új kontextusokban való megjelenéséből is."

---

Gyakran Ismételt Kérdések (FAQ)

Mi a különbség a Directory Traversal és a Local File Inclusion (LFI) között?

A Directory Traversal és a Local File Inclusion szorosan kapcsolódnak, de van közöttük különbség. A Directory Traversal a fájlrendszerben való navigálásra összpontosít (../ használatával), míg az LFI konkrétan a lokális fájlok include-olására vagy betöltésére vonatkozik egy alkalmazásban. Az LFI gyakran Directory Traversal technikákat használ, de nem minden Directory Traversal vezet LFI-hoz.

Hogyan lehet megkülönböztetni a valódi Directory Traversal sebezhetőséget a false positive-tól?

A valódi sebezhetőség azonosításához több tényezőt kell vizsgálni: a szerver válaszának tartalmát (pl. /etc/passwd tartalom megjelenése), a HTTP status kódokat, a válasz méretét és időzítését. False positive esetén általában hibaüzenetet kapunk vagy a normál alkalmazás működés folytatódik. Fontos a context-aware tesztelés és a manuális verifikáció.

Milyen szerepet játszik a Web Application Firewall (WAF) a Directory Traversal védelem terén?

A WAF fontos védelmi réteget képez, de nem lehet rá teljes mértékben hagyatkozni. Képes felismerni és blokkolni a tipikus Directory Traversal mintákat, de a fejlett bypass technikák ellen kevésbé hatékos. A WAF-ot mindig kombinálni kell proper input validációval és secure coding practices-szel. Emellett rendszeres frissítés és rule tuning szükséges.

Hogyan befolyásolja a containerizáció (Docker, Kubernetes) a Directory Traversal kockázatokat?

A containerizáció jelentősen csökkentheti a Directory Traversal támadások hatását, mivel az alkalmazás izolált környezetben fut. Azonban nem szünteti meg teljesen a kockázatot – a container-en belül még mindig lehetséges fájlokhoz való jogosulatlan hozzáférés. Fontos a proper volume mounting, user privileges korlátozása és security contexts használata.

Mit jelent a "null byte injection" a Directory Traversal kontextusában?

A null byte injection (%00) egy régebbi PHP sebezhetőség volt, ahol a null karakter lezárta a string feldolgozást. Például ../../../etc/passwd%00.jpg esetén a PHP csak a .jpg előtti részt dolgozta fel, így megkerülhette a fájlkiterjesztés ellenőrzést. Modern PHP verziókban ez már nem működik, de más nyelvekben hasonló problémák előfordulhatnak.

Hogyan lehet hatékonyan tesztelni a Directory Traversal sebezhetőségeket CI/CD pipeline-ban?

A CI/CD integrációhoz automatizált SAST és DAST eszközöket kell használni. SAST eszközök képesek a forráskódban felismerni a potenciálisan sebezhető mintákat, míg a DAST eszközök a futó alkalmazást tesztelik. Fontos a threshold beállítása, hogy a build ne törjön meg minden kis finding miatt, de a kritikus sebezhetőségek blokkolják a deployment-et. Custom security tests írása is ajánlott.