AI vám napísala aplikáciu. Kto skontroluje, či je bezpečná?

Pred niekoľkými rokmi znamenalo vytvorenie webovej aplikácie návrh architektúry, programovanie, testovanie a často týždne či mesiace vývoja.

Dnes dokáže človek pomocou AI coding nástrojov vytvoriť funkčný prototyp za výrazne kratší čas.

Popíše požiadavku.

AI pripraví databázu.

Vytvorí prihlasovanie.

Doplní API.

Pridá administráciu.

Pripraví formuláre.

Napojí platobnú bránu.

Pomôže aplikáciu nasadiť.

A na prvý pohľad všetko funguje.

Používateľ sa vie registrovať.

Administrátor sa vie prihlásiť.

Dáta sa ukladajú.

API odpovedá.

Objednávka prejde.

Práve v tomto bode však vzniká veľmi dôležitá otázka:

Kto overil, že aplikácia je nielen funkčná, ale aj bezpečná?

Funkčnosť a bezpečnosť totiž nie sú to isté.

Aplikácia môže dokonale plniť zadanie a zároveň obsahovať chybu, ktorá umožní používateľovi pristupovať k údajom iného používateľa.

Môže správne ukladať formulár a pritom nedostatočne validovať vstup.

Môže mať prihlasovanie, ale nedostatočnú kontrolu oprávnení.

Môže bezpečne pracovať pri bežnom používaní, ale zlyhať pri neočakávanom alebo úmyselne škodlivom vstupe.

Môže používať knižnicu, ktorá má známu bezpečnostnú chybu.

A v repozitári môže zostať API kľúč, heslo alebo connection string.

Vibe coding preto nemení potrebu bezpečnostného auditu. Skôr mení to, ako rýchlo dokážeme vytvoriť veľké množstvo kódu, ktoré musí niekto zodpovedne preveriť.

Čo je vibe coding?

Pojmom vibe coding sa bežne označuje spôsob vývoja, pri ktorom človek významnú časť implementácie zadáva prostredníctvom prirodzeného jazyka AI coding nástroju alebo agentovi.

Vývojár alebo používateľ nemusí písať každý riadok kódu ručne.

Namiesto toho opisuje požadované správanie:

„Pridaj registráciu používateľa, prihlasovanie, reset hesla a administráciu.“

AI následne navrhne alebo vytvorí implementáciu.

Tento spôsob práce môže výrazne urýchliť prototypovanie aj bežný vývoj.

Problém vzniká vtedy, keď sa medzi:

„AI to naprogramovala“

a:

„aplikáciu sme nasadili do produkcie“

stratí profesionálna kontrolná vrstva.

AI-generovaný kód nie je automaticky nebezpečný

Je dôležité nezačať túto diskusiu strašením.

AI-generovaný kód nie je automaticky menej bezpečný iba preto, že ho vytvorila AI.

Rovnako ručne napísaný kód nie je automaticky bezpečný iba preto, že ho vytvoril človek.

Bezpečnostné chyby existovali dávno pred generatívnou AI.

MITRE vo svojom zozname CWE eviduje stovky typov softvérových slabín a každoročne zostavuje zoznam najvýznamnejších z nich.

V aktuálnom CWE Top 25 za rok 2025 patria medzi najvyššie hodnotené slabiny napríklad:

• Cross-Site Scripting,
• SQL Injection,
• Cross-Site Request Forgery,
• Missing Authorization,
• Path Traversal,
• OS Command Injection,
• Code Injection,
• Unrestricted File Upload,
• Deserialization of Untrusted Data,
• Improper Access Control,
• Missing Authentication for Critical Function,
• Server-Side Request Forgery.

Ide o všeobecné softvérové slabiny.

Nie o „AI chyby“.

AI však dokáže generovať kód veľmi rýchlo a používateľ môže implementovať oblasti, ktorým úplne nerozumie.

To mení rizikový profil procesu.

Aj samotní výrobcovia AI coding nástrojov odporúčajú kontrolu

Nie je to iba názor bezpečnostných konzultantov.

GitHub vo svojej dokumentácii pre kontrolu AI-generovaného kódu odporúča:

• spustiť automatické testy,
• použiť statickú analýzu,
• kontrolovať bezpečnostné problémy,
• preverovať nové závislosti,
• kontrolovať, či kód zodpovedá architektúre a zámeru projektu,
• a AI-generované zmeny manuálne preverovať.

GitHub zároveň výslovne upozorňuje, že generovaný kód môže obsahovať bezpečnostné zraniteľnosti alebo iné problémy.

To je veľmi dôležité.

AI coding nástroj má byť nástrojom vývojára, nie automatickým bezpečnostným certifikátom výsledného softvéru.

OpenAI pri vlastnom používaní coding agentov rieši hranice a kontrolu

Podobný princíp vidíme aj pri agentnom programovaní.

OpenAI pri opise bezpečného používania Codexu vo vlastných pracovných postupoch zdôrazňuje technické hranice, riadenie prístupu, ľudské schválenie rizikovejších operácií a uchovávanie telemetrie o činnosti agenta.

To ukazuje širší princíp:

bezpečnosť AI vývoja nie je iba otázkou kvality jedného vygenerovaného súboru.

Patrí sem aj:

• k čomu má agent prístup,
• aké príkazy môže vykonať,
• aké prostredie môže meniť,
• aké tajomstvá môže vidieť,
• a ktoré operácie vyžadujú schválenie človeka.

Najväčší omyl: „Aplikácia funguje, takže je v poriadku“

Funkčný test overuje napríklad:

