DEVSECOPS A SECURE SDLC

Co je DevSecOps a proč ho CRA vyžaduje, aniž by ho jmenoval

DevSecOps není nástroj ani role. Je to způsob organizace práce, ve kterém jsou bezpečnostní kontroly součástí téhož dodávkového procesu jako build a nasazení: spouštějí se automaticky, běží při každé změně a jejich výsledek má vlastníka, který s ním něco udělá. Proti tomu stojí model, na který je většina firem zvyklá — bezpečnost jako jednorázová brána před vydáním, obvykle v podobě penetračního testu a zprávy, kterou vývoj dostane týden před termínem.

V textu aktu o kybernetické odolnosti (Cyber Resilience Act, CRA), tedy nařízení (EU) 2024/2847, slovo DevSecOps nenajdete. Nařízení je technologicky neutrální a nepředepisuje ani jeden konkrétní nástroj. Co ale předepisuje, jsou činnosti, které se musí opakovat, a to je přesně ta část, kterou jednorázová kontrola před vydáním neumí pokrýt.

Nejvýraznější je to u posouzení kybernetických bezpečnostních rizik. Podle čl. 13 odst. 2 ho výrobce provádí a jeho výsledek zohledňuje ve fázi plánování, návrhu, vývoje, výroby, dodání a údržby produktu; podle čl. 13 odst. 3 se dokumentuje a aktualizuje po celou dobu podpory. Dokument napsaný týden před kontrolou tohle nedoloží — musí být poznat, že vznikal průběžně.

Podobně je na tom celá příloha I část II. Neukládá vlastnosti produktu, ale procesy výrobce. A procesy se nedají doložit šablonou.

• Softwarový kusovník (SBOM) ve strojově čitelném formátu, alespoň s nejdůležitějšími závislostmi produktu (příloha I část II bod 1). Aby byl k něčemu, musí vznikat při každém buildu, ne jednou ročně.
• Neprodlené řešení a odstraňování zranitelností včetně poskytování bezpečnostních aktualizací (bod 2) — to znamená mít frontu nálezů, triage a někoho, kdo o nich rozhoduje.
• Pravidelné testování a přezkoumávání bezpečnosti produktu (bod 3). Slovo „pravidelné“ je tam schválně.
• Politika koordinovaného zveřejňování zranitelností a kontaktní adresa pro hlášení (body 5 a 6) — vstupní kanál zvenčí, který někdo čte a na který se odpovídá.
• Bezpečná distribuce aktualizací, tam, kde to jde, automatická (bod 7), a jejich neprodlené a bezplatné šíření s poradní zprávou (bod 8).
• Náležitá péče u komponent třetích stran včetně open source (čl. 13 odst. 5) a povinnost nalezenou zranitelnost oznámit tomu, kdo komponentu udržuje (čl. 13 odst. 6).
• Hlášení aktivně zneužívaných zranitelností a závažných incidentů ve lhůtách 24 hodin, 72 hodin a 14 dnů (čl. 14, použitelný od 11. 9. 2026). Tohle je čistě provozní schopnost — buď ji tým má, nebo ji nemá.

Je tu ještě jeden požadavek, který se čte jako drobnost a přitom předpokládá funkční proces: produkt se dodává na trh bez známých zneužitelných zranitelností (příloha I část I bod 2 písm. a). Takové tvrzení o svém produktu můžete udělat jen tehdy, když víte, z čeho se skládá, a když to pravidelně kontrolujete proti aktuálním datům. Přehled zbylých požadavků přílohy I je v průvodci nařízením.

Shift-left: proč se bezpečnost řeší v návrhu, ne před vydáním

Shift-left znamená posunout bezpečnostní rozhodnutí co nejblíž k okamžiku, kdy vznikají — do požadavků, návrhu a psaní kódu. Důvod je prozaický: čím později se chyba najde, tím víc věcí je na ní postavených. Oprava v návrhu je změna diagramu. Oprava po vydání je změna kódu, regresní testy, nová verze, upozornění pro zákazníky a jejich vlastní plán nasazení.

