Nová bezpečnostní priorita CIO: Váš dodavatelský řetězec softwaru

Jedním z důvodů, proč je open source v podnicích populární, je to, že poskytuje dobře otestované stavební bloky, které mohou urychlit vytváření sofistikovaných aplikací a služeb. Ale softwarové komponenty třetích stran a pohodlí balíčků a kontejnerů přinášejí rizika spolu s výhodami, protože aplikace, které vytváříte, jsou jen tak bezpečné jako tyto závislosti. 

Útoky softwarového dodavatelského řetězce jsou tak rozšířené, že je Gartner uvedl jako druhou největší hrozbu pro rok 2022. Výzkumná firma předpovídá, že do roku 2025 zažije 45 % organizací na celém světě jeden nebo více útoků na softwarový dodavatelský řetězec – a 82 % ředitelů IT si myslí, že vůči nim budou zranitelní. Patří mezi ně útoky prostřednictvím zranitelností v široce používaných softwarových komponentách, jako je Log4j, útoky proti build pipeline (srov. hacky SolarWinds, Kaseya a Codecov) nebo hackeři kompromitující samotná úložiště balíčků.

„Útočníci přesunuli prioritu z produkčního prostředí na softwarové dodavatelské řetězce, protože softwarové dodavatelské řetězce jsou nejslabším článkem,“ vysvětluje Lior Levy, generální ředitel společnosti Cycode. „Dokud zůstanou softwarové dodavatelské řetězce relativně snadným cílem, budou útoky na softwarové dodavatelské řetězce přibývat.“

Nedávné významné incidenty byly budíčkem pro průmysl vývoje softwaru, říká Rani Osnat, senior viceprezident pro strategii společnosti Aqua Security. „Odhalili jsme desetiletí neprůhlednosti a nedostatku transparentnosti, a proto je to tak velký problém.“

Studie kódových bází, které používají otevřený zdrojový kód, ukazují, že zranitelnosti a zastaralé nebo opuštěné komponenty jsou běžné: 81 % kódových bází mělo alespoň jednu zranitelnost, 50 % mělo více než jednu vysoce rizikovou zranitelnost a 88 % používalo komponenty, které nebyly nejnovější verzí nebo neměly za dva roky žádný nový vývoj.

Přečtěte si také:

Šestero nejpřeceňovanějších IT technologií

Tyto problémy však pravděpodobně nenaruší popularitu open source – a komerční software a služby jsou také zranitelné. Když byl LastPass napaden, nepřišel o zákaznická data, ale neoprávněná strana mohla zobrazit a stáhnout část jeho zdrojového kódu, což by mohlo v budoucnu usnadnit útok na uživatele správce hesel, a útočníkům umožnilo narušení Twilio zahájit útoky skrze dodavatelský řetězec na navazující organizace.

Hrozba „stínového kódu“

Stejně jako bezpečnostní týmy brání své sítě, jako by již byly narušeny, musí CIO předpokládat, že veškerý kód, interní nebo externí, a dokonce i vývojová prostředí a nástroje, které jejich vývojáři používají, již byla kompromitována a zavést zásady na ochranu před útoky proti jejich softwarovým dodavatelským řetězcům a minimalizaci jejich dopadu.

Ve skutečnosti Osnat navrhuje, aby CIO přemýšleli o tomto „stínovém kódu“ stejně jako o stínovém IT. „Je třeba se na to dívat jako na něco, co není jen bezpečnostní problém, ale skutečně něco, co sahá hluboko do toho, jak získáváte software, ať už je to open source nebo komerční: jak jej zavádíte do svého prostředí, jak jej aktualizujete, jaký druh kontrol, které chcete mít, a jaké kontroly chcete od svých dodavatelů požadovat,“ říká.

Přečtěte si také:

Rekordní Unicorn vykopl nový rok

Transparentnost: Směrem k softwarovému rozpisu materiálů

Fyzické dodavatelské řetězce již používají štítky, seznamy složek, bezpečnostní listy a materiálové rozpisy (kusovníky), takže regulační orgány a spotřebitelé vědí, co v produktech končí. Nové iniciativy mají za cíl aplikovat podobné přístupy k softwaru a pomoci organizacím pochopit síť závislostí a útočnou plochu jejich procesu vývoje softwaru.

Výkonný příkaz Bílého domu 14028 o zabezpečení dodavatelského řetězce softwaru vyžaduje, aby dodavatelé softwaru dodávající federální vládě poskytli kusovník softwaru (SBOM) a použili kontrolní seznam zabezpečení úrovní dodavatelského řetězce pro softwarové artefakty (SLSA), aby se zabránilo neoprávněné manipulaci. 