„Dokáže sa používateľ prihlásiť?“

Bezpečnostný test sa pýta:

„Dokáže používateľ obísť prihlasovanie?“

Funkčný test overuje:

„Dokáže používateľ otvoriť svoju faktúru?“

Bezpečnostný test sa pýta:

„Dokáže zmenou identifikátora otvoriť faktúru iného používateľa?“

Funkčný test:

„Dokáže administrátor vymazať používateľa?“

Bezpečnostná kontrola:

„Kontroluje server pri každom volaní skutočne rolu používateľa?“

Toto je zásadný rozdiel.

Bežné používanie aplikácie testuje to, čo má používateľ robiť. Bezpečnostný audit testuje aj to, čo by robiť nemal.

Aktuálny OWASP Top 10:2025

OWASP v roku 2025 vydal novú verziu svojho známeho prehľadu najvýznamnejších bezpečnostných rizík webových aplikácií.

Aktuálny OWASP Top 10:2025 obsahuje:

1. Broken Access Control
2. Security Misconfiguration
3. Software Supply Chain Failures
4. Cryptographic Failures
5. Injection
6. Insecure Design
7. Authentication Failures
8. Software or Data Integrity Failures
9. Security Logging and Alerting Failures
10. Mishandling of Exceptional Conditions

Už tento zoznam ukazuje, prečo nestačí spustiť jeden automatický scanner.

Niektoré problémy sa týkajú kódu.

Iné architektúry.

Ďalšie konfigurácie.

A veľká časť oprávnení a business logiky sa dá správne posúdiť iba v kontexte konkrétnej aplikácie.

OWASP Top 10 nie je kompletný bezpečnostný checklist

Aj toto je dôležitý rozdiel.

OWASP Top 10 je predovšetkým awareness dokument – prehľad významných rizík webových aplikácií.

Samotný OWASP pri budovaní moderného Application Security programu odporúča na systematické overovanie používať OWASP Application Security Verification Standard – ASVS.

OWASP dokonca upozorňuje, že nástroje nedokážu kompletne detegovať, testovať alebo ochrániť proti všetkým kategóriám Top 10.

Pre profesionálny audit je preto ASVS vhodnejší základ než tvrdenie:

„Scanner skontroloval OWASP Top 10, takže aplikácia je bezpečná.“

OWASP ASVS 5.0: Lepší základ pre skutočný audit

OWASP Application Security Verification Standard poskytuje konkrétne požiadavky na overovanie bezpečnostných kontrol webových aplikácií.

Aktuálna stabilná verzia 5.0.0 bola vydaná v máji 2025.

ASVS sa zaoberá napríklad:

• architektúrou a threat modelingom,
• autentifikáciou,
• session managementom,
• access controlom,
• validáciou a sanitizáciou vstupov,
• kryptografiou,
• error handlingom a logovaním,
• ochranou dát,
• komunikáciou,
• business logikou,
• súbormi a zdrojmi,
• API a webovými službami,
• konfiguráciou.

To je výrazne širší pohľad než jednoduché skenovanie niekoľkých známych typov útokov.

Čo by sme kontrolovali na aplikácii vytvorenej pomocou AI?

Pri bezpečnostnom audite by sme nezačínali otázkou:

„Napísala to AI?“

Začali by sme otázkou:

„Čo táto aplikácia robí, aké dáta spracúva a čo by sa mohlo stať, keby niektorá bezpečnostná kontrola zlyhala?“

Podľa typu aplikácie by audit obsahoval viacero vrstiev.

1. Architektúra a trust boundaries

Najskôr potrebujeme pochopiť systém.

Čo komunikuje s čím?

Kde sa nachádzajú dáta?

Ktoré komponenty sú dostupné z internetu?

Kde prechádza používateľský vstup?

Ktoré služby majú zvýšené oprávnenia?

Typická aplikácia môže obsahovať:

Prehliadač používateľa
        ↓
Web / frontend
        ↓
Backend API
        ↓
Databáza
        ↓
Externé služby
        ↓
E-mail / platby / cloud storage / AI API

Každé prepojenie predstavuje hranicu, ktorú treba posúdiť.

Bez znalosti architektúry totiž security scanner často nevie, čo je pre aplikáciu skutočne kritické.

2. Autentifikácia: Kto je používateľ?

Prihlásenie patrí medzi najcitlivejšie časti aplikácie.

Audit kontroluje napríklad:

• spracovanie hesiel,
• reset hesla,
• ochranu prihlasovacích tokenov,
• životnosť sessions,
• odhlásenie,
• ochranu citlivých operácií,
• prípadnú viacfaktorovú autentifikáciu.

Veľmi nebezpečný omyl je implementovať vlastnú kryptografiu alebo vlastný „šikovný“ spôsob ukladania hesiel namiesto použitia dobre zavedených bezpečnostných mechanizmov platformy.

V .NET aplikácii môže byť napríklad výrazne rozumnejšie správne použiť overené frameworkové mechanizmy než navrhovať vlastný systém autentifikácie od nuly.

3. Autorizácia: Čo smie používateľ robiť?

Autentifikácia odpovedá:

„Kto ste?“

Autorizácia odpovedá:

„Čo smiete robiť?“

A práve Broken Access Control je v OWASP Top 10:2025 na prvom mieste.

Predstavme si API:

GET /api/orders/1058

Používateľ je prihlásený.

Objednávka 1058 je jeho.

Všetko funguje.

Čo sa však stane, ak pošle:

GET /api/orders/1059

a objednávka 1059 patrí inému používateľovi?

