Ešte pred pár rokmi platilo, že softvér sa dodá a bezpečnosť sa „doladí“ podľa potreby. Cyber Resilience Act (CRA) to otáča naruby. Hovorí jasne: kto softvér vyvíja a uvádza na trh, ten za jeho bezpečnosť aj zodpovedá – od uvedenia na trh až po koniec podpory. To, čo bolo doteraz dobrou praxou, je teraz zákonná povinnosť.

A nejde len o odporúčanie. Za porušenie základných bezpečnostných požiadaviek hrozí firme pokuta až do 15 miliónov eur alebo 2,5 % z celosvetového ročného obratu – podľa toho, čo je vyššie.

Pre vývojárske tímy to znamená jednu zásadnú zmenu: bezpečnosť sa musí riešiť od prvého commitu, priamo vo vývojovej pipeline, nie tesne pred odovzdaním.

Čo presne CRA prináša

Cyber Resilience Act (nariadenie EÚ 2024/2847) je prvý celoeurópsky predpis, ktorý stanovuje povinné bezpečnostné požiadavky pre produkty s digitálnymi prvkami – softvér aj hardvér – predávané na trhu EÚ. Nariadenie už platí a jeho povinnosti nabiehajú postupne: hlásenie zraniteľností je povinné od 11. septembra 2026, väčšina ostatných povinností od 11. decembra 2027.

Z pohľadu bežnej vývojárskej praxe sú kľúčové tri veci:

  • Riadenie zraniteľností. Firma musí mať proces, ako zraniteľnosti nachádza, vyhodnocuje a opravuje. Aktívne zneužívané zraniteľnosti a vážne incidenty treba hlásiť národnému CSIRT-u aj európskej agentúre ENISA cez jednotnú platformu – prvé varovanie do 24 hodín, podrobnejšie do 72 hodín od zistenia.
  • Prehľad o zložení softvéru. Každý produkt musí mať SBOM (Software Bill of Materials) – zoznam všetkých komponentov a knižníc, z ktorých je poskladaný, v strojovo čitateľnom formáte. Uchováva sa minimálne 10 rokov.
  • Bezpečnosť počas celej podpory. Produkt sa nesmie dodať so známou zraniteľnosťou a firma musí poskytovať bezpečnostné aktualizácie zdarma, spravidla aspoň päť rokov.

Spoločný menovateľ všetkých troch bodov: nestačí byť bezpečný, treba to vedieť aj dokázať. A to sa nedá odbaviť manuálne, raz za čas, na konci projektu – musí to byť súčasť každého buildu.

🔍 Skryté číslo: 2

Prečo je SBOM viac než formalita

Väčšina moderného softvéru je poskladaná z open-source knižníc a komponentov od iných firiem – bežná aplikácia môže mať stovky závislostí, a každá z nich je potenciálna cesta pre útočníka. Prípad Log4Shell to ukázal jasne: najväčším problémom firiem nebola samotná oprava, ale zistiť, kde všade sa zraniteľná knižnica vôbec používa.

Presne to má riešiť SBOM. Ak je aktuálny a strojovo čitateľný, otázka „zasiahla nás táto nová zraniteľnosť?“ sa dá zodpovedať v priebehu minút, nie dní – ale len za jednej podmienky, že existuje pre celé portfólio, nielen pre nové projekty. Jednorazovo vytvorený SBOM totiž zastará hneď pri ďalšom vydaní. Zmysel má len vtedy, keď vzniká automaticky, ako súčasť build procesu.

Ako to funguje v praxi?

Požiadavky CRA sme zaviedli priamo do vývojových procesov, ako súčasť DevSecOps:

  • SBOM vzniká automaticky pri každom builde, vo formáte CycloneDX – rovnako ako samotná aplikácia. Každá verzia produktu tak má presný záznam o tom, z čoho je zložená.
  • SBOM následne putuje do Dependency-Tracku – open-source platformy projektu OWASP, ktorú na správu softvérových závislostí používa viac ako 20 000 organizácií vo svete. U nás slúži ako centrálny register všetkých produktov a komponentov. Zraniteľnosti vyhodnocujeme cez nástroj Trivy, ktorý komponenty rozpoznáva podľa presných identifikátorov balíkov, nie len podľa podobnosti názvu – takže falošných poplachov je málo. Register sa vyhodnocuje priebežne, takže o novom riziku vieme aj pri produktoch, ktoré bežia už roky.
  • Každé zistenie má vlastníka a jasný proces – triedime podľa závažnosti, pravdepodobnosti zneužitia a toho, či ide o aktívne zneužívanú zraniteľnosť. Dependency-Track navyše kontroluje aj licencie použitých komponentov voči našim interným pravidlám.

Výsledok: vulnerability management u nás nie je akcia raz za týždeň, ale nepretržitý proces na pozadí každého projektu.

Regulácia ako príležitosť, nie prekážka

Firmy, ktoré majú prehľad o svojich softvérových komponentoch, získavajú viac než len súlad s legislatívou. Rýchlejšie reagujú na incidenty, lepšie plánujú technologický dlh a vedia zákazníkom aj regulátorom ukázať, ako je ich softvér postavený. V tendroch a dodávateľských vzťahoch sa schopnosť doložiť SBOM čoraz častejšie stáva podmienkou spolupráce – nie len výhodou navyše.

Pomôžeme vám pripraviť sa

Ako software house aj systémový integrátor pomáhame firmám zvládnuť túto zmenu v praxi:

  • zavedieme procesy tvorby a správy SBOM priamo do CI/CD pipeline,
  • implementujeme nástroje na priebežné vyhodnocovanie zraniteľností, vrátane Dependency-Tracku a Trivy,
  • zosúladíme vývoj softvéru s požiadavkami CRA – od posúdenia rizík až po technickú dokumentáciu.

Kybernetická odolnosť dnes nie je len otázka IT. Je to otázka dôvery a konkurencieschopnosti.

Ak túto tému riešite, radi budeme vaším partnerom. Napíšte nám.