Vlastný kód je len časť toho, čo sa nakoniec nasadí do produkcie. Ďalšiu časť tvoria open-source knižnice, frameworky, kontajnerové obrazy a nástroje na zostavenie. Každá z týchto súčastí môže obsahovať zraniteľnosť alebo sa stať cestou útoku. Kto nevie, z čoho sa jeho softvér skladá, len ťažko na také riziko reaguje.
Priame a tranzitívne závislosti
Priame závislosti sú knižnice, ktoré váš tím vedome pridal do projektu. Tranzitívne závislosti si do projektu priniesli ony samy. Jedna priama knižnica môže stiahnuť rad ďalších balíkov, o ktorých v tíme nikto nerozhodoval.
Práve tranzitívne závislosti bývajú slabým miestom. Nie sú viditeľné v hlavnom konfiguračnom súbore projektu a ich aktualizácia závisí od toho, ako rýchlo reagujú autori priamych knižníc. Keď sa objaví zraniteľnosť v hlboko vnorenom balíku, prvá otázka znie: používame ho vôbec, a ak áno, kde?
Nástroje na správu balíkov zvyčajne dokážu strom závislostí vypísať. Oplatí sa to raz urobiť a pozrieť sa, čo všetko projekt v skutočnosti obsahuje. Bez priebežnej evidencie sa však na uvedenú otázku nedá rýchlo odpovedať.
SBOM ako súpis zložiek
SBOM (Software Bill of Materials) je strojovo čitateľný súpis komponentov, z ktorých sa softvér skladá. Americká agentúra CISA ho na svojej stránke o SBOM prirovnáva k zoznamu ingrediencií. Obsahuje názvy komponentov, ich verzie, dodávateľov, vzájomné vzťahy a často aj licencie.
Používajú sa najmä dva otvorené formáty:
- CycloneDX, štandard spravovaný OWASP a Ecma International, vydaný ako ECMA-424.
- SPDX, otvorený štandard vydaný aj ako medzinárodná norma ISO/IEC 5962:2021.
Oba formáty podporuje rad nástrojov na zostavenie aj analýzu. Voľba medzi nimi je menej dôležitá ako to, aby SBOM vznikal automaticky pri každom zostavení a zodpovedal skutočne nasadenej verzii. Ručne udržiavaný zoznam rýchlo zastará. Pri kontajnerových obrazoch platí to isté: základný obraz obsahuje balíky operačného systému, ktoré tiež potrebujú evidenciu a aktualizácie.
SBOM sa hodí aj vo vzťahu k zákazníkom, z ktorých niektorí ho požadujú pri výbere dodávateľa. Pre výrobcov produktov s digitálnymi prvkami na trhu EÚ navyše nariadenie o kybernetickej odolnosti (EÚ) 2024/2847 okrem iného vyžaduje SBOM pokrývajúci aspoň závislosti najvyššej úrovne. Hlavné povinnosti sa podľa Európskej komisie uplatnia od 11. decembra 2027. Či a ako sa nariadenie týka práve vášho produktu, treba posúdiť podľa jeho textu.
SCA: priebežná kontrola, nie jednorazový sken
SCA (Software Composition Analysis) porovnáva komponenty v projekte s databázami známych zraniteľností a licencií. Nástroje môžu pracovať so zdrojovým kódom, so zostaveným artefaktom alebo priamo so SBOM. Napríklad open-source platforma OWASP Dependency-Track dokáže SBOM priebežne vyhodnocovať a upozorniť na novo zverejnené zraniteľnosti.
Výstup SCA však nie je hotový zoznam úloh. Zraniteľnosť v knižnici nemusí byť vo vašej aplikácii zneužiteľná, ak sa dotknutá funkcia nevolá alebo nie je dostupná zvonka. Naopak nenápadné zistenie môže byť vážne, ak sa týka komponentu, ktorý spracúva vstupy od používateľov. Výsledky preto treba posúdiť v kontexte, podobne ako zistenia z penetračného testu.
V praxi pomáha:
- spúšťať kontrolu pri každom zostavení a blokovať len jasne definované prípady,
- sledovať novo zverejnené zraniteľnosti aj pri verziách, ktoré už bežia v produkcii,
- radiť zistenia podľa závažnosti a dosiahnuteľnosti, aby tím nezahltili,
- zapisovať, prečo bolo konkrétne zistenie vyhodnotené ako nezneužiteľné.
Pravidlá pre aktualizácie a nové balíky
Bez pravidiel sa závislosti aktualizujú nárazovo, zvyčajne až pri probléme. Pomôže niekoľko jednoduchých zásad:
- Pre bezpečnostné opravy kritických komponentov si stanovte lehotu podľa vlastného rizika a dodržiavajte ju.
- Bežné aktualizácie robte pravidelne, napríklad v každom šprinte alebo raz mesačne.
- Zamykajte konkrétne verzie pomocou lock súborov, aby sa zostavenie dalo zopakovať.
- Sledujte komponenty, ktoré už nikto neudržiava, a plánujte ich náhradu.
Pozornosť si zaslúži aj výber nových balíkov. Útočníci zneužívajú napríklad typosquatting, teda balíky s názvom, ktorý sa od obľúbenej knižnice líši napríklad len jedným znakom. Ďalším rizikom je prevzatie opusteného balíka alebo kompromitácia účtu jeho autora. Pred pridaním novej závislosti overte presný názov, správcu, históriu vydaní a aktivitu projektu. Zvážte tiež, či knižnicu naozaj potrebujete. Pomôcť môže interný register alebo proxy balíkov s povolenými zdrojmi.
Nezabudnite ani na samotnú cestu zostavenia. Prístupové tokeny k registrom balíkov a k systému CI by mali mať len nevyhnutné oprávnenia. Zmeny v konfigurácii zostavenia by mali prechádzať rovnakou kontrolou ako zmeny v kóde.
Kontrolný zoznam pre vývojový tím
- SBOM vzniká automaticky pri každom zostavení vo formáte CycloneDX alebo SPDX.
- Ku každej nasadenej verzii dokážete dohľadať jej SBOM.
- SCA kontroluje priame aj tranzitívne závislosti.
- Nové zraniteľnosti sledujete aj pri verziách, ktoré už bežia.
- Výsledky SCA niekto posudzuje v kontexte a rozhodnutia zapisuje.
- Pre bezpečnostné aktualizácie máte dohodnuté lehoty.
- Verzie závislostí sú zamknuté a zostavenie je opakovateľné.
- Nové balíky prechádzajú krátkou kontrolou názvu, správcu a aktivity.
- Viete, ktoré komponenty už nie sú udržiavané.
Ak chcete overiť, ako dobre máte závislosti a cestu zostavenia pod kontrolou, môžeme ich zahrnúť do bezpečnostnej analýzy softvéru spolu s architektúrou a kódom. Cieľ a rozsah si najprv ujasníme. Ako prvý krok si môžete dohodnúť krátku konzultáciu.