Ak server kontroluje iba to, že používateľ je prihlásený, ale nie to, že daný zdroj smie otvoriť, vzniká vážna chyba v access controle.

Frontendové skrytie tlačidla nie je bezpečnostná kontrola.

Oprávnenie musí kontrolovať server.

4. Horizontálne a vertikálne zvýšenie oprávnení

Bezpečnostný audit musí preveriť dva rozdielne scenáre.

Horizontálny prístup

Používateľ A pristupuje k údajom používateľa B.

Vertikálny prístup

Bežný používateľ získa možnosť vykonávať administrátorské operácie.

To sú chyby, ktoré automatizovaný scanner bez kontextu rolí nemusí správne rozpoznať.

5. Business logic: Oblasť, ktorú scanner často nechápe

Predstavme si rezervačný systém.

Normálny proces:

Vybrať termín
→ overiť dostupnosť
→ zaplatiť
→ potvrdiť rezerváciu

Bezpečnostná otázka znie:

Dá sa preskočiť druhý alebo tretí krok a zavolať API posledného kroku priamo?

Podobné problémy môžu vzniknúť pri:

• zľavových kupónoch,
• platbách,
• objednávkach,
• limitoch používateľov,
• registráciách,
• stavových workflow,
• schvaľovaní dokumentov.

OWASP pri Secure Code Review osobitne zdôrazňuje business logic, stavové prechody, oprávnenia a workflow bypassy ako oblasti, kde je potrebné ľudské pochopenie kontextu.

6. Injection: SQL už nie je jediný problém

Injection patrí medzi klasické bezpečnostné problémy.

Najznámejší príklad je SQL Injection.

Riziko však môže existovať aj pri:

• operačných príkazoch,
• LDAP dotazoch,
• NoSQL dotazoch,
• template enginoch,
• dynamickom vykonávaní kódu.

Základným princípom je nedovoliť, aby neoverený vstup používateľa zmenil význam príkazu, ktorý aplikácia vykonáva.

Pri databázach preto využívame parametrizované dotazy alebo správne použitie bezpečných ORM mechanizmov.

String concatenation používateľského vstupu do SQL príkazu je typický anti-pattern, ktorý si zaslúži okamžitú pozornosť.

7. Cross-Site Scripting – XSS

XSS je v aktuálnom MITRE CWE Top 25 na prvom mieste.

Problém vzniká, keď aplikácia vloží nedôveryhodný obsah do webovej stránky bez správneho kontextového encodingu alebo sanitizácie.

Typickým miestom rizika sú:

• komentáre,
• profily používateľov,
• rich-text editory,
• administrácia,
• obsah načítaný z API.

Moderný framework môže množstvo situácií automaticky ošetriť.

Riziko však vzniká napríklad pri obchádzaní bezpečného templatingu alebo pri priamom vkladaní HTML.

8. CSRF

Cross-Site Request Forgery môže byť relevantný najmä pri aplikáciách používajúcich cookie-based autentifikáciu.

Útočník sa pokúša prinútiť prehliadač prihláseného používateľa vykonať operáciu, ktorú používateľ nezamýšľal.

Ochrana závisí od použitej architektúry a autentifikačného modelu.

Preto nestačí univerzálna veta:

„Máme API, CSRF sa nás netýka.“

Treba poznať konkrétny spôsob prenosu a overovania identity.

9. File upload: „Nahraj obrázok“ môže byť bezpečnostná funkcia

Upload súborov vyzerá ako jednoduchá vlastnosť.

V skutočnosti treba riešiť napríklad:

• povolené typy súborov,
• skutočný obsah súboru,
• veľkosť,
• miesto uloženia,
• názov súboru,
• prístupové práva,
• spracovanie obrázkov alebo dokumentov.

Samotná kontrola prípony .jpg nemusí byť dostatočná.

Aplikácia musí pracovať s uploadom ako s nedôveryhodným vstupom.

10. Path traversal

Ak používateľ môže ovplyvniť cestu k súboru, treba preveriť, či nedokáže opustiť povolený adresár.

Path Traversal patrí aj medzi najvyššie hodnotené slabiny v MITRE CWE Top 25 za rok 2025.

Riziko môže vzniknúť napríklad pri:

• sťahovaní dokumentov,
• zobrazovaní príloh,
• spracovaní šablón,
• zálohovaní súborov.

11. SSRF: Server nesmie slepo načítavať ľubovoľnú URL

Server-Side Request Forgery vzniká vtedy, keď aplikácia umožní používateľovi ovplyvniť adresu, ktorú následne načíta samotný server.

Typickými funkciami môžu byť:

• import z URL,
• náhľad externého odkazu,
• webhook test,
• sťahovanie dokumentov,
• načítanie vzdialeného obrázka.

Bez správnych obmedzení môže server pristupovať aj k miestam, ktoré nie sú dostupné priamo z internetu.

Pri cloudovej infraštruktúre môže mať takáto chyba obzvlášť nepríjemné dôsledky.

12. Secrets: API kľúč nepatrí do Git repozitára

AI coding agent potrebuje pri práci často množstvo kontextu.

Repozitár pritom môže obsahovať:

• connection stringy,
• API kľúče,
• access tokeny,
• privátne certifikáty,
• heslá.

Takéto tajomstvá nemajú byť natvrdo uložené v zdrojovom kóde.

Majú sa spravovať pomocou vhodného secrets managementu a oddeliť podľa prostredia.

GitHub pri agentnom vývoji používa secret scanning práve na identifikovanie takýchto problémov.

