Vlastní kód je jen část toho, co se nakonec nasadí do produkce. Další část tvoří open-source knihovny, frameworky, kontejnerové obrazy a nástroje pro sestavení. Každá z těchto součástí může obsahovat zranitelnost nebo se stát cestou útoku. Kdo neví, z čeho se jeho software skládá, těžko na takové riziko reaguje.
Přímé a tranzitivní závislosti
Přímé závislosti jsou knihovny, které váš tým vědomě přidal do projektu. Tranzitivní závislosti si do projektu přinesly ony samy. Jedna přímá knihovna může stáhnout řadu dalších balíčků, o kterých v týmu nikdo nerozhodoval.
Právě tranzitivní závislosti bývají slabým místem. Nejsou vidět v hlavním konfiguračním souboru projektu a jejich aktualizace závisí na tom, jak rychle reagují autoři přímých knihoven. Když se objeví zranitelnost v hluboko zanořeném balíčku, první otázka zní: používáme ho vůbec, a pokud ano, kde?
Nástroje pro správu balíčků obvykle umějí strom závislostí vypsat. Vyplatí se to jednou udělat a podívat se, co všechno projekt ve skutečnosti obsahuje. Bez průběžné evidence se ale na uvedenou otázku nedá rychle odpovědět.
SBOM jako soupis složek
SBOM (Software Bill of Materials) je strojově čitelný soupis komponent, ze kterých se software skládá. Americká agentura CISA ho na své stránce o SBOM přirovnává k seznamu ingrediencí. Obsahuje názvy komponent, jejich verze, dodavatele, vzájemné vztahy a často i licence.
Používají se hlavně dva otevřené formáty:
- CycloneDX, standard spravovaný OWASP a Ecma International, vydaný jako ECMA-424.
- SPDX, otevřený standard vydaný také jako mezinárodní norma ISO/IEC 5962:2021.
Oba formáty podporuje řada nástrojů pro sestavení i analýzu. Volba mezi nimi je méně důležitá než to, aby SBOM vznikal automaticky při každém sestavení a odpovídal skutečně nasazené verzi. Ručně udržovaný seznam rychle zastará. U kontejnerových obrazů platí totéž: základní obraz obsahuje balíčky operačního systému, které také potřebují evidenci a aktualizace.
SBOM se hodí i ve vztahu k zákazníkům, z nichž někteří ho požadují při výběru dodavatele. Pro výrobce produktů s digitálními prvky na trhu EU navíc nařízení o kybernetické odolnosti (EU) 2024/2847 mimo jiné požaduje SBOM pokrývající alespoň závislosti nejvyšší úrovně. Hlavní povinnosti se podle Evropské komise uplatní od 11. prosince 2027. Zda a jak se nařízení týká právě vašeho produktu, je potřeba posoudit podle jeho textu.
SCA: průběžná kontrola, ne jednorázový sken
SCA (Software Composition Analysis) porovnává komponenty v projektu s databázemi známých zranitelností a licencí. Nástroje mohou pracovat se zdrojovým kódem, se sestaveným artefaktem nebo přímo se SBOM. Například open-source platforma OWASP Dependency-Track umí SBOM průběžně vyhodnocovat a upozornit na nově zveřejněné zranitelnosti.
Výstup SCA ale není hotový seznam úkolů. Zranitelnost v knihovně nemusí být ve vaší aplikaci zneužitelná, pokud se dotčená funkce nevolá nebo není dostupná zvenku. Naopak nenápadný nález může být vážný, pokud se týká komponenty, která zpracovává vstupy od uživatelů. Výsledky je proto potřeba posoudit v kontextu, podobně jako nálezy z penetračního testu.
V praxi pomáhá:
- spouštět kontrolu při každém sestavení a blokovat jen jasně definované případy,
- sledovat nově zveřejněné zranitelnosti i u verzí, které už běží v produkci,
- řadit nálezy podle závažnosti a dosažitelnosti, aby tým nezahltily,
- zapisovat, proč byl konkrétní nález vyhodnocen jako nezneužitelný.
Pravidla pro aktualizace a nové balíčky
Bez pravidel se závislosti aktualizují nárazově, obvykle až při problému. Pomůže několik jednoduchých zásad:
- Pro bezpečnostní opravy kritických komponent si stanovte lhůtu podle vlastního rizika a dodržujte ji.
- Běžné aktualizace provádějte pravidelně, například v každém sprintu nebo jednou měsíčně.
- Zamykejte konkrétní verze pomocí lock souborů, aby se sestavení dalo zopakovat.
- Sledujte komponenty, které už nikdo neudržuje, a plánujte jejich náhradu.
Pozornost si zaslouží i výběr nových balíčků. Útočníci zneužívají například typosquatting, tedy balíčky s názvem, který se od oblíbené knihovny liší třeba jen jedním znakem. Dalším rizikem je převzetí opuštěného balíčku nebo kompromitace účtu jeho autora. Před přidáním nové závislosti ověřte přesný název, správce, historii vydání a aktivitu projektu. Zvažte také, zda knihovnu opravdu potřebujete. Pomoci může interní registr nebo proxy balíčků s povolenými zdroji.
Nezapomeňte ani na samotnou cestu sestavení. Přístupové tokeny k registrům balíčků a k systému CI by měly mít jen nezbytná oprávnění. Změny v konfiguraci sestavení by měly procházet stejnou kontrolou jako změny v kódu.
Kontrolní seznam pro vývojový tým
- SBOM vzniká automaticky při každém sestavení ve formátu CycloneDX nebo SPDX.
- Ke každé nasazené verzi umíte dohledat její SBOM.
- SCA kontroluje přímé i tranzitivní závislosti.
- Nové zranitelnosti sledujete i u verzí, které už běží.
- Výsledky SCA někdo posuzuje v kontextu a rozhodnutí zapisuje.
- Pro bezpečnostní aktualizace máte dohodnuté lhůty.
- Verze závislostí jsou zamčené a sestavení je opakovatelné.
- Nové balíčky procházejí krátkou kontrolou názvu, správce a aktivity.
- Víte, které komponenty už nejsou udržované.
Pokud chcete ověřit, jak dobře máte závislosti a cestu sestavení pod kontrolou, můžeme je zahrnout do bezpečnostní analýzy software spolu s architekturou a kódem. Cíl a rozsah si nejdřív ujasníme. Prvním krokem může být krátká konzultace.