Konkrétní násobky, které kolují po prezentacích — desetkrát dráž ve fázi testů, stokrát dráž v provozu — pocházejí ze studií, které jsou staré a metodicky sporné, a my je tu opakovat nebudeme. Směr je nesporný, číslo ne. Pro rozhodování stačí směr.

Podstatnější je, že řada požadavků nařízení jsou vlastnosti návrhu, ne nálezy skeneru. Bezpečná výchozí konfigurace, minimalizace zpracovávaných dat, omezení prostoru k útoku, možnost bezpečně smazat a přenést data — to jsou rozhodnutí o architektuře (příloha I část I bod 2 písm. b, g, j, m). Skener najde SQL injection. Nenajde, že se produkt dodává se stejným výchozím administrátorským heslem pro všechny instalace, protože po technické stránce je to funkční záměr.

Shift-left se přitom občas vykládá jako „všechno se otestuje u vývojáře“. To je nedorozumění. Část kontrol se posunout nedá, protože potřebují běžící aplikaci nebo skutečné prostředí — dynamické testování, testy konfigurace, penetrační test. Shift-left mění pořadí a četnost, ne rozsah.

• Požadavky — bezpečnostní požadavky vznikají spolu s funkčními. Kdo se ověřuje, k čemu má přístup, co se loguje, jak dlouho se data drží.
• Návrh — threat model, hranice důvěry, volba kryptografie a mechanismu aktualizací. Tady se rozhoduje o většině toho, co se později nedá levně změnit.
• Kód — kontroly v editoru a nad diffem v pull requestu, code review s bezpečnostním hlediskem, žádné tajné údaje v repozitáři.
• Build — analýza závislostí, generování SBOM, skenování obrazu, podepisování artefaktů, reprodukovatelnost buildu.
• Před vydáním — dynamické testování, testy konfigurace, kontrola, že v produktu nejsou známé zneužitelné zranitelnosti.
• Po vydání — sledování komponent proti aktuálním datům o zranitelnostech, příjem hlášení zvenčí, distribuce oprav.

V praxi je nejlevnější zásah do návrhu ten, který proběhne dřív, než tým začne psát. My proto threat model děláme jako workshop nad skutečnou architekturou produktu, ne jako dokument sepsaný zpětně — jeho výstup se pak dá použít jako podklad pro posouzení rizik podle čl. 13.

Kategorie nástrojů a co která reálně umí

Zkratek je hodně a marketingové materiály je používají volně. Níže jsou u každé kategorie tři věci: co najde, co nenajde a kdy se hodí. Poslední položka v seznamu — threat modeling — není nástroj, ale disciplína, a je tu schválně: bez ní zbytek seznamu jen produkuje nálezy bez souvislosti.

Struktura odpovídá tomu, jak kategorie člení OWASP DevSecOps Guideline, který je dobrým výchozím bodem, pokud si chcete udělat vlastní představu.