Z tohoto důvodu „jsme svědky toho, že mnoho podniků se mnohem vážněji dívá na svůj dodavatelský řetězec softwaru,“ říká senior analytička společnosti Forrester Janet Worthingtonová. „Všechny společnosti dnes vyrábějí i spotřebovávají software a vidíme, že stále více výrobců k nám přichází a říká: ‚Jak mohu vyrobit software, který je bezpečný a který mohu potvrdit pomocí kusovníku softwaru‘.“

Přečtěte si také:

Dáváte si předsevzetí? Máme pár tipů z IT pro letošek

Existuje mnoho meziodvětvových projektů, včetně Národní iniciativy NIST pro zlepšení kybernetické bezpečnosti v dodavatelských řetězcích (NIICS), iniciativy Supply Chain Integrity, Transparency, and Trust (SCITT) od společnosti Microsoft a dalších členů IETF, stejně jako pracovní skupina OpenSSF Supply Chain Integrity.

„Všichni zastávají holističtější přístup a říkají, počkejte chvíli, potřebuji vědět, co přináším do svého dodavatelského řetězce, se kterým vytvářím software,“ říká Worthingtonová.

Nedávný průzkum Linux Foundation zjistil, že povědomí o SBOM je vysoké, 47 % dodavatelů IT, poskytovatelů služeb a regulovaných odvětví dnes SBOM používá a 88 % očekává, že je bude používat v roce 2023.

SBOM budou nejužitečnější pro organizace, které již mají správu aktiv pro softwarové komponenty a rozhraní API. „Lidé, kteří dnes mají robustní procesy vývoje softwaru, snáze vkládají nástroje, které mohou generovat softwarový kusovník,“ říká Worthingtonová.

SBOM mohou být vytvořeny systémem sestavení nebo mohou být následně vygenerovány nástroji pro analýzu složení softwaru. Mnoho nástrojů lze integrovat do kanálů CI/CD a spustit jako součást sestavení, nebo dokonce i když stáhnete knihovny, říká. „Může vás varovat: ‚Hej, máte tuto součást ve svém potrubí a má kritický problém, chcete pokračovat?‘“

Aby to bylo užitečné, potřebujete jasné zásady, jak vývojářské týmy získávají software s otevřeným zdrojovým kódem, říká generální ředitel společnosti Chainguard Dan Lorenc. „Jak vývojáři vědí, jaké jsou zásady jejich společnosti pro to, co je považováno za ‚bezpečné‘, a jak vědí, že s otevřeným zdrojovým kódem, který si pořizují, což představuje velkou většinu veškerého softwaru, který dnes vývojáři používají, se skutečně nemanipulovalo?“

Pište pro CIO Business World

Máte dobré nápady, máte co říct? Chcete se podělit o své znalosti se čtenáři CIO BW?

Je tu ideální příležitost. V redakci neustále hledáme externí autory, kteří rozšíří náš záběr. Nabízíme možnost publikací zajímavých článků nejen na webu, ale také v našem tištěném magazínu. Pokud máte zájem, ozvěte se šéfredaktorovi na e-mail: radan.dolejs@iinfo.cz

Poukazuje na open-source projekt Sigstore, který JavaScript, Java, Kubernetes a Python používají k určení původu softwarových balíčků. „Sigstore je pro integritu softwaru něco jako certifikáty pro webové stránky; v podstatě zavádějí systém správy a ověřování důvěry,“ říká.

„Myslím, že CIO by měl začít indoktrinací svých vývojářských týmů v těchto základních krocích používání nově vznikajících standardních přístupů pro za prvé, uzamčení sestavovacích systémů a za druhé, vytvoření opakovatelné metody pro ověření důvěryhodnosti softwarových artefaktů před jejich uvedením do prostředí, “ říká Lorenc.

Vlastní přispění

Ať už jde o komponenty, rozhraní API nebo funkce bez serveru, většina organizací řádově podceňuje to, co používají, pokud neprovádějí rutinní inventury, zdůrazňuje Worthingtonová. „Zjišťují, že některá z těchto rozhraní API nepoužívají správné metody ověřování nebo možná nejsou napsána způsobem, který očekávali, a možná jsou některá z nich dokonce zastaralá,“ říká.

Kromě zranitelností je vyhodnocení podpory komunity za balíčkem stejně důležité jako pochopení toho, co kód dělá, protože ne všichni správci chtějí, aby jejich kód byl považován za kritický zdroj. „Ne všechny open source [produkty] jsou stejné,“ varuje.

„Open source je možná zdarma ke stažení, ale jeho použití rozhodně není zdarma. Použití vámi znamená, že jste odpovědní za pochopení bezpečnostní pozice, která za tím je, protože je ve vašem dodavatelském řetězci. Musíte k tomu přispět zpět. Vaši vývojáři se musí podílet na opravě zranitelností,“ říká Worthingtonová, která navrhuje, aby organizace byly také připraveny přispívat finančně, ať už přímo do projektů s otevřeným zdrojovým kódem, nebo do iniciativ, které je podporují zdroji a finančními prostředky. „Když vytváříte open-source strategii, je její součástí pochopení rozpočtu a důsledků.“

