Jak migrace .NETu odhalila bezpečnostní dluh – a proč by vás to mělo zajímat

Z hlediska technického provedení šlo pro nás víceméně o rutinní projekt. Přišel za námi zákazník s tím, že provozuje distribuovaný systém pro správu fyzické infrastruktury. Systém se skládal z backendu ve starším .NET frameworku, který obsahoval několik desítek samostatně operujících Windows služeb, a frontendové aplikace.

Na nás byl vznesen požadavek vzít tento backend a zmigrovat jej na modernější .NET 8. Součástí tohoto požadavku na migraci byla také revize stávající bezpečnost projektu s ohledem na nové regulace.

Bezpečákův průvodce regulacemi

Regulacemi nás v poslední době straší spousta bezpečnostních či právních odborníků. O jakých regulacích je vlastně řeč? Tou první je Nový zákon o kybernetické bezpečnosti, který vešel v platnost v listopadu 2025.

Jedná se o transpozici celoevropské směrnice NIS2, která zpřísňuje požadavky na bezpečnost dodávaného softwaru a provozovaných informačních služeb. Ve stručnosti tato transpozice vyžaduje zavedení systému řízení kybernetické bezpečnosti a obecně řízení rizik a incidentů ve firmě.

Z manažerského hlediska to znamená školit zaměstnance v oblasti kyberbezpečnosti a také zodpovědnost vedení subjektů za řešení bezpečnostních rizik. Z technického hlediska to znamená mj. řídit přístupy, šifrovat data, řešit monitoring a v neposlední řadě také zajistit bezpečnost vývoje softwaru – takzvaný SSDLC (secure software development lifecycle).

Bezpečný vývojový cyklus je, lidsky přeloženo, soubor procesních a technických opatření, která zajišťují, že bezpečnost dodávaného softwaru se řeší od návrhu až po provoz (tzv. shift-left přístup, tedy přesouváme bezpečnost na začátek) a ne až na konci (tzv. bolted-on přístup, tedy řešíme bezpečnost až dodatečně).

Součástí SSDLC je například modelování hrozeb spolu s definicí bezpečnostních požadavků a architektury při návrhu (či refaktorizaci/migraci) softwaru, dodržování principů bezpečného vývoje, testování typu SAST a DAST (static/dynamic application security testing), skenování závislostí a zranitelností v knihovnách, automatizace bezpečnostních kontrol v CI/CD pipeline a případně také penetrační testování.

Druhou významnou regulací je Cyber Resilience Act (CRA), který se zaměřuje primárně na bezpečnost produktů (digitálních či s digitálními prvky) uváděných na trh. Na rozdíl od NIS2, která cílí výslovně na provozovatele služeb a jejich schopnost řídit kybernetická rizika, CRA ukládá povinnosti přímo výrobcům softwaru a zařízení.

Ti musí zajistit, že jejich produkty jsou bezpečné již při uvedení na trh a zůstávají bezpečné po celou dobu jejich životního cyklu, včetně poskytování bezpečnostních aktualizací a řešení zranitelností. Tato regulace nabude plné účinnosti v prosinci roku 2027, od toho bodu dál bude nutné plně vyhovovat jejím požadavkům. Povinnost hlásit aktivně zneužívané zranitelnosti a incidenty nicméně začíná platit o něco dříve, a to již v září 2026, tedy ještě letos.

Obě regulace se částečně překrývají, zejména v oblasti bezpečnosti vývoje softwaru a řízení zranitelností. Zatímco NIS2 (a její česká transpozice) vyžaduje, aby organizace měly zavedené procesy pro bezpečný vývoj a řízení rizik v rámci svého provozu, CRA tyto požadavky konkretizuje z pohledu samotného produktu.

Jak NIS2, tak CRA například požadují řízení svého dodavatelského řetězce, což z pohledu CRA jako pevný požadavek znamená dodávat se softwarem i tzv. SBOM (software bill of materials), který obsahuje informace o tom, jaké knihovny dodávaný software využívá. V praxi to znamená, že organizace vyvíjející software musí splnit jak procesní požadavky na úrovni řízení (NIS2), tak i konkrétní požadavky na vlastnosti a bezpečnost dodávaných produktů (CRA).

Co oči nevidí, to vývojáře (zatím) nebolí

Když jsme se začali zabývat prostředím, ve kterém zákazník svůj software vyvíjel, zjistili jsme, že stav je z hlediska bezpečnosti horší, než by se na první pohled mohlo zdát. CI/CD pipeline byla roztříštěná mezi dva nezávislé systémy – Azure DevOps Server (on-prem) a Jenkins. Bez jednotné strategie, společných standardů nebo nějaké centrální kontroly.

Z hlediska technického navíc vůbec nebylo nutné toto nastavení mít, zůstalo tam z „historických“ důvodů. Co hůř, ani jedno z prostředí neobsahovalo jakoukoliv formu bezpečnostní kontroly, ať už formou statické analýzy, či alespoň analýzy závislostí. Viditelnost do bezpečnostních zranitelností kódu a knihoven byla doslova nulová a tým zákazníka jednoduše nevěděl, jaké bezpečnostní problémy v jejich codebase o statisících řádků kódu existují.

Aby toho nebylo málo, v konfiguraci Jenkinsu se povedlo objevit hardcoded credentials – hesla k databázím, strojům. Vše v plaintextu, čitelné pro kohokoliv s přístupem k build serveru. To už není technický dluh, to je bezpečnostní incident, který tam mohl existovat měsíce bez povšimnutí, neboť to nikdo neřešil.

