SLSA (vyslovuj salsa) neboli Supply chain Levels for Software Architects je sada bezpečnostních doporučení a standardů, které slouží ke zvýšení vnitřní bezpečnosti při vývoji software. Jejich dodržování má zabránit zejména tzv. útoku na dodavatelský řetězec (supply chain attack).
Problém
Jak se váš software postupně stává složitějším, stává se složitějším i proces jeho vývoje a tím pádem odhaluje více míst, kterých mohou útočníci využít:
- A – Kód, který neprošel revizí (princip čtyř očí)
- B – Repozitář se zdrojovým kódem byl narušen
- C – Zdrojový kód byl změněn po nahrání z repozitáře
- D – Systém pro sestavení byl narušen
- E – Použila se vadná závislost
- F – Byl vynechán systém pro průběžnou integraci (CI/CD)
- G – Repozitář s balíčky byl narušen
- H – Použil se vadný balíček
SLSA pojmenovává úrovně zajištění, které určují různý stupeň odolnosti proti případným útokům. Úrovní je záměrně několik s vědomím, že žádná ochrana není dokonalá a každá firma si musí sama rozhodnout, kam až chce zajít a kolik do prevence investovat.
Úroveň 1 – dokumentace procesu sestavení
Tato úroveň je poměrně jednoduchá. Vyžaduje automatizovaný proces sestavení, což je stejně jedním z rozumných principů vývoje software a vytvoření metadat o jeho průběhu. Např. napíšete build skript, který kromě binární podoby vašeho produktu vytvoří i textový soubor s časovým razítkem a IP adresou stroje, kde běžel.
Úroveň 2 – odolnost vůči napadení procesu sestavení
Tato úroveň vyžaduje použití repozitáře se zdrojovým kódem, software musí být sestaven na vyhrazeném počítači (nikoli na náhodném počítači programátora) a metadata, která dokáže vytvořit pouze autentikovaná služba. V praxi může jít třeba o podpis binárního balíku privátním klíčem, ke kterém má přístup jenom server.
Úroveň 3 – odolnost vůči konkrétním druhům útoků
Na této úrovni je zabezpečena odolnost proti některým konkrétním známým druhům útoků. Celý proces musí být auditovatelný pro případné vyšetřování, což vyžaduje např. uchovávat podobu historie zdrojového kódu po dobu nejméně 18 měsíců, skripty pro sestavení musí být také verzované (build as a code) a musí běžet na krátkodobém prostředí (typicky kontejner nebo virtuální stroj, který se vytvoří a spustí pouze po dobu sestavení a po jeho dokončení se zničí. Útočník má tedy velmi krátký čas na to, aby do procesu sestavení pronikl. Metadata musí být také nezfalšovatelná, např. privátní klíč musí být uložen v bezpečném úložišti.
Úroveň 4 – nejvyšší úroveň důvěry
Poslední úroveň jde ještě dál. Vyžaduje např. takzvané hermetické buildy – neboli sestavení musí běžet na stroji, který nemá přístup nikam jinam, než do přesně definovaných bezpečných úložišť. Každá část procesu sestavení musí být schválena dvěma lidmi, což snižuje riziko zneužití. Jako součást metadat systém vygeneruje informace o všech závislostech, které byly použity, včetně verzí knihoven třetích stran. K počítači, na kterém sestavení běží, má přístup jen velmi omezená množina prověřených osob.
Závěr
Na standardu SLSA spolupracuje řada velkých firem jako např. Intel, Google, VMWare apod. Projekt se intenzivně rozvíjí, v současné době je specifikace ve verzi 0.1.
Pokud si myslíte, že vaše firma se může stát obětí bezpečnostního útoku při vývoji software, tak SLSA je doporučení právě pro vás. Pokud si to nemyslíte, tak se zamyslete ještě jednou.
Pokud se vám článek líbil, sledujte mě na LinkedIn nebo Twitter.