13. Environment variables samy osebe nevyriešia správu tajomstiev

Veľmi častý automatický návrh znie:

Presuňte heslo do environment variable.

Je to lepšie než commitnúť heslo do verejného repozitára.

Stále však treba vyriešiť:

• kto môže premennú čítať,
• kde je hodnota uložená,
• ako sa rotuje,
• či sa náhodou nevypisuje do logu,
• ako sa spravujú rôzne prostredia.

Bezpečnosť tajomstiev je proces, nie názov konfiguračného súboru.

14. Závislosti: AI môže pridať balík, ktorý ste nikdy predtým nevideli

Moderná aplikácia môže obsahovať desiatky až stovky externých balíkov.

AI môže pri riešení úlohy automaticky navrhnúť ďalší.

GitHub pri kontrole AI-generovaného kódu výslovne odporúča preverovať:

• či balík skutočne existuje,
• či je udržiavaný,
• odkiaľ pochádza,
• akú má licenciu,
• či neobsahuje známe zraniteľnosti.

To súvisí aj s veľkou zmenou OWASP Top 10:2025.

Software Supply Chain Failures sú samostatnou kategóriou číslo 3.

15. Supply chain nie je iba „starý npm package“

Softvérový supply chain zahŕňa omnoho viac:

• NuGet, npm, PyPI a ďalšie balíky,
• build nástroje,
• GitHub Actions alebo iné CI/CD komponenty,
• Docker images,
• SDK,
• third-party JavaScript,
• externé API a služby.

Bezpečnostný audit preto preveruje aj to, z čoho je aplikácia vlastne postavená.

16. SBOM: Čo vlastne máme v aplikácii?

Software Bill of Materials – SBOM – predstavuje inventár softvérových komponentov.

Pri väčšom projekte môže pomôcť odpovedať na otázku:

„Používame vo svojom produkte komponent, v ktorom bola práve zverejnená kritická zraniteľnosť?“

Bez prehľadu závislostí sa na túto otázku odpovedá veľmi ťažko.

17. Security misconfiguration

Druhá kategória OWASP Top 10:2025 je Security Misconfiguration.

Aplikácia môže mať relatívne kvalitný kód, ale byť nasadená nevhodným spôsobom.

Typické oblasti kontroly:

• debug režim v produkcii,
• detailné chybové stránky,
• predvolené účty,
• zbytočne otvorené služby,
• nesprávne CORS pravidlá,
• nepotrebné HTTP metódy,
• neaktuálne komponenty,
• chybné cloud permissions.

18. CORS nie je autentifikácia

Veľmi časté nepochopenie:

„API máme zabezpečené CORS-om.“

CORS riadi určitú komunikáciu webových prehliadačov medzi rôznymi originmi.

Nie je náhradou autentifikácie alebo autorizácie serverového API.

Útočník nemusí vaše API volať z bežného prehliadača.

Bezpečnostné rozhodnutia musia byť vynútené na serveri.

19. Kryptografia: Nevymýšľajte vlastné algoritmy

Cryptographic Failures sú stále samostatnou kategóriou OWASP Top 10:2025.

Pri audite preverujeme:

• či sú citlivé dáta chránené pri prenose,
• či sú heslá správne hashované,
• či sa používajú moderné kryptografické mechanizmy,
• kde sú uložené kľúče,
• ako sa s nimi pracuje.

Zásadné pravidlo:

nevytvárajte vlastnú kryptografiu tam, kde existuje zavedené, správne implementované riešenie.

20. Logy môžu zachrániť incident – alebo prezradiť heslo

Security Logging and Alerting Failures sú v OWASP Top 10:2025 samostatnou kategóriou.

Bez logov nemusíte vedieť:

• že niekto opakovane skúša cudzie účty,
• že používateľ získava zakázané zdroje,
• že API generuje nezvyčajné chyby,
• že bol zmenený kritický údaj.

Na druhej strane logovanie musí byť navrhnuté správne.

Do logov nemajú bez rozmyslu smerovať:

• heslá,
• access tokeny,
• session cookies,
• celé platobné údaje,
• iné citlivé osobné informácie, ak ich tam nepotrebujeme.

21. Rate limiting a ochrana zdrojov

Aj funkčné API sa môže stať problémom, ak môže jeden používateľ bez obmedzenia vykonávať náročnú operáciu.

Týka sa to napríklad:

• login endpointov,
• resetu hesla,
• odosielania e-mailov,
• generovania PDF,
• uploadu súborov,
• AI API volaní.

Pri AI aplikáciách môže mať chýbajúci limit aj priamy finančný dopad, ak každé volanie spotrebúva platené API zdroje.

22. Multi-tenant aplikácie potrebujú osobitnú kontrolu izolácie

Ak rovnakú aplikáciu používa viac firiem alebo zákazníkov, treba preveriť tenant isolation.

Typická kritická chyba:

dotaz filtruje záznam podľa ID, ale nefiltruje podľa TenantID.

Aplikácia pritom môže pri normálnom používaní fungovať úplne bezchybne.

Problém sa prejaví až pri pokuse pristúpiť k cudziemu objektu.

Pre SaaS aplikácie je preto kontrola izolácie zákazníckych dát jednou z najdôležitejších oblastí auditu.

23. Administrácia musí byť auditovaná prísnejšie než verejný formulár

Administrácia často obsahuje najcitlivejšie funkcie systému.

Môže:

• meniť používateľov,
• exportovať dáta,
• meniť ceny,
• schvaľovať platby,
• spravovať oprávnenia.

