Bezpečnosť softvéru nie je jednorazová úloha, ale neustály proces, pretože útočníci aj ich techniky sa vyvíjajú. Mimoriadne dôležitou časťou je ochrana dodávateľského reťazca softvéru — od kódu až po produkciu. Prednáška ukázala, prečo sa riziká často skrývajú v závislostiach a ako ich dostať pod kontrolu.
Čo ukázal incident s knižnicou Mat JS
Programátori pri práci bežne siahajú po otvorených knižniciach, ktoré urýchľujú vývoj. V prípade knižnice Mat JS vznikol klon, ktorý ponúkal “minimalizovanú” verziu, no do funkcie odmocniny vložil kód na odosielanie prihlasovacích údajov do služby Discord. Takéto škodlivé úpravy bývajú schované v obfuskovanom kóde a na prvý pohľad pôsobia nevinne. Ide o pripomienku, že útoky sa môžu tváriť ako bežné optimalizácie.
Riziko znásobuje popularita knižníc a ich prepojenia: Mat JS zaznamenával státisíce stiahnutí týždenne a tisíce ďalších balíkov na ňom záviseli. Keď sa zraniteľnosť objaví v takomto uzle, má potenciál zasiahnuť veľkú časť ekosystému. Útočníci rátajú s tým, že vývojári dôverujú známym názvom a automatizovaným aktualizáciám. Preto treba pozerať nielen na to, čo používame, ale aj odkiaľ to pochádza a ako to vzniklo.
Tranzitívne závislosti: slepé miesto reťazca
Priame závislosti si tímy zvyčajne strážia, no práve tranzitívne závislosti — tie, ktoré si prinášajú ďalšie balíky — tvoria ťažko viditeľnú časť rizika. Podľa skúseností z praxe až väčšina zraniteľností v projektoch pramení práve z nich. Audity sú náročné, pretože počet takýchto komponentov rýchlo rastie a mení sa s každou aktualizáciou. Vzniká dojem, že kontrolujeme iba špičku ľadovca.
V prostredí verejnej správy sa k tomu pridáva závislosť na externých dodávateľoch, ktorých interné bezpečnostné procesy sú pre odberateľa “čiernou skrinkou”. Ak dodávateľ používa zastarané systémy alebo zraniteľné knižnice, riziko sa prenesie až k inštitúcii. V takomto reťazci sa slabé miesta šíria naprieč fázami vývoja aj medzi organizáciami. Preto nestačí chrániť iba vlastné úseky, ale aj nároky klásť na celý reťazec.
Ako sa brániť: od “shift left” po SLSA, SBOM a provenance
Princíp “shift left security” znamená posun kontroly bezpečnosti čo najskôr do procesu: od písania kódu, cez zostavenie a nasadzovanie, až po monitoring produkcie. Čím neskôr zraniteľnosť odhalíme, tým drahšie a rizikovejšie je jej riešenie. Pomáhajú štandardy, napríklad SLSA, ktoré definujú úrovne zabezpečenia dodávateľského reťazca a odporúčané postupy. K ich praktickej realizácii slúžia otvorené nástroje, napríklad zo spoločenstva okolo Sigstore.
Konkrétnym základom je SBOM (zoznam softvérových komponentov) a “provenance” (pôvod a spôsob vzniku artefaktu). SBOM hovorí, čo presne softvér obsahuje; provenance opisuje, kde, kedy a akým procesom bol vyrobený. Ak organizácia vyžaduje tieto metadáta pri vstupe dodávky a automaticky ich overuje, vie nevyhovujúci softvér zastaviť ešte pred nasadením — prax známa už aj z niektorých štátov. Keďže útoky na softvérový reťazec rastú a odhady hovoria o zasiahnutí veľkej časti organizácií do roku 2025, systematická kontrola od začiatku vývoja prestáva byť voľbou a stáva sa nutnosťou.