• SCA (Software Composition Analysis) — analyzuje závislosti: knihovny, které jste použili, a jejich tranzitivní závislosti. Najde známé zranitelnosti v komponentách třetích stran, licenční rizika a zastaralé verze; z téhož běhu obvykle vypadne i SBOM. Nenajde chybu ve vašem vlastním kódu a ve výchozím nastavení většinou neřeší, jestli je zranitelná funkce z vašeho kódu vůbec dosažitelná — proto část nálezů reálné riziko nepředstavuje. Pro CRA je to nejpřímější vazba ze všech: kusovník podle přílohy I části II bodu 1 a náležitá péče u komponent podle čl. 13 odst. 5 stojí přesně na tomhle přehledu.
• SAST (statická analýza) — čte váš zdrojový kód bez jeho spuštění. Najde injection, nebezpečné použití kryptografie, natvrdo zapsané údaje, chyby ve zpracování vstupu. Nevidí runtime: nezná konfiguraci, nasazení ani chyby v logice oprávnění, protože aplikaci nespouští. Podíl falešně pozitivních nálezů je z celého seznamu nejcitlivější místo. Nejlépe funguje nad diffem v pull requestu, ne jako noční sken celého repozitáře.
• DAST (dynamické testování) — testuje běžící aplikaci zvenčí, bez znalosti kódu. Najde chyby konfigurace, chybějící hlavičky, odhalené koncové body, problémy s ověřováním a autorizací, tedy věci, které statická analýza z principu vidět nemůže. Nenajde, co neprojde — pokrytí je omezené tím, kam se skener dostane, a u API bez popisu rozhraní bývá pokrytí nízké. Potřebuje běžící prostředí, takže patří do noční úlohy proti stagingu, ne do každého commitu.
• IAST a RASP — obojí stojí na instrumentaci uvnitř běžící aplikace. IAST koreluje běh s místem v kódu, takže nálezy mají výrazně nižší podíl falešně pozitivních než SAST. IAST ale vidí jen to, co projdou vaše testy, a vyžaduje podporu pro daný jazyk a běhové prostředí. RASP není testování, ale ochrana za běhu — blokuje útok v aplikaci. Dává smysl jako dočasné kompenzační opatření tam, kde oprava trvá, ne jako náhrada opravy.
• Secrets scanning — hledá klíče, tokeny a hesla v repozitáři a v celé historii gitu. Poměr přínosu a úsilí je tady dobrý a podíl falešně pozitivních nízký, zvlášť u tokenů s rozpoznatelným tvarem. Zásadní je pochopit, co nález znamená: jakmile se tajný údaj do historie dostal, je kompromitovaný a musí se rotovat. Přepsání historie problém neřeší, jen ho schová. Kontrola patří na dvě místa — do pre-commit hooku u vývojáře a na stranu serveru, protože hook se dá vypnout.
• Skenování kontejnerových obrazů a IaC — u obrazů najde zranitelné balíčky základního obrazu, zbytečné nástroje ve výsledném obrazu a běh pod rootem; to je vrstva, kterou analýza aplikačních závislostí obvykle míjí. U infrastruktury jako kódu (Terraform, manifesty Kubernetes, Helm) najde otevřené bezpečnostní skupiny, veřejná úložiště, privilegované pody, chybějící šifrování. Ani jedno neřekne, jestli je nález ve vašem prostředí zneužitelný — kontext dodáváte vy.
• Threat modeling — jediná disciplína ze seznamu, která není nástroj. Nad diagramem toků dat a hranic důvěry se ptáte, co může útočník chtít, kudy se k tomu dostane a co selže první. Nenajde konkrétní zranitelnost v konkrétním řádku, zato najde chybějící kontrolu, kterou žádný skener nehlásí, protože není chybou v kódu. Pro CRA má praktický význam: dokumentovaný výstup threat modelu je použitelný podklad pro posouzení rizik podle čl. 13 odst. 3.
• Fuzzing — generuje deformované vstupy a hledá pád nebo neošetřený stav. Má smysl u parserů, implementací protokolů, zpracování formátů souborů a obecně u nativního kódu, kde jsou důsledky chyby v práci s pamětí nejtvrdší. U běžné podnikové webové aplikace nad databází je poměr přínosu a úsilí špatný. U knihovny, kterou dodáváte dál, dává smysl provozovat ho průběžně, ne jednorázově.

Žádná z kategorií nepokrývá jinou. SCA nezná váš kód, SAST nezná běh, DAST nezná strukturu a threat model nenajde překlep. Zavádět je proto má smysl postupně a v pořadí podle toho, co u vašeho produktu nejvíc bolí — pořadí, které nám vychází z projektů, je v časové ose na konci stránky.

Falešně pozitivní nálezy: hlavní důvod, proč zavedení umře

Tohle je část, kterou dodavatelé nástrojů nezmiňují rádi, a přitom o ní rozhoduje úspěch celého zavedení. Typický scénář vypadá takhle: firma koupí platformu, zapne v ní všechno, první sken nad zavedenou kódovou základnou vrátí stovky až tisíce nálezů, tým se do nich pustí, po dvou týdnech zjistí, že většina z nich v jeho kontextu není zneužitelná, a přestane je číst. Od té chvíle je bezpečnostní kontrola v pipeline jen zdroj šumu a první skutečný nález v něm zapadne.