Audit preto sleduje nielen prihlásenie do administrácie, ale aj:

• autorizáciu jednotlivých operácií,
• session management,
• MFA podľa rizika,
• auditné logy,
• ochranu pred CSRF,
• bezpečnosť exportov.

24. API treba auditovať samostatne

Moderné frontendové aplikácie často komunikujú takmer výhradne cez API.

To znamená, že skrytie tlačidla vo frontende nemá bezpečnostný význam, ak server príslušnú operáciu stále dovolí.

Pri API audite kontrolujeme napríklad:

• autentifikáciu,
• autorizáciu jednotlivých objektov,
• validáciu dát,
• rate limiting,
• mass assignment,
• nepotrebné údaje v odpovediach,
• správne spracovanie chýb.

25. Error handling: Chyba nesmie odhaliť vnútornosti aplikácie

OWASP Top 10:2025 priniesol novú kategóriu Mishandling of Exceptional Conditions.

Chybové stavy sú často menej testované než bežný „happy path“.

Aplikácia však musí bezpečne reagovať aj na:

• neplatné vstupy,
• výpadok databázy,
• timeout externej služby,
• neexistujúci súbor,
• neočakávaný stav workflow.

Chybová odpoveď by zároveň nemala používateľovi prezrádzať:

• stack trace,
• SQL dotaz,
• serverové cesty,
• connection string,
• iné citlivé interné informácie.

Čo dokáže automatický bezpečnostný scanner?

Automatizované nástroje majú pri audite dôležité miesto.

Môžu napríklad pomáhať identifikovať:

• známe zraniteľnosti závislostí,
• niektoré rizikové vzory v zdrojovom kóde,
• uniknuté secrets,
• niektoré konfiguračné problémy,
• určité chyby dostupné dynamickým testovaním.

Veľkou výhodou automatizácie je rýchlosť a opakovateľnosť.

Scanner môžete spustiť pri každom pull requeste alebo deployment pipeline.

To však nie je celý audit.

Čo scanner typicky nevie spoľahlivo rozhodnúť?

Automatizovaný nástroj často nevie pochopiť:

• že používateľ A nemá vidieť objednávku používateľa B,
• že zľavu možno použiť iba raz,
• že faktúru môže schváliť iba určitá rola,
• že po určitej zmene stavu už operácia nemá byť možná,
• že export obsahuje viac údajov, než daný pracovník potrebuje.

To sú problémy závislé od business kontextu.

OWASP Secure Code Review preto priamo opisuje manuálnu kontrolu ako doplnok automatických SAST a DAST nástrojov.

SAST, DAST, SCA a secret scanning: Aký je medzi nimi rozdiel?

Metóda	Čo analyzuje	Typické použitie
SAST	Zdrojový kód bez spustenia aplikácie.	Hľadanie rizikových vzorov a dátových tokov.
DAST	Bežiacu aplikáciu zvonka.	Testovanie správania nasadenej aplikácie.
SCA	Externé knižnice a závislosti.	Hľadanie známych zraniteľností komponentov.
Secret scanning	Repozitár a ďalšie zdroje.	Hľadanie API kľúčov, tokenov a ďalších tajomstiev.
Manual secure code review	Kód, architektúru a logiku.	Kontextové a business-logic problémy.
Penetračné testovanie	Bežiacu aplikáciu a jej attack surface.	Praktické overovanie zneužiteľnosti a bezpečnostných kontrol.

Profesionálny audit nepoužíva jednu z týchto metód ako náhradu všetkých ostatných.

Vyberá ich podľa rizika a architektúry konkrétneho projektu.

NIST Secure Software Development Framework

Bezpečnosť by v ideálnom prípade nemala vzniknúť až deň pred nasadením aplikácie.

NIST Secure Software Development Framework – SSDF – odporúča integrovať bezpečnostné postupy priamo do životného cyklu vývoja softvéru.

Cieľom je:

• znižovať počet zraniteľností už počas vývoja,
• znižovať dopad tých, ktoré zostanú neodhalené,
• a riešiť ich príčiny tak, aby sa neopakovali.

Aktuálnou finálnou verziou základného dokumentu je NIST SP 800-218 SSDF 1.1.

NIST zároveň zverejnil návrh verzie 1.2, ktorý bol v čase prípravy tohto článku stále draftom.

To je dobrý príklad toho, prečo pri bezpečnostných štandardoch treba uvádzať konkrétnu verziu dokumentu.

Secure by Design: Bezpečnosť nemá byť platený doplnok

CISA a partnerské bezpečnostné autority presadzujú princíp Secure by Design.

Jednou z jeho základných myšlienok je, že zodpovednosť za bezpečný produkt nemá byť prenesená iba na zákazníka.

Výrobca softvéru má bezpečnosť zohľadňovať už pri návrhu produktu.

To je veľmi vhodný princíp aj pre AI-assisted development.

Namiesto procesu:

AI vytvorí aplikáciu
→ aplikáciu nasadíme
→ raz možno spravíme security audit

je lepšie:

Požiadavky
→ návrh architektúry
→ threat model
→ AI-assisted development
→ code review
→ automatické security kontroly
→ manuálne overenie rizikových oblastí
→ testovanie
→ deployment
→ monitoring
→ priebežné aktualizácie

A čo Codex alebo AI bezpečnostný agent?

Aj bezpečnostné audity začínajú využívať AI.

OpenAI v marci 2026 predstavil Codex Security ako application security agenta, ktorý sa snaží analyzovať kontext projektu, hľadať komplexnejšie zraniteľnosti a validovať nálezy.