Přečtěte si také:

Sedm způsobů, jak zničit svoji reputaci lídra IT

Neberte to jako pouhý výdaj, ale jako příležitost lépe porozumět komponentám, na kterých jste závislí. „Dokonce to pomáhá udržet si vývojáře, protože se cítí být součástí komunity. Mohou přispět svými dovednostmi. Mohou to použít ve svém životopisu,“ dodává.

Pamatujte, že zranitelnosti lze nalézt kdekoli ve vašem technologickém zásobníku, včetně sálových počítačů, které stále častěji používají Linux a open source jako součást pracovní zátěže, ale často postrádají bezpečnostní procesy a rámce, které se staly běžnými v jiných prostředích.

Ochrana vašeho kanálu

Důležitá je také ochrana vašeho kanálu dodávání softwaru. Secure Software Development Framework (SSDF) a SLSA společnosti NIST jsou dobrým místem, kde začít: Toto pokrývá osvědčené postupy na různých úrovních vyspělosti počínaje jednoduchým systémem sestavení, poté protokoly a metadata pro audit a reakci na incidenty až po plně zabezpečený kanál buildu. Užitečné jsou také dokumenty CNCF Software Supply Chain Best Practices, pokyny společnosti Gartner ke zmírnění rizik zabezpečení dodavatelského řetězce softwaru a rámec Microsoft OSS Secure Supply Chain Framework, který zahrnuje procesy i nástroje.

Je však důležité si uvědomit, že pouhé zapnutí automatických skenovacích nástrojů určených k nalezení škodlivého kódu může produkovat příliš mnoho falešných poplachů, než by bylo užitečné. A přestože systémy pro kontrolu verzí, jako jsou BitBucket, GitHub, GitLab a další, zahrnují funkce zabezpečení a ochrany přístupu (včetně stále podrobnějšího řízení přístupových zásad, ochrany větvení, podepisování kódu, vyžadování MFA pro všechny přispěvatele a skenování tajemství a přihlašovacích údajů), často musejí být výslovně povoleny.

Ani projekty, jako je Factory for Repeatable Secure Creation of Artifacts (FRSCA), které mají za cíl zabezpečit sestavovací kanály implementací SLSA v jediném stacku, ještě nejsou připraveny k produkci, ale CIO by měli očekávat, že systémy buildů budou v budoucnu zahrnovat více těchto postupů.

I když jsou SBOM pouze částí odpovědi, nástroje k jejich vytváření a práci s nimi stále dozrávají, stejně jako procesy pro jejich vyžádání a použití. Ve smlouvách musí být uvedeno nejen to, že chcete SBOM, ale jak často očekáváte, že budou aktualizovány a zda budou obsahovat zprávy o zranitelnosti a upozornění, radí Worthingtonová. „Pokud se najde nová důležitá zranitelnost, jako je Log4j, řekne mi to prodejce, nebo budu muset sám hledat v SBOM, abych zjistil, jestli jsem ovlivněn?“

Organizace budou také potřebovat nástroje pro čtení SBOM a zavádění procesů, aby mohly podniknout kroky k tomu, co tyto nástroje najdou. „Potřebuji nástroj, který mi řekne, jaké jsou známé zranitelnosti [v SBOM], jaké jsou důsledky pro licence a zda se to děje nepřetržitě,“ říká Worthingtonová.

Ředitelé IT by měli mít na paměti, že SBOM „je aktivátor, ale ve skutečnosti nic neřeší, pokud jde o zabezpečení vašeho dodavatelského řetězce. Pomáhá vám vypořádat se s incidenty, které se vám mohou cestou stát,“ říká Osnat, který je optimistický, pokud jde o rychlost reakce odvětví i širokou spolupráci, která probíhá kolem standardů pro SBOM a atestace kódu, což pomůže zajistit interoperabilitu nástrojů (což organizace vyzvedly jako zvláštní zájem ve výzkumu Linux Foundation). To by mohlo vést ke stejným zlepšením standardů transparentnosti a podávání zpráv v celém odvětví, jaké přinesl SOC 2.

To znamená, že CIO nemusí čekat na nové standardy nebo nástroje, aby se zabezpečení stalo součástí vývojářské role stejně jako se jí v posledních letech stala kvalita, říká Osnat. Jeho návrh: „Začněte tím, že si pozvete svého CISO a hlavního inženýra, abyste zjistili, jaký je správný model, aby to fungovalo pro vaši organizaci, a jak k této transformaci dojde.“