Falešně pozitivní nález přitom nemusí být chyba nástroje. Často je to správný nález bez kontextu — zranitelnost v knihovně, jejíž postižená funkce se ve vašem produktu nikdy nezavolá; slabý generátor náhodných čísel použitý na něco, co není bezpečnostně citlivé; chybějící hlavička na koncovém bodu, který není veřejný. Nástroj nemá jak vědět, že to tak je. Vy ano — a to rozhodnutí je potřeba někam zapsat, aby se nemuselo dělat znovu při každém běhu.

Druhá polovina pravdy: existují i falešně negativní nálezy. Čistá pipeline není důkaz, že produkt je bezpečný — je to důkaz, že daná sada kontrol nic nenašla. Kdo tenhle rozdíl nepojmenuje nahlas, dřív nebo později postaví rozhodování o vydání na zeleném zaškrtnutí.

• Zamrazit stávající stav (baseline) — historické nálezy se zaevidují a řeší podle plánu, ale pipeline padá jen na nových. Bez tohohle kroku se nová kontrola nedá zapnout na zavedeném produktu.
• Osekat sadu pravidel — výchozí sada je stavěná tak, aby nic nepropásla, ne aby byla použitelná. Pravidla, která ve vašem jazyce a frameworku systematicky produkují šum, se vypínají vědomě a se zápisem důvodu.
• Rozhodnutí zapisovat strojově — u komponent je na to VEX (viz další sekce), u kódu potlačení nálezu s odůvodněním a platností. Rozhodnutí bez odůvodnění je za půl roku nepoužitelné.
• Analýza dosažitelnosti tam, kde ji SCA nabízí — sníží objem nálezů řádově, protože oddělí zranitelnosti v kódu, který se u vás nikdy nespustí.
• Jeden vlastník na jednu frontu nálezů a lhůty podle závažnosti. Nález, který patří všem, nepatří nikomu.
• Měřit šum, ne jen počet nálezů — kolik procent nálezů skončí jako „neplatí pro nás“. Když je to trvale přes polovinu, problém je v nastavení, ne v týmu.

Prakticky to znamená, že první měsíce po zapnutí nástroje nejsou o hledání zranitelností, ale o ladění. Když se tahle fáze přeskočí, tým se naučí kontroly ignorovat a vrátit se k důvěře v ně trvá mnohem déle než původní zavedení.

SBOM prakticky: formáty, okamžik generování a vazba na VEX

Softwarový kusovník je formální záznam komponent v softwarových prvcích produktu a jejich vztahů v dodavatelském řetězci (čl. 3 bod 39). Nařízení po něm chce dvě věci: aby byl v běžně používaném strojově čitelném formátu a aby obsahoval alespoň nejdůležitější závislosti produktu (příloha I část II bod 1). Konkrétní formát nepředepisuje; prvky a formát může upřesnit Komise prováděcím aktem (čl. 13 odst. 24), což se k 8. 8. 2026 nestalo.

V praxi jsou formáty dva. CycloneDX vznikl v OWASP, aktuální specifikace je verze 1.7 z 21. října 2025 a je standardizovaná jako ECMA-424 (2. vydání, prosinec 2025). SPDX spravuje Linux Foundation, aktuální je verze 3.0.1 z prosince 2024; jako ISO/IEC 5962:2021 je zatím uznaná starší verze 2.2.1 a revize na řadu 3.0 je v ISO ve stavu návrhu. Oba formáty požadavek přílohy I splňují a mezi sebou se dají převádět, byť ne bezeztrátově.

Důležitější než volba formátu je okamžik generování. Kusovník má vzniknout při buildu, z toho, co se do artefaktu skutečně dostalo, a má se ukládat vedle artefaktu a s jeho verzí. Kusovník sestavený dodatečně skenem repozitáře je něco jiného: nezachytí, co přidal build, co se vyřešilo z lock souboru a co je uvnitř základního obrazu kontejneru.

A pak je tu otázka, co s ním. Sám o sobě je kusovník inventura, která zastarává v okamžiku, kdy vyjde nová zranitelnost. Užitečný je teprve tehdy, když se průběžně porovnává proti aktuálním datům o zranitelnostech — z toho vzniká odpověď na otázku „týká se nás to?“ v hodinách místo dnů. Kusovník bez tohohle napojení je soubor, ne proces.