A proč to nikoho nebolelo? Protože systém fungoval. Tým zákazníka jsou šikovní vývojáři, systém spolehlivě běží, zákazníci platí, infrastruktura jede. Problém je, že bezpečnost není o tom, jestli systém funguje teď. Je o tom, jestli bude fungovat i ve chvíli, kdy se někdo aktivně snaží, aby nefungoval. A k tomu potřebujete viditelnost – tedy schopnost vědět, co se nejen uvnitř softwaru, ale i vývojového procesu a prostředí děje. Tu zákazník neměl žádnou.

Tři cesty z bezpečnostní slepé uličky

Na základě analýzy jsme zákazníkovi navrhli koncept zabezpečené pipeline pokrývající celý vývojový cyklus od commitu po produkci. Protože nebylo možné pipeline zabezpečit beze změn, zákazníkovi jsme předložili tři varianty řešení:

• Varianta A: Kompletní přesun na GitHub s využitím GitHub Advanced Security (nativní nástroje CodeQL pro SAST, Dependabot pro SCA a secret scanning s funkcí push protection). Z hlediska infrastruktury stále částečně hybridní řešení, zákazník by využíval self-hosted GitHub runnery a sám si je spravoval na základě preference.
• Varianta B: Odstranění Jenkinsu, kompletní přesun na stávající Azure DevOps Server a jeho doplnění o externí nástroje (SonarQube Enterprise pro SAST, OWASP Dependency-Track pro SCA, Gitleaks pro secrety).
• Varianta C: Migrace do cloudového Azure DevOps Services s aktivací GitHub Advanced Security for Azure DevOps. Zachování známého ekosystému, ale s širokými možnostmi security nástrojů.

Každá varianta měla své výhody a omezení. Z hlediska hloubky bezpečnostní analýzy a rychlosti nasazení i s případnou režií vycházel nejlépe GitHub. Z hlediska minimálního zásahu do současného provozu a zachování dat on-premise byl nejlepší stávající Azure DevOps Server s rozšířením. Varianta C zase byla výhodná v rychlosti migrace, která je umožněná nativně díky existujícím nástrojům.

Z nevýhod si tady dovolím vypíchnout jednu specifickou, která variantu B víceméně diskvalifikovala: licence pro SonarQube Enterprise pro codebase rozsahu zákazníka by sama o sobě stála víc než kompletní cloudové řešení. Je to tedy, jako vždy a všude, o kompromisech.

Jak migrace kódu vedla ke strategickému rozhodnutí firmy

V průběhu security analýzy na původně migračním projektu vyplynulo několik zjištění, která přesáhla původní rámec zadání. Zaprvé, Azure DevOps Server má konec životnosti (end of life) v roce 2033. To znamená, že migrace jinam byla s ohledem na bezpečnost tak jako tak v budoucnu nevyhnutelná – a čím déle se odkládá, tím vyšší bude technický a bezpečnostní dluh a tím větší riziko „time-pressure" migrace těsně před deadlinem.

Zadruhé, ekonomická analýza nám poodhalila, že cloudová varianta je v případě zákazníka nejlevnější jak v prvním roce, tak v průběžných provozních nákladech – a to i při škálování na celou firmu. Zatřetí, bez zavedení bezpečné pipeline nemá zákazník šanci vyhovět požadavkům CRA ani nového zákona o kybernetické bezpečnosti, přičemž sankce za nesoulad se pohybují v řádu milionů korun.

Výsledkem bylo, že z původního požadavku „migrujte nám .NET a zabezpečte pipeline pro jeden projekt" se stal celofiremní strategický projekt. Management zákazníka začal řešit otázku, zda a jak migrovat celou DevOps platformu z on-premises infrastruktury do cloudu – a to nejen pro tento jeden systém, ale pro celou organizaci. To, co začalo jako technická migrace frameworku, odhalilo systémový bezpečnostní dluh, který vyžadoval strategické rozhodnutí na úrovni vedení firmy.

Co si z toho odnést?

Příběh tohoto zákazníka není ojedinělý. V praxi narážíme na podobné situace opakovaně – systémy, které fungují roky bez problémů, ale pod povrchem skrývají bezpečnostní rizika, o kterých nikdo neví. Několik klíčových poučení:

1. Bezpečnost se neřeší „potom". Řeší se od prvního commitu. Každý push by měl projít přes secret scanning, každý build by měl mít statickou analýzu a každá závislost by měla být auditovaná. To není luxus – je to zákonný požadavek, který bude vymáhán.
2. Regulace přicházejí a budou se vymáhat. Nový zákon o kybernetické bezpečnosti už v Česku platí. Celoevropská CRA s pokutami až 15 milionů EUR nebo 2,5 % celosvětového obratu nabude plné účinnosti v prosinci 2027, první ostré povinnosti přicházejí už letos na podzim. Čas na přípravu se krátí.
3. „Funguje to" neznamená „je to bezpečné". Systém může perfektně fungovat, a přitom mít v git historii uniklé přístupy, neaktualizované knihovny s kritickými zranitelnostmi nebo API bez řádné validace vstupů. Bez příslušných nástrojů a procesů to jednoduše nevíte.
4. Migrace nebo modernizace je ideální moment pro zavedení bezpečného vývojového procesu. Pokud právě měníte framework, přecházíte na novou autentizaci nebo zavádíte kontejnerizaci – je to přesně ten okamžik, kdy se vyplatí postavit bezpečný vývojový proces od základu. Nový tech stack má zpravidla výrazně lepší podporu s moderními security nástroji.
5. Nakonec – bezpečnostní analýza často odkryje systémové problémy, které přesahují původní zadání. V tomto případě to byl impuls k celofiremní infrastrukturní transformaci. I proto stojí za to se na bezpečnost svého vývojového procesu podívat dřív, než vás k tomu donutí regulátor.