Bezpečnostní hrozby se dnes řeší na stovkách odborných konferencí a diskusních fór. V oblasti bezpečnosti podnikového IT jsme podle Red Hatu svědky jistého posunu v přemýšlení. Místo toho, aby firmy slepě sledovaly, kolik zranitelností bylo v rámci systému pro identifikaci a katalogizaci veřejně známých zranitelností (CVE) nahlášeno, se začínají ptát, které z nich jsou pro ně opravdu relevantní. To je jeden z hlavních vzkazů vyplývající ze studie Red Hat Product Security Risk Reporte za rok 2024 – přejít od kvantity k analýze rizik.
„Počty bezpečnostních upozornění rostou, ale není důvod k panice. Vidíme stovky zranitelností, tisíce výstrah, musíme je však chápat v kontextu. Pokud se podíváme na open source řešení, tak velký nárůst CVE souvisí třeba i s tím, že linuxový kernel začal aktivně označovat i méně závažné chyby. Když je odfiltrujete, čísla zůstávají na podobné úrovni jako v minulém roce. Reálně tedy nečelíme většímu počtu bezpečnostních hrozeb, jen máme přesnější radar,“ vysvětluje Patrik Plachý, senior solution architekt ve společnosti Red Hat, kterého jsme se zeptali na další otázky z oblasti bezpečnosti IT.
Zmíněný report věnuje značný prostor i útoku na knihovnu XZ, jednomu z nejznámějších bezpečnostních incidentů v oblasti open source v roce 2024. Proč?
Protože ukázal, že i důvěryhodné open source projekty mohou být velmi sofistikovaným způsobem kompromitovány. Ve zmíněném případě šlo o úmyslná zadní vrátka vložená do kódu správcem projektu. Avšak otevřenost open source a síla aktivní komunity dokázaly odhalit hrozbu včas – díky rychlé, otevřené a transparentní reakci, okamžité výzvě k downgradu na bezpečnou verzi XZ knihovny a stažení nebo nahrazení dotčených distribučních balíčků se předešlo zásadnějším škodám.
Z rétoriky Red Hatu vyplývá, že rychlost záplat a sdílení odpovědnosti jsou pro zajištění bezpečnosti podnikových řešení klíčová. Co je tím myšleno?
V Red Hatu věříme v model sdílené odpovědnosti, jehož principem je, že my dáváme zákazníkům ověřený, testovaný a pravidelně aktualizovaný software, a zákazník nese odpovědnost za to, jak rychle tyto aktualizace implementuje, jak má nastavené své vlastní bezpečnostní procesy a monitoring. U kritických chyb jsme schopni dodat opravu i během několika hodin.
V této souvislosti se podívejme i na bezpečnost dodavatelského řetězce softwaru. Jak vážné je zde riziko útoků?
Jiný z našich reportů, The state of Kubernetes security report za rok 2024, potvrzuje, že organizace stále více upozorňují na bezpečnostní rizika spojená s dodavatelským řetězcem. Konkrétně 44 % respondentů uvedlo, že zranitelnosti v komponentách dodavatelského softwaru jsou pro ně největším rizikem. Navíc 57 % organizací odhalilo v minulém roce zranitelné komponenty ve svých vlastních softwarových dodávkách – což potvrzuje, že jsou obavy oprávněné. Z toho vyplývá, že je nezbytné zavádět řízení rizik v celém řetězci, od hodnocení dodavatelů, monitoringu zranitelností až po audit závislostí.
Jakou roli při ochraně softwarového řetězce hrají nástroje a procesy?
Významná část organizací používá ke zvýšení důvěryhodnosti softwarových toků specializované nástroje – například bezpečnostní atestace (47 %), skenování zranitelností (45 %), nebo mechanismy autentizace a bezpečného přístupu (41 %). To ukazuje, že moderní ochrana dodavatelského řetězce už není pouze manuální, ale plně automatizovaná a integrovaná do CI/CD pipeline, kdy se jedná o automatizovaný proces, který zahrnuje integraci kódu do sdíleného úložiště (Continuous Integration), automatické testování a přípravu kódu pro vydání (Continuous Delivery) a jeho nasazení do produkčního prostředí (Continuous Deployment). Z reportu také vyplývá, že více než 67 % týmů začleňuje více bezpečnostních opatření přímo do procesu nasazení, což přispívá ke konzistenci a minimalizaci chyb v automatizovaných prostředích.
Ukazuje se, že schopnost rychle reagovat na zranitelnosti a transparentně spravovat bezpečnostní rizika v dodavatelském řetězci je pro organizace stále důležitější. Může být otevřený přístup open source cestou, jak si firmy mohou udržet kontrolu nad vlastními technologiemi, a tím posílit i svou digitální suverenitu?
Rozhodně ano. Právě otevřenost je jedním ze základních stavebních kamenů digitální suverenity. Open source dává organizacím svobodu rozhodovat se na základě svých potřeb, ne podle uzavřených podmínek konkrétního dodavatele. Díky přístupu ke zdrojovému kódu a komunitnímu vývoji mohou organizace nejen důvěřovat kódu, který používají, ale také aktivně přispívat k jeho vývoji nebo si ho přizpůsobit.
Zároveň je open source ekosystém zásadní i z bezpečnostního hlediska. Transparentnost kódu umožňuje rychlou detekci i opravu chyb, a díky komunitnímu modelu a robustní automatizaci je možné reagovat na zranitelnosti často mnohem rychleji než u proprietárních řešení. Red Hat v tomto směru dlouhodobě prosazuje princip tzv. „security through transparency“ – tedy že bezpečnost nevychází ze zamlčování, ale z otevřenosti a spolupráce.
Digitální suverenita dnes neznamená jen provoz vlastního datacentra, ale především svobodu rozhodování a kontrolu nad klíčovou infrastrukturou. A právě open source poskytuje technologické i procesní nástroje, jak této suverenity dosáhnout.
Posiluje se tedy podle vás vnímání open source jako první bezpečné a transparentní volby pro podniková řešení?
Rozhodně. Transparentnost, auditovatelnost a schopnost rychlé reakce jak na změny na trhu, tak na bezpečnostní incidenty jsou hlavní přednosti open source. Samozřejmě, ne všechen open source je stejně kvalitní. Proto je důležité pracovat s ověřeným dodavatelem – tedy někým, kdo vám garantuje, že kód, který nasazujete, byl skutečně prověřený a je bezpečný.
Jaká budou podle vás hlavní bezpečnostní témata příštích let?
Jednoznačně umělá inteligence. AI mění způsob, jakým hledáme chyby, ale zároveň přináší nová rizika – například usnadnění generování škodlivého kódu, který je těžší odhalit. Druhou oblastí je bezpečnost dodavatelského řetězce – kdo píše váš kód, kdo kontroluje balíčky, které používáte. Třetím tématem bude firemní kultura – firmy si musí zvyknout, že bezpečnost není projekt, ale trvalý stav.