Je to zaujímavý smer.

Neznamená to však, že každú aplikáciu môžeme nechať „skontrolovať ďalšou AI“ a tým audit považovať za ukončený.

Bezpečnostný nástroj stále potrebuje:

• správne definovaný scope,
• kontext aplikácie,
• validáciu nálezov,
• prioritizáciu podľa reálneho dopadu,
• a pri kritických aplikáciách odborné ľudské posúdenie.

AI môže byť súčasťou auditu. Nemá byť jediným audítorom.

Rovnako ako pri vývoji môže AI urýchliť bezpečnostnú kontrolu.

Môže pomôcť:

• prechádzať veľký codebase,
• hľadať podozrivé dátové toky,
• analyzovať konfiguráciu,
• navrhovať testovacie scenáre,
• vysvetľovať nálezy vývojárovi.

Stále však potrebujeme kontrolovať, či nález:

• skutočne existuje,
• je zneužiteľný,
• má správne určenú závažnosť,
• a navrhovaná oprava nevytvára ďalší problém.

Najväčším rizikom nie je AI. Je ním falošný pocit istoty.

Najproblematickejšia situácia môže vyzerať takto:

„Aplikáciu vytvorila špičková AI, takže bezpečnosť musí byť vyriešená.“

Alebo:

„Scanner nič nenašiel, takže tam žiadna zraniteľnosť nie je.“

Takéto závery nevyplývajú z dostupných bezpečnostných štandardov.

Seriózne overovanie softvéru pracuje s vrstvami kontrol.

Ako by mohol vyzerať bezpečnostný audit vibe-coded aplikácie?

Pre menšiu firemnú webovú aplikáciu by sme audit rozdelili minimálne na tieto fázy.

Fáza 1: Scope a architektúra

Zistíme:

• čo aplikácia robí,
• aké dáta spracúva,
• aké technológie používa,
• aké externé služby využíva,
• aké používateľské roly obsahuje.

Fáza 2: Threat model

Identifikujeme:

• kritické aktíva,
• trust boundaries,
• možné vstupné body,
• významné scenáre zneužitia.

Fáza 3: Automatická analýza

Podľa technológie:

• SAST,
• SCA,
• secret scanning,
• konfiguračné kontroly,
• prípadne DAST.

Fáza 4: Manuálny secure code review

Prioritne:

• authentication,
• authorization,
• business logic,
• spracovanie vstupov,
• práca s citlivými dátami,
• file upload,
• externé integrácie.

Fáza 5: API a runtime testovanie

Overíme správanie bežiacej aplikácie a relevantné bezpečnostné kontroly.

Fáza 6: Konfigurácia a deployment

Skontrolujeme:

• production konfiguráciu,
• secrets,
• HTTPS a TLS,
• bezpečnostné hlavičky,
• CORS,
• logging,
• cloud permissions podľa dostupného scope.

Fáza 7: Report

Každý relevantný nález by mal obsahovať:

• popis problému,
• dotknutý komponent,
• riziko a možný dopad,
• dôkaz alebo spôsob reprodukcie v bezpečnom rozsahu,
• odporúčanú opravu,
• prioritu.

Fáza 8: Retest

Po oprave kritických a významných problémov sa overí, či bol problém skutočne odstránený a či oprava nevytvorila regresiu.

Bezpečnostný audit nie je zoznam 300 warningov

Automatický nástroj môže vytvoriť veľké množstvo nálezov.

Časť z nich môže byť:

• false positive,
• málo významná,
• nerelevantná pre danú architektúru,
• alebo iba všeobecné odporúčanie.

Úlohou odborného auditu je nálezy validovať a zoradiť podľa skutočného rizika.

Napríklad:

Chýbajúca bezpečnostná hlavička

nemusí mať rovnakú prioritu ako:

možnosť stiahnuť dokument iného zákazníka zmenou ID v URL.

Bez kontextu môže byť počet nálezov zavádzajúci.

Čo by mal dostať klient ako výsledok?

Výstup by mal byť použiteľný pre majiteľa firmy aj vývojára.

Nie iba export scanneru.

Odporúčame minimálne:

Časť	Obsah
Executive summary	Zrozumiteľné zhodnotenie hlavných rizík.
Scope	Čo bolo a nebolo predmetom auditu.
Metodika	Použité štandardy a metódy.
Nálezy	Konkrétne bezpečnostné problémy.
Dopad	Čo môže problém znamenať pre firmu alebo používateľa.
Odporúčaná oprava	Praktický smer riešenia.
Priorita	Poradie riešenia podľa rizika.
Retest	Výsledok opätovného overenia opráv.

Je možné automatizovať základný bezpečnostný audit ako SaaS?

Áno – ale treba veľmi presne definovať, čo nástroj robí.

Automatizovaný produkt môže veľmi dobre kontrolovať napríklad:

• bezpečnostné HTTP hlavičky,
• TLS konfiguráciu,
• verejne viditeľné technické informácie,
• známe zraniteľnosti závislostí, ak má prístup k projektu,
• secrets,
• vybrané vzory v zdrojovom kóde,
• niektoré konfiguračné chyby.

Pri repozitári môže robiť aj SAST a dependency analysis.

Takýto nástroj môže byť výborným prvým filtrom.

Nesmie však zákazníkovi vytvárať dojem:

„Máte skóre 92/100, vaša aplikácia je bezpečná.“

To by bolo neprimerané tomu, čo automatizovaná kontrola dokáže overiť.

Automatický audit a profesionálny audit môžu tvoriť jeden produktový lievik