• Zveřejňovat SBOM se nemusí. Orgánu dozoru nad trhem se předkládá na odůvodněnou žádost, je-li to nezbytné k ověření souladu (příloha VII bod 8). Uživateli se zpřístupňuje jen tehdy, když se tak výrobce rozhodne (příloha II bod 9).
• Jeden kusovník na jednu verzi artefaktu. Kusovník bez vazby na konkrétní build je nepoužitelný pro odpověď na otázku, které vydání je zasažené.
• Hloubka záznamu. Nařízení žádá alespoň nejdůležitější závislosti; praxe směřuje k tranzitivnímu stromu, protože zneužitelná bývá právě závislost tři úrovně pod tou, kterou jste si vybrali.
• VEX (Vulnerability Exploitability eXchange) je druhá polovina. Kusovník říká, co v produktu je; VEX říká, jestli konkrétní zranitelnost produkt skutečně ovlivňuje — se stavy typu „netýká se“, „týká se“, „opraveno“, „prošetřuje se“ a s odůvodněním.
• Formáty VEX jsou tři a liší se způsobem doručení: CSAF jako samostatný profil bezpečnostního upozornění, CycloneDX vložený přímo do kusovníku a OpenVEX jako minimalistický samostatný dokument. Minimální náležitosti popsala CISA v samostatném dokumentu.
• Praktický přínos VEX je dvojí: interně nahradí opakované ruční rozhodování o témže nálezu, externě zabrání tomu, aby čtyřicet zákazníků poslalo čtyřicet stejných dotazů, jakmile vyjde zranitelnost v rozšířené knihovně.

Pozor na záměnu, která se u kusovníku objevuje často: SBOM není splnění povinnosti řešit zranitelnosti. Je to vstup do ní. Povinnost neprodleně řešit a odstraňovat zranitelnosti stojí v příloze I části II bodě 2 samostatně a kusovník ji nenahrazuje — rozdíl mezi oběma režimy rozebírá sekce průvodce o SBOM a řízení zranitelností.

Brány v CI/CD: co blokovat a co jen hlásit

Brána je místo v pipeline, kde se běh zastaví, protože kontrola našla něco, co dál nesmí. Rozhodnutí, co bude bránou a co jen hlášením, je z celého zavedení to nejvíc politické a rozhoduje o tom, jestli si tým kontroly osvojí, nebo je začne obcházet.

Tvrdá brána na všechno hned od začátku má předvídatelný konec. Vývojáři mají termín, brána stojí mezi nimi a nasazením, a tak se najde cesta kolem: přepínač, který kontrolu přeskočí, štítek „výjimka“, který se přestane odebírat, nebo přesun kontroly do úlohy, u které je selhání povolené. Formálně kontrola pořád běží, fakticky už nic nehlídá — a to je horší výchozí stav než žádná kontrola, protože o něm nikdo neví.

Použitelné pravidlo je jednoduché: blokovat tam, kde je podíl falešně pozitivních nálezů nízký a následek propuštění vysoký. Všechno ostatní nejdřív hlásit, změřit a teprve pak případně utáhnout. A brána nemusí být jedna — jinak se rozhoduje u pull requestu, jinak u sloučení do hlavní větve a jinak u vydání, protože jen u vydání musí platit, že produkt jde na trh bez známých zneužitelných zranitelností (příloha I část I bod 2 písm. a).

