Pravděpodobně jste už slyšeli frázi „nejde o to, jestli, ale kdy“ v souvislosti s narušením bezpečnosti. Je to klišé, protože je to pravda. Ale zde je část, o které se lidé mluví jen zřídka: skutečné časové okno mezi okamžikem, kdy se ve vašem kódu objeví zranitelnost, a okamžikem, kdy ji skutečně opravíte. V oboru to nazýváme Mean Time to Remediation (MTTR).
Pro mnoho společností je MTTR děsivé číslo. Proč? Protože tradiční způsob hledání chyb je pomalý. Většina podniků se stále spoléhá na „roční Penetration Test“ – rozsáhlý, drahý audit, kdy firma jednou ročně přijde, dva týdny prozkoumává systém a předá 60stránkové PDF se všemi zjištěnými nedostatky. Než se tato zpráva dostane na stůl CTO, vývojáři už vydali deset nových verzí aplikace. Zpráva je zastaralá dříve, než je vůbec přečtena.
Tento „jednorázový“ přístup vytváří nebezpečné zpoždění. Pokud je kritická zranitelnost zavedena v lednu, ale váš plánovaný test je až v říjnu, právě jste útočníkům dali devítiměsíční náskok. Právě zde přichází na řadu automatizované bezpečnostní testování. Nejde o úplné nahrazení lidí, ale o uzavření této mezery, aby se doba potřebná k nalezení a opravě chyby zkrátila z měsíců na hodiny.
V tomto průvodci podrobně rozebereme, jak přesně snížit vaše MTTR, proč je automatizované testování jediným způsobem, jak držet krok s moderními cykly nasazení, a jak vybudovat pracovní postup, který skutečně funguje pro vývojáře, namísto aby jim překážel.
Co přesně je Mean Time to Remediation (MTTR)?
Než se ponoříme do „jak na to“, ujasněme si, co měříme. MTTR je průměrná doba, za kterou je hrozba neutralizována poté, co byla detekována. Je to kritická metrika, protože přímo koreluje s vaší expozicí riziku. Čím déle zranitelnost existuje v produkčním prostředí, tím vyšší je pravděpodobnost, že ji najde botnet nebo škodlivý aktér.
Pro výpočet MTTR v podstatě vezmete celkový čas strávený opravou všech zranitelností za určité období a vydělíte ho počtem opravených zranitelností.
Rovnice MTTR vypadá zhruba takto: (Time of Fix 1 - Time of Detection 1) + (Time of Fix 2 - Time of Detection 2)... / Total Number of Fixes
Ale když se podíváte blíže, MTTR se ve skutečnosti skládá z několika menších fází:
- Doba identifikace: Jak dlouho trvá, než vaše nástroje nebo výzkumník najdou chybu?
- Doba třídění: Jak dlouho trvá po nalezení chyby určit, zda se jedná o skutečné riziko, nebo o False Positive?
- Doba prioritizace: Kdo to opraví a má to přednost před novou funkcí, kterou chce produktový manažer?
- Doba nápravy: Skutečný akt napsání kódu, otestování záplaty a její nasazení do produkce.
Když lidé říkají, že chtějí „snížit MTTR“, obvykle se zaměřují na část týkající se kódování. Skutečné úzké hrdlo je však téměř vždy v prvních třech fázích. Pokud trvá tři týdny identifikovat chybu a další týden rozhodnout, zda je důležitá, vaši vývojáři už začínají s deficitem.
Selhání bezpečnostního modelu „jednorázového testování“
Po desetiletí byl zlatým standardem pro bezpečnost manuální Penetration Test. Najmete si specializovanou firmu, ta simuluje útok a předá vám zprávu. Zatímco vysoce kvalitní manuální testování je stále nezbytné pro komplexní logické chyby, používat jej jako svou primární bezpečnostní strategii v cloud-native světě je jako kontrolovat detektor kouře jednou ročně a předpokládat, že se váš dům mezitím nezapálí.
„Past shody s předpisy“
Mnoho malých a středních podniků padá do pasti dodržování předpisů. Projdou auditem SOC 2 nebo HIPAA a cítí se bezpečně. Shoda je však základ, nikoli strop. Zpráva o shodě dokazuje, že jste byli v bezpečí v den auditu. Nic neříká o kódu, který jste v úterý ráno nasadili do produkce.
Problém zpětnovazební smyčky
Vývojáři nenávidí dlouhé zpětnovazební smyčky. Pokud vývojář napíše kus kódu v únoru a Penetration Tester mu v červnu řekne, že je zranitelný, tento vývojář už zapomněl kontext daného kódu. Musí zastavit svůj aktuální projekt, ponořit se zpět do staré logiky a pokusit se zjistit, co se pokazilo. Toto tření vytváří nelibost mezi bezpečnostními a inženýrskými týmy.
Náklady na manuální škálování
Manuální testování se neškáluje. Jak vaše aplikace roste ze tří stránek na třicet a vaše infrastruktura se rozšiřuje napříč AWS a Azure, náklady na manuální testování raketově rostou. Buď platíte více za stejnou frekvenci testů, nebo testujete méně často. Ani jedno není vítězná strategie.
Jak automatizované bezpečnostní testování mění pravidla hry
Zde platformy jako Penetrify mění dynamiku. Přechodem k On-Demand Security Testing (ODST) a Continuous Threat Exposure Management (CTEM) přestanete vnímat bezpečnost jako událost a začnete ji vnímat jako proces.
Automatizované bezpečnostní testování nejenže "skenuje" – integruje se. Mapuje vaši útočnou plochu v reálném čase, což znamená, že ví, kdy jste otevřeli nový port nebo přidali nový API endpoint dříve, než by to zjistil lidský auditor.
Shift Left: Dřívější odhalování chyb
"Shifting left" je termín, který často uslyšíte v DevSecOps. Jednoduše to znamená přesunout bezpečnostní testování dříve v životním cyklu vývoje softwaru (SDLC). Místo testování na konci ("pravá" strana časové osy) testujete během vývoje.
Když automatizujete fáze průzkumu a skenování, můžete najít běžné chyby – jako ty v OWASP Top 10 – téměř okamžitě po napsání kódu. To mění "bezpečnostní krizi" v "jednoduchou opravu chyby."
Snížení šumu
Jedním z největších přispěvatelů k vysokému MTTR je "únava z upozornění." Staré skenery zasypou vývojáře 500 "středními" upozorněními, z nichž polovina jsou False Positives. Vývojář pak celý seznam ignoruje.
Moderní automatizované platformy se zaměřují na dosažitelnost a využitelnost. Místo pouhého konstatování "máte zastaralou knihovnu" se inteligentní systém zeptá: "Je tato knihovna skutečně volána veřejně přístupnou funkcí?" Pokud je odpověď ne, priorita klesá. To umožňuje týmům soustředit se na 5 % zranitelností, které skutečně představují kritické riziko.
Mapování útočné plochy: První krok k rychlejší nápravě
Nemůžete opravit to, o čem nevíte, že existuje. To je problém "Shadow IT". Vývojář může spustit stagingové prostředí v GCP, aby otestoval novou funkci, a zapomenout ho vypnout. Nyní máte živý, neměřený server s databází obsahující zrcadlená produkční data.
Co je Attack Surface Management (ASM)?
ASM je nepřetržité objevování a monitorování všech aktiv přístupných z internetu. To zahrnuje:
- Subdomény: Zapomenuté weby
dev.example.comnebotest-api.example.com. - Otevřené porty: Nechráněné SSH nebo RDP porty ponechané otevřené pro "rychlý přístup."
- API Endpoints: Nedokumentované "zombie" API, které stále používají staré verze vaší mobilní aplikace.
- Cloudové úložiště: Špatně nakonfigurované S3 buckety, které jsou omylem nastaveny jako veřejné.
Proč ASM snižuje MTTR
Pokud máte jasnou mapu své útočné plochy, část „doba identifikace“ vašeho MTTR klesne téměř na nulu. Nemusíte čekat na čtvrtletní skenování, abyste zjistili, že máte únik; systém vás upozorní v okamžiku, kdy se online objeví nové, zranitelné aktivum.
Hloubková analýza: Řešení OWASP Top 10 pomocí automatizace
Abychom skutečně pochopili, jak automatizace snižuje MTTR, podívejme se na několik běžných zranitelností z OWASP Top 10 a porovnejme manuální a automatizovaný přístup.
1. Nefunkční řízení přístupu
Představte si, že uživatel může přistupovat k datům jiného uživatele pouhou změnou ID v URL (např. změnou /user/101 na /user/102).
- Manuální přístup: Pentester tráví hodiny ručním testováním různých kombinací ID, aby našel chyby IDOR (Insecure Direct Object Reference).
- Automatizovaný přístup: Automatizovaný nástroj lze nakonfigurovat tak, aby testoval různé úrovně oprávnění napříč všemi API endpointy, označující endpointy, které nevyžadují řádnou validaci relace.
2. Kryptografické chyby
Používání zastaralé verze TLS nebo ukládání hesel v prostém textu.
- Manuální přístup: Auditor spustí několik skriptů proti hlavičkám vašeho serveru a zaznamená zastaralou verzi TLS do zprávy.
- Automatizovaný přístup: Kontinuální skener kontroluje vaši konfiguraci SSL/TLS každý den. V okamžiku, kdy certifikát vyprší nebo se šifra stane zastaralou, je v Jira automaticky otevřen ticket.
3. Injekce (SQLi, XSS)
Útočník pošle škodlivá data do formuláře, aby ukradl informace z databáze nebo spustil skripty v prohlížeči jiného uživatele.
- Manuální přístup: Specialista zkouší různé payloady, aby „rozbil“ vstupní pole.
- Automatizovaný přístup: Automatizované dynamické testování zabezpečení aplikací (DAST) pošle tisíce známých útočných vzorů proti vašim vstupům během několika minut, přesně identifikující, která pole jsou zranitelná.
Srovnání: Manuální vs. automatizovaný pracovní postup nápravy
| Funkce | Manuální Penetration Testing | Automatizované testování (Penetrify) |
|---|---|---|
| Frekvence | Roční nebo pololetní | Kontinuální / Na vyžádání |
| Objevování | Snímek k určitému datu | Mapování útočné plochy v reálném čase |
| Zpětná vazba | Týdny/Měsíce (prostřednictvím PDF zprávy) | Minuty/Hodiny (prostřednictvím Dashboardu/API) |
| Náklady | Vysoké náklady na jedno zapojení | Škálovatelné předplatné |
| Integrace do vývoje | Nesourodá; oddělená od CI/CD | Integrovaná do DevSecOps pipeline |
| Dopad na MTTR | Vysoký (pomalá identifikace/třídění) | Nízký (rychlá detekce/náprava) |
Implementace rámce pro kontinuální řízení expozice hrozbám (CTEM)
Pokud se chcete posunout za hranice jednoduchého skenování a skutečně snížit své MTTR, potřebujete rámec. CTEM je moderní způsob pohledu na bezpečnost. Namísto „opravování chyb“ „řídíte expozici“.
CTEM se obecně řídí pětifázovým cyklem:
Krok 1: Vymezení rozsahu
Nesnažte se vařit oceán. Definujte, co skutečně potřebuje ochranu. Je to vaše API pro zákazníky? Vaše platební brána? Váš administrativní portál? Správným vymezením rozsahu zajistíte, že se vaše automatizované nástroje zaměří svou „energií“ na cíle s vysokou hodnotou.
Krok 2: Objevování
Toto je fáze ASM, o které jsme mluvili. Použijte nástroje k nalezení každé jednotlivé IP adresy, domény a cloudového zdroje spojeného s vaší společností. Byli byste překvapeni, jak často se „zapomenutý“ projekt z doby před dvěma lety stane vstupním bodem pro narušení bezpečnosti.
Krok 3: Prioritizace
Ne všechny zranitelnosti jsou si rovny. „Kritická“ zranitelnost na serveru, který je blokován firewallem a neobsahuje citlivá data, je ve skutečnosti méně nebezpečná než „střední“ zranitelnost na vaší hlavní přihlašovací stránce. Automatizované nástroje zde pomáhají poskytováním kontextu. Řeknou vám, zda je zranitelnost „dosažitelná“ z internetu. Pokud ano, posune se na začátek seznamu.
Krok 4: Validace
Zde se skutečně projevuje část „automatizace“. Jakmile je nalezena potenciální chyba, systém může spustit simulovaný útok (Breach and Attack Simulation), aby zjistil, zda lze chybu skutečně zneužít. Pokud ji systém nemůže zneužít, může jít o False Positive. To ušetří vašim vývojářům hodiny marného honění se za duchy.
Krok 5: Mobilizace
Toto je poslední úsek závodu MTTR. Validace je k ničemu, pokud informace jen leží na dashboardu. Mobilizace znamená, že data proudí přímo do nástrojů, které vývojáři již používají.
- Jira/GitHub Issues: Zranitelnost je odeslána jako ticket.
- Slack/Teams: Vedoucí bezpečnosti je okamžitě upozorněn.
- Průvodci nápravou: Namísto pouhého sdělení „nalezeno XSS“ platforma poskytuje úryvek kódu ukazující, jak sanitizovat vstup.
Integrace bezpečnosti do CI/CD Pipeline (DevSecOps)
Pro dosažení nejnižšího možného MTTR nemůže být bezpečnost samostatným oddělením. Musí být součástí kódu pipeline. To je srdce DevSecOps.
Ideální automatizovaná Pipeline
Zde je, jak vypadá moderní pipeline s nízkým MTTR:
- Code Commit: Vývojář nahraje kód do větve.
- SAST (Static Analysis): Automatizovaný nástroj skenuje surový zdrojový kód na zjevné chyby (jako jsou napevno zakódovaná hesla).
- Build & Deploy to Staging: Aplikace je nasazena do dočasného cloudového prostředí.
- DAST (Dynamic Analysis): Automatizovaný nástroj (jako Penetrify) útočí na běžící aplikaci a testuje chyby za běhu, které SAST nemůže vidět.
- Validace: Systém kontroluje, zda nový kód nezavedl nějaké bezpečnostní regrese.
- Schválení/Sloučení: Pokud nejsou nalezeny žádné kritické chyby, kód se přesune do produkce.
Než se kód dostane do produkce, byl již mnohokrát testován. Pokud se chyba přece jen proklouzne, nepřetržité skenování v produkci ji zachytí a zpětnovazební smyčka ji vrátí vývojáři během hodin, nikoli měsíců.
Role „Penetration Testing as a Service“ (PTaaS)
Možná se ptáte: „Pokud je automatizace tak skvělá, proč stále potřebuji Penetration Testing?“
Odpověď je, že automatizace je skvělá v hledání „známých neznámých“ – typů chyb, které mají vzory. Ale potýká se s „neznámými neznámými“, jako jsou složité chyby v obchodní logice (např. uživatel, který může uplatnit slevový kód pětkrát, protože systém nekontroluje počet).
Zde přichází na řadu PTaaS. PTaaS je hybridní model. Využívá automatizaci pro těžkou práci (průzkum, skenování, mapování povrchu) a zapojuje lidské experty pro chirurgické údery.
Jak PTaaS urychluje nápravu
V tradičním modelu čekáte, než člověk dokončí test, abyste získali výsledky. V modelu PTaaS automatizace běží 24/7. Když lidský tester něco najde, zaznamená to do stejné platformy, jakou používá automatizace.
Vývojář vidí jednotný proud zranitelností. Nezajímá je, jestli to našel bot nebo člověk – vidí jen tiket s úrovní závažnosti a řešením. Toto sjednocení odstraňuje „zpoždění hlášení“ a výrazně snižuje MTTR.
Časté chyby, které prodlužují MTTR
I s vynikajícími nástroji společnosti často sabotují rychlost vlastní nápravy. Zde jsou nejčastější úskalí:
1. „Bezpečnostní zeď“
Když bezpečnostní tým funguje spíše jako strážce než jako partner. Pokud je bezpečnost vnímána jako „oddělení Ne“, vývojáři si najdou způsoby, jak obejít skenování nebo skrýt aktiva, aby se vyhnuli problémům.
- Řešení: Dejte vývojářům přístup k bezpečnostním dashboardům. Nechte je spouštět vlastní skeny. Když chybu najdou sami, je mnohem pravděpodobnější, že ji rychle opraví.
2. Přílišné spoléhání na označení „Kritické“
Některé nástroje označují vše jako „Kritické“, aby si kryly záda. Když vývojář uvidí 50 „Kritických“ upozornění, přestane nástroji důvěřovat.
- Řešení: Použijte systém hodnocení založený na riziku. Kombinujte skóre CVE (technická závažnost) s obchodním dopadem (jedná se o databázi s kreditními kartami?).
3. Zanedbávání fáze „Triage“
Mnoho společností přechází přímo od „Skenování“ k „Opravě“. Nevěnují čas ověření, zda je chyba skutečně zneužitelná v jejich konkrétním prostředí. To vede k „churnu“, kdy vývojáři tráví dny opravováním něčeho, co ve skutečnosti nebylo rizikem.
- Řešení: Implementujte rychlý krok Triage. Použijte nástroj, který poskytuje důkazy proof-of-concept (PoC), že zranitelnost je skutečná.
4. Neschopnost sledovat trendy
Pokud se díváte pouze na aktuální seznam chyb, hrajete si na „Whac-A-Mole“. Opravujete symptomy, ne nemoc.
- Řešení: Analyzujte své MTTR v průběhu času. Pokud si všimnete, že chyby „Broken Access Control“ trvají nejdéle opravit, možná váš tým potřebuje více školení o tom, jak implementovat autorizaci.
Krok za krokem plán, jak snížit vaše MTTR počínaje dneškem
Pokud se váš současný bezpečnostní proces zdá pomalý a neohrabaný, nemusíte všechno předělávat přes noc. Můžete zvolit fázovaný přístup.
Fáze 1: Viditelnost (Týden 1-2)
Přestaňte hádat, jaká je vaše útočná plocha. Začněte mapováním svých externích aktiv.
- Identifikujte všechny veřejné IP adresy a domény.
- Auditujte své cloudové buckety (S3, Azure Blobs).
- Seznamte své veřejně dostupné API.
- Cíl: Snížit „čas identifikace“ na nulu.
Fáze 2: Kontinuální základ (Týden 3-4)
Nastavte automatizované skenování pro svá aktiva s nejvyšším rizikem.
- Integrujte cloudový skener, který běží podle plánu (např. denně nebo týdně).
- Nejprve se zaměřte na OWASP Top 10.
- Nastavte základní upozornění (Slack nebo Email) pro „Kritické“ nálezy.
- Cíl: Eliminovat mezeru „point-in-time“.
Fáze 3: Integrace s vývojem (Měsíc 2)
Zaveďte bezpečnost do pracovního postupu vývojářů.
- Propojte svou bezpečnostní platformu s Jira nebo GitHub.
- Stanovte „SLA“ (Service Level Agreement) pro opravy (např. Kritické musí být opraveny do 48 hodin, Vysoké do 14 dnů).
- Cíl: Snížit čas „Prioritizace“ a „Triage“.
Fáze 4: Plné DevSecOps (Měsíc 3+)
Automatizujte pipeline.
- Spouštějte skeny automaticky při nasazení kódu do stagingu.
- Implementujte automatizovanou validaci, abyste zajistili, že opravy skutečně fungují.
- Přesuňte se k modelu PTaaS pro testování komplexní logiky.
- Cíl: Dosáhněte minimálního, předvídatelného MTTR.
Scénář z reálného světa: Boj SaaS startupu
Podívejme se na hypotetický příklad. "CloudScale," rychle rostoucí B2B SaaS společnost, vydávala aktualizace třikrát denně. Každý prosinec prováděli manuální Penetration Test.
Starý způsob: V březnu vývojář náhodou zavedl zranitelnost SQL Injection do modulu pro resetování hesla.
- Detekce: Chyba zůstala neodhalena až do prosincového Penetration Testu.
- Třídění: Zpráva byla doručena v lednu. Vedoucí bezpečnosti strávil týden revizí 60stránkového PDF.
- Náprava: Vývojář, který se mezitím přesunul na jiný projekt, strávil tři dny opětovným učením starého kódu, aby chybu opravil.
- Celkové MTTR: ~10 měsíců.
Nový způsob (s Penetrify): CloudScale implementuje automatizované bezpečnostní testování.
- Detekce: V okamžiku, kdy je kód pro resetování hesla nasazen do stagingu, automatizovaný skener identifikuje zranitelnost SQLi.
- Třídění: Systém automaticky validuje chybu a vytvoří Jira ticket označený jako "Kritický" s odkazem na přesnou řádku kódu.
- Náprava: Vývojář vidí ticket, zatímco má kód stále čerstvě v paměti. Aplikuje opravu a nasadí ji do produkce.
- Celkové MTTR: 4 hodiny.
Rozdíl není jen v rychlosti; je v riziku. V prvním scénáři byla společnost zranitelná téměř rok. Ve druhém bylo okno expozice kratší než polední přestávka.
Často kladené otázky (FAQ)
Nahrazuje automatizované testování potřebu lidských Penetration Testerů?
Ne. Automatizace je fantastická pro hledání běžných zranitelností a udržování základní úrovně bezpečnosti. Lidé jsou však stále lepší v hledání "logických" chyb – věcí, jako je obcházení platební brány nebo manipulace s obchodním procesem. Ideální strategií je hybridní přístup: použijte automatizaci pro 90 % práce a lidi pro komplexních 10 %.
Nezpomalí automatizované skeny mou deployment pipeline?
Může, pokud nejste opatrní. Klíčem je spouštět "lehké" skeny (SAST) během buildu a "hluboké" skeny (DAST) v paralelním stagingovém prostředí. Tímto způsobem vývojář nemusí čekat na dokončení celého skenu, než může sloučit svůj kód, ale bezpečnostní tým stále získá potřebná data.
Jak se vypořádat s False Positives v automatizovaných nástrojích?
False Positives jsou největším zabijákem důvěry vývojářů. Pro jejich minimalizaci používejte nástroje, které nabízejí "analýzu dosažitelnosti" nebo automatizovanou validaci. Pokud nástroj řekne "Máte zranitelnost," zeptejte se ho "Můžete to dokázat?" Pokud nástroj nemůže poskytnout proof-of-concept nebo cestu k chybě, považujte to za nižší prioritu.
Je automatizované bezpečnostní testování drahé pro malé týmy?
Ve skutečnosti je to obvykle levnější než alternativa. Jeden špičkový manuální Penetration Test může stát tisíce dolarů. Cloudová automatizační platforma je typicky založena na předplatném. Pro SME jsou náklady na předplatné mnohem nižší než náklady na jeden velký únik dat nebo náklady na najmutí interního Red Teamu na plný úvazek.
Moje aplikace je jednoduchá. Opravdu potřebuji kontinuální testování?
I jednoduché aplikace se mění. Můžete aktualizovat závislost, změnit nastavení cloudu nebo přidat novou integraci třetí strany. Jakákoli z těchto změn může otevřít novou díru. Kontinuální testování zajišťuje, že "jednoduché" se náhodou nestane "zranitelným."
Doporučení pro váš tým
Pokud chcete začít snižovat svůj MTTR ještě dnes, zde je váš kontrolní seznam:
- Přestaňte se spoléhat na každoroční audit. Je to jen zaškrtávací políčko pro dodržování předpisů, nikoli bezpečnostní strategie.
- Proveďte inventuru svých aktiv. Nemůžete chránit to, co nevidíte. Okamžitě zmapujte svou externí útočnou plochu.
- Integrujte se se svými nástroji. Přestaňte používat PDF. Přesuňte bezpečnostní nálezy do Jira, GitHubu nebo Slacku.
- Zaměřte se na dosažitelnost. Nenechte své vývojáře zahltit upozorněními úrovně „Střední“, která ve skutečnosti nelze zneužít.
- Posilněte své vývojáře. Dejte jim nástroje k prohledávání vlastního kódu, než se dostane k bezpečnostnímu auditorovi.
Závěrečné myšlenky: Posun k proaktivní bezpečnosti
Cílem snížení Střední doby do nápravy není jen metrika v tabulce. Jde o změnu kultury vaší organizace. Když je bezpečnost „jednou ročně událostí“, je zdrojem stresu, tření a strachu. Když je bezpečnost nepřetržitým, automatizovaným procesem, stává se jen další součástí zajištění kvality.
Využitím cloud-native platforem, jako je Penetrify, přecházíte z reaktivního přístupu – čekání, až vám někdo řekne, že jste zranitelní – k proaktivnímu přístupu. Najdete mezery, ověříte rizika a opravíte kód dříve, než „špatní kluci“ vůbec zjistí, že zranitelnost existuje.
V moderním cloudovém prostředí je rychlost vším. Vaši vývojáři dodávají kód rychleji než kdy dříve; vaše bezpečnostní testování musí držet krok. Nenechte, aby váš MTTR byl slabým článkem ve vašem řetězci.
Jste připraveni přestat hádat a začít zabezpečovat? Pokud vás unavuje každoroční cyklus Penetration Testů a chcete způsob, jak zachytit zranitelnosti v reálném čase, je čas prozkoumat modernější přístup. Navštivte Penetrify a zjistěte, jak automatizované mapování útočné plochy a testování na vyžádání může snížit váš MTTR a dát vašemu týmu klid.