23 červen 2026 / 5 minut čtení
TL;DR:
Problém: Útočníci stále častěji neútočí přímo na korporace, ale na jejich dodavatele. Jeden kompromitovaný dodavatel může otevřít dveře desítkám organizací (například v případě SolarWinds).
Proč audit nestačí: Certifikát ISO/IEC 27001 ani vyplněný dotazník neprokazují skutečnou odolnost. Bezpečná verze softwaru je bezcenná, pokud je kompromitován samotný proces jeho vývoje.
Co s tím: Požadujte praktické důkazy – penetrační testy, red teaming, bezpečné CI/CD a Secure SDLC nebo transparentní SBOM.
Legislativa: Směrnice NIS2 a Cyber Resilience Act již dnes přesouvají odpovědnost za bezpečnost dodavatelského řetězce přímo na management.
Digitalizace v Evropě přináší bezprecedentní míru propojení mezi organizacemi, jejich dodavateli a technologickými partnery. Dodavatelské řetězce hrají klíčovou roli nejen ve výrobě a automobilovém průmyslu, ale také v odvětvích, jako jsou IT, telekomunikace, energetika či další oblasti kritické infrastruktury. Právě toto propojení vytváří nové příležitosti pro útočníky, kteří se stále častěji nezaměřují přímo na korporace, ale na jejich dodavatele. V článku se podíváme na to, proč samotný audit nebo certifikace dodavatele již nestačí k objektivnímu posouzení jeho odolnosti a jak nové evropské regulační požadavky mění přístup ke kybernetické bezpečnosti v celém dodavatelském ekosystému.
Přestože velké podniky investují někdy i miliony eur do ochrany svého perimetru, infrastruktury a vzdělávání zaměstnanců, útočníci často volí cestu nejmenšího odporu. Namísto přímého útoku se zaměřují na menší dodavatele nebo poskytovatele služeb, přes které se mohou k cíli dostat mnohem snadněji. Známým příkladem je incident SolarWinds, při kterém útočníci kompromitovali proces vývoje a aktualizací softwaru, díky čemuž se škodlivý kód od dodavatele softwarového produktu dostal k tisícům organizací včetně vládních institucí a velkých korporací.
Na rostoucí rizika spojená s dodavatelským řetězcem reagují i samotné firmy. Významným faktorem je například přísnější legislativa, jako je směrnice NIS2 či Cyber Resilience Act. Směrnice NIS2 rozšiřuje okruh regulovaných subjektů, zavádí přísnější požadavky na řízení kybernetických rizik včetně bezpečnosti dodavatelského řetězce a výrazně zvyšuje odpovědnost managementu za kybernetickou bezpečnost organizace.
Zvýšený zájem však nepochybně souvisí i s rostoucím počtem bezpečnostních incidentů. Firmy od dodavatelů stále častěji požadují reálný důkaz technické odolnosti v podobě penetračního testu aplikace či IT řešení před jeho pořízením, nikoli pouze vyplněné bezpečnostní dotazníky nebo audit podle ISO/IEC 27001.
Tento tlak na ověřování bezpečnosti softwarových produktů zaznamenalo i Citadelo. Zatímco v roce 2024 vedl v zájmu o penetrační testování finanční sektor, náš Ethical Hacking Report za rok 2025 ukazuje, že vývojáři softwaru (software houses) se stali suverénně druhým nejčastěji testovaným segmentem a tvořili až 11 % všech projektů. Firmy si zároveň uvědomují, že nejzranitelnějším článkem zůstává člověk, což dokládá i výrazný nárůst zájmu o simulované phishingové a vishingové útoky, které pomáhají ověřovat připravenost zaměstnanců na reálné hrozby.
Stále více organizací proto doplňuje tradiční penetrační testy o pokročilejší formy ověřování odolnosti dodavatelů, jako je red teaming, který simuluje chování reálného útočníka napříč technickými i procesními vrstvami organizace. Součástí red teamingu bývá také sociální inženýrství včetně phishingových nebo vishingových kampaní, které prověřují připravenost jednotlivých zaměstnanců reagovat na útoky.
Právě kombinace technických testů a ověření lidského faktoru poskytuje realističtější obraz o skutečné úrovni kybernetické bezpečnosti dodavatele. Ve společnosti Citadelo dlouhodobě pozorujeme, že organizace stále častěji vyžadují právě takové praktické důkazy bezpečnostní odolnosti namísto formálního splnění auditních požadavků.
S rostoucím využíváním umělé inteligence a LLM modelů se do popředí dostává také AI bezpečnost. Firmy začínají řešit nejen bezpečnost vlastních aplikací, ale i rizika vyplývající z používání externích AI modelů, přičemž penetrační testování AI modelů a chatbotů se postupně stává součástí bezpečnostního testování moderních aplikací.
Nedávná omezení přístupu k vybraným modelům společnosti Anthropic pro evropské uživatele zároveň ukázala, že závislost na jednom poskytovateli AI může představovat významné provozní i dodavatelské riziko.
Navzdory rostoucímu zájmu o testování softwarových produktů vidíme značný prostor pro zlepšení bezpečnosti procesů vývoje softwaru, zejména v zavádění principů Secure SDLC a ochraně CI/CD pipeline. Ve výsledku je totiž zcela jedno, jak bezpečná je konkrétní verze softwaru, kterou jsme měli možnost testovat, pokud dodavatel podcení bezpečnost samotného vývojového procesu či CI/CD pipeline.
Rizika spojená s interním útočníkem (insider threat), možnost kompromitace prostřednictvím závislostí třetích stran v důsledku útoků typu dependency confusion nebo dokonce škodlivá rozšíření ve vývojářském prostředí otevírají cestu ke kompromitaci výsledné aplikace. Bezprostředně po úspěšném penetračním testu tak může být u klientů nasazena nová, kompromitovaná verze aplikace.
Bezpečnost začíná návrhem architektury, pokračuje prací se zdrojovým kódem, správou přístupů a končí až kompilací, testováním a nasazením. Základem je správné nastavení procesů, jako jsou chráněné větve v repozitářích (protected branches), revize kódu, řízení přístupů nebo zavedení automatizovaných bezpečnostních skenů, jako jsou SAST, DAST či skenování závislostí.
Důležitou součástí je také transparentnost při používání knihoven a balíčků, například prostřednictvím Software Bill of Materials (SBOM). Teprve kombinace těchto a mnoha dalších opatření vytváří předpoklad, že se bezpečnost netýká pouze výsledného softwarového produktu, ale celého procesu od jeho vzniku až po dodání zákazníkovi a následné aktualizace.

Bezpečnost dodavatelského řetězce již dávno přesahuje rámec IT bezpečnosti a stává se strategickým obchodním rizikem. V dnešním propojeném IT světě již nestačí investovat výhradně do ochrany vlastní infrastruktury. Klíčové je systematicky řídit rizika také v rámci dodavatelského ekosystému a hodnotit skutečnou bezpečnost, nikoli pouze deklarovanou úroveň bezpečnosti partnerů, na nichž jsou závislé vaše interní procesy a provoz.
Všechny články
Přihlaste se k odběru našeho newsletteru a získejte všechny důležité novinky v oblasti kybernetické bezpečnosti a etického hackování.