ANECT a.s.AISLE v praxi: zkušenost z pohledu bezpečnostního architekta
Moderní AppSec nástroje postavené na AI slibují rychlejší detekci zranitelností, lepší prioritizaci nálezů i podporu při jejich opravách. Jak ale vypadají jejich přínosy v reálném vývojovém prostředí?
Petr Mojžíš, Lead Security Architect v ANECTu, shrnuje zkušenost vývojového týmu, který platformu AISLE využil při analýze několika webových SaaS aplikací. V textu se zaměřuje na praktický dopad na práci vývojářů, kvalitu bezpečnostních nálezů, zkrácení doby potřebné k nápravě i roli seniorních vývojářů při finálním posouzení oprav.
AISLE je moderní AppSec platforma postavená čistě na AI, která se nesoustředí jen na hledání zranitelností v kódu, ale pracuje s celkovým kontextem aplikace, prioritizuje nálezy podle jejich dopadu a zároveň navrhuje jejich opravy. Jako v dnešní době velmi podstatný bonus také vytváří SBOM včetně inventarizace použité kryptografie.
Měl jsem možnost detailně diskutovat zkušenosti vývojového týmu, který AISLE použil na několik víceméně webových SaaS aplikacích postavených na poměrně širokém spektru technologií jako Python, .NET, Node.js, React nebo GraphQL. Nesnažil jsem se hodnotit technologii samotnou, ale spíše pochopit, jaký má reálný dopad na práci vývojářů a kybernetickou bezpečnost jako takovou.
Ukázalo se, že AISLE v mnoha ohledech mění očekávání od bezpečnostních nástrojů. Přestože technicky “pouze” realizuje statické bezpečnostní testování kódu a jeho dekompozici (SAST a SCA), v praxi se účinek posouvá výrazně dál. Ve výsledku se de facto chová jako náhrada security engineera v oblasti code review (samozřejmě včetně toho, že příslušný specialista by měl v rukou i SAST a SCA nástroje). Vývojáři oceňovali zejména schopnost rychle identifikovat false positives a posuzovat nálezy v kontextu konkrétní implementace, nikoliv jen podle statických pravidel. Zároveň ale zaznělo, že interpretace výstupů není vždy triviální a méně zkušení vývojáři mohou mít problém správně pochopit navržené opravy. S “živým” security engineerem je to však mnohem horší – chce po vás odstranění zranitelnosti nebo slabiny, ale opravný kód vám nenapíše. Velmi výrazně se potvrdilo, že kvalita nálezů je jeden z hlavních přínosů. Tým uváděl, že nebylo nutné re-klasifikovat žádný z přibližně dvaceti false positives jako skutečný nález. Stejně tak se neobjevily falešně pozitivní nálezy mezi zhruba pěti sty identifikovanými zranitelnostmi. Tato kombinace v tomto případě dokonce nulové chybovosti na obou stranách vedla k vyšší důvěře ve výstupy a zároveň k ochotě s nimi skutečně pracovat.
Z mé role “bezpečáka” mne samozřejmě zajímal hlavně bezpečnostní přínos. Přibližně padesát z analyzovaných zranitelností by vývojový tým bez AISLE pravděpodobně odhalil až v rámci dynamického testování nebo v rámci penetračních testů. Typicky šlo o chyby v autorizaci API endpointů s CVSS i 9 a vyšší. AISLE zde poskytl výrazně dřívější detekci, učebnicový “shift left” naživo. Ještě zajímavější byly případy zranitelností, které by tým pravděpodobně neodhalil vůbec. Šlo například o scénáře typu man-in-the-middle v kontextu použití knihoven třetích stran, nebo o rizika spojená s nadměrným logováním, včetně potenciálního ukládání citlivých údajů (hesel) v chybových stavech aplikace. Tyto typy nálezů často unikají běžnému testování, protože je nikdo explicitně nehledá. Podobně AISLE identifikoval i zranitelnosti využitelné pro DoS útoky, které nejsou běžně zachycovány v testovacích scénářích. Konkrétně šlo například o chyby v integraci knihoven pro LDAP, které by bylo možné zneužít vůči těmto backendovým službám. Tento typ nálezů ukazuje, že schopnost pracovat s kontextem skutečně rozšiřuje dosah (pokrytí) bezpečnostního testování.
Velmi praktický dopad se projevil v oblasti remediation. Bez ohledu na to, zda se původní doba opravy pohybovala v řádu dní nebo týdnů, nasazení AISLE ji zkrátilo na jednotky hodin. Důležité přitom je, že tento efekt byl dosažen bez jakéhokoli navýšení kapacit týmu. AISLE na první pohled řeší jen detekci, ale vzhledem k tomu, že reálná práce je v detailních analýzách, třídění nálezů a v psaní oprav, je zde z hlediska bezpečnosti jasné výrazné zkrácení MTTR (Mean Time To Remediate).
Z pohledu řízení rizik jsem se s vývojáři po těchto diskuzích shodl, že nasazení AISLE vedlo ke snížení celkového bezpečnostního rizika na úroveň, kterou by většina organizací označila jako nízkou. Bez navýšení kapacit týmu na práci na opravách zůstaly už po prvních dnech pouze v nějakém kontextu zneužitelné zranitelnosti s CVSS menší než 7.
Na druhou stranu se potvrdilo, že AISLE neeliminuje potřebu seniorních vývojářů, naopak ji podtrhuje. U složitějších oprav je stále nutná hlubší znalost architektury a schopnost zasadit navržené změny do širšího kontextu aplikace. Objevovaly se i situace, kdy AISLE navrhoval alternativní implementace oprav pro téměř stejnou věc. A seniorní vývojáři se při finálním ladění navržených oprav nejednou pěkně zapotili. Přes kontext, který si AISLE vytváří, nemá dostatečný rozhled, aby rozuměl celému ekosystému aplikace.
Celkově lze zkušenost s AISLE shrnout jako radikální posun v tom, jak může být bezpečnost integrována do vývoje. Není to jen další SAST+SCA nástroj. Z mého pohledu je to na straně bezpečnosti vývoje hmatatelná odpověď na hrozby, které s používáním AI přicházejí na straně útočníků, zejména ve schopnosti nacházet zranitelnosti.
Zpět na blog