V roce 2026 o 131% více nahlášených CVE denně než loni.

Dodavatelský řetězec

NIST SSDF (SP 800-218)

Secure Software Development Framework neboli SSDF je soubor praktik NIST pro vývoj bezpečného softwaru. Vyšel jako SP 800-218 a ve čtyřech skupinách popisuje, co dělá vyspělý vývojový program, aniž by určoval, jaké nástroje použít. Široce známým se stal díky americkým federálním pravidlům pro software a dnes je běžným měřítkem bezpečného vývoje obecně.

Aktualizováno

Čtyři skupiny praktik

SSDF člení své praktiky do čtyř skupin. Každá praktika stanovuje výsledek a NIST výslovně uvádí, že nejde o checklist: je to základ pro plánování podle rizika.

Skupina Cíl Příklady
Prepare the Organization (PO) Lidé, procesy a nástroje jsou připraveni Stanovit bezpečnostní požadavky, přidělit role, zabezpečit vývojové prostředí
Protect the Software (PS) Kód a vydání jsou chráněny před neoprávněnou změnou Chránit všechny formy kódu, ověřovat integritu vydání, archivovat každé vydání
Produce Well-Secured Software (PW) Málo zranitelností v tom, co vydáváte Navrhovat s ohledem na bezpečnost, znovu používat dobře zabezpečený software, revidovat a testovat kód
Respond to Vulnerabilities (RV) Najít zbývající chyby a vypořádat se s nimi Průběžně identifikovat zranitelnosti, určit jejich prioritu a opravit je, analyzovat hlavní příčiny

Praktiky, které se týkají vašeho dodavatelského řetězce

  • PO.3, podpůrné toolchainy, a PO.5, zabezpečená prostředí. Váš systém CI patří k tomu, co musíte chránit. Viz checklist zabezpečení pipeline CI/CD.
  • PS.3, archivovat a chránit každé vydání. Patří sem shromažďování údajů o původu (provenance) komponent každého vydání a SSDF jako jeden ze způsobů uvádí SBOM.
  • PW.4, znovu používat dobře zabezpečený software. Komponenty třetích stran je třeba prověřit a udržovat aktuální, a právě tam patří analýza softwarového složení.
  • RV.1, průběžně identifikovat zranitelnosti. Jde o trvalou povinnost, ne o bránu před vydáním, takže vyžaduje monitorování toho, co už jste dodali.
  • RV.2, posoudit, určit prioritu a napravit. Viz jak určovat prioritu zranitelností.

Je SSDF povinný?

Sám o sobě ne. Je to publikace NIST, ne zákon. Několik let se přímo týkal federálních dodavatelů v USA, protože memoranda OMB M-22-18 a M-23-16 po nich vyžadovala prohlášení o dodržování praktik z něj odvozených. To se změnilo 23. ledna 2026: memorandum OMB M-26-05 obě zrušilo a přešlo k přístupu založenému na riziku. Úřady mohou dál používat společný formulář prohlášení a normy NIST, ale už nemusí, takže dodavatelé by měli počítat s tím, že se požadavky budou mezi úřady lišit.

Mimo federální zakázky zůstává SSDF užitečný jako společný jazyk. Zákazníci z něj čerpají v bezpečnostních dotaznících a dá se namapovat na další normy.

Verze SSDF

  • Verze 1.1, SP 800-218, vydaná v únoru 2022, je aktuální finální verze.
  • Verze 1.2, SP 800-218 Revision 1, byla zveřejněna jako návrh v prosinci 2025.
  • SP 800-218A je komunitní profil, který rozšiřuje SSDF na generativní AI a základní modely dvojího užití.

Jak SSDF zavést

  1. Zmapujte, co děláte dnes. Projděte praktiky a zaznamenejte, kde je už splňujete a s jakými důkazy.
  2. Seřaďte mezery podle rizika. SSDF počítá s tím, že ho uplatníte podle vlastního rizika, takže ne každá praktika si zaslouží stejnou hloubku.
  3. Automatizujte důkazy. Důkazy, které vznikají v pipeline, zůstávají aktuální bez další práce. Důkazy psané ručně zastarávají.
  4. Určete vlastníky. Každá praktika potřebuje odpovědnou osobu. Většina připadne vývoji, ne bezpečnosti.
  5. Pravidelně revidujte. Aktualizujte mapování, jak se mění vaše nástroje a jak postupuje verze 1.2.

SSDF, SLSA a CRA

SSDF říká, čeho má program bezpečného vývoje dosáhnout. SLSA jde do hloubky u jedné jeho části, integrity buildu. EU Cyber Resilience Act je zákon s vlastními povinnostmi. Práce odvedená pro jeden se přenáší do ostatních, protože všechny očekávají, že víte, co je ve vašem softwaru, a že řešíte jeho zranitelnosti.

Kde pomáhá CRACI

SSDF je široký program a žádný nástroj ho celý nepokryje. CRACI dodává důkazy pro praktiky, které závisejí na buildu a na tom, co bylo dodáno: SBOM z každého jobu GitHub Actions, izolované joby a kontrolu odchozího provozu v prostředí buildu, průběžné monitorování dodaného softwaru a triáž toho, co najde. CRACI vám soulad nezajistí a mapování i prohlášení zůstávají na vás. Viz bezpečnost softwarového dodavatelského řetězce s CRACI.

NIST SSDF: časté dotazy

Co je NIST SSDF?

Secure Software Development Framework, vydaný jako NIST SP 800-218. Je to soubor praktik pro vývoj bezpečného softwaru rozdělený do čtyř skupin: příprava organizace, ochrana softwaru, vývoj dobře zabezpečeného softwaru a reakce na zranitelnosti.

Co znamená zkratka SSDF?

Secure Software Development Framework.

Je SSDF povinný?

Ne. Je to doporučení, ne zákon. Federální dodavatelé v USA dříve museli podávat prohlášení o dodržování jeho praktik, ale memorandum OMB M-26-05 tento požadavek v lednu 2026 zrušilo. Úřady o prohlášení mohou žádat i nadále.

Jaká je nejnovější verze SSDF?

Aktuální finální verzí je verze 1.1 (SP 800-218, únor 2022). Verze 1.2 byla zveřejněna jako návrh v prosinci 2025, její stav proto ověřte na webu NIST.

Jaký je rozdíl mezi SSDF a SLSA?

SSDF pokrývá bezpečný vývoj jako celek, napříč lidmi, procesy a technologiemi. SLSA jde do hloubky u integrity buildu a původu. Dobře se doplňují.

Vyžaduje SSDF SBOM?

Žádá, abyste shromažďovali a sdíleli údaje o původu komponent každého vydání, a jako jeden ze způsobů uvádí SBOM. Popisuje výsledky, nepředepisuje konkrétní nástroj.

Důkazy, které vznikají přímo z buildu

Získejte SBOM a záznamy o zranitelnostech z každého jobu GitHub Actions, aniž byste je psali ručně.

Rezervujte si demo