Z obchodného pohľadu dáva zmysel rozdeliť službu do vrstiev.

Úroveň 1 – automatická kontrola

Rýchla základná analýza.

Úroveň 2 – odborný code review

Manuálna kontrola najrizikovejších komponentov.

Úroveň 3 – kompletný application security audit

Architektúra, kód, dependencies, runtime, konfigurácia a business logic.

Úroveň 4 – priebežný monitoring

Security checks v CI/CD a pravidelná kontrola nových zmien.

Tým sa z jednorazového auditu môže stať dlhodobá služba.

Kedy by sme audit považovali za veľmi dôležitý?

Najmä ak aplikácia:

• spracúva osobné údaje,
• pracuje s platbami,
• obsahuje používateľské účty,
• má administráciu,
• umožňuje upload súborov,
• komunikuje s internými firemnými systémami,
• ukladá citlivé dokumenty,
• používa viacero používateľských rolí,
• funguje ako multi-tenant SaaS,
• umožňuje AI agentovi vykonávať akcie.

Čím väčší možný dopad zneužitia, tým hlbšia by mala byť kontrola.

Aplikácia vytvorená za víkend môže spracúvať rovnaké dáta ako aplikácia vyvíjaná rok

Toto je podľa nás jedna z najdôležitejších zmien, ktoré prináša vibe coding.

Čas potrebný na vytvorenie aplikácie už nie je dobrým odhadom jej rizikovosti.

Malá aplikácia vytvorená za dva dni môže mať:

• 100 používateľov,
• osobné údaje,
• platobnú integráciu,
• administrátorský účet,
• prístup k firemnému CRM.

Bezpečnostné požiadavky preto musia vychádzať z toho, čo aplikácia robí, nie z toho, ako dlho jej naprogramovanie trvalo.

A čo aplikácia určená iba interne?

Aj interná aplikácia potrebuje primerané zabezpečenie.

„Nie je verejne propagovaná“ neznamená automaticky:

„Nikto sa k nej nemôže dostať.“

Treba preveriť:

• či je dostupná z internetu,
• akú autentifikáciu používa,
• aké údaje obsahuje,
• kto má oprávnenie,
• ako sa aktualizuje.

Bezpečnosť AI agentov prináša ďalšiu vrstvu

Ak aplikácia obsahuje AI agenta, ktorý môže vykonávať akcie, attack surface sa rozširuje.

Agent môže mať nástroje na:

• odoslanie e-mailu,
• úpravu CRM,
• vytvorenie objednávky,
• čítanie dokumentov,
• prácu so súbormi.

V takom prípade už nekontrolujeme iba tradičnú webovú bezpečnosť.

Musíme preveriť aj:

• hranice oprávnení agenta,
• validáciu tool callov,
• potrebu ľudského schválenia,
• oddelenie dôveryhodných a nedôveryhodných vstupov,
• ochranu citlivého kontextu,
• auditovateľnosť vykonaných akcií.

To je už samostatná téma, ktorej sa budeme venovať podrobnejšie.

Praktický checklist pre majiteľa vibe-coded aplikácie

Ak ste si vytvorili aplikáciu pomocou ChatGPT, Codexu, GitHub Copilotu, Claude Code alebo iného AI coding nástroja, pred ostrým nasadením by ste mali vedieť odpovedať aspoň na tieto otázky:

1. Viem presne, aké používateľské roly aplikácia obsahuje?
2. Kontroluje server oprávnenie pri každej citlivej operácii?
3. Dokáže používateľ pristúpiť iba k svojim dátam?
4. Sú heslá ukladané bezpečným frameworkovým mechanizmom?
5. Je reset hesla bezpečný a časovo obmedzený?
6. Nie sú v repozitári API kľúče alebo heslá?
7. Vieme, aké externé knižnice aplikácia používa?
8. Kontrolujeme ich známe zraniteľnosti?
9. Sú všetky vstupy validované na serveri?
10. Používame parametrizované databázové dotazy?
11. Je upload súborov obmedzený a kontrolovaný?
12. Nezverejňuje produkcia debug informácie?
13. Sú produkčné a vývojové prostredia oddelené?
14. Máme logy významných bezpečnostných udalostí?
15. Neukladáme do logov secrets alebo citlivé dáta?
16. Má aplikácia primerané rate limiting mechanizmy?
17. Sú externé API volania obmedzené na potrebné ciele?
18. Fungujú správne chybové stavy?
19. Existujú automatické testy?
20. Prešiel kód statickou bezpečnostnou analýzou?
21. Prešli dependencies bezpečnostnou kontrolou?
22. Skontroloval kritické časti človek, ktorý rozumie bezpečnosti?
23. Máme zálohy a overený spôsob obnovy?
24. Vieme, čo budeme robiť po objavení zraniteľnosti?
25. Vieme, kto je za bezpečnosť aplikácie zodpovedný?

Ak je pri viacerých otázkach odpoveď:

„Neviem.“

neznamená to automaticky, že aplikácia je zraniteľná.

Je to však dobrý dôvod na odbornú kontrolu.

Čo by sme ako vývojári Consultee nerobili?

Bezpečnostnú službu by sme nemali predávať tvrdeniami:

„Našli sme 237 chýb, váš web je nebezpečný.“

Ani:

„Náš scanner skontroloval OWASP Top 10 na 100 %.“

A už vôbec nie:

„Po našom audite už aplikáciu nemožno hacknúť.“

Takéto tvrdenia nemožno profesionálne garantovať.

Bezpečnostný audit je posúdenie v definovanom rozsahu, čase a metodike.