• Blokovat prakticky vždy — nalezený tajný údaj v commitu, artefakt bez platného podpisu, build z neznámého nebo neauditovatelného zdroje, selhání kontroly integrity závislostí (změna lock souboru bez odpovídající změny v kódu).
• Blokovat u vydání — zranitelnost s vysokou závažností v přímo používané komponentě, pro kterou existuje oprava; komponenta s aktivně zneužívanou zranitelností; obraz s neopravenými zranitelnostmi základního obrazu, u nichž je vydaný patch.
• Jen hlásit, alespoň na začátku — nálezy statické analýzy nad zavedeným kódem, zranitelnosti v tranzitivních závislostech bez prokázané dosažitelnosti, nálezy dynamického testování, doporučení k nastavení infrastruktury.
• Neblokovat nikdy podle skóre samotného — CVSS měří závažnost v obecném případě, ne riziko ve vašem nasazení. Brána postavená jen na „vše nad 7,0“ generuje zastavení, která tým naučí bránu obcházet.
• Cesta výjimky musí existovat a být zapsaná — kdo ji schvaluje, na jak dlouho platí a co se stane, až vyprší. Výjimka bez expirace se za rok promění v trvalý stav, o kterém nikdo neví.
• Rychlost je bezpečnostní parametr. Kontrola, která v pull requestu běží dvacet minut, se dřív nebo později přesune jinam. Do PR patří jen to, co se stihne v jednotkách minut, zbytek do nočního běhu.

Samotná pipeline je přitom aktivum, které patří do rozsahu ochrany. Prostředí, ve kterém se staví a podepisují artefakty rozesílané zákazníkům, je typický cíl útoku na dodavatelský řetězec — a jeho kompromitace je přesně ten případ závažného incidentu s dopadem na bezpečnost produktu, který se od 11. 9. 2026 hlásí podle čl. 14 odst. 3 (podrobně v průvodci).

Řízení zranitelností po vydání: KEV, EPSS a hlášení podle CRA

Vydáním produktu práce nekončí, u CRA naopak začíná ta část, která má nejdelší dobu trvání — doba podpory je nejméně pět let a vydané bezpečnostní aktualizace musí zůstat dostupné nejméně deset let od svého vydání (čl. 13 odst. 8 a 9). Po celou tu dobu musí fungovat smyčka: sledovat, vyhodnotit, opravit, distribuovat, informovat.

Nejtěžší rozhodnutí v téhle smyčce je, jestli je zranitelnost aktivně zneužívaná. Definice nařízení je přísnější, než jak se ten pojem používá běžně: jde o zranitelnost, u níž existují spolehlivé důkazy, že ji škodlivý aktér v systému zneužil bez svolení vlastníka systému (čl. 3 bod 42). Není to totéž co zneužitelná. Existence funkčního proof of concept ohlašovací povinnost sama o sobě nespouští.

Dva veřejné zdroje se pro tohle rozhodování používají a je užitečné vědět, co který z nich znamená. Katalog KEV americké agentury CISA obsahuje zranitelnosti s přiděleným CVE, u kterých existuje důkaz o aktivním zneužívání a je znám postup nápravy. Je to silný externí signál, ale ze své povahy zpožděný, neúplný a orientovaný na americké prostředí — nepřítomnost v KEV není důkazem, že se zranitelnost nezneužívá.

EPSS od organizace FIRST je něco úplně jiného: statistický model, který denně odhaduje pravděpodobnost, že bude zveřejněná zranitelnost v následujících 30 dnech zneužita ve volné přírodě. Aktuální je model verze 4 z března 2025. EPSS je predikce, ne pozorování — je výborný na řazení fronty oprav a nepoužitelný jako spouštěč 24hodinové lhůty podle čl. 14. Ten spouští znalost skutečnosti, ne pravděpodobnost.

V praxi je prvním důkazem obvykle něco vašeho: telemetrie z produktu, hlášení od zákazníka, nález z reakce na incident nebo zpráva, která dorazí na kontaktní adresu pro hlášení zranitelností podle přílohy I části II bodu 6. Právě proto ta adresa nemá být jen řádkem na webu.

