Open source a CRA: knižnice, ktoré používate, a čo je open-source steward

Open source a Cyber Resilience Act je téma, kde sa mieša úľava aj prekvapenie. Úľava: nariadenie nerobí z každého open-source vývojára výrobcu. Prekvapenie: keď open-source knižnice používate vo svojom komerčnom produkte, zodpovednosť za ne je na vás. Poďme si to rozmotať — a vysvetliť novú rolu „open-source steward".

Nekomerčný open source je mimo

Základné pravidlo: ak vyvíjate open-source softvér mimo obchodnej činnosti — komunitný projekt, ktorý nikto nemonetizuje — nespadáte pod povinnosti výrobcu podľa CRA. Nariadenie zámerne nechce udusiť dobrovoľnícky vývoj. Len čo ale open source monetizujete (platená edícia, licencie, platená podpora ako súčasť komerčnej ponuky), stávate sa výrobcom so všetkým, čo k tomu patrí.

Nová rola: open-source steward (čl. 24)

Medzi „čistý dobrovoľník" a „výrobca" pridáva CRA medzičlánok. Správca open-source softvéru (open-source steward, čl. 24) je právnická osoba, ktorá systematicky a trvalo podporuje vývoj open-source softvéru určeného na komerčné použitie — typicky nadácia alebo organizácia, ktorá stojí za významnými knižnicami. Pre stewarda platí odľahčený režim, nie plné povinnosti výrobcu:

1. zaviesť a dodržiavať politiku kybernetickej bezpečnosti (čl. 24(1)) podporujúcu bezpečný vývoj a riešenie zraniteľností,
2. spolupracovať s orgánmi dohľadu na požiadanie,
3. hlásiť aktívne zneužívané zraniteľnosti a závažné incidenty týkajúce sa ich vývojovej infraštruktúry.

Žiadne CE, žiadne vyhlásenie o zhode — steward nie je výrobca. Ide o primeranú mieru zodpovednosti pre tých, čo držia dôležité kúsky ekosystému.

Najdôležitejšia časť pre bežnú firmu

Väčšina malých firiem nie je ani steward, ani čistý open-source projekt — sú výrobcovia, ktorí open source používajú. A tu je jadro veci: keď vo svojom komerčnom produkte použijete open-source knižnicu, za bezpečnosť toho komponentu v rámci vášho produktu zodpovedáte vy. Čl. 13 od výrobcu žiada náležitú starostlivosť pri integrácii komponentov tretích strán — vrátane tých open-source.

Preložené do praxe: to, že knižnica je „cudzia" a zadarmo, vás nezbavuje povinnosti sledovať v nej zraniteľnosti a reagovať. Presne preto je SBOM (zoznam aj tých open-source komponentov) a ich monitoring základom celého procesu — viac v návode na SBOM.

Ako zvládnuť zodpovednosť za open source v praxi

Dobrá správa: nemusíte auditovať zdrojový kód každej knižnice. Stačí mať proces, ktorý zvláda tri veci:

1. Vedieť, čo používate. SBOM, ktorý obsahuje aj open-source závislosti vrátane verzií — bez neho neviete, čo vlastne sledovať.
2. Sledovať v tom zraniteľnosti. Denné porovnanie proti databázam (OSV, KEV, EPSS) vám povie, keď v niektorej z knižníc vyjde problém.
3. Vedieť reagovať. Keď nález príde, posúdite ho a v prípade potreby aktualizujete knižnicu alebo prijmete zmiernenie — a rozhodnutie zdokumentujete.

Toto je presne tá istá slučka ako pri vlastnom kóde; open source ju len rozširuje o komponenty, ktoré ste nenapísali. Náležitá starostlivosť podľa čl. 13 neznamená „ručíte za bezchybnosť cudzej knižnice", ale „máte prehľad a reagujete".

Časté omyly

1. „Používame open source, tak sme mimo CRA." Nie — mimo je nekomerčný vývoj open source. Používanie open source v komerčnom produkte zodpovednosť neruší.
2. „Za dieru v knižnici zodpovedá jej autor." Voči vášmu zákazníkovi a orgánu dohľadu zodpovedáte za svoj produkt vy, aj za jeho open-source časti.
3. „Steward = ktokoľvek, kto prispieva do open source." Nie — steward je právnická osoba systematicky podporujúca open source pre komerčné použitie (čl. 24), nie jednotlivý prispievateľ.

Príklad: CVE v obľúbenej knižnici

Predstavte si, že v populárnej knižnici, ktorú máte medzi závislosťami, vyjde CVE-2026-YYYY. Čo z toho pre vás plynie ako pre výrobcu, ktorý ju používa v komerčnom produkte?

1. Zistíte, či sa vás týka. Zo SBOM viete, ktoré vaše verzie tú knižnicu (a v akej verzii) obsahujú — a či spadáte do zraniteľného rozsahu.
2. Posúdite a rozhodnete. Ak áno, aktualizujete na opravenú verziu; ak to hneď nejde, prijmete zmiernenie a rozhodnutie zdokumentujete (súčasť risk assessmentu).
3. Ak je aktívne zneužívaná (KEV), zvážite hlásenie podľa čl. 14 a po oprave advisory.

To, že dieru „spôsobila" cudzia knižnica, vás tejto slučky nezbavuje — voči zákazníkovi a orgánu zodpovedáte za svoj produkt ako celok.

Časté otázky

1. Musíme auditovať kód každej závislosti? Nie. Stačí ich mať v SBOM, sledovať v nich zraniteľnosti a vedieť reagovať.
2. Sme malý open-source projekt bez príjmu — sme steward? Skôr nie; steward je právnická osoba systematicky podporujúca open source pre komerčné použitie (čl. 24), nie každý prispievateľ.

Kľúčový bod

Open source a CRA majú tri roviny, ktoré sa oplatí nezamieňať. Nekomerčný vývoj open source je mimo povinností výrobcu — nariadenie nechce udusiť dobrovoľníkov. Správca open-source softvéru (čl. 24) je právnická osoba systematicky podporujúca open source pre komerčné použitie a má odľahčený režim (politika, súčinnosť, hlásenie), bez CE. A napokon to najdôležitejšie pre bežnú firmu: keď open-source knižnice používate vo svojom komerčnom produkte, za tie komponenty v rámci vášho produktu zodpovedáte vy (čl. 13). To, že knižnica je cudzia a zadarmo, vás nezbavuje povinnosti sledovať v nej zraniteľnosti a reagovať. Náležitá starostlivosť pritom neznamená ručiť za bezchybnosť cudzieho kódu — znamená mať prehľad (SBOM), sledovať (monitoring) a reagovať (triage a dokumentácia). Presne túto slučku robíte aj pri vlastnom kóde; open source ju len rozširuje o to, čo ste nenapísali.

Ako pomáha CRAguard

CRAguard berie open-source komponenty rovnako vážne ako vlastný kód: v SBOM sú aj vaše závislosti a denne ich porovnávame proti databázam zraniteľností. Keď v open-source knižnici vyjde nový problém, dostanete verdikt a podklad pre reakciu — nech je autor knižnice ktokoľvek. Zistite, či sa vás CRA týka, alebo sa zaraďte do waitlistu.

Tento článok je informatívny a nie je právnym poradenstvom. Vychádza z nariadenia (EÚ) 2024/2847 (čl. 24 správca open-source softvéru, čl. 13 náležitá starostlivosť pri komponentoch) a usmernenia Európskej komisie zo dňa 27. 7. 2026 (vrátane pohľadu na FOSS).