Môže výrazne zvýšiť dôveru v bezpečnostný stav aplikácie a odhaliť reálne problémy.

Nie je však matematickým dôkazom, že v softvéri neexistuje žiadna ďalšia chyba.

Čo by sme naopak klientovi mali vedieť povedať?

Napríklad:

„Aplikáciu sme preverili podľa definovaného scope pomocou kombinácie automatickej analýzy, manuálneho code review a testovania vybraných bezpečnostných kontrol. Identifikovali sme konkrétne nálezy, zoradili ich podľa rizika a po oprave kritických problémov vykonali retest.“

To je transparentné a overiteľné.

Môže sa bezpečnostný audit vibe-coded aplikácií stať novou službou?

Podľa nás áno.

Nie preto, že by sme mali tvrdiť, že AI generuje zlý kód.

Ale preto, že AI výrazne znižuje bariéru vstupu do vývoja softvéru.

Aplikácie dnes vytvárajú aj ľudia, ktorí predtým software development nerobili.

Dokážu vytvoriť:

• CRM,
• rezervačný systém,
• internú administráciu,
• SaaS produkt,
• AI asistenta,
• firemný portál.

Často však nemajú skúsenosti s application security.

To vytvára nový priestor medzi:

„aplikácia funguje“

a:

„aplikácia je pripravená bezpečne fungovať v produkcii“.

A práve tento priestor môže byť samostatnou profesionálnou službou.

Záver: AI zrýchlila programovanie. Kontrolu však nezrušila.

Generatívna AI zásadne mení spôsob, akým vzniká softvér.

Vývojár dokáže pracovať rýchlejšie.

Malá firma si dokáže vytvoriť vlastný nástroj.

Podnikateľ môže za niekoľko dní overiť produktový nápad.

To je obrovská príležitosť.

Ale rýchlosť vývoja nemení základné pravidlá softvérovej bezpečnosti.

Stále potrebujeme:

• správnu architektúru,
• bezpečné prihlasovanie,
• správne oprávnenia,
• validáciu vstupov,
• kontrolu závislostí,
• ochranu tajomstiev,
• logovanie,
• testovanie,
• monitoring,
• a odborné posúdenie kritických častí.

AI môže napísať aplikáciu.

AI môže pomôcť napísať testy.

AI môže pomôcť nájsť bezpečnostné problémy.

Ale zodpovednosť za to, čo reálne nasadíme zákazníkom a aké dáta aplikácii zveríme, zostáva na nás.

Preto by posledná otázka pred produkčným deploymentom nemala byť iba:

„Funguje to?“

Mala by byť aj:

„Kto skontroloval, že sa to nedá použiť spôsobom, ktorý sme nezamýšľali?“

Vytvorili ste aplikáciu pomocou AI?

Ak aplikácia pracuje s používateľskými účtami, osobnými údajmi, platbami, internými dokumentmi alebo externými API, pred produkčným nasadením má zmysel preveriť nielen jej funkčnosť, ale aj bezpečnostné kontroly.

V Consultee sa dlhodobo venujeme softvérovému vývoju a technickým auditom. Bezpečnostný audit AI-assisted a vibe-coded aplikácií preto vnímame ako prirodzené rozšírenie technického auditu: kombináciu automatických nástrojov, kontroly zdrojového kódu, architektúry a reálneho fungovania aplikácie.

Cieľom nie je strašiť počtom warningov. Cieľom je nájsť problémy, ktoré môžu mať reálny dopad, a určiť, čo treba opraviť ako prvé.

Ďalšie čítanie na blogu Consultee

Na túto tému prirodzene nadväzuje náš článok Technický SEO audit: chyby, ktoré brzdia rast, ktorý ukazuje podobný princíp pri weboch: problém nemusí byť viditeľný na prvý pohľad, ale môže existovať v technickej vrstve.

Pri projektoch využívajúcich AI odporúčame aj článok Čo sa zmenilo v LLMO.PRO V2: technickejší pohľad na nový AI audit webu, kde vysvetľujeme rozdiel medzi automatizovaným auditom, signálmi pripravenosti a hlbšou odbornou kontrolou.

Odborné zdroje

• OWASP Top 10:2025 – aktuálny prehľad hlavných rizík webových aplikácií.
• OWASP Application Security Verification Standard 5.0 – štandard požiadaviek a overovania technických bezpečnostných kontrol.
• OWASP Secure Code Review Cheat Sheet – metodika manuálnej bezpečnostnej kontroly zdrojového kódu.
• OWASP Web Security Testing Guide – metodika testovania webových aplikácií.
• MITRE CWE Top 25 Most Dangerous Software Weaknesses 2025 – dátovo zostavený prehľad významných softvérových slabín.
• NIST SP 800-218 Secure Software Development Framework – rámec pre bezpečný životný cyklus softvéru.
• CISA Secure by Design – princípy budovania bezpečnosti priamo do softvérových produktov.
• GitHub – Review AI-generated code – odporúčania na testovanie, review, security scanning a kontrolu závislostí AI-generovaného kódu.
• OpenAI – Running Codex safely at OpenAI – technické hranice, schvaľovanie a telemetria pri coding agentoch.
• OpenAI – Codex Security – application security agent predstavený v roku 2026.

Aktualizované: september 2026. Článok je všeobecným odborným materiálom o application security, nie bezpečnostným posúdením konkrétnej aplikácie. Rozsah vhodného auditu závisí od architektúry, spracúvaných dát, používateľských rolí, technológií a obchodného rizika konkrétneho systému.