• Denní porovnání kusovníku proti zdrojům dat o zranitelnostech, s automatickým založením úkolu u shody. Ruční kontrola tuhle práci v rozsahu desítek produktů neustojí.
• Triage se dvěma výstupy — jestli se nás to týká (a záznam do VEX, pokud ne) a jak je to naléhavé. Řazení podle kombinace závažnosti, dosažitelnosti ve vašem produktu a EPSS dává lepší pořadí než kterýkoli z těch údajů sám.
• Samostatný signál na aktivní zneužívání — sledování KEV, upozornění dodavatelů komponent, vlastní telemetrie. Tenhle signál má jinou naléhavost než běžná fronta oprav, protože z něj plyne lhůta.
• Rozhodovací pravomoc a dosažitelnost mimo pracovní dobu. Lhůta 24 hodin běží od okamžiku, kdy se výrobce dozví, ne od pondělního rána. Musí být předem jasné, kdo rozhodne a kdo oznámení podá.
• Oprava oddělená od funkčních změn, tam, kde to je technicky možné (příloha I část II bod 2) — zákazník, který kvůli bezpečnostní opravě musí přijmout i novou funkcionalitu, ji nasadí později.
• Poradní zpráva k vydané opravě s popisem zranitelnosti, dopadu, závažnosti a postupu nápravy (příloha I část II body 4 a 8). Zveřejnění lze v odůvodněných případech odložit, dokud uživatelé nemají možnost opravu nasadit.

Hlášení podle čl. 14 je od 11. září 2026 provozní povinnost s lhůtami 24 hodin, 72 hodin a 14 dnů, u incidentů jeden měsíc. Co přesně se do které zprávy píše, komu se podává a od čeho se která lhůta počítá, rozebírá sekce průvodce o hlášení. Poprvé si tenhle proces nemá tým zkoušet naostro.

Secure SDLC jako rámec: kde se to potkává s normami

DevSecOps je provozní polovina věci — co běží, kdy a s jakým výsledkem. Secure SDLC je ta druhá polovina: rámec, který říká, jaké činnosti v životním cyklu vůbec existují, kdo je vlastní a jak se pozná, že jsou dělané dobře. Bez rámce vznikne sbírka nástrojů, kterou nejde nikomu doložit; bez provozu vznikne dokumentace, která neodpovídá realitě.

Rámců je několik a nejsou konkurenční — každý řeší jinou otázku. Níže jsou čtyři nejpoužívanější v evropském a průmyslovém kontextu, stručně a s tím, k čemu se hodí.

Jedna věc ale platí pro všechny a je dobré ji vědět předem: ani jeden z těchto rámců nezakládá presumpci shody s CRA. Ta vzniká výhradně použitím harmonizované normy, jejíž odkaz je zveřejněný v Úředním věstníku (čl. 27 odst. 1), a k 8. 8. 2026 taková norma pro CRA neexistuje. Certifikát je dobrý základ a doklad o zavedených procesech, ne náhrada posouzení shody.

• NIST SSDF (SP 800-218) — čtyři skupiny praktik: příprava organizace (PO), ochrana softwaru (PS), tvorba dobře zabezpečeného softwaru (PW) a reakce na zranitelnosti (RV). Poslední skupina odpovídá téměř jedna ku jedné tomu, co po výrobci chce příloha I část II. Aktuální je verze 1.1 z února 2022; verze 1.2 vyšla 17. 12. 2025 jako první veřejný návrh SP 800-218r1, připomínkové řízení skončilo 30. 1. 2026 a k 8. 8. 2026 není finální.
• OWASP SAMM — model zralosti, ne kontrolní seznam. Pět obchodních funkcí (Governance, Design, Implementation, Verification, Operations), patnáct praktik a tři úrovně zralosti. Hodí se na to, na co se rámce jako SSDF nehodí: zjistit, kde stojíte dnes, a mít měřitelný rozdíl proti stavu za rok.
• IEC 62443-4-1 — životní cyklus bezpečného vývoje produktu pro průmyslovou automatizaci, osm skupin praktik od správy bezpečnosti přes definici požadavků, návrh a ověřování až po správu chyb a aktualizací, se čtyřmi úrovněmi zralosti. Z existujících norem je obsahově nejblíž tomu, co příloha I část II po výrobci chce, a u průmyslových produktů je to obvykle rozumný výchozí bod.
• ISO/IEC 27001:2022 — systém řízení bezpečnosti informací, tedy organizace, ne produkt. Vývoje se dotýká skupina opatření přílohy A od 8.25 (životní cyklus bezpečného vývoje) přes 8.28 (bezpečné programování) po 8.29 (testování bezpečnosti při vývoji a přejímce). Pokryje procesní část a řízení změn; posouzení rizik na úrovni produktu, kusovník ani technickou dokumentaci podle přílohy VII nenahradí.

Praktické doporučení: rámec si nevybírejte podle toho, který je „správný“, ale podle toho, komu co budete dokládat. Průmyslovému zákazníkovi 62443-4-1, americkému odběrateli SSDF, dozoru podle CRA vlastní posouzení rizik a technickou dokumentaci. Souvislosti mezi normami a regulací rozebírá průvodce standardy, vazbu certifikátů na CRA pak FAQ ke CRA.

Jak s tím umíme pomoct

Předchozí sekce popisují, co se dělá. Tahle popisuje, co z toho děláme s klienty a v jakém formátu. Nabídku máme rozdělenou na samostatné části schválně — většina firem nepotřebuje všechno, potřebuje dva nebo tři chybějící díly.

Pracujeme s tím, co už máte. Pokud v pipeline běží nástroj, který dává smysl, ladíme ho místo výměny. S výrobci nemáme žádné partnerství ani provizní model, takže doporučujeme neutrálně podle vašeho prostředí a nemáme důvod vás k žádnému nástroji tlačit; licenci umíme dodat i prodat, ale není to náš cílový segment — nevylučujeme to, jen na tom nestavíme. Stejně tak nenahrazujeme vývojový tým — kontroly a procesy nakonec musí provozovat ti, kdo produkt vyvíjejí, jinak to po našem odchodu vydrží jeden kvartál.

• Konzultace — jednorázové sezení nad vaším produktem a vývojem. Projdeme, co dnes běží, co z toho pokrývá požadavky CRA a co chybí. Výstupem je seznam kroků v pořadí a s odhadem pracnosti, ne nabídka.
• Posouzení stávající pipeline — co v CI/CD skutečně běží, co která kontrola pokrývá, kde jsou slepá místa, kolik šumu produkuje a jestli brány nejsou fakticky obcházené. Výstupem je seřazený seznam nálezů a doporučené pořadí nápravy.
• Threat modeling produktu — workshop s vývojovým týmem nad skutečnou architekturou. Hranice důvěry, toky dat, scénáře útoku, chybějící kontroly. Výstup je psaný tak, aby se dal použít jako podklad posouzení rizik podle čl. 13.
• Zavedení Secure SDLC — činnosti, vlastníci, rozhodovací body a cesta výjimky, namapované na zvolený rámec (SSDF, IEC 62443-4-1) a na požadavky přílohy I. Včetně toho, co se má dokládat a čím.
• Nastavení bran v CI/CD — výběr a zapojení kontrol do vašeho CI, zamrazení stávajícího stavu, ladění pravidel, politika bran a jejich postupné utahování. Cílem je stav, kdy tým kontrolám věří.
• SBOM a VEX — generování kusovníku při buildu, jeho ukládání a verzování, průběžné porovnávání proti datům o zranitelnostech a proces, ve kterém se rozhodnutí „netýká se nás“ zapisuje jednou a strojově.
• Proces řízení zranitelností a hlášení podle čl. 14 — triage, role, dosažitelnost mimo pracovní dobu, obsah jednotlivých zpráv a nácvik nanečisto, aby se ostrá 24hodinová lhůta neřešila poprvé při reálné události.

Formáty spolupráce jsou dva: ohraničené posouzení s výstupem a termínem, nebo dlouhodobá spolupráce s pravidelnou kapacitou, když chcete zavádění vést postupně a s někým po ruce. Co která varianta obnáší, popisuje stránka Security Assessment; rozsah a cenu domlouváme podle toho, kolik produktů a týmů to má pokrýt.

Pořadí zavádění, které se nám osvědčuje

Tohle není požadavek nařízení ani norma. Je to náš odhad z projektů — orientačně produktový tým 5 až 15 lidí s jedním hlavním produktem a existující CI. Doby jsou hrubé, kroky se překrývají a pořadí se mění podle toho, co už máte hotové. Smysl seznamu je jiný: ukázat, že se to zavádí po částech, a co po čem má následovat.

Oficiální zdroje

Odborná tvrzení o povinnostech a termínech na téhle stránce vycházejí z následujících zdrojů, stav k 8. 8. 2026. Znění předpisů stránka nenahrazuje.